Recently in Attacks and Exploits Category

Last week was the last week of my SANS mentor class for Hacker Techniques, Exploits and Incident Handling. Hopefully my students will try out for certification and pass gloriously.

As always, we wrapped the 10-week teaching cycle up with the ever-entertaining capture-the-flag (CtF) session that really drives home a few key points. In a previous blog post (computer security badness hierarchy. January 13, 2009), I argued that when we focus on our responsibility for securing information technology (as part of a much larger socio-economic information system), information security practitioners really only have to worry about a few types of things: Bad Users, Bad Configuration, and Bad Software.

Most CtF's are completely in line with my hierarchy and by using tools such as nmap and metasploit and by leveraging exploit code that is readily available in places like the Offensive Security Exploit Database (formerly known as Milw0rm), most challenges in "hack labs" can be solved easily.

The major exploitable categories are typically credential re-use (bad users), unpatched software (bad software), running unnecessary services (bad configuration) and lack of port filtering (bad configuration), and can be found on most (if not all) enterprise networks. Of course, there are many more attack vectors (think "Web" and "end-point").

As a security practitioner, there are few tools more valuable than a well-designed and fully implemented vulnerability management program. When possible, it is nice to drop the $100K+ to purchase one of the commercial suites, but by ensuring that all your computers (servers, desktops and laptops) are configured according to a hardening template and that they receive all patches in a timely fashion is already a major gain. Put on top of that a decent (current) anti-malware package, and you have a nice start.

Do not underestimate the complexity of "just" doing this. If you haven't started this yet, get going. If you have started, but don't think you're done: welcome to the club ;)

If you are embarking on such a project, think about collecting some metrics about how well you are doing it so you can measure progress and define success. Think of numbers like: percentage of end-points that have been patched appropriately, percentage of end-points with current anti-malware software, average lag between publication of vulnerabilities and completion of roll-out, number of end-points in compliance with the hardening template, etc.

It had been in the back of my mind for a long time to war-dial my own organization, just to see if there are any unauthorized modems attached to computers on our network.

The modem attack vector has been long ignored, but if present, it offers a great vector into a network. More commonly than not, locally attached modems are not subject to firewalls, intrusion detection systems, or any other of security controls.

Since I only looked at phone numbers of which we knew a modem was attached, my little exercise was not a true wardialing effort, nor did it provide full coverage. Yet, it yielded pretty useful results. I had (note: past tense!) just over 20 telephone DiDs that were marked as modem lines. When dialed, not one of those lines actually picked up (yay!). Most lines either went to voicemail (shouldn't happen on a modem line), were off the hook, or were disconnected altogether.

All in all, this effort allowed us to reclaim a bunch of unused DiDs, and it confirmed that on our registered modem lines nobody had configured their modem to auto-answer.

The next step will be to identify rogue modem lines.

Fortunately, I do not expect to find that many (if at all). Our field support technicians have been looking out for the presence of modems for a year or two now, and as machines are swapped out on their regular schedule, legacy modems are removed.

Let's see what we come up with in the next few months, but this is one attack vector that should be mostly closed.

A number of recent high-profile online account compromises clearly shows the need for strong passwords. As in several cases, it also demonstrated clearly that security settings that depend on secret answers to public questions are insufficient. The most notable of those compromises was probably the Sarah Palin Yahoo account hack. 

I am not sure when it happened, but Google caught on to this as well and introduced a well-known form of two-factor authentication that can be used for account resets. By telling Google even more about yourself (in this case, registering your SMS-capable cell phone number), they will be able to send a password reset token to your phone.

Using SMS messages as a secondary authentication factor has been used extensively by several European banks and is used to authorize payments made through online banking systems. Every time an online transaction is made, a one-time password in the form of a transaction authorization number (TAN) is sent to the registered cell phone numbers. Payments will only be processed when the web site user is able to produce the correct TAN.

I am glad to see that such relatively simple measures are making it to the mainstream online service providers. While not perfect, security practitioners have been opposed to weak (knowledge-based) authentication schemes for a long time.

Hopefully, this initiative will be picked up by other service providers soon.

I regularly review firewall configurations to figure out what incoming connections we allow, other than web access. In the course of the last 5 years or so, it has become abundantly clear that there had better be a very good reason for anything that is not web to be still exposed directly to the Internet. As more obscure protocols become less used, it becomes harder to retain experienced administrators who really know what they are talking about, and as a result, securing those protocols becomes much harder.

Which the advent of 'everything over the web', new challenges have emerged. Secure application development, web content filtering (inbound and outbound), web application firewalls, specialized intrusion detection systems, etc. are all important tools to have, but, in the end, all those tools must be configured, maintained and tested also.

As a result, requiring regular vulnerability scans is an important tool to not only detect problems in the application, but also to test all the controls that protect the information that is manipulated by it. Penetration testing to assess the potential impact of the vulnerabilities that were discovered would sometimes be the logical next step.

There are roughly two types of vulnerability scans: manual scans and automated scans. Manual scans, if conducted by a highly skilled individual with enough time, will find things that you would not have even dreamed about. A major drawback is that they are (very) costly and the outcome of the scan is highly dependent on the person conducting it. Automated scans are relatively cheap, can run consistently and continuously and they are thorough. The drawback of automatic scanning is that they will only find vulnerabilities that were previously known and have been implemented in the scan tool's logic.

There are some solutions out there that take a hybrid approach to vulnerability scanning. They perform an automated scan, which is supported by human experts who manually verify the  results in order to avoid false positives. Human testers will also be much more qualified to detect business logic flaws than automated scans can.

The automatic scans will detect of the vast majority of the problems, which allows the human expert to concentrate on the more interesting stuff.

One vendor that offers this service is WhiteHat Security through their Sentinel product. I have been working with Sentinel for a few weeks now, and my impression that our developers had things fairly well under control was confirmed. Yet, Sentinel also found a number of vulnerabilities that I had no idea were present on our web presence. The WhiteHat staff is very responsive to inquiries and I am a very happy customer. The price tag is reasonable; a full year of continuous scanning will amount to roughly the same price tag as a once-off scan of a medium-sized site conducted by a human tester.

If you are in the market for a hybrid web application vulnerability scanner, you should check out WhiteHat's offering.