Hackszine.com: Cryptography Archives

Archive: Cryptography

Page 1 of 2 1 2 >>

July 29, 2008

DJBDNS, DNS exploits, Bernstein, Schneier, and security by design

If you haven't been living under a rock, you've probably heard of the DNS vulnerability that Dan Kaminsky announced about a half year ago. The plan was that Kaminsky would be working with DNS server vendors to provide a patch, giving ample time for administrators to upgrade before the details of the exploit were released later this year. Unfortunately the exploit was leaked prematurely, causing a general freak-out mode amongst people that administer DNS systems.

When I read the article on Slashdot, the "all name servers should be patched as soon as possible" quote dropped a bit of scare on me too. What about my sad little DNS server? I envisioned spending an evening working through a time consuming process of patching and reconfiguring things that I haven't had to touch in years. Much to my pleasant surprise, djbdns, D. J. Bernstein's DNS server, was not vulnerable. My decision to use djbdns a number of years ago was primarily due to his vocal philosophy of engineering security by design instead of by response.

Bruce Schneier's analysis of things is spot on as usual. It's a solid case study for hygienic software engineering practices and the design of secure systems.

The real lesson is that the patch treadmill doesn't work, and it hasn't for years. This cycle of finding security holes and rushing to patch them before the bad guys exploit those vulnerabilities is expensive, inefficient and incomplete. We need to design security into our systems right from the beginning. We need assurance. We need security engineers involved in system design. This process won't prevent every vulnerability, but it's much more secure -- and cheaper -- than the patch treadmill we're all on now.

What a security engineer brings to the problem is a particular mindset. He thinks about systems from a security perspective. It's not that he discovers all possible attacks before the bad guys do; it's more that he anticipates potential types of attacks, and defends against them even if he doesn't know their details. I see this all the time in good cryptographic designs. It's over-engineering based on intuition, but if the security engineer has good intuition, it generally works.

Kaminsky's vulnerability is a perfect example of this. Years ago, cryptographer Daniel J. Bernstein looked at DNS security and decided that Source Port Randomization was a smart design choice. That's exactly the work-around being rolled out now following Kaminsky's discovery. Bernstein didn't discover Kaminsky's attack; instead, he saw a general class of attacks and realized that this enhancement could protect against them. Consequently, the DNS program he wrote in 2000, djbdns, doesn't need to be patched; it's already immune to Kaminsky's attack.

The djbdns server wasn't pre-installed on the Linux distro I based my poor old server on. DJB's deamontools package, which manages the startup and shutdown of the service, was annoying to deal with when every other application just uses a normal init rc script. The dns server configuration and setup was also unfamiliar to me, having previously only worked with BIND zone files.

There's one other thing that has really been different with djbdns than any other DNS server I've ever administered: I've never had to patch it. I've only had one other software experience like this, with the qmail mail transfer system. Qmail is also designed by Bernstein. Hmm.

If you're upgrading your DNS server anyway, maybe now is the time to start thinking about your alternatives.

Daniel J. Bernstein's djbdns server
Schneier - The DNS Vulnerability
DJB on DNS forgery
Slashdot - Kaminsky's DNS Attack Disclosed, Then Pulled

July 27, 2008

Cyber Security Awareness Week

Dan Guido from the Information Systems and Internet Security Lab at the Polytechnic Institute of NYU wrote in about the Institute's 5th annual Cyber Security Awareness Week. If you're in high-school or a college undergraduate program, this is a great opportunity to test your infosec skills against your peers, and hopefully earn a little prize money in the process.

ISIS Lab is organizing NYU-Poly's 5th annual Cyber Security Awareness Week (CSAW) where students can compete and win prizes in a variety of information security challenges. There will be door prizes, raffles for participating, and bonus prizes for undergrad and high school participants. Qualified finalists will receive a travel scholarship to attend the awards ceremony in New York City.

There are a number of events, including an application security "capture the flag" challenge, a security quiz which covers everything from cryptography to risk management, and a 5-day forensics puzzle. There's even an embedded systems challenge where teams are tasked with trying to find hardware and software bugs in a mock control system.

This looks like a lot of fun. Some of the contest materials become available at the beginning of September, so sign up soon if you're interested in participating.

Cyber Security Awareness Week 2008

July 23, 2008

NTFS Alternate Data Streams - hide files inside other files

The NTFS file system has support for additional data, called Alternate Data Streams (ADS), to be attached to any file. Normally this is used by the operating system and file explorer to bind extra data to a file, such as the file's access control information, searchable file meta-data like keywords, comments and revision history, and even information that can mark a file as having been downloaded from the internet. Because this extra information is bound to the file at the filesystem level, you can move the file from one folder to another and all of the various meta-information and permission data stays with the file.

The interesting thing is that a file can have 0 to many ADS forks attached to any file or directory. While some of the ADS identifiers are use by the OS, there's nothing stopping you from adding other ADS forks to a file. You can do this directly from the command line, using a simple colon ":" notation.

Let's say you have a file called test.txt. You can store a secret message in the file like this:
echo "This is a secret" > test.txt:secretdata

If you view the contents of the file, you won't see anything peculiar. If you know about the existence of the secretdata ADS entry, however, you can easily extract the hidden information with the following command:
more < test.txt:secretdata > output.txt

When you now open output.txt, you'll find your secret data inside.

Because it's a lower level OS feature, you can even trick most programs into loading the data. In the scenario above, you could actually load and edit the secretdata stream inside of notepad by running "notepad test.txt:secretdata".You can even store and execute binary data of any particular size in an ADS fork. For instance, maybe you want to shove solitaire inside one of your text file's ADS entries:

type c:\winnt\system32\sol.exe > test.txt:timewaster.exe

Running the file is as simple as "start .\test.txt:timewaster.exe". Wild, no?

So the odd thing is that all these hidden streams are floating about your filesystem and until Vista's /R flag on the DIR command, there hasn't really been a very good built-in way of detecting them. To solve this, Frank Heyne created an application called LADS which is an excellent command line utility that will scan a directory and print out stream names and sizes for files within it.

There's was also a tool released in an MSDN article about file streams that will at an extra tab to the file properties in Windows Explorer. I've linked to a FAQ that Frank maintains about ADS that walks you through setting up the dll and registry entries to make this work. When it's activated, the Streams tab in the properties panel will let you create, view, edit or delete the stream data that's attached to any file, right in Explorer.

I can see how this file system feature could be useful, but it's a little odd that it's so hidden from the user and there seem to be a few problems with the concept. Obviously, because of ADS's hidden nature, there are a number of malicious uses that can be employed by jerk-o's who write virii and that sort of thing. Even ignoring that, there are also data interchange issues—moving a file between NTFS and another file system causes the loss of all this attached information. Call me old fashioned, but I like my files the way they used to be, with a start, an end, and some bytes in between.

Frank Heyne - Alternate Data Streams in NTFS FAQ
LADS - NTFS alternate data stream list utility
The Dark Side of NTFS
MSDN: A Programmer's Perspective on NTFS Streams and Hard Links

June 24, 2008

Videos from past Shmoocons

You may have dug the videos of past DEFCON conferences that we posted back in May, but there's a whole other infosec conference, Shmoocon, which is held in D.C. every February.

ShmooCon is an annual East coast hacker convention hell-bent on offering three days of an interesting atmosphere for demonstrating technology exploitation, inventive software & hardware solutions, and open discussions of critical infosec issues.

It's a while until the next conference comes up, but there have been some great presentations at past conferences, most of which are available online. Peteris Krumins recently assembled links to all of the videos and presentation files that are available at the Shmoocon site (including the 2008 conference), posting them to his blog as a single big index.

A quick search on YouTube also turned up a series of videos by Scott Moulton from Shmoocon 2007 and 2008 on the topic of data recovery for both traditional hard disks and flash drives. It's pretty fascinating stuff, whether you're interested in this from a forensics or security perspective, or if you've ever just wondered what exactly goes into recovering important data from a crashed disk when you send it out to a data recovery shop.

Hacking Videos from Shmoocon
Scott Moulton's videos on data recovery for SSD flash drives and hard disks
Shmoocon Infosec Conference

Debian/Ubuntu users: update your SSL keys and certs

It was announced yesterday that sometime back in September 2006 a line of code was removed from the Debian distributed OpenSSL package. That one line of code was responsible for causing an uninitialized data warning in Valgrind. It also seeded the random number generator used by OpenSSL. Without it, the error went away, but the keyspace used by affected systems went from 2^1024 to about 2^15. Oh noes!

A large majority of Debian and Ubuntu systems are affected. To correct the problem, you'll need to not only update OpenSSL, but also revoke and replace any cryptographic keys and certificates that were generated on the affected systems. From the Debian security advisory:

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.

For most people, this boils down to your ssh server's host key and any public key pairs used for remote ssh authentication. Any keys or certificates generated on the affected machines for SSL/https use also need to be revoked and regenerated. It's pretty ugly, really.

As far as teachable moments go, there's probably a lot to think about here. Software developers have this weird natural tendency to want to fix and reengineer things that aren't even broken. I'd go so far as to say that the desire to reengineer is inversely proportional to a programmer's familiarity and understanding of the code. I think it comes from our intense desire to make sense of things. It's the guru who's able to channel that hacker urge into solving new problems instead of creating new bugs out of old solutions.

DSA-1571-1 openssl -- predictable random number generator
OpenSSL PRNG Debian Toys (more discussion of the problem here)

May 4, 2008

Videos from past DEFCONs

I wasn't able to make it to last years DEFCON hacker/security conference, and DEFCON 16 isn't until later this summer. As you can imagine, I've been a little impatient for a good ol' info-security paranoia fix. Thankfully, it looks like a ton of videos from past conferences have been posted to the DEFCON site. This might be pretty interesting to even the die-hards in the crowd who religiously attend. Having been to a couple of these, it's pretty hard (read: impossible) to get into all the sessions you would like to hit.

The more recent content is encoded as mp4's. Unfortunately, you'll need Real Player to view much of the older content. It's better than nothing, though.

It also looks like there have been a number of sessions from DEFCON 15 encoded and uploaded to Google Video. I've included a link to a list of these below as well.

Defcon Media Archives: 1993 - Present
Links to DefCon 15 Session and Panel Videos on Google Video

April 4, 2008

Add keystroke user verification to Gnome

Nathan Harrington amended the GNOME Desktop Manager to include keystroke dynamics in the user verification process. When the user enters their username, the timings between key press events are measured and compared against a stored pattern. The theory is that there is a significant difference in timings for words typed by different individuals, so the way a username is entered provides a bit of extra "fingerprint" information that can be used to help authenticate a user.

I'm not sure how immediately useful this will be, since this particular example won't affect other login methods, such as an ssh session. Nevertheless, the idea is pretty cool and the code is all there for you to monkey around with.

Identify and verify users based on how they type [via slashdot]

March 4, 2008

Ram dump over Firewire

Unlike USB2, the Firewire spec allows devices to have full DMA access. By impersonating the appropriate device, a PC can essentially obtain full read/write access to another machine's RAM, just by connecting the two machines with a Firewire cable. Adding to the recent discussion about the insecurities of physical access and Princeton's cold-boot RAM dump demonstration, Adam Boileau released a Linux Firewire utility that will give you immediate Administrator to an XP machine:

It's two years later, and I think anyone who was going to get the message about Firewire has already got it, and anyone who was going to be upset about it has got over it. Besides, according to Microsoft's definition, it never was a Security Vulnerability anyway - screensavers and login prompts are - as Bruce says - about the Feeling of Security. Anyway, today's release day for Winlockpwn, the tool I demoed at Ruxcon for bypassing windows auth, or popping an admin shell at the login window.
...

Yes, you can read and write main memory over firewire on windows.
Yes, this means you can completely own any box who's firewire port you can plug into in seconds.
Yes, it requires physical access. People with physical access win in lots of ways. Sure, this is fast and easy, but it's just one of many.
Yes, it's a FEATURE, not a bug. It's the Fire in Firewire. Yes, I know this, Microsoft know this. The OHCI-1394 spec knows this. People with firewire ports generally dont.

Adam's tools include a few Python apps that can copy and impersonate Firewire device signatures, dump RAM on a remote machine, bypass Windows authentication, and extract BIOS passwords. It's not exactly comforting, but I've got a new appreciation for Firewire now. This is the sort of access that used to only be possible by creating hardware that physically connects to the PCI bus. Now all you need is a cable and a laptop.

Firewire, DMA & Windows - direct memory access over Firewire - [via] Link

February 28, 2008

Detecting forged photos algorithmically

John Graham-Cumming posted an automated tool for detecting "Clone Tool" Photoshop forgeries. Photojournalism ethics issues (LInk, Link) aside, John had some ulterior motives:

I was motivated to work on this program by greed (or at least my never-ending love of having a little flutter on things). Best of the Best runs spot-the-ball competitions in airports to win very expensive cars. But they also run the same competition online. That meant I could get my hands on the actual image used... could I process it to discover where the ball had been removed? (In reality, this isn't the right way to win because the actual ball position is not governed by where it actually was, but where a judge thinks it was).
Would it be cheating if I could? Apparently not, the competition rules say I should use my skill and judgment in determining the ball position. Surely, skill covers my programming ability.

So, I went looking for tampering algorithms and eventually came across Detection of Copy-Move Forgery in Digital Images written by Jessica Fridrich at SUNY Binghamton. The paper describes an algorithm for detecting just the sort of changes I thought I was looking for.

Essentially the algorithm cuts the image into a bunch of 16x16 chunks and runs each chunk through a discrete cosine transform. The DCTed chunks are compressed and sorted, and the algorithm looks for multiple matching chunks that were shifted the same direction and distance, highlighting the source image if a large number of matches are found.

Another blogger, jjwiseman, released a speed optimization for John's code, which he successfully used on the infamous Adnan Hajj Reuters images. While the algorithm is able to detect this style of manipulation, it's noted that it has a habit of returning false positives in images with a blurry background.

That said, it'd be pretty interesting to run this through a big database of news photos and see what turns up.

Detection of Copy-Move Forgery in Digital Images - Link (PDF)
John Graham-Cumming's Clone Tool Detector - Link
Protecting Journalistic Integrity Algorithmically (jjwiseman's update) - Link

February 22, 2008

Extracting encryption keys after a cold boot

In this video, researchers at Princeton demonstrate the ability to lift encryption keys from RAM that has been powered off for a brief period of time. When you use a full disk encryption product, the key is stored in RAM while the machine is unlocked and operating. This data is typically considered safe as long as it's not paged out to disk since RAM is considered volatile. The truth, though, is that the volatility of the data in unpowered RAM is dependent on a few factors including temperature and the length of time it's been without power:

Contrary to popular assumption, DRAMs used in most modern computers retain their contents for seconds to minutes after power is lost, even at operating temperatures and even if removed from a motherboard. Although DRAMs become less reliable when they are not refreshed, they are not immediately erased, and their contents persist sufficiently for malicious (or forensic) acquisition of usable full-system memory images. We show that this phenomenon limits the ability of an operating system to protect cryptographic key material from an attacker with physical access. We use cold reboots to mount attacks on popular disk encryption systems -- BitLocker, FileVault, dm-crypt, and TrueCrypt -- using no special devices or materials.

By rebooting a laptop off of a USB drive with a small-footprint kernel, an attacker could pretty easily dump the full contents of RAM with little risk of loosing data. Even if the machine's BIOS is configured to disallow booting from external drives, the attacker could use an upside-down can of compressed air to cool the RAM prior to shutdown and then quickly transfer the RAM to a second machine.

Since it's not a trivial task to swap keys, there are other even more sinister attack scenarios. For instance, a key could be swiped when convenient, then used to inspect the disk contents at multiple points in time at a later date. Screw up and leave your computer recently-powered and unattended once, and the drive could be accessed at any point in the future. The machine wouldn't even need to be stolen for this opportunistic approach to be effective, so you might never know that your data's security is compromised.

If you use disk encryption as a last defense for the security of your data, it seems prudent to shut your machine down completely (no hibernating) several minutes prior to it leaving your immediate control.

Lest We Remember: Cold Boot Attacks on Encryption Keys - [via Jay] Link

February 6, 2008

TrueCrypt for OS X

TrueCrypt 5.0 was released yesterday and OS X has been added to the list of supported operating systems, making it the only open source volume encryption utility that works in Linux, Mac and Windows. It's a really slick utility for creating an AES-256 or Serpent encrypted volume that you can drop sensitive files inside.

You can use TrueCrypt to create an encrypted volume image inside a file, or you can encrypt a whole disk image or partition. The OS X version uses MacFUSE to provide user-mode mounting of the encrypted disk. The main application window, pictured above, gives you a simple interface for creating and mounting encrypted images.

Once an image is mounted, you can use it like a normal hard disk. Unmount the disk and you're left with a file full of random gibberish. FAT is the only filesystem that's available through the interface, but once the disk is mounted, you can reformat it with Disk Utility to use XFS.

There are a couple of things worth noting. In the Windows and Linux versions a special bootloader is available that lets you encrypt your entire system drive. It doesn't look like that option is available in the OS X version. Also, when I tested the latest OS X binary this evening, the "hidden volume" plausible deniability feature wasn't working. Hopefully that will be added in a future release. Until then, TrueCrypt is better suited for storing tax documents and things you wouldn't want visible to a laptop thief, rather than the details of where you've hidden the bodies.

TrueCrypt - [via] Link

January 15, 2008

Unlimited ripping of Netflix "Watch Now" movies

A while ago we wrote about removing the DRM from Netflix "Watch Now" movies. At the time, it involved wading through a bit of HTML source to find the target video URL. Since then, a couple of important things have happened: a Greasemonkey script was written that makes it a bit easier to download and process the DRMed WVM file, and more importantly, Netflix is now allowing unlimited downloads.

What can you do with this? Well, you can download a number of videos ahead of time and then watch them at your leisure, especially if you travel a lot and are offline for extended periods of time. It also means you can convert the files to mp4 format for playing on your mac, iPod or Apple TV device. Or maybe you were hoping to finish that documentary you were making about the strange facial expressions of Sylvester Stallone and needed a few more clips to splice into your film...

How To Rip Netflix "Watch Now" Movies - Link
Netflix Downloader Greasemonkey Script - Link

November 18, 2007

MD5 collision demonstration

MD5, the cryptographic hash function that's often used to verify that files have not been tampered with, has been broken for a couple of years now. A lot of times when you hear about some algorithm being compromised, it's not something that's immediately practical to exploit... an encryption algorithm's effective strength is reduced by a bit or two, or maybe a hash function has been compromised such that a huge amount of computational effort can make a completely bargled file that has an identical checksum to a known source. Not so in the case of MD5, as Peter Selinger describes:

It is now well-known that the crytographic hash function MD5 has been broken. In March 2005, Xiaoyun Wang and Hongbo Yu of Shandong University in China published an article in which they describe an algorithm that can find two different sequences of 128 bytes with the same MD5 hash. ... As we will explain below, the algorithm of Wang and Yu can be used to create files of arbitrary length that have identical MD5 hashes, and that differ only in 128 bytes somewhere in the middle of the file.

Selinger's example exploit will allow you to produce two working executable files with different behaviors, but matching checksums. Presumably, one would be a file with the intended behavior, and the other an "evil" version that could be slipped in as a replacement without anyone knowing. Pretty interesting stuff.

Collisions in the MD5 cryptographic hash function - Link

November 5, 2007

How NOT to use TOR

A lot of people use TOR as a sort of anonymity and encryption magic bullet, but that's really not what it's designed for. Your packets are encrypted and routed through various TOR nodes, each node only knowing about the node on either side of it and unaware of the full routing path, until finally it pops out of an exit node, is decrypted and then sent along its way to the destination. The fundamental idea is that only the exit node knows the final destination, and it doesn't know where the packet originated unless the operator of the exit node is in cahoots with all the other nodes along the packets' route. TOR is a routing anonymization service.

A couple of months ago, 100 government and embassy email account passwords were published by Dan Egerstad. What did these email accounts have in common? Individuals from these organizations were presumably using the TOR network to protect their communications, but by sending unencrypted traffic over the TOR network, they were actually exposing this data to a lot of potentially nefarious parties. But wait, the data moving over the TOR network is encrypted, right?

Which brings us back to the exit node. Your data leaves the TOR network in its raw form. So if you are using an unencrypted protocol, your communication can be read (or modified) by the exit node or anything between the exit node and the destination server. So while your immediate ISP can't really tell who you are sending packets to, someone at an exit node can, and chances are good that that someone is more interested in your communications than the average server on your normal routing path.

This someone might be a government entity, a criminal organization, or maybe just some Swedish security researcher dude who is interested in what's going over his five exit nodes and decides to publish the more interesting tidbits for the world to see.

Just to give you something to think about we did look into a few servers out of 1000 we thought looked interesting. We aren't trying to tell you what to think, you will have to do that yourself.
Example of Exit-nodes that can read your traffic:

• Nodes named devilhacker, hackershaven...
• Node hosted by an illegal hacker-group
• Major nodes hosted anonymously dedicated to ToR by the same person/organization in Washington DC. Each handling 5-10TB data every month.
• Node hosted by Space Research Institute/Cosmonauts Training Center controlled by Russian Government
• Nodes hosted on several Government controlled academies in the US, Russia and around Asia.
• Nodes hosted by criminal identity stealers
• Node hosted by Ministry of Education Taiwan (China)
• Node hosted by major stock exchange company and Fortune 500 financial company
• Nodes hosted anonymously on dedicated servers for ToR costing the owner US$100-500 every month
• Node hosted by China Government official
• Nodes in over 50 countries with unknown owners
• Nodes handling over 10TB data every month

We can prove all this but not the intentions of each server. They might be very nice people spending a lot of money doing you a favor but it could just as well be something else. We don't however think it's weird that Universities are hosting nodes, just that you need to be aware of it. Criminals, hackers and Governments are running nodes, why?

The moral of the story is that you shouldn't use TOR for the purposes of secure communications. You should be using TOR to anonymize routing. If you are passing indentifiable information over the wire that you don't want read, such as your email or bank information, you need to use a secure end-to-end encrypted channel, like ssh, https, or ssl-imap. What TOR provides is a mechanism for anonymizing the routing of your communications so that people in your routing path don't know who you're sending a message to.

Moral #2 is that information you send through the TOR network is more than likely under higher scrutiny by many interested parties. Encryption matters here more than anywhere else.

How 100 sensitive accounts were compromized - Link
Anonymity and the Tor Network (Schneier) - Link

October 31, 2007

Decrypting GSM

Check out this video from last August's CCC Camp, which describes using a Universal Software Radio Perhiperal (USRP) to record GSM messages, and then using an FPGA to defeat the A5/1 encryption that's used to secure an encrypted GSM channel in the span of a couple weeks. By spending a couple months to precompute a 5 TB lookup table you could bring the decryption process down to just a few minutes.

First half of the talk is an introduction into GSM interception. Second half presents a new method for cracking the GSM encryption A5/1. This is a new attack that can crack any encrypted channel (SMS, Voice) within 3-5 minutes regardless of how long the conversation is (e.g. can crack a telephone conversation that only lasts 4 seconds).

Now, most of us won't be running out right now to grab an FPGA and a software radio so we can start cracking GSM voice converstations and SMS messages, but the actual discussion of how GSM works and how the team went about putting together a real-time cracking method for A5/1 is fascinating. What's really crazy is that for a few thousand dollars, anyone could really set up a GSM recording and cracking system. This isn't just NSA or government-funded spy stuff.

At about the 19 minute mark, Steve talks a little about how mobile identification and position information is transmitted. If you've ever called the phone company to track down a stolen phone, you've probably been told this isn't possible. Turns out that if you've had a phone lost or stolen, it actually transmits its position information _all_the_time_. So, technically, your network operator should be able to tell you the phone's location to within 200 meters.

The A5 Cracking Project - [via] Link
GNU Radio - Link