The State of Wisconsin has a history of mishandling data breaches, this time by the University of Wisconsin System. Last Thursday evening UW-Madison disclosed that a campus database containing Social Security numbers of 60,000 former students and staff had been repeatedly hacked or accessed since 2008. A University Website and the letter sent to victims of the breach assert there is no evidence that anyone's information was retrieved. The statement implies there is no risk of ID theft although all the University releases were careful not to use the words "identity theft" in any of the text.
The State of Wisconsin bungled major data breaches in 2007 and again in 2008 involving Social Security numbers. The 2007 incident involved 171,000 Wisconsin taxpayers who were mailed tax forms with their Social Security Number printed on the mailing label. In 2008, 260,000 recipients of state health care benefits were mailed a brochure with their Social Security number printed on the mailing label. The management of both breaches was bungled by prematurely announcing that the mail, which had not been delivered to recipients, contained Social Security numbers. The premature press releases exacerbated the breach by putting identity thieves on notice to steal the mail. In both cases, the State provided credit-monitoring services to the victims upon request.
Now, the University of Wisconsin is denying victims credit monitoring services because the University contends that they have no evidence that Social Security numbers were retrieved by the hackers. Critics argue that conversely, the University has no evidence that Social Security numbers were not retrieved over the two-year period by hackers. To add to the mishandling of their public relations, the University has declined to comment on camera.
Although the University of Wisconsin determined that the recent hacking incident began in 2008, they did not detect the breach until October 26, 2010. The database contained 60,000 pre-2008 university photo identifications that included Social Security numbers. They notified victims by mail in a letter dated November 30. This author first noticed the release on the evening of December 9 on Madison.com although the date stamp on that article now shows December 10.
This author also has an early University faculty/staff picture identification card last validated in December 1993. I have not received a letter either because my ID card information was not included in breached files or because the University does not have my current mailing address. The limited information provided on the University's Incident Website makes it impossible for would-be victims like me to know if my picture ID contain my Social Security number was part of the breach.
The University appears to be downplaying the significance and threat of the breach to the public. They are also being cautious in their statements and have declined on camera interviews. It is not easy to find the letter they sent to victims or the incident Website through online searches or through the University Website. Information is difficult to find unless you know where to look for it. It is not consumer friendly.
The incident Website states, "We wanted to make you aware of the incident and let you know what we have done to prevent this from happening in the future." The statement on the Website and letter make it appear that the University is voluntarily providing notification to victims. However, under law, the University is required to notify victims of the breach.
Breach notification laws have been enacted by Wisconsin and 45 other states, the District of Columbia, Puerto Rico and the Virgin Islands. These laws require notification of victims if a breach occurs that involves residents of their state or territory. Each of the 49 laws differs in compliance requirements and penalties for noncompliance. It is likely that the 60,000 victims of the recent UW breach reside in many, if not all, of the 49 U.S. jurisdictions that have a breach notification law. The University is required to comply with the laws of each state or territory in which a victim of the breach currently resides.
It is not clear that the University met the compliance requirements for each breach notification law. For example, while the Wisconsin law requires notification of victims within 45 days of learning of a breach, the Illinois law requires notification in the "Most expedient time possible without unreasonable delay." Some states exempt notification of victims if the electronic information accessed was encrypted.
It is standard procedure to encrypt sensitive information that is stored electronically regardless if it is facing the internet, secured behind a firewall, or offline. Encryption software is inexpensive and commonplace even on home and business computer systems. For example, Microsoft Vista and Windows 7 operating systems have turnkey solutions for data encryption--bitlocker. It is a reasonable consumer expectation that a leading research university, such as the University of Wisconsin-Madison would have standard security practices in place to protect sensitive student, staff and faculty information through encryption and other commonly available security measures.
The Family Educational Rights and Privacy Act (FERPA) requires educational institutions to protect student information including Social Security numbers. Penalties for violation include the loss of federal funds.
Amendments to FERPA published in December 2008 recommend that educational institutions adopt standard security practices to protect electronic information. The FERPA refers to several National Institute of Standards and Technology (NIST) Information Security Standards.
For example, an excerpt from NIST Special Publication 800-53 says, "The use of encryption by the organization reduces the probability of unauthorized disclosure of information and can also detect unauthorized changes to information."
It appears that the University of Wisconsin has not adopted the FERPA recommendations on information security standards.
This is not the first time UW-Madison computers were hacked. A year ago, the University determined that computers in the Chemistry Department were hacked over a several year period potentially compromising the names and Social Security numbers of nearly 3,000 people on campus.
A leading study on data breaches published in 2009 that we authored included the following findings:
Education-related organizations account for nearly one-third of all the data breach incidents reported in the U.S.
Colleges and universities account for 78% of all education-related breach incidents.
Over a third of all educational sector data breaches occur by hacking.
Encryption would have prevented 60% of all data breaches and the compromise of over 90% of all consumer profiles.
The University Incident Website provides limited information to victims, avoids addressing identity theft and denies victims of complimentary credit monitoring services. University statements emphasize that there is no evidence that information was taken, however, they provide no assurance that information was not retrieved manually, photographically or by other means transparent to their admittedly weak information systems security.
Victims that are concerned about identity theft should take preventive measures immediately. Victims of identity theft often do not see clues of identity theft until over a year after thieves misuse their information.
While financial fraud is easily detected by credit monitoring, other types of identity theft such as medical identity theft, employment fraud, Social Security and benefits fraud can take years to detect. Then it can take years for victims to restore their good name after spending hundreds of hours and thousands of dollars.
Today, anyone with a computer, desktop publishing and a printer can counterfeit a Social Security card with your name and Social Security number. Counterfeit cards can be sold over and over again compounding the identity theft problem with victims. A counterfeit Social security card and a counterfeit birth certificate opens the door to getting employment, a driver's license and a bank account.
Victims of the UW breach can request that an initial 90-day fraud alert be placed on all three credit reports by contacting any one of the three major credit reporting agencies, Equifax, Experian or TransUnion, listed below. The credit reporting agencies will also provide a credit report as part of the process.
Equifax (800-525-6285) - online or phone for placing fraud alert
Experian (888-397-3742) - online or phone for placing fraud alert
TransUnion (800-680-7289) - online or phone for placing fraud alert
Consumers may also obtain a free credit report from each of the three credit reporting agencies annually. We recommend that consumers stagger their requests for credit reports from each of the three credit reporting agencies by four months in order to increase the frequency of credit report monitoring. This is no substitute for a credit monitoring service, which continuously monitors all three reports. The Federal Trade Commission Website given below also provides high quality information to consumers and victims about preventing, detecting and reporting identity theft.
AnnualCreditReport.com Online or 1-877-322-8228
Federal Trade Commission--Identity theft site
Consumers that see value in more comprehensive identity theft risk mitigation services should consider purchasing such services on their own, regardless if they have been a victim of a breach or not. We have recommended high-value services in other articles.
As a service to the Madison Community, we are providing free telephone consultations to victims of the University of Wisconsin data breach. We will provide answers to questions about identity theft, a free informational guide on how to protect you against identity theft, and recommendations on high-value identity theft risk mitigation services for consumers. We can be contacted by email or by telephone (608-241-3500).
Sunday, December 12, 2010
Discover Account Security Review
With the recent news that the hacking group Anonymous will launch attacks against Visa, Mastercard, and PayPal, I have decided to do my security review on Discover. I currently have a Discover credit card and frequently use discover.com. Although we have learned that credit cards may not carry as big of a risk as debit cards, any type of business that holds records of user's names, addresses, phone numbers, social security #'s, and bank account numbers are susceptible to attacks from hackers. Discover offers the option to control your account online. Users can manage their account, make payments, withdraw cash, and view their statements on the Discover website.
As an owner of a Discover Credit Card and user of the online "Account Center", I have a few worries about the security that Discover uses.The CIA triad is extremely important to protect Discover users. I think that is absolutely imperative that user's account information, including name, birth date, address, user name, and password, are kept confidential. In addition to the fear of identify theft, I believe it a must that credit card number, expiration date, and validation code stay private (only available to the user). Integrity is also important. Discover has to make sure that when a user makes a payment or changes their account in any sort of way, the user's changes are not compromised by a hacker. Additionally, it is important the card holder's username and password are never changed by hackers. Finally, availability may be the most important aspect. As a user, I expect that I will always be able to access my account over the internet as well as always be able to use my card.
If I were a hacker, I would view Discover as a source for a lot of information. First, user information is valuable in today's day and age. Disclosing account holders' names and other personal information could be profitable if other businesses would pay for the information. But the obvious goal of a hacker would be to disclose the card information and bank account information (common on users' account center because it is a common method of payment) in order to use the accounts for themselves. With a similar goal in mind, a hacker may try to alter users' information and change it to their own. This way they would have access to a card that could potentially have their own name attached to it. As we have learned from this course, hacking isn't always about personal gain. Hackers could overload the discover online site to deny access to users, simply to be a pain (or potentially as a distraction for another attack).
Although these threats arise when running a sensitive business, I believe that Discover has done a great job of implementing security measures to mitigate attacks. Users must have a user name, password, and answer to a security question to access their account. Additionally, when a user logs in, the site prompts them with the question "Is this a Shared Computer?" -- a precaution against leaving your account up on a public computer. As soon as you get to your account center, you see that the web site is secure. Clicking on the lock in the top corner of my browser, I have learned that Discover is protected with a 112 bit 3DES encryption. It carries a Verisign Class 3 Extended Validation.
A potential threat is in the "Cash Now" section of the web site, because a hacker's goal would most likely be money. But this section requires another security measure, both the expiration date and validation code on the credit card. Finally, the last security measure I noticed was the automatic logoff. After 5 minutes of inactivity the website automatically logs the user out.
I think that the security is very good on the Discover online Account Center, but the only thing that worries me is all of the access controls are "something you know". I would recommend adding another access control - either "what you are" or "something you have". I think that a card scanner (possibly in the future) on computers would allow users to log on to their account with two access controls. A different option would be to implement the finger print scanners that are already on some laptops. If Discover somehow required you to scan your index finger to log on, it would make it even more difficult for hackers to access your account.
As an owner of a Discover Credit Card and user of the online "Account Center", I have a few worries about the security that Discover uses.The CIA triad is extremely important to protect Discover users. I think that is absolutely imperative that user's account information, including name, birth date, address, user name, and password, are kept confidential. In addition to the fear of identify theft, I believe it a must that credit card number, expiration date, and validation code stay private (only available to the user). Integrity is also important. Discover has to make sure that when a user makes a payment or changes their account in any sort of way, the user's changes are not compromised by a hacker. Additionally, it is important the card holder's username and password are never changed by hackers. Finally, availability may be the most important aspect. As a user, I expect that I will always be able to access my account over the internet as well as always be able to use my card.
If I were a hacker, I would view Discover as a source for a lot of information. First, user information is valuable in today's day and age. Disclosing account holders' names and other personal information could be profitable if other businesses would pay for the information. But the obvious goal of a hacker would be to disclose the card information and bank account information (common on users' account center because it is a common method of payment) in order to use the accounts for themselves. With a similar goal in mind, a hacker may try to alter users' information and change it to their own. This way they would have access to a card that could potentially have their own name attached to it. As we have learned from this course, hacking isn't always about personal gain. Hackers could overload the discover online site to deny access to users, simply to be a pain (or potentially as a distraction for another attack).
Although these threats arise when running a sensitive business, I believe that Discover has done a great job of implementing security measures to mitigate attacks. Users must have a user name, password, and answer to a security question to access their account. Additionally, when a user logs in, the site prompts them with the question "Is this a Shared Computer?" -- a precaution against leaving your account up on a public computer. As soon as you get to your account center, you see that the web site is secure. Clicking on the lock in the top corner of my browser, I have learned that Discover is protected with a 112 bit 3DES encryption. It carries a Verisign Class 3 Extended Validation.
A potential threat is in the "Cash Now" section of the web site, because a hacker's goal would most likely be money. But this section requires another security measure, both the expiration date and validation code on the credit card. Finally, the last security measure I noticed was the automatic logoff. After 5 minutes of inactivity the website automatically logs the user out.
I think that the security is very good on the Discover online Account Center, but the only thing that worries me is all of the access controls are "something you know". I would recommend adding another access control - either "what you are" or "something you have". I think that a card scanner (possibly in the future) on computers would allow users to log on to their account with two access controls. A different option would be to implement the finger print scanners that are already on some laptops. If Discover somehow required you to scan your index finger to log on, it would make it even more difficult for hackers to access your account.
Two Major Ad Networks Found Serving Malicious Ads
Two major online ad networks, DoubleClick and MSN, were found to be serving malware over the past week. Experts say that this is a result of a group of attackers who tricked the two networks by pretending to be ad providers.
The attackers registered the domain name ADShufffle.com, one letter off from ADShuffle.com, which is an online advertising group, to trick the two ad networks into accepting the ads they had infected with malware. If a user visited a website that was displaying the infected ads, a malicious javascript code in the ad started a drive-by download process which installed malware like "HDD Plus" onto the users machine. Simply visiting the page (not clicking on an ad), infected the visitor.
Some big sites infected by the attack were MSN Real Estate, MSNBC.com, and Windows Live Mail.
A spokesman for Google (owners of DoubleClick), said that the ads only ran for a short amount of time, and that DoubleClick's malware filters picked up on the ads as well.
Incidents like this show the danger of browsing through the internet without any protection. Even without directly interacting with elements on a webpage, this event shows how malicious code can run simply by visiting a webpage. This highlights the importance of using script or ad blockers on website, as they can prevent covert attacks like this from installing malware on a computer.
Incidents like this show the danger of browsing through the internet without any protection. Even without directly interacting with elements on a webpage, this event shows how malicious code can run simply by visiting a webpage. This highlights the importance of using script or ad blockers on website, as they can prevent covert attacks like this from installing malware on a computer.
Thursday, December 9, 2010
Security Review on Cross-site scripting (XSS)
Cross-site scripting (XSS) is a security vulnerability in web applications which allows client side scripts to be injected into web pages to attack users who view these web pages (similar to SQL injections in my last blog post). Recently, XSS attacks have surpassed buffer overflow attacks to become the most popular security vulnerability. Over 80% of all website attacks on the internet are XSS exploits and researchers claim that up to 68% of all websites on the internet are vulnerable to this type of attack. Facebook, MySpace, Twitter, and other top websites on the internet today have been compromised by XSS attacks.
XSS exploits focus on attacking the client side and are very effective at bypassing client side security mechanisms. There are two types of XSS attacks: non-persistent and persistent. I will discuss the traditional non-persistent and persistent attacks as well as the newer DOM-based vulnerabilities exploited by XSS.
The most common type of XSS attack is a non-persistent one. Typically in this attack, a website will present a submission form to a user where they are allowed to type text and the server will immediately process the text and display it on a resulting page. If the user crafts HTML code properly and the server does not properly escape these HTML control characters, an XSS vulnerability has been found and can be exploited by the attacker. An example of this attack is typing a string of text into a search engine, which will process the text and usually display it on the resulting page. This example will not be of harm to anyone but the user who typed in the HTML code, but if they had injected this code into a URL link to a valid website with an XSS vulnerability and had somebody else click the link, they could steal the victim's information. If the victim is currently logged into an account on the valid website, the hacker could gain full access to their account session by stealing their session cookie.
Persistent XSS attacks are more severe and indirect than non-persistent attacks. When a server takes input from a user and permanently stores that submitted information on a web page (such as a Facebook profile or forum online where users are allowed to input HTML segments), users who visit that web page are subject to an attack if the website did not properly handle the escaping of HTML control characters. The attacker could steal the victims cookie and gain full access to their session.
In recent years, Web 2.0 applications which can dynamically generate web page information without users having to hit the refresh button in their browsers have been subject to DOM-based XSS vulnerabilities. DOM stands for "Document Object Model" and is basically a way to interact with objects in HTML. JavaScript is a client side scripting language for websites. Asynchronous JavaScript (known as Ajax) can retrieve data asynchronously from the server in the background of the web page by using the HTML object known as XmlHttpRequest which can make HTML requests and server queries without updating the web page the user is currently on. Attackers can exploit DOM-based XSS vulnerabilities to essentially gain access to this object and steal information.
There are a few steps that users and website developers can take to defend themselves from XSS attacks. The first thing is that website developers can make sure to properly escape HTML input from users. If the website's function is to allow users to input HTML (such as for formatting their profile page on MySpace) then the website developers must run this untrusted HTML input through an HTML policy engine to check for XSS. Another thing that website developers can do to avoid their user's accounts and information being stolen through XSS attacks is to attach the IP address of the user logged in to their session cookie. This way, if an attacker successfully steals a session cookie from a logged in user on a website through XSS, they will not be able to use the cookie unless they are within the same network as the victim.
One thing users can do to prevent themselves from XSS is to disable the use of scripts in their browsers. They may also add lists of trusted or untrusted domains into a list in their browser where they would like scripting enabled/disabled depending on the domain they are visiting. This approach is not entirely useful, however, due to the fact that many websites across the internet require the use of scripts to function properly.
Looking into the future, scanning technologies are emerging which scan websites for possible XSS attacks and allow website developers to patch the holes before they are exploited by attackers. These scanning technologies are not perfect and cannot find every single vulnerability in the website.
If you are a website developer, it is important to know the risks and understand how XSS works so that you can help secure your website as much as possible. Set up a sandbox website and test your skills! If you are completely new to XSS you can read up about some basics HERE. If you are familiar with XSS you should go HERE to learn about some more advanced tricks of XSS.
Sources:
http://www.ihtb.org/security/xss_hacking_exposed.txt
http://en.wikipedia.org/wiki/Cross-site_scripting
http://ha.ckers.org/xss.html
XSS exploits focus on attacking the client side and are very effective at bypassing client side security mechanisms. There are two types of XSS attacks: non-persistent and persistent. I will discuss the traditional non-persistent and persistent attacks as well as the newer DOM-based vulnerabilities exploited by XSS.
The most common type of XSS attack is a non-persistent one. Typically in this attack, a website will present a submission form to a user where they are allowed to type text and the server will immediately process the text and display it on a resulting page. If the user crafts HTML code properly and the server does not properly escape these HTML control characters, an XSS vulnerability has been found and can be exploited by the attacker. An example of this attack is typing a string of text into a search engine, which will process the text and usually display it on the resulting page. This example will not be of harm to anyone but the user who typed in the HTML code, but if they had injected this code into a URL link to a valid website with an XSS vulnerability and had somebody else click the link, they could steal the victim's information. If the victim is currently logged into an account on the valid website, the hacker could gain full access to their account session by stealing their session cookie.
Persistent XSS attacks are more severe and indirect than non-persistent attacks. When a server takes input from a user and permanently stores that submitted information on a web page (such as a Facebook profile or forum online where users are allowed to input HTML segments), users who visit that web page are subject to an attack if the website did not properly handle the escaping of HTML control characters. The attacker could steal the victims cookie and gain full access to their session.
In recent years, Web 2.0 applications which can dynamically generate web page information without users having to hit the refresh button in their browsers have been subject to DOM-based XSS vulnerabilities. DOM stands for "Document Object Model" and is basically a way to interact with objects in HTML. JavaScript is a client side scripting language for websites. Asynchronous JavaScript (known as Ajax) can retrieve data asynchronously from the server in the background of the web page by using the HTML object known as XmlHttpRequest which can make HTML requests and server queries without updating the web page the user is currently on. Attackers can exploit DOM-based XSS vulnerabilities to essentially gain access to this object and steal information.
There are a few steps that users and website developers can take to defend themselves from XSS attacks. The first thing is that website developers can make sure to properly escape HTML input from users. If the website's function is to allow users to input HTML (such as for formatting their profile page on MySpace) then the website developers must run this untrusted HTML input through an HTML policy engine to check for XSS. Another thing that website developers can do to avoid their user's accounts and information being stolen through XSS attacks is to attach the IP address of the user logged in to their session cookie. This way, if an attacker successfully steals a session cookie from a logged in user on a website through XSS, they will not be able to use the cookie unless they are within the same network as the victim.
One thing users can do to prevent themselves from XSS is to disable the use of scripts in their browsers. They may also add lists of trusted or untrusted domains into a list in their browser where they would like scripting enabled/disabled depending on the domain they are visiting. This approach is not entirely useful, however, due to the fact that many websites across the internet require the use of scripts to function properly.
Looking into the future, scanning technologies are emerging which scan websites for possible XSS attacks and allow website developers to patch the holes before they are exploited by attackers. These scanning technologies are not perfect and cannot find every single vulnerability in the website.
If you are a website developer, it is important to know the risks and understand how XSS works so that you can help secure your website as much as possible. Set up a sandbox website and test your skills! If you are completely new to XSS you can read up about some basics HERE. If you are familiar with XSS you should go HERE to learn about some more advanced tricks of XSS.
Sources:
http://www.ihtb.org/security/xss_hacking_exposed.txt
http://en.wikipedia.org/wiki/Cross-site_scripting
http://ha.ckers.org/xss.html
Cyber Warfare as the Growing Battle Many is Unprepared for…
When the term warfare is used it is often related to desolate fields, charging armies and exploding bombs. Historically this is largely true. Modern society, however, has become so incredibly interconnected through technology that it is difficult to really imagine a time without it. Many of the financial transactions that take place are now virtual and the credit systems, on which countries thrive, are completely digital. It is this interconnectivity that brings rise to a new form of warfare, which exists only in cyberspace, that is designed to attack and disrupt these transactions on a large scale. Cyber Warfare is a term used to reflect a large scale attack directed at disrupting the functions of a complex system. It can affect a single individual or an entire nation. However, one thing that has become a growing concern of many nations over the globe is how prepared they are for a dedicated assault from a foreign or even a local source.
The PDF written by a retire General Eugene E. Habiger highlights the need for the United States to prepare for the growing inevitability of a cyber attack on a large scale. Vulnerabilities can be seen today with group like Anonymous who are capable of launching crippling DOS attacks on major corporations almost on a whim while coordinating these attacks through instant chat services like Twitter. The internet has largely become a battlefield with the only safes zones being the areas that go unnoticed by the larger society. Cyber attacks happen everyday and happen with very little warning. They can install monitoring devices, access databases, crash entire networks and steal confidential information. This begs the question as to why, with so much evidence of their lethality, proper security measures have not been taken to protect against such attacks.
There are two reasons that are often held to be the cause of the general perceived apathy toward cyber attacks. There first reason is that unlike warships and bombs, the internet has such a broad range of uses and, as such, is not a visible sign of destructive potential. The internet is used for so many things in modern society that it is often elevated as the greatest of human achievements. These ideas are compounded with the fact that, while major attacks happen everyday, they are often downplayed or go unmentioned. This creates an aura of misinformation on how devastating or how compromising these attacks can be. The second reason is that there is simply no way to really prevent them, only defend against them. Much of modern security doesn’t directly target an attacker but only defends against the potential of attack. When the idea is brought forward it usually sounds like “not only is there a small chance to get the attacker but we can’t really even predict what type of attack could be next. Only defend against what we already know exists and take measures so that if something bad happens we won’t be completely crippled…” This has a dangerous habit of leading to a “deal with it when it happens” mentality that can sow the seeds of major disaster. This is not to say that there are not steps that can be taken to make a system more secure, it’s that they usually aren’t taken to the degree that they need to be. In order to adequately prepare for the growing war, countries and companies alike need to start taking steps to design security measures that will protect against potential attacks. As impossible as it seems, it is either work toward controlling these attacks or simply letting them happen.
http://cybersecureinstitute.org/docs/whitepapers/Habiger_2_1_10.pdf
WikiLeaks 'revenge attacks' target Mastercard and Visa
Computer hackers, called "Anonymous" have taken it upon themselves to hack into businesses, personal accounts, and even popular websites that have censored or spoken out against WikiLeaks. Most prominently MaterCard, Visa, and PayPal, who previously have stated they will not support donations made to the anti-secrecy group, have all announced being hit by DoS attacks last night. This Anonymous group has also been credited with hacking onto Sarah Palin's personal website and tampering with her and her husbands personal credit cards and most recently has been targeting Amazon who withdrew server space WikiLeaks was using. Anonymous has threatened to attack anyone who tries to censor WikiLeaks. MasterCard has said some customers experienced complete loss of service, but they are working to restore service to their customers. Recently, Anonymous has threatened Twitter who has been accused of monitoring and deleting posts centering around WikiLeaks.
Obviously the attack occurred when Anonymous hit the different servers enough to shut down service on multiple servers for multiple customers. They also encouraged other pro WikiLeakers to down load a program that would temporarily take over their PCs in order to assist in the DOS attacks. Because the companies were not quick enough in responding to the attack, they were experiencing some serious server issues. Since the attacks, the companies have been able to begin restructuring and bringing service back to all customers.
Companies should first and foremost make sure that none of their customer's personal data was breached and that all information was kept safe. In the case that information was leaked, then customers need to be notified immediately and accounts should be monitored. Companies should also be more aware of the situation surrounding these events and realize that these hackers are not going to stop. By being more aware, the attacks may not be as problematic as they were this time, and could possibly even be stopped. As WikiLeaks becomes a bigger issue, companies who openly disagree, must realize they have put themselves in the line of fire from these hackers and seek to make sure all security measures are put into place. If the government is pressuring some companies to alter themselves, they should also be helping to ensure as much protection is granted to these companies as possible.
http://www.telegraph.co.uk/news/worldnews/wikileaks/8190421/WikiLeaks-revenge-attacks-target-Mastercard-and-Visa.html
Obviously the attack occurred when Anonymous hit the different servers enough to shut down service on multiple servers for multiple customers. They also encouraged other pro WikiLeakers to down load a program that would temporarily take over their PCs in order to assist in the DOS attacks. Because the companies were not quick enough in responding to the attack, they were experiencing some serious server issues. Since the attacks, the companies have been able to begin restructuring and bringing service back to all customers.
Companies should first and foremost make sure that none of their customer's personal data was breached and that all information was kept safe. In the case that information was leaked, then customers need to be notified immediately and accounts should be monitored. Companies should also be more aware of the situation surrounding these events and realize that these hackers are not going to stop. By being more aware, the attacks may not be as problematic as they were this time, and could possibly even be stopped. As WikiLeaks becomes a bigger issue, companies who openly disagree, must realize they have put themselves in the line of fire from these hackers and seek to make sure all security measures are put into place. If the government is pressuring some companies to alter themselves, they should also be helping to ensure as much protection is granted to these companies as possible.
http://www.telegraph.co.uk/news/worldnews/wikileaks/8190421/WikiLeaks-revenge-attacks-target-Mastercard-and-Visa.html
Wednesday, December 8, 2010
Low Orbit Ion Cannon
Sometimes questionable tech blog Gizmodo described the Low Orbit Ion Cannon attack software in a feature today. The software was used by Anonymous to perform their Distributed Denial of Service attacks on those companies that had stopped supporting WikiLeaks.
The software, developed by the infamous image forum 4Chan, works essentially like any Denial of Service attack - it floods the target with dummy requests so that legitimate attempts to connect to the server are dropped. The software, which is cross-platform compatible, provides a user interface, simplifying the process of conducting a DoS attack to only needing a URL or IP address.
Another feature, called "Hivemind," allows users of computers running the program to turn over control of the program to a central user who can direct all the connected computers to attack a single site. This is essentially how a standard DDoS attack works - except that in this case, the owners of the computers on the botnet intentionally grant permission to use their computer in the attack.
The software is also fully open-source, which means that the generally technology-savvy users of the attack networks can review the code to know that the Hivemind feature does only what it says it's supposed to and nothing more. And, being open-source, it could be more difficult to eliminate the program from the Internet as anyone with the code can adapt and/or compile it.
Source: http://gizmodo.com/5709630/what-is-loic
The software, developed by the infamous image forum 4Chan, works essentially like any Denial of Service attack - it floods the target with dummy requests so that legitimate attempts to connect to the server are dropped. The software, which is cross-platform compatible, provides a user interface, simplifying the process of conducting a DoS attack to only needing a URL or IP address.
Another feature, called "Hivemind," allows users of computers running the program to turn over control of the program to a central user who can direct all the connected computers to attack a single site. This is essentially how a standard DDoS attack works - except that in this case, the owners of the computers on the botnet intentionally grant permission to use their computer in the attack.
The software is also fully open-source, which means that the generally technology-savvy users of the attack networks can review the code to know that the Hivemind feature does only what it says it's supposed to and nothing more. And, being open-source, it could be more difficult to eliminate the program from the Internet as anyone with the code can adapt and/or compile it.
Source: http://gizmodo.com/5709630/what-is-loic
Subscribe to:
Posts (Atom)
Posts
