In the struggle between cyber attackers and cyber defenders, many tools have been built to create a strategic advantage or to gather intelligence. One category of software has the benefit of being both. Honeypots are a combination of software and hardware that emulate a target computer system or service for the purpose of attracting attackers and/or analyzing their attack. In essence, honeypots are tools used against attackers to both catch them red-handed and to figure out how they’re doing the dirt.

Attackers regularly scan large blocks of IP addresses in an attempt to find exploitable computers. When they think they’ve found a likely target, some form of attack usually follows. By placing honeypots on the Internet, security researchers are able to get a first-hand view of just how the attacker carries out his goal. Since the honeypot is no different from any other computer system from the perspective of the attacker, they are likely to never even suspect anything is wrong.

Honeypots may run under a virtual machine or within some other form of sandbox environment to protect the host computer from suffering any actual harm. The effect is similar to a glass-bottom boat, where all attacker activity is transparent to the researcher. Most honeypots advertise themselves by responding to scans as if they were a vulnerable service. For example, a honeypot may accept connections to TCP port 80 and claim that it is a webserver. The attacker will be inclined to believe that a webserver actually resides on the target computer at TCP port 80, even though this is incorrect. If the attacker attempts to attack the computer via that channel, the honeypot will log the effort for future analysis.

It can also be fun to set one up on your own computer and see what you catch. HoneyBOT is Windows honeypot software that lets you turn your system into a functional honeypot, ready to catch attackers in the act . If that’s your thing.

It’s all over the news; Google finally has an Android to call its own. The media is throwing around terms such as iPhone killer, but that doesn’t seem altogether likely to me. Perhaps it will level out to a PC vs. Mac sort of scenario. This actually sounds plausible as in my research I came across news of a project working on porting Mac OSX 7 to the iPhone, and the great big thing with Android back when I got mine was running Debian on the G1.

(more…)

If you’re working with SSL (whether websites or otherwise), it sometimes helps to be able to send text and commands directly to the server, but it’s not as easy as just telnetting to the server like with non-SSL servers. That’s where s_client comes in. It’s part of the openSSL suite, so you’ll find it on all unix based systems, and can compile it on Windows based systems.

s_client handles all of the SSL negotiation, with you controlling as much of the negotiation as you want. You can tell s_client what algorithms to “support”, and if the server will complete the negotiation, you know that the server supports that algorithm as well. This is useful to determine if a server supports weak algorithms.

s_client also acts like telnet. So if all you need to do is negotiate the SSL, s_client will handle all of that. If you’re trying to debug SSL, s_client lets you do that as well.

All of the options are listed at the OpenSSL documentation page, but I’ll cover some of the most common ones here.

To just create an SSL connection, use
openssl s_client -connect host:port

The certificates that belong to the server will be displayed, along with the algorithm that was negotiated.

To see if the server supports weak algorithms, you can use
openssl s_client -connect host:port -ssl2 -cipher cipherlist
Where cipherlist looks like CIPHER1:CIPHER2:CIPHER3 The server will select the first cipher in the list it will accept. You can use the openssl ciphers command to see the specific list of ciphers that your copy of OpenSSL supports, or you can refer to the documentation, which also includes “ciphers” such as EXPORT and eNULL – which means export level or no encryption.
Generally, I use
openssl s_client -connect host:port -ssl2 -ciphers eNULL:EXPORT

s_client is a useful tool both for diagnosing SSL/TLS problems, and for checking on the cipher strengths a server supports.

Over the past few days I attended the Techno Forensics 2009 conference held at NIST. It was free and I needed the CPEs, and it’s vaguely inline with what I do, so I went.

(more…)

A few days ago, a friend of mine asked me how emails are forged. Instead of directing them to Google, I figured it’d be more fun to explain it to them. So in the interest of sharing, my explanation to them was as follows…

Email forgery is made possible due to the way email servers accept mail from email client programs and from each other. The whole process is not much different from the way regular snail mail is delivered. When you mail a letter, you write the name and address of the recipient and (usually) your own name and address so they know where to send any replies to. But this is just what’s supposed to happen. In reality, you could write anyone’s name and address as either the sender or the recipient and the mailman wouldn’t really care– his job is just to deliver the letter to whatever recipient address is listed, not to verify that you are who you say you are.

(more…)

October is Cyber Security Awareness Month (among other things including Breast Cancer Awareness Month), so this post is going to help make you aware of how to learn about vulnerabilities and – more importantly – patches in the systems you manage.

Vulnerabilities are found in several places – the first place you’re likely to find public disclosure of a vulnerability is the Full Disclosure mailing list. On the downside, it’s a very high noise to content ratio (i.e. there’s a *lot* of noise – probably 90-95% noise). The second place it’s likely to show up, and be more useful to you is in the bugtraq mailing list – this is because bugtraq is moderated. It has a much lower noise to content ratio (90-95% of it will be useful). If you want to be on the cutting edge of vulnerability research, these are the two go-to lists.

milw0rm.org (which has questionable uptime at the moment) has a great database of exploits. If there’s an exploit in the wild, milw0rm will likely have a copy of it. And vice versa, if milw0rm has exploit code for it, you’re likely to see people attempting it.

All of these sites are for *all* vulnerabilities, including many that may not affect you, and if you’re short on time, you want to know what vulnerabilities affect you – and if there’s a patch. Vendor specific mailing lists (or web pages) are your friends here. Sometimes, you have to be a support paying customer to have access to these lists, but the ones I list here are free for everyone to join.

-Windows has several options depending on what you want to get from them.

-Apple has their security-announce list available through mailing list or RSS feed.

-FreeBSD has a whole group dedicated to vulnerabilities, with links to a list of the vulnerabilities in FreeBSD as well as the ports tree.

-Sun has a knowledgebase article that lists all current vulnerabilities and advisories.

-Linux vulnerabilities are generally listed through the distribution you choose to install.
* Red Hat has several public lists for vulnerability announcements depending on the product you’re interested in.
* Debian – debian-security-announce mailing list
* Ubuntu – ubuntu-security-announce mailing list
* SuSE has a web page devoted to advisories.

Whatever operating system you run or administer, find out where the advisories are posted and monitor them for activity. Everything is going to have vulnerabilities sooner or later; you’re not “safe” just because you run an obscure operating system or application. Keep up-to-date and you’ll reduce the surface area for attacks.

After recently upgrading to Windows 7, I installed our company’s SimpleCAPI tool to import some test certificates for a project. While I was unit testing my new code, I discovered some strange things had occurred during the certificate import process. Some native CAPI code I had written was failing with a “KeySet does not exist” error, but only for certain certificates. So, I fired up SimpleCAPI again, deleted the certificates, and re-imported them. After doing that, the unit tests ran fine.

Some time later, I ran into a similar problem unit testing another segment of code, and the same fix worked for that problem as well. After retracing my steps a bit and trying to re-create the error, I found that the keysets could only not be loaded when I had launched SimpleCAPI as an Administrator in Windows 7 to install the certificates, and my unit test project was not run under an Administrator context. However, when the certificates were imported in a SimpleCAPI session that was not launched as an administrator, then the keys were available regardless of the unit test context.

This probably isn’t going to be a problem that’s widely experienced, as 999 times out of 1000 (1), certificates are imported using the standard Windows certificate wizard, not an external application like SimpleCAPI. However, I do need to figure out why this is happening. My guess is simply that the key container created during the certificate import is flagged with administrator access only, so attempting to acquire a handle to the key context in my native CAPI code was failing due to a read/write permissions error, not a problem with the KeySet’s existence.

I also need to fix the CAPI code so that the key handle can be obtained with a read-only context. Hopefully that will get around the problem entirely. Regardless, I took this as a lesson that the “Run as Administrator” shortcut in Windows 7 can have more subtle implications than just granting some extra privileges for an application. This is something that I’ll need to keep in mind when developing Windows applications going forward.

1: 84% of all statistics are made up on the spot.

The PCI-DSS (Payment Card Industry Data Security Standard) is a set of requirements for businesses and merchants that deal with credit card information. These standards are designed to protect the customer by requiring businesses to protect sensitive cardholder data. Complying with the PCI-DSS requirements can result in changes to a business data infrastructure, including securing networks, implementing access controls, and creating a robust information security policy.

However, despite the stringent requirements, there has still been doubt about the real-world effectiveness of the PCI-DSS. The idea that PCI-DSS doesn’t make consumer credit card data much safer has been discussed ad nauseum, and not without some compelling evidence. In 2008, 4.2 million credit card numbers were stolen from the PCI-DSS compliant grocery chain Hannaford Brothers.

But isolated instances of failed PCI-DSS policies provide nothing more than anecdotal evidence of the perceived weakness of the standard. To truly examine its impact, a formal study should be done. On September 24, 2009, the Ponemon Institute released the results of such a study. This study (pdf) included survey data collected from people representing a number of different companies and businesses.

Some of the important key findings:

• Cost of PCI is, on average, 1/3 of the overall security budget
• 79% have had a data breach
• 55% of companies focus only on protecting the credit card data and not other sensitive information
• There is uncertainty as to what personell are the most accountable for PCI-DSS compliance
• Smaller companies are less compliant than larger companies (75k+ employees)

From the study, one can deduce that the standards favor larger companies, who are usually better able to conform to the requirements, due in part to larger security budgets and more resources. It is also interesting that the majority of companies surveyed (55%) expressed interest in only protecting the card holder data. This means that other consumer data (such as social security numbers, addresses, etc) could be swinging in the wind with no protection at all. It almost seems as if companies want to adhere to the PCI-DSS just enough to be compliant.

But if companies don’t have a serious vested interest in protecting their customers’ sensitive data (ALL of it), then maybe they’ve missed the point. The PCI-DSS certainly gets merchants thinking about security, but the lengths that they go to achieve this security shouldn’t stop with PCI-DSS compliance. Naturally, no set of standards is capable of covering all fronts– especially not in a landscape that changes as frequently as information security. But if companies don’t take the hint and think seriously about protecting data and securing their systems against threats, then compliance is nothing more than a glorified checklist representing an ineffective baseline for security practices.

If we think of the PCI-DSS as a panacea for cardholder data breaches, then it is indisputably ineffective. However, if we think of it as a guideline and a foundation on top of which real security measures can be built, then it may prove to be quite valuable.

NIST recently released an overview report on the current state of research in security metrics (short story: there are almost none), and some areas where they feel more research is warranted. One of the problems with security as a business process is that managers are being taught process improvements is the way to save money, but with security, there are no obvious metrics to measure to improve the process. Security is subjective, based on the person and the situation, and measurements tend to the objective side of things.

I think that seeing new measurements is really going to improve the overall security landscape – once they’re accepted and used. NIST and the Feds already kind of lead the way with FIPS and Common Criteria (European based), and I think that if they start using a particular metric, the commercial world will follow. One of the detriments to security metrics is that until the last few years, it hasn’t been well studied in universities – the “hotbeds” of research. I think that now we may start to see more metrics coming out as more graduate students start to study it. And if you happen to be a current grad student interested in security metrics, the NIST paper has some great starting points for a thesis.

Electronic health records (EHRs) are touted as making healthcare more affordable and efficient. It also assists care providers – you doctor – in making fewer mistakes such as prescribing a drug that reacts with other drugs you are taking but he doesn’t know about. The 2009 economic stimulus package aims at encouraging physicians to adopt EHRs, eventually reducing the Medicare payments to those who do not adopt EHRs.

What are Electronic Health Records, why are they useful, and more relevant here, what are the security implications of using them?

(more…)