[SecurityRatty] tag: tamper-proof

Red Hat Releases Critical OpenSSH Update After Detection Of Server Intrusion

Sun, 24 Aug 2008 12:32:40 +0000

More than a week after a cryptic note hinted at a security breach at Fedora, the open-source group has finally agreed that two separate server intrusions compromised the security of Red Hat’s OpenSSH packages. Red Hat has warned that hackers were able to commandeer its systems and tamper with code - but said that since [...]

Mailing error at the University of Maryland exposes student information

Fri, 18 Jul 2008 05:18:07 +0000

Technorati Tag: Security Breach

Date Reported:
7/17/08

Organization:
University of Maryland

Contractor/Consultant/Branch:
Department of Transportation Services

Victims:
All students registered for Fall 2008 classes

Number Affected:
23,727

Types of Data:
Names, addresses, and Social Security numbers

Breach Description:
On July 1st, 2008, the University of Maryland Department of Transportation Services mailed an on-campus parking brochure to all students registered for Fall 2008 classes as of June 15, 2008. Recipient Social Security numbers were inadvertently exposed on the mailing labels.

Reference URL:
University of Maryland
ABC Channel 7 News
WTOP FM 103.5 News

Report Credit:
University of Maryland

Response:
From the online sources cited above:

On July 1st, 2008, the University of Maryland’s Department of Transportation Services sent all students registered at the time, by U.S. mail, a brochure with on-campus parking information.

On July 8, 2008, the University discovered that the labels on that mailing included the addressees’ Social Security numbers.
[Evan] Sheesh, a fraudster doesn't even have to tamper with the mail if the Social Security number is on the label.

The error was discovered on the morning of July 8 when calls were made to the University.

This parking mailer was sent to all individuals registered for Fall 2008 classes at the University of Maryland as of June 15, 2008.

The mailing list numbered 23,727 individuals.

In our annual effort to provide parking and transportation information to the University community, the names and addresses of all registered students was requested internally at the Department of Transportation Services for the purpose of creating mailing labels for a brochure.

This information was generated by a computer query and included names, addresses and what was believed to be University identification numbers (UIDs).
[Evan] When writing and executing database queries, isn't it a good idea to check the results and see if the information displayed is the information you were looking for? I wonder if UIDs are also nine digits long like Social Security numbers are.

Our normal process is to remove the University ID numbers prior to mailing.
[Evan] Is it safe to assume that "normal process" was not followed in this instance? If so, then why not? There is no mention in the school's response.

It was not apparent to departmental staff that these numbers not only still existed within the file, but were Social Security numbers, and not University ID numbers.
[Evan] Not apparent? They were on the labels!

The numbers were not identified as Social Security numbers and did not show the normal spacing between digits.
[Evan] So it would be xxxxxxxxx instead of xxx-xx-xxxx. What percentage of people would recognize the first set of nine digits as a SSN?

This mailer was sent using third class, bulk mail delivery and may not have been delivered to you yet.

Currently, there is no evidence that anyone's Social Security number has been misused.

The University apologizes and deeply regrets this unfortunate mistake.

We are initiating immediate action to ensure that this error does not recur.
[Evan] Like what? Maybe train people to review their query results and follow "normal process"?

The University of Maryland values the critical importance of your personal information.

We strongly recommend that you take appropriate precautions to mask, black out or destroy this document after use.

In unfortunate situations like this, it is possible that dishonest people may contact you asking for personal information in the guise of offering assistance from the University.
[Evan] Equally unfortunate is the fact that there are a lot of dishonest people.

Please note that the University WILL NOT contact you by phone, e-mail or in any other way requesting personal information regarding this incident.

Please do not release any personal information in response to contacts claiming to be from the University.

In response to this incident, the University, and specifically the Department of Transportation Services, has moved to severely restrict access to sensitive student and faculty/staff information; we believe the fewer individuals who have access to this data will only increase our ability to protect sensitive information.

If individuals feel that they would like to take extra steps beyond the fraud alert, the University has arranged with Equifax to make available, at no cost to them, a 12-month service that includes credit monitoring, customer care, fraud expense reimbursement insurance and access to their credit report.

If you have not received this mailer and are unsure if you are included in the affected group, please call toll-free 1(877) 935-2428, Monday - Friday, 8:30 a.m. - 5 p.m. EST.

You may contact us in one of the following ways:
By telephone: Toll-free 1(877) 935-2428, Monday-Friday, 8:30 a.m. - 5 p.m. EST
Via e-mail: parkingmailer@umd.edu
Mailing address: Regents Drive Garage, Building #202, College Park, MD 20742

Commentary:
The lack of attention to detail coupled with lack of control leads to an increase of risk of confidential information disclosure. Not all that uncommon.

Past Breaches:
Unknown

Ironkey High Security Flash Drive: Use and Review

Sun, 06 Jul 2008 20:48:42 +0000

New Video:Ironkey High Security Flash Drive: Use and Review
The Ironkey is a high security thumb drive designed to provide strong AES encryption, tamper resistance and other security services. I’d seen the Ironkey advertised quite a bit, and even read about its crypto systems and ruggedness, but was left wondering about how it works in operation. Since the hardcore tech side has been covered elsewhere, I’ll concentrate on the Ironkey’s usability and features. Some of the topics covered will include: How is the drive mounted without admin privileges in Windows? How is it mounted in Linux? How does the “Self Destruct” feature work? What is Secure Sessions? How is the Ironkey better than just using Truecrypt? I made this video to answer those sorts of questions for myself and others. If you want more details on the crypto involved, see the links section at the end of this video. The model I will be working with is the 1GB Ironkey Personal. I’ll show its use and give my opinions on the device.

By the way, you may notice that I'm making fewer posts over the next month or so. I'll be busy studying for the GRE, wish me luck.

.. and now - PIN stealing..

Thu, 19 Jun 2008 06:38:00 +0000

Once the bad guys figured out how easy it was to sniff unencrypted ATM and card authorization traffic to steal track data, and after making a killing with stolen card numbers, they began setting their sights on bank PINs. PIN numbers - thanks to ANSI's TG3 - are encrypted with a half decent algorithm (and they are looking to strengthen that even more now). Which means that sniffing the traffic will only give you an encrypted number - something which would require a decryption key. A number of security controls like requiring dual control and split knowledge for key components, strict physical security requirements and Tamper Resistant Security Modules help in securing the keys. Assuming one cannot gain access to the encryption keys, this leaves only two scenarios for an attacker to gain access to the unencrypted PINs:
1. Before the PIN is encrypted by the Tamper Resistant Security Module (an ATM in the case of bank customers). Most criminals have been using fake PIN PADs and a number of techniques like jamming cards etc steal PINs blissfully unaware that they are on camera most of the time. Nice video ? here.

2. After the PIN reaches the issuer and is decrypted. This is the scarier situation -as the attacker would have access to a database of unencrypted PIN numbers / PIN offsets coming in from all around the globe. PCI supposedly requires that issuers be compliant and not store unencrypted PANs or PINs - but no validation is required (unless they are a VisaNet processor).

Well - Kevin Poulsen at Wired wrote today about how an alleged ATM crime spree has been blamed on a Citibank hack. Though Citibank has denied the hack as the cause of the fraudulent withdrawals - all signs seem to point towards it so far.
(This definitely is not new - While testing an issuer's security I'd stumbled upon ATM log entry files - complete with PAN, PIN, full name, address, zip code and atm location - back in the day when RFP just released whisker. )

This is probably just the beginning of a new wave. Issuers really need to pull up their socks and begin to treat cardmember data with the same respect that PCI Co is requiring merchants and processors to do. - and while I'm wishing horses - can ANSI or someone start working on some standards for requiring all track data to be encrypted in transit?

I Am IronKey, and I Can Encrypt Anything

Wed, 21 May 2008 20:00:00 +0000

The IronKey USB flash drive is one of the most secure devices I've ever worked with, but simultaneously tries to be--and achieves being--among the simplest to interact with in achieving that security. The product, from the eponymous company IronKey, comes in capacities from 1 GB to 8 GB that encrypts data five ways to Sunday while achieving government certification as tamper evident. A secured, anonymized version of Firefox is also onboard. Prices start at $79 including a one-year subscription for anonymous browsing; an 8 GB drive is $299.

ATM Communication - How Secure ?

Fri, 21 Mar 2008 09:34:00 +0000

A while ago, I attended a class on PIN and Key Management for Payment Networks. ANSI has laid out strict guidelines (in their ANSI X9 TG-3 standards checklist, ANSI documents X9.8 and X9.24) for how a customer's PIN should be kept secure: how they should be stored on the card (store only the difference/offset of the encrypted PIN value and the natural PIN), what the minimum encryption requirements are (Triple DES), what the specifications of the devices that encrypt/decrypt the PIN are (Tamper Resistant Security Modules), how PINs should be exchanged between various Financial Institutions (exchange keys between two FIs out-of-band AND under the principles of dual control and then encrypt the keys, how should compromised - no - even "suspect" compromised PINs and Keys that encrypt the PINs be treated (securely delete the key, recreate a new key under the principles of dual control and split knowledge and re-encrypt *every* key or PIN that has been encrypted under it! and re-issue cards containing PIN offsets for PINs encrypted under the new encryption key, if applicable) etc.

It was simply awesome. To know that the Financial Institutions do their due diligence is a huge confidence booster. The fact that these guidelines are just that - guidelines, and haven't been strictly enforced by governing bodies is not my biggest concern. Neither is the fact that there are a number of papers out there that talk about the insecurities in PIN translation.

The following, however, is:

The folks at redspin (Brian Hayes, Matt Marshall) analysed ATM traffic and wrote a paper on insecurities in ATM communications.

What you see above is the raw data message format that leaves the atm connected to a network. Cleartext communication. Notice the account number and expiration date. Totally vulnerable to man-in-the-middle attacks. The response message that is supposed to come from the FI, looks something like this:

I'm not going to say what one needs to do at this point. Read up message format ISO 8583. It is scary.

Attack and Defense: Securing ASP.NET 2.0 Apps

Thu, 13 Mar 2008 06:44:00 +0000

Thanks to all who attended this DevWeek talk today. Here's a link to the demos I did, along with the tamper-detection code I showed you. Enjoy!

Updated (20 Mar 2008) with new link.

Attack and Defense: Securing ASP.NET 2.0 Apps

Thu, 13 Mar 2008 06:44:00 +0000

Thanks to all who attended this DevWeek talk today. Here's a link to the demos I did, along with the tamper-detection code I showed you. Enjoy!

Updated (20 Mar 2008) with new link.

Attack and Defense: Securing ASP.NET 2.0 Apps

Thu, 13 Mar 2008 00:44:00 +0000

Thanks to all who attended this DevWeek talk today. Here's a link to the demos I did, along with the tamper-detection code I showed you. Enjoy!

Chip & PIN terminals vulnerable to simple attacks

Tue, 26 Feb 2008 17:33:32 +0000

Steven J. Murdoch, Ross Anderson and I looked at how well PIN entry devices (PEDs) protect cardholder data. Our paper will be published at the IEEE Symposium on Security and Privacy in May, though an extended version is available as a technical report. A segment about this work will appear on BBC Two’s Newsnight at 22:30 tonight.

We were able to demonstrate that two of the most popular PEDs in the UK — the Ingenico i3300 and Dione Xtreme — are vulnerable to a “tapping attack” using a paper clip, a needle and a small recording device. This allows us to record the data exchanged between the card and the PED’s processor without triggering tamper proofing mechanisms, and in clear violation of their supposed security properties. This attack can capture the card’s PIN because UK banks have opted to issue cheaper cards that do not use asymmetric cryptography to encrypt data between the card and PED.

In addition to the PIN, as part of the transaction, the PED reads an exact replica of the magnetic strip (for backwards compatibility). Thus, if an attacker can tap the data line between the card and the PED’s processor, he gets all the information needed to create a magnetic strip card and withdraw money out of an ATM that does not read the chip.

We also found that the certification process of these PEDs is flawed. APACS has been effectively approving PEDs for the UK market as Common Criteria (CC) Evaluated, which does not equal Common Criteria Certified (no PEDs are CC Certified). What APACS means by “Evaluated” is that an approved lab has performed the “evaluation”, but unlike CC Certified products, the reports are kept secret, and governmental Certification Bodies do not do quality control.

This process causes a race to the bottom, with PED developers able to choose labs that will approve rather than improve PEDs, at the lowest price. Clearly, the certification process needs to be more open to the cardholders, who suffer from the fraud. It also needs to be fixed such that defective devices are refused certification.

We notified APACS, Visa, and the PED manufactures of our results in mid-November 2007 and responses arrived only in the last week or so (Visa chose to respond only a few minutes ago!) The responses are the usual claims that our demonstrations can only be done in lab conditions, that criminals are not that sophisticated, the threat to cardholder data is minimal, and that their “layers of security” will detect fraud. There is no evidence to support these claims. APACS state that the PEDs we examined will not be de-certified or removed, and the same for the labs who certified them and would not even tell us who they are.

The threat is very real: tampered PEDs have already been used for fraud. See our press release and FAQ for basic points and the technical report where we discuss the work in detail.