RSA, a subsidiary of EMC and one of the leading suppliers of cryptographic solutions including SecurID has been hacked. The actual date and time is unclear, but it was around 17 March 2011. An official report from the RSA to the US Securities and Exchange Commission (SEC) can be read here.

At the time of writing this, RSA are being very cagey about their communication into the public domain. Some commentators fear the issue is worse than RSA are letting on.  Information released so far from RSA confirms there was an issue, but then lists the basic security safeguards that clients should have in place anyway. This is leading people to speculate that sensitive information has been stolen – if that is the case, it can weaken the effectiveness of the SecurID token.

Background

• Typically, Internet based systems such as Internet banking use RSA’s SecurID as one of several layers of security.
• With SecurID, the client/user has their own (personal) PIN that they use in conjunction with the auto-generated number on the SecurID token.
• If, as some are speculating, SecurID token serial numbers and seeds have been stolen, it would mean that a hacker could potentially simulate a client’s SecurID token without having the physical token in their possession.  Therefore the hacker would only need to obtain the user’s PIN in order to gain access.
• RSA have an estimated 40 million SecurID customers.

What should you do now?

• Firstly, don’t panic.
• If a client/user of a SecurID device calls and wants their token PIN reset, make sure you can positively identify them.
• Keep a log of all calls and PIN changes.
• Make sure there is a written procedure in place that describes how you positively identify someone and how you reset their PIN.
• Make sure that all staff follow the procedure !
• Monitor your network and your SecurID infrastructure. Look for unusual patterns in usage and traffic.
• Monitor your SecurID infrastructure and produce reports to show failed authorisation attempts, SecurID token lockouts and activity out of usual hours.
• Ensure your client/user records and SecurID records are kept secure.
• Ensure you don’t send SecurID token to clients/users in an active state.
• Do not use the SecurID feature to allow a PIN to be auto-reset after a number of failed attempts.

Positively identifying someone on the telephone

• Call the client/user back on a pre-agreed telephone number.
• Set-up specific secret phrases or key challenge/responses between you (the provider) and your client/user. This could be set questions/answers or questions about recent account activity.
• Do not accept an email request – emails are very easily spoofed to look as if they have been sent from someone else.
• Do not rely on the sound of the callers voice.

What do I do if my SecurID service is provided for me?

• Firstly, ask your provider why they haven’t already advised you of the potential risk to your business !
• Ask them what monitoring they are performing on SecurID usage and unusual activity. Ask for copies of these reports so that you can evidence them.
• Ask your supplier to keep you informed of any developments.

What should I tell my client/user

• Remind them of the importance of not divulging their PIN.
• Supply written instructions of what to do if they lose their SecurdID token and/or PIN.
• Remind them of the importance of not divulging personal information on social media sites such as Facebook.
• Reassure them that your systems have not been compromised and that their data is safe.

Four USA Treasury Web sites have been  taken-offline after their cloud computing host was hacked. The attack caused users to be redirected to a malicious site in the Ukraine.

The four URLs infected were BEP.gov (Bureau of Engraving and Printing), BEP.treas.gov, Moneyfactory.gov and Moneyfactory.com.  The type of attack was a script injection that redirected users. The attack was unusual in that only IP addresses that had not previously visited the Treasury site were targeted, which made it difficult for authorities to track.

Roger Thompson, chief research officer at AVG Technologies, first noticed the attack on Monday (03 May 2010). He is reported as explaining that the hackers added a small snippet of almost undetectable iframe HTML code that redirected visitors to a Web site in the Ukraine. This site then launched a variety of Web-based attacks based on a commercially available attack-kit called the ‘Eleonore Exploit pack’.

The Ukrainian Web site is associated with similar attacks, which targeted a small number of known software bugs, including flaws in Adobe Reader software.

In a statement, the USA Treasury said “The Bureau of Engraving and Printing (BEP)entered the cloud computing arena last year. The hosting company used by BEP had an intrusion and as a result of that intrusion, numerous BEP and non-BEP websites were affected”.

At the time of writing this, the Web sites are still suspended and it isn’t clear how the hackers managed to install malicious code on the Treasury Department Web sites.

.

Final thoughts ….

The headlines suggest that the vulnerability is at the Cloud infrastructure level instead of the individual Web services hosted on it. Exact details aren’t yet know, but let’s hope it isn’t a ‘cloud computing’ issue, as it could impede the deployment of  cloud services to companies who are already nervous about jumping into a cloud service provider.

This issue does highlight just how important security is for the underlying cloud infrastructure layer, because an issue at this layer can potentially impact all services running on it.

.

Also read ….

• Cloud Computing – why is everyone so excited ?

Google has a single sign-on system known internally as ‘Gaia’ and allows users to log into many of Google’s services that it offers, such as Gmail, web search, business applications and others, using just the  one password.

The hackers stole the code after gaining access to the Google’s software repository – this is the ’crown jewels’ for their services. The hackers copied the software but it is not thought that they gained access to customer passwords, which means that users aren’t directly affected by the theft. However, the risk to Google is that the hackers could examine the software for security vulnerabilities to devise ways to gain access to the system that would later impact users.

Google announced in January 2010 that it had been hacked. The hackers had targeted the source code repositories at other companies.

It is believed that the theft started when an instant message was sent to a Google employee in China who was using Windows Messenger. The message included a link to a malicious website. When the employee clicked the link, the hackers were able to gain access to the employee’s computer. This meant that they were inside the Google corporate network and from there, they could connect to Google’s headquarters in California.  It is thought that the intruders know the names of the ‘Gaia’ software developers, because the hackers had access to an internal Google corporate directory that lists the business activities of every Google employee. 

According to a McAfee report, the hackers used a malicious website that was hosted in Taiwan. When the victim clicked on a link to the site, the site downloaded and executed a malicious JavaScript, with a zero-day exploit that attacked a vulnerability in the user’s Internet Explorer browser. A binary executable (program) disguised as a JPEG file then downloaded to the user’s system that opened a backdoor into the computer, setting up a connection to the attackers’ command and control servers that were also hosted in Taiwan.

From that initial access point, the attackers obtained access to the source-code management system or burrowed deeper into the corporate network to gain a persistent hold.

Read More in this New York Times article.

This incident highlights the concerns that many people already have, that using ‘Cloud’ services can be less secure than private or own hosting. Entrusting your data to a third party provider needs careful due dilliegence to make sure the service and security protection is good enough for your needs.

The criminals were aged 31, 30 and 25. The investigators believe that other arrests may follow.

The first member of the gang was arrested in early February, when he inadvertently logged into the network without disguising the address of his computer. His computer allowed the investigators to link to two more suspects who were arrested later in the month.

The botnet was monitored and rendered inactive in December, following an investigation by the FBI, the Spanish Guardia Civil and security experts around the world.

The network of computers (botnet) was designed to steal sensitive information, including usernames, passwords, banking credentials and credit card data, from online e-mail services and social media sites. One of the criminas had 800,000 pieces of personal data on his machine.

Some very high profile businesses were targeted. Christopher Davis, chief executive of security firm Defence Intelligence, was one of the firms invited to join the Mariposa Working Group, which was set up to deal with the botnet in May 2009. Davis said “It would be easier for me to provide a list of the Fortune 1000 companies that weren’t compromised”.

A senior research advisor, Pedro Bustamante said the criminals behind the botnet did not have “advanced hacking skills”. “This is very alarming because it proves how sophisticated and effective malware distribution software has become, empowering relatively unskilled cyber criminals to inflict major damage and financial loss,” he said.

The criminal gang made money by renting out parts of the botnet to other cyber-criminals in addition to selling stolen credentials and using banking and credit card information to make transactions via ‘money mules’.

Working with law enforcement agencies comes with a risk for security firms. After the botnet was closed down, Defence Intelligence were hit by a Distributed Denial of Service (DDoS) attack in an apparent act of retaliation. The firm remains determined to pursue such cases. Davis said “We will continue to fight the threat of botnets and the criminals behind them. We’ll start by dismantling their infrastructure and won’t stop until they’re standing in front of a judge”.

Zaman was sentenced to 46 months in jail and three years supervised release in addition to a US$75,000 fine by a court in Boston after pleading guilty to one count of conspiracy in April 2009.

Zaman laundered between $600,000 and $800,000 for Gonzalez, who also pleaded guilty to a string of cyber-attacks on several firms, resulting in the theft of tens of millions of payment card details. According to the court papers, Gonzalez asked to be paid for card numbers in digital currency or by wire to a bank account in Latvia.

In November 2005 Zaman used ATM cards linked to accounts in the names of fictitious or unrelated individuals to withdraw and repatriate approximately $38,000 of Gonzalez’s Latvian funds. He then sent the money in cash, minus a cut, to the hacker in Miami.

During 2005 and 2006, Zaman went to California for Gonzalez on three occasions. He picked up between $50,000 and $370,000 from an unknown man and then shipped the cash to Gonzalez in Federal Express boxes after taking his cut. A similar process was carried out from New York.

In March 2008, Zaman sent Gonzalez logs from Barclays ATM systems, where he was working as a programmer. Although Gonzalez uploaded these logs to a Latvian server, there was no evidence that the data was used.

Gonzalez was sentenced to 20 years and one day (owing to the need to deal with the peculiarities in the USA sentencing statutes), after pleading guilty to many attacks on different companies which include Heartland Payment Systems and TJX.

The impact to Heartland Payment Systems was significant. It agreed to pay US$2.4 million to settle a consumer cardholder class action suit for losses suffered. It also paid US$1.5 million for the cost of notice to the settling class, and $0.76 million to cover the legal fees.

Heartland also agreed to a $3.6 million settlement with American Express. Its provision for expenses related to the massive data breach were US$73.3 million.

March 2010

Hancock sent an open letter to customers that warned of the scam. It occurred between August and September 2009 and provided the thieves with access to the names printed on customer payment cards, card numbers and expiration dates and PIN codes.

Hancock Fabrics said that reported incidents of fraud had been “limited” but said that customers who shopped with them in the summer of 2009 should check their account statements.

The retailer worked with USA state and federal authorities to replace all of their PIN pads as well as installing an automated system that allows them to monitor them for suspicious activity.

December 2009

The hackers gained access to the database by using a well known SQL-injection method. This is something that should be tested during the development phase of a project.

The issue was made worse because RockYou attempted minimise the negative publicity by downplaying the incident. Firstly by covering it up by not notifying their users and then downplaying it in an official statement as being an issue that only affected ‘older’ applications. The hacker responsible for the initial breach published a small portion of the dataset he had retrieved and demonstrated that not only did he have access to the entire RockYou database, but passwords were stored in the clear. The issue then became worse when it was discovered that RockYou stored user credentials for social networks and other partner sites including MySpace and also webmail accounts.

The RockYou account creation process did not encourage or enforce strong passwords. It only enforced a password of a minimum length of five characters. There was no requirement for mixed-case, numbers and the process actually encouraged simple passwords by not allowing any punctuation at all. Passwords were communicated to new users of the service by clear text e-mails.

Interestingly, an analysis of the 32 Million passwords revealed the top 10 to be:

1. 123456
2. 12345
3. 123456789
4. Password
5. iloveyou
6. princess
7. rockyou
8. 1234567
9. 12345678
10. abc123

This list shows how important it is to choose a password that cannot be obviously guessed.

In March 2010, it was discovered that software distributed on a new Vodafone ‘HTC Magic’ mobile phone was infected with the ‘Mariposa bot’ client.

When the phone was connected to a PC, the bot automatically installed itself, then ‘phoned home’ to receive further instructions – probably to steal the user’s credentials and send them to the malware writer. The Mariposa bot was not the only malware found on the phone. There was also the Conficker malware and a Lineage password stealing malware.

There have been similar examples with other products, such as fake ‘Sony Memory Sticks’ that were packaged to look new, but contained malware that would infect your PC as soon as you used it.

The lesson is not to trust any source. Make sure you properly test the media for malware before using it.

March 2010

The scale of the breach was a major embarrassment to HSBC. They initially claimed that no more than ten accounts had been affected when the news first broke at the end of 2009. In a statement from the HSBC Swiss private bank, they admitted that data relating to 15,000 client accounts was stolen by a former IT employee three years previously. In addition, an additional 9000 accounts that had been closed in the past were also affected.

“We deeply regret this situation and unreservedly apologise to our clients for this threat to their privacy”, Alexandre Zeller, chief executive of the HSBC Swiss private bank, told reporters that he had received reassurances from the French authorities that the information will not be used “inappropriately”. The HSBC statement said “the bank does not believe that the stolen data has or will allow any third party to access any client account”.

Foreign tax authorities are willing to pay for information relating to Swiss private bank accounts and this has been a growing source of diplomatic tension. In January 2010, the Swiss government said it planned to draft a new law that would ban banking officials from co-operating with foreign countries where private account details have been stolen.

A laptop containing unencrypted personal information for 800,000 people who applied for jobs with clothing retailer Gap Inc. has been stolen.

The computer contained social security numbers and other sensitive information belonging to residents of the US and Puerto Rico who applied online or by phone for jobs from July 2006 to June 2007, the retailer said in this list of frequently asked questions. Details for applicants living in Canada were also exposed, although they didn’t include social insurance numbers.

The laptop was stolen from the offices of a third-party vendor the Gap hired to manage applicant data. The Gap didn’t identify the vendor or explain why it failed to encrypt such a large number of applicants’ personal information.

Gap joins scores of other organizations that have lost sensitive information entrusted to them. The US Department of Veterans Affairs, IBM and VeriSign have also been dogged by laptops or storage tapes that weren’t encrypted and were later lost or stolen.

More recently, high-stakes data breaches have resulted from criminals who found ways to exploit weaknesses in corporate networks. Last week, TD Ameritrade said hackers infiltrated a database containing social security numbers, birth dates and account numbers on an undisclosed number of clients. And in August, cyber gumshoes discovered a Trojan that stole more than 1.3 million records from people who were looking for work through job recruiter Monster.com.

Few companies disclose details of their data-retention policies, such as whether computers containing sensitive information are encrypted. This is partly because the release of too much information can tip off criminals. But we can’t help thinking the lack of disclosure also gives lawyers wriggle room in the event something goes wrong.

Indeed, Gap’s FAQ didn’t say whether customer records, applicant information and other sensitive details in its possession are encrypted, or whether it plans to enforce such a policy in the future. The Associated Press, however, quoted Glenn Murphy, the company’s CEO and chairman saying the storing of applicant data without encrypting it ran contrary to Gap’s agreement with the third-party vendor.

Gap is contacting applicants based in the US and Puerto Rico who had their social security numbers exposed. It is also arranging for them to receive one year of free credit monitoring. The company said it is unaware of any of the data being misused. ®

Posted in Enterprise Security, 28th September 2007 20:59 GMT