[SecurityRatty] tag: 13th

Security Briefing: June 13th

Fri, 13 Jun 2008 13:38:29 +0000

Friday the 13th.

Well, it was apparently worse than I thought at Infosecurity Canada. I spoke with eight people that attended and all of them gave it a unanimous thumbs down. Too bad. I guess if they were better organized it wouldn’t have sucked that badly.

Click here to subscribe to Liquidmatrix Security Digest!.

And now, the news… (better late than never)

Ameritrade Settling Hacking Lawsuit | Wired
McKinnon’s last ditch appeal to be heard by Lords | Heise Security
Third time’s the charm? RIAA tries end run around old case | Ars Technica
AG creates Cyber Crimes Unit division: Conway hopes to target Internet predators | Medical Leader News
Outsourcing contracts must offer personal data security | Computer Weekly
Windows Inspection Tool Set Helps You Troubleshoot Your System | AppScout
Web Application Security: Don’t Bolt It On; Build It In | IT Business Net
Opinion: Breach laws fail to protect anyone | InterGovWorld
Hacking: A story untold | Burlington Free Press

Tags: News, Daily Links, Security Blog, Information Security, Security News

Random Number Bug in Debian Linux

Mon, 19 May 2008 02:07:59 +0000

This is a big deal:

On May 13th, 2008 the Debian project announced that Luciano Bello found an interesting vulnerability in the OpenSSL package they were distributing. The bug in question was caused by the removal of the following line of code from md_rand.c
	MD_Update(&m,buf,j);
	[ .. ]
	MD_Update(&m,buf,j); /* purify complains */
These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL. You can see one such report to the OpenSSL team here. Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only "random" value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.

More info, from Debian, here. And from the hacker community here. Seems that the bug was introduced in September 2006.

More analysis here. And a cartoon.

Random numbers are used everywhere in cryptography, for both short- and long-term security. And, as we've seen here, security flaws in random number generators are really easy to accidently create and really hard to discover after the fact. Back when the NSA was routinely weakening commercial cryptography, their favorite technique was reducing the entropy of the random number generator.

The Rise of Kosovo Defacement Groups

Mon, 21 Apr 2008 00:31:00 +0000

There's no better way to assess the incident that still haven't made it into the mainstream media, but to violate defacement group's OPSEC, by obtaining internal metrics for defaced sites on behalf of a particular group. According to this screenshot, released by one of the members of the Kosovo Hackers Group, a group that's been defacement beneath the radar as of recently, the mass deface included 300 sites, and on the 13th of April, Quebec's Common Ground Alliance site got also defaced by the group. Web application vulnerabilities in a combination with SQL injecting web backdoors is what is greatly contributing to the success of newly born defacement groups. And of course, commercially obtainable tools as you can see one of the bookmarks in the screenshot, indicating the use of such.

The rise of this particular group greatly showcases the cyclical pattern of cyber conflicts as the extensions of propaganda, PSYOPs and demonstration of power online, most interestingly the fact that at the beginning of their capabilities development process, they target everyone, everywhere, to later on move to more targeted attacks to greatly improve the effectiveness of the PSYOPs motives.

ESMNE inadvertently discloses employee financial details

Sun, 06 Apr 2008 12:51:10 +0000

Technorati Tag: Security Breach

Date Reported:
3/26/08

Organization:
Eastern Sales and Marketing New England ("ESMNE")

Contractor/Consultant/Branch:
None

Victims:
Current and former employees

Number Affected:
137

Types of Data:
Names, bank identification numbers and bank account numbers

Breach Description:
"I am writing to notify you that on March 20, 2008, Eastern Sales and Marketing New England ("ESMNE") learned that it inadvertently disclosed to one of its former employees your name, bank identification number and bank account number."

Reference URL:
New Hampshire State Attorney General breach notification

Report Credit:
The New Hampshire State Attorney General

Response:
From the online source cited above:

I am writing to notify you that on March 20, 2008, Eastern Sales and Marketing New England ("ESMNE") learned that it inadvertently disclosed to one of its former employees the name, bank identification number and bank account number of 137 of current and former employees.

ESMNE believes that 8 of these 137 affected employees are New Hampshire residents.

On March 13, 2008, ESMNE sent a letter to a former employee regarding funds (totaling $985.44) that it erroneously deposited into her account during her employment with the company.
[Evan] This information is unique in a breach notification.

The funds should have been deposited into another employee's account as reimbursement for his business expenses. ESMNE has reimbursed that other employee, but would like the former employee to return the money she received in error.
[Evan] More interesting and unique information.

ESMNE enclosed with the March 13th letter documents verifying that the money was deposited in error.

Unfortunately, ESMNE failed to redact from those documents information related to other employees. That information included the employees' names, bank identification numbers and bank account numbers.

The employee who received the inadvertent disclosure returned the documents to ESMNE and stated that she does not want any of the inadvertently disclosed information in her possession.

ESMNE has sent notices to all of the affected New Hampshire residents.

We have no reason to believe that your information has been misused. In fact, the former employee to whom ESMNE accidentally disclosed the information returned all of the information to us and informed us that she does not want the information in her possession.
[Evan] It is a good thing that the person receiving the information was honest about this matter. If the information had been sent to someone with lesser morals, the company may have never been aware of their mistake.

Nevertheless, we want to inform you of the situation and suggest some steps you may want to consider to protect yourself.

We take seriously our commitment to safeguarding confidential information entrusted to us by our employees, such as your personal information.

Rest assured that we are carefully reviewing this matter and taking measures to ensure that it does not happen again.

Again, we apologize for any inconvenience or concerns the disclosure of your information to one former employee may cause.

We are committed to assisting you in protecting yourself. If you have any questions or need additional information, please contact Cindy Murray at 781-314-7106.

Commentary:
A simple user error on the part of ESMNE? I wonder if the employee that sent the letter to the former employee was aware of the information and it's sensitivity. Well designed and relevant information security awareness (and training) can limit the number and and impact of employee errors.

Past Breaches:
Unknown

The Science of Intrusion Prevention Testing

Wed, 27 Feb 2008 11:00:00 +0000

(Source: NSS Labs) LIVE WEBCAST
How do you accurately gauge the effectiveness of complex security products like intrusion prevention systems? Testing security products is a complex science, and the market place is filled with vendor claims, product reviews, analyses, and lab test reports. These reported measurements can vary widely depending on the sources, methodologies and tools used. And even then, the results may not be relevant for your environment. Whether you are going to perform your own tests, or read someone else's lab results, get a quick educational primer on the science of testing security products.

Join NSS Labs experts, Christian Stankevitz, CTO and Bob Walder, Chief Scientist.

What you'll learn:
- Best practices and tools for testing complex security products
- How to evaluate security & performance requirements
- How to avoid common pitfalls when evaluating IPS and anti-malware products
- The importance of using live exploits against real hosts

This webcast will air on Thursday, March 13th, at 2PM EST.

AIB technical problem discloses details of bank transfers

Wed, 28 Nov 2007 14:08:26 +0000

Technorati Tag: Security Breach

Date Reported:
11/21/07

Organization:
Allied Irish Bank (AI

Contractor/Consultant/Branch:
None

Victims:
Certain AIB customers who made or received international payments between November 13th and 15th, 2007. Some customers of other banks involved in the transactions may also be affected.

Number Affected:
11,000*

*AIB customers, unknown number of victims that are customers of other banks

Types of Data:
Names, addresses and "private bank account details".

Breach Description:
The announcement from AIB sums this breach up well; "A technical problem occurred in the issuing of these advice notices to some AIB customers that made international payments between the 13th and 15th November 2007. This affected 15,000 payment advices, which were sent in error to the wrong customers."

Reference URL:
The Irish Times Story
Computer Weekly Story
RTE Business Story

Report Credit:
The Irish Times

Response:
From the sources cited above:

A significant error at AIB bank earlier this month led it to send 15,000 notifications to its customers containing the private bank account details of other individuals. A total of 11,000 AIB customers are affected by the move, writes John Downes

Last night, it also emerged that some of the bank account details sent to AIB customers in recent days relate not just to AIB accounts, but also reveal the names and bank account details of customers with other banks.

It is understood that as many as 7,500 of the notices contained the names, addresses and full bank account numbers of AIB customers.This means these details, contained in notices relating to "inward" payments, are now in the possession of other customers of the bank.

Most of the remaining "outward" payment notices included the name of a bank account holder, usually with a bank other than AIB, and their account numbers, but not their address.

A bank spokesman said the information in question was no more or less than would be contained in a company invoice or cheque
[Comfyllama] Which wouldn't be a big deal if this information were meant to be public, but it WASN'T.

However the error, which AIB said was the result of a "technical problem" in the issuing of international payment advice notices, has been labelled a "serious breach" by a spokesman for the Office of the Data Protection Commissioner.
[Comfyllama] Sounds like someone made a change to one or more internal systems, likely without thorough testing and/or validation.

Customers of the bank who either received or transferred an international payment between November 13th and 15th are affected by the error.

Those who received the notices were wrongly provided with details relating to someone else's transaction. As a result, they were incorrectly told the transaction related to their account.
[Comfyllama] Can you imagine receiving a notice that X number of Euro (EUR) were transferred from your account, and you had nothing to do with it. My heart would just about burst out of my chest!

The bank stressed that no customer accounts have been incorrectly credited or debited as a result of the error. A company spokesman added that it had "nothing whatsoever" to do with computer "hackers" or other unauthorised parties attempting to access its system.

AIB has informed the Office of Data Protection Commissioner which is awaiting an AIB report on the matter in the coming days. The company said it would allow affected customers to change their bank account details should they so wish.

"AIB regrets that this occurred and is currently writing to each customer involved to apologise, to explain how this occurred and to reassure them that this was an isolated error," the bank said.

One of the incorrect notices, seen by The Irish Times , wrongly informed the customer that a payment of €5,000 had been made from their business account to an account with the Bank of China.

Commentary:
Errors will always be a part of our daily lives, but at the same time we should do everything within reason to prevent them. In IT, this is one of the primary reasons for proper change control processes. As a part of most good change control, testing and validation are completed before the change is successful. If testing and/or validation fail, a roll-back is initiated.

I'm not sure what AIB's change control processes or procedures are, but in this case they appear to have failed. I am also not sure how sensitive the data involved actually is, so determining the risk to victims is a little sketchy. Many IT folks aren't particularly fond of change control (and documentation in general), but this may be a good case to demonstrate its importance.

Now that I think a little more, these changes should have been thoroughly tested on a test platform prior to production implementation also.

Past Breaches:
Unknown

Show 013 - An Interview with Ross Anderson

Fri, 13 Apr 2007 16:33:21 +0000

On the 13th episode of The Silver Bullet Security Podcast, Gary chats with Ross Anderson, Professor of Security Engineering at the Computer Laboratory at Cambridge University and author of the book Security Engineering. Gary and Ross discuss the effect of posting his excellent book on the net for free, the simple reasons why most systems fail, the economic imbalance between engineers/developers and a system’s users (with respect to who should address security), and why publicly describing attacks is essential to security engineering. They close out by examining the security implications of wearing a kilt.

Ross Anderson
Light Blue Touchpaper - A security blog by Cambridge computer scientists.
Security Engineering - Ross’ groundbreaking book in print and online
WEIS 2007 - Sixth Workshop on the Economics of Information Security
RFID and the Middleman [PDF]
The Clan Anderson Society
Ross playing the bagpipes