The Hacker Factor Blog

I'm a big fan of non-classical computer forensics. When most people think of computer forensics, they think of recovering deleted files, cracking cryptography, or de-worming an infected computer. But there is so much more...

Digital image analysis has a warm place in my heart. This is a relatively new field and very cutting-edge. While there has been plenty of work on creating realistic computer graphics and better animation, there has been very little focus on detection and analysis. There are maybe a handful of researchers in this area, and they are all working on different problems.

Cynthia Baron recently published a book titled Adobe Photoshop Forensics: Sleuths, Truths, and Fauxtography. If you have any interest in this field, then I expect you to be as excited about this book as I am. There are few (if any) books that really delve into digital image forensics, and Baron has done an excellent job covering the topic.

But before I begin, I should fully disclose my ties with this book. When I was preparing my Black Hat talk on digital image analysis (PDF), I had asked Baron to be a technical reviewer. Back then, I knew she was writing a book, but I didn't know the details. (In all fairness, she has authored nearly a dozen books, so "she was writing a book" should never come as a surprise with her.) She had sent me a variety of pictures to analyze and the results were very interesting. (Many of the pictures are in the book.) She also wrote a little about my own work -- I am mentioned on 6 pages, including 4 that are just about me! (Cool!) However, while I am mentioned in the book, I was not involved in the writing or reviewing of the book. Moreover, the vast majority of the book does not cover anything about me or my work.

I consider this book extremely well written. It provides an excellent overview of the topic and dives down into some detailed examples. This is not a programming book -- you won't find source code in it. What you will find are methods, techniques, and pointers for more information.

The thing that impressed me the most is the general flow of the text. Each section of the book covers the impact from fraudulent images, detailed examples, techniques for professionally modifying images, and methods to detect modifications.

• Part I covers counterfeiting and legal implications. (I really like her detailed examples of fake medicine packaging and the manipulation of photos to sway juries.)
  
  
• Part II is my personal favorite: professional misconduct. A picture is worth a thousand words. Want to create a sensational news story or spread propaganda? Here's how...
  
  
• Part III covers what I usually consider "shopped" (or "manipulated with Photoshop") images. Things like taking 10 pounds off a picture or removing wrinkles.
  
  
• Part IV delves into the more fantastic images. It covers everything from UFOs and ghosts (want to fake a UFO photo?) to steganography.

There are many legitimate reasons for needing to know these graphic modification techniques. However, they can also be abused. Understanding the forensic aspect -- how to detect the modification -- can be crucial. Each chapter of this book has plenty of real examples, interesting sidebars, colorful photos, and useful tips. Whether you want to create fakes, detect modifications, or just learn more about this field, Adobe Photoshop Forensics is a must read.

I regularly monitor my web logs. This allows me to identify potential attacks, and compute metrics like "what are my popular blog topics?". Web logs include origination IP addresses, where people went, and where they came from (the referer[sic] links).

There is no such thing as online privacy. When you click on a link from a search engine, the recipient system sees the query you entered since the query is in the URL and listed as a referer to the site. As AOL learned, queries are frequently distinct enough to identify people and motivations.

Some referers to my site are just creepy, like people searching for pornography with bears (I'm not making this up) and finding a link to my Think Like The Bear blog entry. However, some have been rather humorous...

• "GET /papers/cc-pos-20.pdf%20%20I%20hate%20seeing%20our%20name%20on%20this%20stuff"
  After I released my paper on Point-of-Sale Vulnerabilities, my logs recorded this request. This user went to the paper, but included additional text. In all likelihood, the user received a link to my paper in an email and the mailer included text after the URL as if it were part of the URL. (This is a common error, and a symptom of another security risk.) In this case, the text after the URL said, "I hate seeing our name on this stuff". The source IP address? It traces to a company explicitly mentioned in the paper as having poor security processes. (My reply to them, "If you hate seeing your name associated with credit card vulnerabilities, then stop doing stupid stuff.")
  
  
• "Referer: http://www.google.com/search?q=does+PCI+require+consumers+to+change+password+90+days&hl=en&start=10&sa=N"
  This user was searching Google and trying to see if the PCI DSS requires password changes after 90 days. While I am glad to see that they are looking up this information, I am disappointed that the source IP address came from one of the big credit card processing centers. (And the answer is "yes" -- PCI DSS recommends new passwords at least every 90 days. See section 8.5.9.) I can only hope that this was a curious employee and not their person responsible for PCI compliance. (Let's hope they are one of the 65% compliant and not the 35% non-compliant.)
  
  
• My logs have recorded many automated malware scans. (These happen daily and are a regular feature on the Internet.) One set of attacks came from an interesting IP address -- they originated from inside the firewall of a large online retailer. They appear to have botnet nodes inside their network. Adding to this problem: (1) they have no contact method for reporting security vulnerabilities and (2) logs indicate that the compromise has been exploited for over a year. Using the old-boy's network (thanks M.!), I have reported this to the right people. Hopefully these systems did not have credit card access. (If they did, then this could rival the TJX compromise.)
  
  Update: It is a Friday on a 4-day holiday weekend, and they just got back to me. No credit cards or customer information appears to have been compromised. The system(s) have been taken offline until they can better understand what was going on. (It may not have been part of a botnet, but was showing abnormal behavior.)
  
  
• There have been a series of people searching for carding-related sites, such as "http://www.google.lt/search?hl=lt&q=cvv2+fulls&btnG=Paie%C5%A1ka&meta=", "http://www.google.com/search?q=free+cvv2+and+cc+with+fullz+and+forum&hl=en&start=60&sa=N", and "http://devilfinder.com/find.php?q=sell+cvv". I'm honestly glad to see that the bad guys are having trouble finding their forums. This also means that they are stoopid enough to get caught.

Web logs record everything and offer no privacy. Adding to this problem, there are plenty of web sites that give really bad advice. For example, Alister Cameron recommends using Google to search for your credit card numbers and other personal information. Google is not a government agency and they hold onto all searches for years. If you search for your name, credit card, and social security number, then Google will save that information. (Congratulations! You just compromised yourself!)

As a user on the web, you should assume that sites are logging your connections. And anything you search for could be read by anyone else, any time in the future.

While Elvis the Turkey sits in the oven, awaiting the next basting, I thought I'd blog about Thanksgiving.

Normally this American holiday is about giving thanks for the things we have. In this regard I thank pretty much everyone I have communicated with over the last year.

As for the actual meaning of Thanksgiving, I think this cartoon (which Valdis showed me) really captures the essence of the holiday:



Following Thanksgiving comes the 33 days of Christmas. (Actually, "33+" since many stores started playing that horrible music as much as a few weeks ago. It probably wouldn't be that bad if it wasn't the same 7 songs over and over and over for over a month... but I digress.)

This year, many people have asked me about online shopping and credit card security. My general response can be taken as good news or as bad:

This year, online shopping is as safe as in-store shopping.

The reason is pretty simple -- nearly all big companies are sending credit card information across networks and storing information in centralized servers. And as Visa pointed out, more than a third of large merchants have not implemented even the minimal security requirements.

The level of personal security this year is really up to the individual. Here's some quick tips that I'm sure you're already doing...

• Shred credit card receipts (you have a cross-cut shredder, right?).
  
• Don't lose track of your purchases and watch your credit card statement.
  
• Shop with a credit card and not a debit card (debit cards have no loss limit).
  
• Watch out for anything suspicious (in-store and online).
  
• Don't shop online from a remote location, like a coffee house, bookstore, or hotel; only do it from the comfort of your own home. Remember: you don't know who is watching the network, and this is the season for the biggest compromises.
  
• Along with remote shopping, don't assume that HTTPS and that little lock on your browser means you are secure. "HTTPS" only means it uses SSL and not that the connection is secure.
  
• Check your system for viruses before shopping online. If your computer is running "slow" or having odd pop-ups or unknown programs run, then you are probably infected. Shopping online with an infected system is as secure as handing your wallet to a mugger.

If you do these basic steps, then you will probably be alright (since any financial compromise will be outside of your own control).

This year, give thanks for what you got, and don't give away things you want to keep. Have a safe and happy holiday season.

Your average non-technical user knows that they need "security", but do not know what that actually means. Many also have heard the buzzword "cryptography" enough to know that it is important, but do not understand why. Even people who say cryptolec sounding phrases like "DES is a weak cipher" may not actually understand what they are saying -- even if they know it is weak, do they know what "weak" mean?

The problem with cryptography is repeated in other fields. For example, just because I can drive a car does not mean that I understand what all those things under the hood really do. And while people may brag about great gas mileage, they usually don't know all of the different things that can impact fuel consumption; everything from tire pressure to fuel quality impacts performance. My first car got 40MPG mixed highway/city driving, but that was heavily influenced by my driving habits. When other people drove my car, they got around 30MPG.

And this bring up another problem. Web browsers use a little lock icon to denote a secure connection. However, the little lock on the browser only says you are using SSL, not that the algorithm is strong. In fact, SSL is not a secure cipher at all -- it is a framework for negotiating and managing ciphers. "Plain text" is not secure, but is the "NULL cipher" -- great for debugging. And while the NULL cipher is supported by every SSL library I have seen, it is usually disabled by the application that uses the library. However, if you use SSL with the NULL cipher, then you still get that little lock in the browser. The lock does not mean "secure", it only means SSL.

And SSL's usage leads to a usability problem. Consider this snippet of HTML:

<frameset cols="50%,*">
  <frame src="https://isc.sans.org/">
  <frame src="https://www.paypal.com/">
</frameset>

Save this snippet as "snippet.html".

• If you load the snippet using HTTP (http://.../snippet.html), then you get two frames that each use SSL. However, since snippet.html uses HTTP, you won't see the little lock in your browser.
  
• If you load the snippet using HTTPS (https://.../snippet.html), then you get the little lock in your browser. But the lock only represents your initial SSL connection and not the contents of each frame.
  
• In addition, the HTTPS from PayPal actually uses SSL connections to 4 different servers, but since you cannot view the SSL connection information, you do not know if they are secure or not.

In fact, there are many different parts to the cryptographic-secure problem that most people do not realize. For example:

• Random number generator. It was recently pointed out that the random number generator in Windows is not very random. A poor random number generator allows an attacker to more easily reproduce the seed number.
  
• Algorithm. A weak algorithm reduces the effort for an attacker. And as Bruce Schneier pointed out, some algorithms may even contain backdoors. (And did anyone notice that the backdoor algorithm was reportedly planted by the NSA and the NSA also helped Microsoft develop security for Windows? I cannot help but wonder if the weak random number generator is related to this.)
  
• Algorithm parameters. WEP is not secure, but the fault is not in the algorithms. The problem is with the algorithm's parameters. In the case of WEP, the initial vector (IV) is too small. For 64bit encryption, there are only 4096 different IV values.
  
• Exchange protocol (e.g., Anonymous Diffie-Hellman) and Authentication system. This is where SSL goes horribly wrong. An established SSL connection usually uses good-enough security options. An attacker is unlikely to hijack an established connection. However, the initial setup of the SSL connection can be easily hijacked, compromised, etc. In this situation, your connection will be securely encrypted, but you will be connected to an untrustworthy source (man-in-the-middle attack). Basically, unless you use client-side certificates, SSL cannot be fully trusted. And how many online banks issue client-side certs to customers? Oh yeah, zero.
  
• Key strength. This goes back to "choose a good password". Again, few non-hackers/crackers have ever heard of John the Ripper. And of the people who do use it, I doubt many have taken the time to really look over the default rule sets.

The Internet Storm Center recently quoted one of their readers, Craig:

"just because your pieces fit and operate as a cryptographic system, doesn't mean that you put them together in a way that makes the cryptographic system secure"

Adding to the "parts is parts" mentality, many cryptographic systems are only secure by name. For example, the HP Secure Web Console has a simple cipher: they do an exclusive-OR of every byte with one byte. (Where's the security? It's in the name.)

The big question becomes: what can we do to improve cryptographic system security?

The first response is almost always "user education". However, there are over 135 million cars on the road -- do we really need 135 million mechanics? And even if we all know that SSL is not secure, we still use it (because there is no other option). The problem is not with the users; the problem is with the systems.

Following user education are usually discussions for full disclosure. I have a different rant about how "more eyes" does not mean "more security". (Just look at RFC 1945 which covers HTTP/1.0. How many people reviewed this RFC and didn't notice the "Referer" spelling error? At least 44 people contributed to this document...) I own a button that says, "Why document? It was hard to write, it should be hard to understand!" Cryptography is a niche skill. Even with commented code, few people are qualified to tell when an algorithm is weak. In the case of HTTPS and the little lock, the algorithm may not be weak, but the implementation can still be flawed.

Finally, providing more information to user's won't improve the situation. Without a basic understanding of cryptography, your average user has no way to tell if 3DES is more secure than AES128. Consider this: if your car had more dials on the dashboard (oil pressure, break pad temperature, battery voltage, etc.), would it make you a better driver?

So here's a question for my twelve loyal readers: what can be done to improve cryptographic security and how we use it? And how can we improve network security?

The results from this year's Department of Defense's Cyber Crime Center (DC3) Forensic Challenge is out!

This was one of the hardest forensic challenges I have ever participated in. It consisted of four classes of problems:

• Media. Imagine a DVD-RW cut in half. Now get the data off of it. Other media problems included a re-written CD-RW (get off the original data, not the rewritten stuff), a scratched up CD-ROM (I think they used a power-sander), and a quarter of a disk (take a CD-ROM and cut it like a pizza, then give each team one slice).
  
• Hardware. They gave each team a dead USB Thumb drive. Get the data off of it. (One member of my team, Kerwyn, did it by removing the memory and soldering it onto a different thumb drive.)
  
• Cryptography. A bunch of challenges with encrypted data. Your job is to identify the encryption system and decrypt the data.
  
• Images. Given some pictures, which are real and which are computer generated? A second challenge had modified images -- identify what was done to each image.

Last year, my team placed 5th. Paul (5%) and I (95%) beat out every government and military team, and most of the commercial and academic teams.

This year? The challenges were much harder. Basically, if you don't crack crypto and don't have any means to recover damaged media, then there were few other challenges that you could attempt. According to the DC3, there were 126 teams, but only 11 teams submitted solutions. Talk about hard... imagine a marathon where less than 10% of the racers even cross the finish line. (Last year, there were 140 teams with 21 submitting solutions. That is still only 15%.)

Teams had a few months to work on the challenges, and a hard deadline for submitting solutions. I didn't think I would win, but I was hoping for one of the top 3 positions. And considering that no solutions had been received one day before the deadline, I felt pretty good.

As it turns out, the big winner was team "Total Recall" from Sam Houston State University! Congratulations Total Recall! Second place went to Cyber Warriors -- another academic team. [Update: While Total Recall had the highest score, Cyber Warriors had the highest score among teams eligible for the grand prize. Congratulations to both teams!] My group, team Hacker Factor, came in third and had the highest score among civilian teams! Rounding out the top five teams were teams AWGN (Air Force Communication Agency) and Super Secret Squirrels (unknown affiliation).

The surprising thing this year was the lack of government (non-military) and commercial teams. There was no highest scoring team in either of these categories. Considering that there were 21 government and commercial teams, someone should have had the highest score in both of these categories. Even though the challenges were hard, the inability for any of these teams to submit any solution (even a partial solution) makes me question the skill set in these markets. (In all fairness, last year's champion was Access Data, a commercial outfit.)

I really need to thank my team. Kerwyn did an amazing job with the USB challenge. (What kind of geek has micro-soldering and surface mounting tools at home? Kerwyn!) Adam and Paul provided excellent feedback on the image analysis challenges. (And of course, me, Neal Krawetz.) Together, we attempted the USB challenge, both image analysis challenges, and the audio steganography challenge. The damaged media and crypto cracking challenges were beyond our combined skill sets.

This is the second year that the DC3 has held the Forensic Challenge. And Hacker Factor is the only team to place in the top five both years. (Brag brag brag)

I have already heard from David Smith, Georgetown University. He said his team solved the CD-ROM "quick erase" challenge (CD challenge #3). (I want to know how he did it! Kerwyn and I knew one way to solve it but we didn't have the right hardware.)