In a sub-continuation of Laura’s earlier article describing the now broken state of MD5 hashes, I’d like to provide a more concise one-stop-shop on how to distrust a CA in the event that this threat becomes more of an attacking reality.

Firefox / Thunderbird

1. In the Menu Bar select “Tools”
2. Select “Options”
3. Select “Advanced” tab
4. Click “View Certificates”
5. Select the “Authorities” tab
6. Select the CA that you would like to distrust “Equifax Secure Global eBusiness CA-1″ in this scenario.
7. Select “Edit” button
8. Uncheck all three areas of trust
9. Select “OK” and exit out, or repeat for any other CAs you would like to distrust

Firefox Certificate List

Firefox Certificate Trust Options

Internet Explorer 7

1. Select “Tools” in the Menu Bar*
2. Select “Internet Options”
3. Select the “Content” tab
4. Select the “Certificates” button
5. Select the “Trusted Root Certificate Authorities” tab
6. Select the CA that you would like to distrust “Equifax Secure Global eBusiness CA-1″ in this scenario.
7. Select the “Advanced” button
8. Uncheck all trust options
9. Select “OK” and exit out, or repeat for any other CAs you would like to distrust

IE7 Certificate List

IE7 Certificate Trust Options

*To make IE7’s Menu Bar visible you need to right click in an empty area in any of the other “bar” areas, this is best done to the right of the current page tab. Then select “Menu Bar” from the drop down.

Making IE7 Menu Bar visible

OS X – Keychain

1. Go to Applications
2. Select Utilities
3. Select Keychain Access
4. Double click the CA in X509Anchors (Tiger) or System Roots (Leopard)
5. In the “Trusts” section, change the trust to “Never Trust”

OS X Keychain Trust Options

For a better guide on accessing OS X items please refer to Laura’s original posting as I don’t have updated screenshots (She’s got the only Mac in-house).

Now you should be able to keep tabs on what trusts are being granted to each CA. In general, you should monitor what trusts you are allowing on your CAs anyway, but with the recent events of the MD5 collapse, it only helps to be a little more proactive.

Each Tuesday, Security Musings features a topic to help educate our readers about security.  For more information about Gemini Security Solutions’ security education capabilities, contact us!

If you haven’t heard yet, a practical attack on the X.509 infrastructure using MD5 hashes has been demonstrated at the Chaos Communication Congress (CCC) today.

The basic gist of the attack is that a “normal” certificate is issued from a well-known and trusted CA (in this case “Equifax Secure Global eBusiness CA-1″) and then use the “magic” of MD5 hashing to create a certificate that collides with the “real” one, but just happens to be a CA. This CA can then issue certificates as they please, and your browser will trust them, no questions asked.

The details are a bit more in depth, and unless you study cryptography, you will find rather boring and dry. However, MD5 hashes have been known to collide in X.509 certificates since 2005, and this paper just takes it a step further and shows how bad this really is. The attack requires a little bit of money (to buy certificates) and some statistics on how the CA operates (how soon certs are issued, what the “next” serial number will be). Then a knowledge of how to collide MD5 hashes is used to create a new certificate – with the CA basic constraint set to “true”. Suddenly, you have a CA certificate that is trusted by all of the major browsers.

What does this mean for “normal” people? It means that an attacker can now create a site that looks just like your bank’s but takes your username and password, and your browser isn’t going to complain about it. You’ll have a lock, or a yellow location bar, or whatever your browser uses to indicate that the site is “trusted” and “secure”. However, you’ll be giving your username and password to the attacker.

What can you do about it? Immediately, remove the Equifax Secure Global eBusiness CA-1 from the list of trusted CAs – I’ve provided links below for how to do that on various systems and browsers. However, that is certainly not the only CA that is vulnerable, just the one that’s been proven to be vulnerable. There are several CAs listed in the linked paper that issue MD5 certificates – stop trusting them too. In the long run, the CAs have to fix themselves and stop using MD5 hashes in certificates. SHA-1 is better, and SHA-256 is best (good luck finding a CA that issues only SHA-256 hash certificates).

How to distrust CAs:

• OS X – Keychain. Double-click the CA in X509Anchors (Tiger) or System Roots (Leopard) and under Trust, select “Never Trust”.
• Firefox – The instructions are for the Comodo certificate, but it’s the same thing.
• Internet Explorer (and anything that uses MS CAPI, like Outlook).

Having a ready-to-run portable Linux-based security tool set can be very useful. Although similar to the classic CD/DVD-ROM based bootable distributions, a USB-based toolkit can be a real life saver if the computer you wish to run it on doesn’t have a working optical drive. The process of writing data to the boot record of a USB drive isn’t exactly common knowledge. Although there are many ways to do this, I will outline a very simple procedure below.

You will need:

• 1 portable USB drive with adequate space on it (available at Amazon, Newegg, etc)
• 1 copy of BackTrack in ISO format (or other live Linux distribution)
• 1 copy of UNetbootin (open source)

Step 1:
Plug in your USB drive and run UNetbootin

Step 2:

In the “Diskimage” section, enter the disk location of the BackTrack ISO image

Step 3:

In the “Type” dropdown box, make sure “USB Drive” is selected and in the “Drive” dropdown box, select the drive letter corresponding to your portable USB drive.

Step 4:

Click “OK” and wait for the program to work its magic

When it’s done you should have a nice bootable USB drive containing a live Linux distribution– perfect for peeking at the hard drives of a host computer, troubleshooting network problems, or impressing your friends.

Each Tuesday, Security Musings features a topic to help educate our readers about security.  For more information about Gemini Security Solutions’ security education capabilities, contact us!

A sniffer, which can also be referred to as a network analyzer, is a piece of software that analyzes network traffic, decodes it, and gives it back packet information so that a network administrator can use it to help diagnose problems on the network.  But because these tools can be so powerful, they can also help give leverage to those of the black hat world by allowing them to pull plain text information off the network as well (usernames, passwords, unencrypted emails, instant message chat, etc.).

Some of the more “legitimate” uses for a sniffer fall towards the roles of the network administrators. They can be used to probe the network for bandwidth usage, helping pinpoint which individual machines may be running malware or simply have wrong network settings. Sniffers are often used as a practical defense against finding intrusion attempts by detecting inappropriate traffic. If you’re ever going to be in a role where you need to ensure your network is protected, you would do well to learn how to use a sniffer. I recommend Wireshark (formerly known as Ethereal), it’s free (as in beer) and well supported with great documentation.  Other alternatives are NAI Sniffer (commercial), TCPDump (*nix), WinDump (Win32), Cain & Abel, Dsniff, and Ettercap (the last three are more specialized for password extraction but can still be used to test your applications or network protocols).

Sniffers can also be used to bypass security. Many application protocols pass credentials in plain text or use weak encryption that is easy for a sniffer to decode. Common examples of insecure protocols are FTP, Telnet, POP3, SMTP, and HTTP Basic Authentication.  Instead, secured/encrypted protocols should be used, SFTP, SSH, HTTPS (SSL).

One of the most common hacks other than password sniffing that sniffers can be used for is probably ARP Spoofing / ARP Poisoning. ARP (Address Resolution Protocol) allows the network to translate IP addresses into MAC addresses. Essentially, when one host using IP on the LAN is trying to contact another, it needs the MAC address of the host it is trying to contact. It first looks in its ARP cache to see if it already knows the MAC address. Otherwise, it sends out an ARP request (looking for the IP).

To view your ARP cache:
Windows Command line: "arp -a"
Linux Command line: "ip neigh show"

In common bus networks like a wired hub or 802.11b, all traffic can be seen by all hosts whose NICs are in promiscuous mode, but not on a switched network. A switch looks at the data sent to it and only forwards packets to the intended recipient based on the MAC. This helps secure the network by only sending packets to where they need to go. Of course, I wouldn’t mention this if there wasn’t some sort of way around it. Programs like Arpspoof (part of the Dsniff package), Ettercap, or Cain & Abel can allow you to fool the network and allow you to spoof another machine making the network think you have the IP it is looking for, then funnel their traffic through you.

So, even with a switched network, it’s not too difficult for an attacker to simply boot up their BackTrack CD, do some ARP spoofing with Dsniff or Ettercap, and redirect traffic through them for the purpose of sniffing.

ARP Spoofing Diagram

So how can one help ensure their network doesn’t fall to these attacks?

• Avoid using insecure protocols like Basic HTTP Authentication and Telnet.  You should make it a practice to sniff your own network to see what information is being passed and ensure you’re not already sending sensitive information across the network.
• If you do have to use an insecure protocol, tunnel it through a secure channel (SSH, SSL, etc.)
• Look into using Static ARP tables between critical workstations and servers. Although a pain to maintain, they do limit the chances of ARP spoofing.
• You can run software like ARPWatch to detect changes in MAC addresses on the network.
• Try running tools that can detect if a NIC is running in promiscuous mode, this could be a sign of sniffing. (Sniffdet and Sentinel are common tools)
• All mobile or guest access points should use a VPN to connect to the network.
• Better yet, keep public terminals on a separate LAN from workstations and servers.
• Lockdown workstations so that users can’t install sniffing software or boot from live CDs (BackTrack, Knoppix, etc.)

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

I often get asked by younger students (early college) how to get into security. I figured I’d give my answer here for everyone to see. Not that this is the only route into security, but it’s how I got here.

I did both an undergraduate and a graduate education in the US. For my undergraduate degree, I studied Computer Science with a minor in Electrical Engineering. I can’t say that it focused much on security, but at the same time, I was working as a system administrator on campus. And I learned the “other” side of security – that of the people that have to implement your suggestions and policies. I also met faculty that were interested in security, and I was fortunate enough to be able to assist in some of the very early “red team” exercises that the NSA sponsored. I wasn’t able to participate since I graduated, but I was able to help set up the lab environment and learn a lot that way. My education certainly didn’t focus on security, but there was a lot of math that helped me understand cryptography later – I didn’t understand it at the time, but now that I understand cryptography better, the math makes perfect sense.

My graduate education was in “Information Networking”, which is a combination of computer science, electrical engineering, and business classes. It was here that I got my first formal educational experience in security – and I promptly dropped the class. It was “Internet Security” taught at Carnegie Mellon. However, the first two classes were mathematical proofs surrounding Kerberos – and I realized that my math skills weren’t strong enough to handle it. Now, I could probably at least understand the class, but I don’t think I’d enjoy it.

I kept working as a system administrator throughout my grad school program. This time, the campus network didn’t have a perimeter firewall, so all of my machines were left to defend themselves. And let me tell you the 128.2 IP address space gets more attacks than you would realize. I learned in the school of hard knocks. Luckily, I wasn’t dealing with any sensitive data that would cause problems if leaked. The worst information that could have gotten out would be the local password file. All of the users used CMU’s Kerberos system.

I became interested in security, and I started to read and practice. I was lucky enough to have friends that also enjoyed security, and we practiced on each other’s systems. We cobbled together “labs” out of old hardware to play with multiple operating systems, and tried exploits against those. In short, we experimented in a controlled environment.

Now, there are several degree programs in Information Security and Information Assurance. Perdue has one (CERIAS), George Mason University in VA has one, James Madison University in VA has one, CMU has a formal one now. I’ve seen some of the students coming out of these programs, and while they may provide a solid theoretical ground for security, the ones that have really shone have been those that experimented – either in a class, or on their own.

If I had to tell you what education to take to end up in security, I’d tell you do either computer science or math (for the crypto tracks), and experiment, experiment, experiment. You’ll learn so much more by doing than by sitting in a classroom. And make sure you’re in a controlled environment so that any of your experiments don’t get away from you!

Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!

This tool for Microsoft Windows gives the user some very important information regarding running processes. It displays a very detailed (and real-time) list of files/directories accessed by a running program. This includes loaded DLLs and file system handles opened or closed during execution.

The security benefits of this tool are based around detection and troubleshooting. It is common for malware to inject DLLs into running processes. With this tool, such a compromise could be easy to detect or track down.

In addition to individual process information, Process Explorer also reports overall system information– memory usage, processor usage, physical memory activity, etc. In many ways, it is like an improved version of Windows Task Manager. It’s relatively small in size, and is run as a stand-alone program (no installation necessary). This makes it ideal for including in one’s security tool set.

Direct Download: http://download.sysinternals.com/Files/ProcessExplorer.zip

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

You may know how to monitor the processes running on your Windows machine, and you may know how to check to see if there are any abnormal network connections being made, but do you know how to synchronize this information to determine exactly what processes are creating what connections? By using some of the non-default options and settings in the Netstat command-line tool and Windows Task Manager, you can do just that.

Read the rest of this entry »

Nmap is a *very* frequently used tool for both network testing and penetration testing. However, most people don’t use half of its capability – I’ll talk about some of the more popular options in this post. Nmap is available at insecure.org, and is available for most operating systems – even Windows. However, I’m not going to discuss the fancy GUI in this post, so you’ll have to dig a bit and consider using the cygwin version.

The first, most popular option is the -O option – for telling you what kind of operating system the target has. It’s pretty obvious on how it’s used, but you also have to know that the system has one open port and one closed port to have a pretty solid idea of what the OS is. So, for any systems that are behind a firewall, you won’t get very accurate results.

The second popular option is -p to tell nmap which ports to scan. If the -p option is missing, only common ports will be scanned. So if you’re looking for something funny on an odd port, you might want to use -p1-65535 to scan all TCP ports. You can also scan all UDP ports with -p U:1-65535 (using -sU). A warning though – if the ports are filtered, or you’re scanning UDP, nmap will wait the full 2 minutes for *each* packet to come back as “undeliverable” (rather than a RST), and scanning can take a very long time.

Another common option is the -sS option. This one scans using only a SYN scan, which used to be the way you wanted to scan, but as firewalls and TCP stacks have gotten better, I think that this is a “wasted” option. I say “wasted” because it *does* help the scan go a bit faster using less resources, since the scanners TCP stack doesn’t have to create full connections.

An option that’s been in nmap a while, but I don’t see used much is -sV – it tries to determine what exactly is running on a port rather that just that something’s listening there. It’s still a bit new, but nmap knows all of the common probes to get something to respond to you, so it’s actually pretty good, but verify it for yourself.

A final option that I think people should use more often is -g (with 80 as an argument). It used to be that almost no one filtered on source ports, now they do. So, when nmap starts up by default, it will use random source ports, which may or may not be allowed through the firewall you’re trying to scan. 80 and 443 are good options, as they’re common web ports. There are others based on what you’ve been able to figure out about the target’s environment – do they use a lot of RDP? What about IMAP? Most firewall admins have gotten smart enough to source port filter based on IP address as well, so it may or may not work, but it’s worth trying.

Nmap has *many* other options that aren’t visible by just doing –help – actually *read* the man page. And try it out – on systems you’re authorized to play with.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!