The Hacker Factor Blog

While nobody likes to be stereotyped, there is some truth behind the generic, nationality-based profiles. For example, I was recently in Australia as part of a necessary trip. I was waiting with a small crowd of people outside a grocery store, waiting for it to open. I could instantly separate the tourists from the locals. There was a large set of people standing by the door. They didn't move; if it weren't for the occasional breath, I would have thought they were statues. They were the local Aussies. They were patiently waiting for the doors to open.

A minority of the people were more anxious. They would shuffle their feet, constantly look around for a place to sit (benches are a rarity outside of tourist areas), and check and recheck their watches. They were the tourists.

The grocery store was supposed to open at 7:00am. At 6:59 and 28 seconds, a trio came down the escalator. They never checked their watches and never looked for a clock, yet they appeared concerned that the store was not open. I knew their nationality even before they spoke: punctual to the second, knowing the time without a watch? German.

All of this makes me wonder... could stereotyping by nationality act as a first-pass for identifying some cybercrimes, such as denial-of-service attacks? For example:

• Western Europe is usually punctual to the second and well planned. A DoS should start at a precise time and last a precise duration. It should not vary from the plan during the attack.
  
• Chinese value punctuality and uniformity. A DoS should be similar to Western Europe, but should not vary in attack methods. For example, if there are 10,000 computers being used in an attack, they will all be configured the same way and used the same way. You won't see a variety of simultaneous attacks.
  
• Latin America and Mexico value content over punctuality. It's OK to be late as long as you contribute. A DoS may not start on time or appear initially organized or even homogeneous, but all attack-bots should contribute to the fray.
  
• The USA and Canada are stereotypical in that they are not extreme in any single dimension. An attack may not start precisely at 1:00, but it will be "around 1:00", it may not be homogeneous, but it will be close. And it may change as needed rather then exhaust one attack method. Americans are also more solitary. You won't see a hundred American hackers working in unison on the same target as you would in China or Brazil.

Using these generic and empirical profiles, we can start guestimating who is behind some known attacks. For example:

• The recent DoS against the root level DNS servers started exactly on the hour. At intervals of 1 hour, there were changes to the attack method. Both the Western Europe and China match this kind of attack: precisely timed, planned, homogeneous, and exhaustive.
  
• The attack against Blue Frog did not start at any particular hour/minute, but it was well choreographed. Each time the attack succeeded and Blue Frog moved on to an alternate safe haven, a new attack method would be initiated. Planned, yet not long-term planning. There was also only one type of attack at a time, suggesting an individual or very small group. This sounds like an American or Canadian.
  
• Similar to Blue Frog, the Smurf attacks from Mafiaboy were not precisely timed, but were exhaustive, showed short-term planning, and were independent attacks. Mafiaboy was Canadian.
  
• The recent DoS against GoDaddy was reportedly spread across a few days, building as it went. It was a variety of attack methods that all assisted in the total attack. This sounds like Latin America and the hacker groups in Brazil immediately come to mind.

Stereotyping and profiling is commonly criticized for its inaccuracy. Not every American is fat, self-absorbed, and eats doughnuts for breakfast. Similarly, there is fuzziness since people may not be located in their influencing country. For example, a Brazilian who is married to a German and living in Canada may appear as any one of the stereotypes, or as a combination. (Then again, a Brazilian married to a German and living in Canada is probably not stereotypical.) However, profiling can be used to organize information before wasting time in an exhaustive search for a likely suspect. It will take time to develop this profile method from empirical to practical. And it leaves me wondering: can stereotyping network attacks be turned into something more definitive?

Thanks to the Internet Storm Center for their feedback and valuable comments.

I got bit by a wild cockatoo. It was a white, sulfur-crested cockatoo. It seems, they have learned to eat out of people's hands -- so I (and most other people on the tour bus) were feeding them. A few of the birds learned that if they bite or scratch the hand that feeds them, then the other hand will drop all of the food it is holding.


One bird scratched my hand (didn't break the skin, but it did startle me and I dropped food). Another bird began stalking me. Every time I tried to feed anyone else, he was there. He ended up biting my thumb -- more like a 1/2 inch paper cut. However, I didn't drop the food for him. Net result? Bird drew blood and didn't get seeds. And I learned that the antiseptic liquid in wet-wipes burns like hell.

How does this relate to computer security? Many organized crime gangs use hostile tactics such as DDoS to blackmail companies into handing over money. And on a smaller scale, I know a half dozen users without any ethical or social values who use impersonation and deceitful tactics to intimidate honest netizens. Like the wild cockatoo, don't give in to these threats or they will only be encouraged, continuing their abuses on other people and escalating from scratches to bites.

I manage a heterogeneous network of computers. They range from an old (but necessary) OS/2 box to various Windows and Linux releases, as well as Mac, HP-UX, and Solaris. Knowing how to repair the system is always critical, since you will eventually do something stupid and hose the system. And "reinstall" is usually not a desirable option, and I consider restoring from backups to be a final course of action when there are no other options.

Each operating system has its own recovery method. In most cases, if I can get to a command-prompt, then I can repair or recover anything.

• For Linux and BSD, there are plenty of "live CD" systems you can use. Knoppix and Damn Small Linux (DSL) immediately come to mind, but there are many others.
  
• For Windows, I can either use Knoppix or the Windows recovery disks. (However, I usually don't use the recovery disks for anything except getting me to a working command prompt. Usually "recovery" means "reset to factory default", and that is an unacceptable solution to me.)
  
• All of the Linux, BSD, and commercial Unix systems (e.g., HP-UX and Solaris) have single-user modes for system repair, or have Live CDs for getting to a command-prompt.
  
• The OS/2 box is supported by the OS/2 installer's CD-ROM (or floppy disks -- yes, OS/2 is old).
  

However, I recently screwed up my Macintosh system (running 10.3). I was trying to optimize it and followed some bad advice from a newsgroup. You see, there is a program called /usr/sbin/lookupd that performs caching of things like DNS requests. Since I don't need the system to cache DNS data, I disabled lookupd. Big mistake; Don't do this! Without lookupd, you cannot run su or sudo in order to become root and undo the change. Furthermore, if you reboot then the login screen will hang.

If you screw up the system (like I did), then you have few options. Knoppix cannot write to the HFS journaling file system (the default OS X install) so you cannot undo the mistake via a Linux system. While, I did find a few solutions that work, all require you to have a second Mac handy. Some of the solutions:

• Use the OS X install and repair CD to reset the system. This will move the corrupt system out of the way and install a new OS. This is a good last-ditch effort, but you will spend hours putting back all of your customizations. Furthermore, I just needed to put back lookupd so a complete reinstall seemed like overkill. ("Next!")
  
• You can connect two Macs using a firewire cable. On the dead one, boot it while holding "T" (right after the chime). This will make it act like a firewire hard drive, allowing the good computer to mount the drive. Then you can repair it. Unfortunately, I don't have any 6-pin to 6-pin firewire cabled. ("Next!")
  
• There are a variety of tools for creating a "Live CD" for Mac OS X. Unfortunately, most cost money ($5 to $100 and up) and the reader feedback makes it sound like your mileage may vary. I'm not willing to drop even $5 on a solution that does not have a solid track record of working.
  
• Then I came across one good program: BootCD. This program will create a Live OS X CD-ROM image and it allows you to select the tools that you want on the system. I selected the Terminal (for the needed command-prompt), Console, System Profiler, and Safari. It's slow -- on my iMac it took nearly an hour to build the base image and 10 minutes per application selected -- but it did create an image, and you only need to do this once. Unfortunately, my iMac only has a CD/DVD reader, and not a writer.
  
  
  
  • I transferred the image to my Ubuntu system (calling the file emergency.iso).
    
  • Although the graphical Nautilus "Write to Disc" option said it was not an ISO, I was able to burn it using cdrecord: sudo cdrecord -blank=fast emergency.iso.
    
  • I put the Live CD in the dead Mac and booted with the Option key pressed. This gave me a choice of boot media, listing the dead hard drive and the Live CD.
    
  • I selected the CD option and booted off it! (I really like software that works as advertised.)
    

The CD is definitely not optimized; you could hear the drive thrashing as it went seeking sectors. However, after a few minutes it did boot! The Terminal application was in the toolbar and opened to a root prompt. The dead hard drive was already mounted at /Volumes/Macintosh HD (use df to see where it is mounted). I was quickly able to fix lookupd (Yes, all of this just so I could run chmod a+x lookupd.) One more reboot off the fixed hard drive and the system was back to normal.

If you happen to have a Mac running 10.1, 10.2, or 10.3, I strongly recommend using BootCD to create a Live CD before you need it. With any luck, you will never need to use this disk. But when you screw up, you will be glad you have it. (Unfortunately, BootCD does not work with 10.4. I suspect that you can create a 10.3 CD and use it for repairing 10.4 systems.)

All of the tools that create Live CDs for the Mac require a running operating system. For this reason, people do not distribute live CD images. Doing so would violate Apple's copyright on their operating system since you would be distributing Apple's code.

It always amazes me when people blindly trust ubiquitous sources. Take Google as an example. The word "Google" has become so universal that the word is understood in all languages; "Google" in English has the same meaning as "Google" in German, Hindi, and Japanese! In fact, the word "Google" it has been added to the English dictionary.

Since Google is widely known, people assume that they can trust it. In 2004, the local TV news (yes, it was the FOX affiliate), reported on phishing. The reporter said that you should use Google to search for your credit card number in order to see if it is found in any online lists. Don't do this! This was the recommendation of the reporter, and not my suggestion.

Some search engines have features like "view recent searches" where you can see what other people are searching for. If you use one of these search engines, then you have no idea who will see your credit card number.

While the Google search engine does not have this feature, Google does collect searches. If you search for your credit card number, then Google will store the number indefinitely. Occasionally we hear about governments requesting copies of Google searches. Some of the requests have been successful, while others have been denied. While these governments are requesting specific types of information, it demonstrates that anything stored at Google could be handed out with the correct legal request. As long as there is data storage, there is also the risk of data leakage. In 2006, AOL released the search information for over 600,000 people. Many of the searches were unique enough to identify the individuals.

Another area of controversy concerns Google Earth. This service uses very high resolution pictures -- down to 6 inches (15 cm) per pixel. Governments have been requesting some sensitive buildings, military bases, and other areas to be blurred or blanked out. Most recently, India has requested the blurring of some strategic military locations. The problem again seems to be misdirected trust. While it is bad to give your enemies high resolution images of sensitive installations, there is another problem: Google now hold a master list of all sensitive areas from multiple countries. If one hacker or disgruntled insider gains access to this information, then the attacker can certainly sell it for a significant profit or use it to help overthrow governments.

With all of this information at hand, I must wonder about the security and practices used by Google. Is it really a good idea to put all your valuable information in one place? And in particular, in the hands of a publicly traded company?

Many of the papers I write are directed toward identifying technical problems. The goal is to raise awareness with the hope that people will recognize the issues and make changes to reconcile the problems. While I sometimes list resolution methods, I usually stay away from telling programmers how to do their job. (As a software engineer, I know my code better than anyone else. If you tell me about a problem, I am capable enough to create a solution. By not providing solutions in my papers, I extend this same courtesy to other programmers.)

It always gives me a warm feeling when papers that I write end up leading to significant changes. For example, in April 2006 I wrote a paper titled Point-of-Sale Vulnerabilities. This white paper details many of the fundamental design flaws in the point-of-sale architecture for credit card processing. Although there are a few explicit exploits mentioned as examples, the majority of the text covers high-level attack vectors. The specifics may differ by vendor, but the attack vectors remain the same.

While I have not released this paper publicly, I know that it has been received by many of the right people. Things that have happened since the limited, non-public release of this paper:

• Visa released three (3) advisories: June 2006, July 2006, and August 2006. (The June advisory directly quotes my paper, even though no citation is provided.) While these alerts do not cover all of the risks identified in the paper, these are three of the bigger ones.
  
• Visa began to audit all of their credit card processing customers for PCI compliance. This Visa-wide audit started less than two months after the paper was released. (Coincidence?)
  
• Almost overnight, a specific model of credit card reader was secured at every location I could find. This specific reader is used as an example in the paper and everyone secured it at the same time. Furthermore, they used one of the methods for securing them that I described in the paper.
  
• TJX, the parent company of Marshalls and TJ Maxx, found a massive compromise that had been going on quietly for years! I need to ask: was it found due to an audit kicked off by my paper? In my paper, I used the big-box retailer aptly named "Target" as a detailed example. The scope of the TJX exploit and the style of compromise was dead-on with the attack vector and anticipated damage that I described.
  

Even though I know that high-level management at Visa have received the paper, I find it ironic that nobody from Visa (or MasterCard or any other credit card) has ever contacted me.

The reason I mention all of this concerns a recent paper of mine. In Laptop Losses and Phishing Fruit Salad, I pointed out many of the floating statistics that are designed to give us concern yet have no basis for measuring risks. In this paper, I used the APWG as an example. Basically, they don't describe what they collect, how they collect it, or details of their analysis methods and information biases. It seems that this paper has hit its mark; Dave Jevans, the Chairman of Anti-Phishing Working Group, wrote:

We do try to describe the methodology in each of our monthly reports, posted at www.antiphishing.org. We will look to enhance this description in the next report.

Dave

Let's hope that future numbers from the APWG will paint a clearer picture for evaluating the risks. Let's also hope that other organizations will elaborate on their collection and analysis methods.