Intrusion detection

“I guess I forgot to lock the door.”

Physical security is something we often take for granted, but it can be just as important as cyber security. One of my clients recently called to say that some suspicious files had suddenly appeared on one of their servers. Naturally, I investigated, but I couldn’t find any breach in the firewall or any indication in the IDS logs that the network had been hacked from outside.

After spending a couple of hours digging around in the server logs, I finally dug into the registry and found that the files had apparently come from a USB device that had been plugged into the server around 9:30 pm on the day in question. Since only three people have access to the servers–myself, the IT Manager and the Controller–and none of us were guilty, I had to suspect that someone had gained unauthorized access to the server room.

Sure enough, the IT Manager recalled leaving early on an emergency the day of the incident and with a sheepish grin told me, “I guess I forgot to lock the door.”

We now have an electronic combination lock on the door and only the three of us have the code. The door automatically locks itself three seconds after it’s opened, so “forgetting” isn’t an option.

Lesson learned. Fortunately, the files were benign.

How to Use the Windows Registry for Cyber Forensics: Part 2

In Part 1 of this series, I introduced you to the concept of date/time coincidence and we explored five registry keys that are useful to the forensic examiner. This time, I’ll show you how data can be encrypted and hidden in the registry.

If you’re involved in data security, you’re familiar with cryptography in some fashion and you know that ciphers - algorithms for performing encryption and decryption - are what do the work. You probably also know that there are a few quick-and-dirty algorithms for encrypting data. One such algorithm is known as the Caesar Cipher, or ROT-13, a simple algorithm that encrypts data by shifting each character 13 places in the alphabet while leaving non-alpha characters untouched. It’s so simple that you can decrypt it manually, but it’s enough to fool the casual observer. Anyone coming across something like cnffj beqsb egurf rperg svyrf vfcnf fjbeq, is naturally going to assume it’s encrypted; in fact, it’s ROT-13 for password for the secret files is password. I broke it up into five-character groups to make it more convincing.

For whatever reason, Microsoft uses ROT-13 to encrypt data in some registry keys. One such key is: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist. Here’s an example: “HRZR_EHACNGU:P:\AFYBBXHC.RKR.” Decrypted, that’s “UEME_RUNPATH:C:\NSLOOKUP.EXE.” (We’ll look at the UserAssist key in Part 3.) A better way to hide data is to encode text-based information in binary format and store it in binary form as a string in registry values of type REG_SZ. Given that binary data is common in the registry, the technique would make it extremely difficult to retrieve the hidden information.

In addition to using ROT-13 and binary encoding to obfuscate data, a suspect could take advantage of a flaw in the registry editor to also make the data invisible to anyone but a forensics examiner who knows about the flaw. From “Forensic Analysis of the Windows Registry:”

The Windows 2000 and XP Registry Editor (regedit.exe or regedt32.exe) have an implementation flaw that allows hiding of registry information from viewing and editing, regardless of users access privilege (Secunia, 2005). The flaw involves any registry values with name from 256 to 259 (maximum value name) characters long. The overly long registry value (regardless of type) not only hides its own presence, but also subsequently created values (regardless of type) in the same key (Franchuk, 2005). The editor stops displaying the remaining of the values thinking the overly long value as the last value in that key. Suspect could exploit such Registry Editor flaw to hide information.

The Windows console registry tool (reg.exe) can display these overly long registry values so the hidden data can be recovered as evidence; however, given the sheer number of entries in the registry, this process is not trivial.

I hope this series is giving you some insight, perhaps even piqueing your interest, in cyber forensics. Hit the comment button and tell me what you think.

In Part 3, we’ll explore some keys that can tell us where a suspect has been storing files.

The Four D’s of Cyber Security: Deny, Discriminate, Detect, & Destroy

This is an interesting and sensible approach to security.  I would call these the “Logics of Cyber Security” because they’re so basic they could well be the principles upon which all cyber security can be based. The paper’s authors call them “first principles,” defining such as “…a basic foundational proposition or assumption that cannot be deduced from any other proposition or assumption”–in other words, logics. (You can read the orginal article, “A Thematic Approach to Cyber Security Using First Principles” and the link to its latest revision at https://wiki.cac.washington.edu/pages/viewpage.action?pageId=7481170&navigatingVersions=true. Note: The article hasn’t been updated since February, 2008.)

Here’s a simple overview of these principles.

DENY — default deny is an absolute must when making shared resources available via servers, network storage, and the Internet. You block everything until you are able to determine whether the entity attempting access is authorized. Another method of denial is encryption. This could be used to provide more granular application by, for instance, denying access to certain resources if the otherwise authorized user has no security clearance for the resource.

DISCRIMINATE –there are several ways one can discriminate between authorized and unauthorized access attempts, the simplest being a password; smart cards, biometrics, and security tokens are other examples, all of which should result in the access attempt being classified as either authorized or unauthorized.

DETECT — some means to detect unauthorized access attempts must be in place. In a Windows environment, one could activate auditing at both account level and resource level. Intrusion detection systems, both network and host based are designed for this purpose.

DESTROY — when unauthorized access attempts are detected, rules must be activated that effectively disrupt the attempt before the resources are compromised. This could be accomplished by dropping the connection, blacklisting the IP, etc.

CERT Says Linux is Under Attack

It had to happen sooner or later; as Linux gains an ever-increasing foothold (Linux market share to reach 7% in 2008 ) in the market, it will become a viable target for criminal hackers. According to the U.S. Computer Emergency Readiness Team (CERT) in US-CERT Current Activity, attacks are already underway:

US-CERT is aware of active attacks against linux-based computing infrastructures using compromised SSH keys. The attack appears to initially use stolen SSH keys to gain access to a system, and then uses local kernel exploits to gain root access. Once root access has been obtained, a rootkit known as “phalanx2″ is installed.

Phalanx2 appears to be a derivative of an older rootkit named “phalanx”. Phalanx2 and the support scripts within the rootkit, are configured to systematically steal SSH keys from the compromised system. These SSH keys are sent to the attackers, who then use them to try to compromise other sites and other systems of interest at the attacked site.

For now, the attack is easily detected (though variants of the rootkit will likely change its behavior): The attack creates a directory “/etc/khubd.p2/” that is hidden from “ls,” but it can be entered with “cd /etc/khubd.p2″. Any directory named “khubd.p2,” regardless of its location, is hidden from “ls” but can be entered using “cd.” Additionally, “/dev/shm/” may contain files from the attack, so anything unusual in there is suspect. You can also try searching for hidden processes and checking the reference count in “/etc” against the number of directories shown by “ls”.

Check out the full article, “SSH Key-based Attacks” for complete details on risk mitigation and compromise response.

New Article Series: Software for Secure Computing

I recently posted the last article in my How to Secure Your Computer series of security maxims (an eBook will be available shortly–stay tuned for details). While editing the book, I realized there’s a wealth of free and Open Source software available that can help anyone from the novice to the professional practice secure computing.

My “Nine Steps to System Security - 2008” (originally posted as “Seven Steps to System Security - 2004“) is the latest iteration of what is essentially the basis of all the maxims. It lays out a plan that’s been proven highly workable and will serve as a rough guide for the sequence of articles in the new series. The maxims will provide additional layers as the series develops.

At last count, there were 26 pieces of software mentioned in the main articles. Many of those will be grouped into a few general categories, but I believe the Software for Secure Computing series will be substantial.

First in the series will be “Software for Secure Computing: Secure Browsers.”

Top Five Personal Firewalls

How well does your personal firewall protect you? GRC’s Leak Test, PCFlank, and Bob Sundling’s TooLeaky all provide a quick way to check your personal firewall to see if it effectively blocks outbound connections. But if you really want to know how well your firewall protects you against a whole host of known attacks, check out Matousec’s Firewall Challenge website. Here are the top five based on Matousec’s extensive testing:

1. Comodo Firewall Pro 3.0.21.329 (Free)
2. Online Armor Personal Firewall 2.1.0.119 ($40, Free version available)
3. ProSecurity 1.43 ($30 single PC home user, $40 household)
4. Outpost Firewall Pro 2008 6.0.2302.264.0490 ($40/year for 3 home PCs)
5. Kaspersky Internet Security 7.0.1.325 ($80/year for 3 PCs)

The top two, Comodo and Online Armor, scored 100% on the tests. I’m using Comodo from now on.