Currently, doctors offices store patient information in a method that suits them. For most of us, the process is seamless – we don’t really care. That is, until we switch doctor’s offices.

Bill Gates is proposing standardizing patient information and making it available across the Internet. The aim is to allow each doctor’s office to communicate patient information with each other, and give patients easier access to their own medical records.

We envision a comprehensive, Internet-based system that enables health-care providers to automatically deliver personal health data to each patient in a form they can understand and use. We also believe that people should have control over who they share this information with. This will help ensure that their privacy is protected and their care providers have everything they need to make fully-informed diagnoses and treatment decisions.

Any such system must make use of strong authentication methods at the offices – and I’m sure they will be. Auditing and logging can mitigate the problems posed by people sharing credentials (which is bound to happen). But what about patients accessing information online?

Just think about how PayPal accounts are authenticated? With a username/password combination. (Sure, they offer hardware tokens, but only security/computer savvy people use them). If that’s how companies, banks, and retailers treat our money, what hope do we have for personal medical information?

Since any system like this is still in the imaginary stage, there are many possibilities. The technology is there, the concerns are there, what needs to happen next?

Wired is running an article by Bruce Schneier where he discusses the fact that the Dual_EC-DRBG (dual elliptic curve deterministic random bit generator) function was revealed to have a backdoor capability during the Crypto 2007 conference. Basically, there can exist a set of complements to the elliptic curve parameters that can remove the randomness.

Of course, we have no way of knowing whether the NSA knows the secret numbers that break Dual_EC-DRBG. We have no way of knowing whether an NSA employee working on his own came up with the constants — and has the secret numbers. We don’t know if someone from NIST, or someone in the ANSI working group, has them. Maybe nobody does.

I do know that the NSA has been pushing Suite B cryptography pretty hard, which includes elliptic curve cryptography and as an extension, the core of the Dual_EC-DRBG function. It’s also pretty common knowledge that ECC has been championed by the NSA for a while. Even if it is totally innocent, it still looks bad.

TOR is a way to browse the web anonymously. However it seems that a number of individuals have had a misunderstanding of anonymous vs. secure.

This article from Australia’s The Age, is a depiction of how Dan Egerstad used TOR against its users.

The question on everybody’s lips was: how did he do it? The answer came more than a week later and was somewhat anti-climactic. The 22-year-old Swedish security consultant had merely installed free, open-source software – called Tor – on five computers in data centres around the globe and monitored it.

A buffer overflow has been found in Oracle 10g and a patch won’t be released until mid-January.

An attack requires authentication to the database, but assuming that, a successful exploit could execute code remotely. Proof-of-concept exploit code was posted on the Internet last Friday.

The best way to prevent this attack is tight network controls and monitoring database logs for unusual activity and logins.

NIST has finally issued notice of a competition for a secure hash replacement to be designated SHA-3. This is similar to the process that NIST followed for AES. This is required because SHA-1 has some serious warts.

NIST has opened a public competition to develop a new cryptographic hash algorithm, which converts a variable length message into a short “message digest” that can be used for digital signatures, message authentication and other applications. The competition is NIST’s response to recent advances in the cryptanalysis of hash functions. The new hash algorithm will be called “SHA-3” and will augment the hash algorithms currently specified in FIPS 180-2, Secure Hash Standard.

So, cryptographers, this is your call to action. Responses are due by October 31, 2008.

[Speeding up the eXploit development process]

Jerome Athias gives a talk on how to more effectively use the eXploit framework.

You can watch the presentation via Google Video Link

Download .doc format – HERE

[Advanced Hacking Flash/Hard Drive Recoveries]

Scott Moulton talks about advanced data recovery from flash and solid state hard drives.

View the presentation via Google Video Link

[Crypto Boot Camp]

Rodney Thayer gave a 2 hour seminar on cryptographic technology. It was designed to give the audience a working knowledge for dealing with vendors. He gave some rules of thumb for choosing encryption. In order of preference, when doing symmetric key crypto: use AES with a minimum 128bit key, if not that 3-key Triple-DES, or last RC4 with 128bit key. For hashing: SHA 256 preferred, SHA 1 if you can’t do any better, and MD5 if you can’t SHA. For public key: RSA using at least a 2048bit key. The top choices in these lists were picked because they’ve stood up to years of scrutiny. One major theme of talk was to never roll your own crypto algorithm or buy someone elses. Proprietary algorithms get broken all the time, like the GSM A5 crypto we talked about earlier this year.

[Release notes not yet available]

[Real world Fuzzing]
Just when you though fuzzing was dead, Eliot Phillips from Hackaday comes back with his notes on Charlie Miller’s fuzzing seminar.

We dropped in on Charlie Miller’s fuzzing seminar at the end of the day yesterday. Fuzzing become a fairly popular topic in the last year and essentially involves giving a program garbage input, hoping that it will break. If it can’t handle the fake data and fails in a non-graceful fashion, you could have found a potentially exploitable bug. Fuzzing is a fairly simple idea, but as Charlie points out, without some thinking while you’re doing it it’s unlikely to be very productive.

Say you wanted to fuzz a PDF reader. You take a random good PDF file and use a fuzzing program iterate through multiple mutations of that file. This brings up the question of how long do you fuzz something? Do you let it run 24hrs, is that enough time? Charlie applies the principles of code coverage to determine exactly how much of the code his fuzzing is actually testing. He used the PNG library as an example. He picked a random PNG to mutate from and it tested a small percentage of the code. Studying the PNG spec he found that there are 21 different chunk types possible in a PNG file so he grabbed 1600 random PNGs and mutated off of those. These many different seed files gave him a lot more code coverage because the files feature almost all the different chunk types. The principle idea being if you don’t execute a line of code you’ll never find the bug in that line of code.

Charlie was part of the team that’s credited for finding the first iPhone exploit. They used code coverage to determine where to start working. Apple’s WebKit is open source and there is a note that says to use Mozilla’s test suite to test modifications the JavaScript core. Using gcov, which is part of gcc, they ran the test against the code. The tool showed what code was executed by the test suite. They ignored that code and started poking at the large block of untested code they found since that was more likely to contain a bug. That’s where they found the Perl RegEx parser which was eventually exploited.

This isn’t just for programs with the source; you can also use code coverage tools like Pei Mei with IDA Pro to determine what part of a binary file the specific code you’re looking for lives. Then you can write smarter generators that will hit more of that particular code.” – via: hackaday

[Video of the presentation – Google Video Link]

[uri use and abuse]

Nathan McFeters and Rob Carter gave a presentation on the problems with URI handling. URIs are used to send commands to external applications from a web browser. itms:// for iTunes for example. Any application that registers a URI has the potential to be abused through this route. For their first example they showed a stack overflow in Trillian’s AIM handling. The next demo created a “Critical Update Available” button on Picasa’s interface. When the user clicked it, their photos would be uploaded to the attacker’s server. They even display a “download progress” bar to encourage the user to keep the connection open.” – via: hackaday

You can read about the attack on cocontributor Billy Rios’s blog.