Heading to Blackhat: Blackhat briefings coverage by the Devil's Advocate crew

Most of the Devil's Advocate crew is going to Black Hat and/or DEFCON this year. While Dan Kaminsky's DNS exploit cat is basically out of the bag, I expect that a number of the briefings will be valuable.

I'll be sitting in on the following briefings:

• AppSec A-Z - Jared DeMott
• DNS Goodness - Dan Kaminsky
• Hoff's The Four Horsemen of the Virtualization Security Apocalypse
• Malware Detection Through Network Flow Analysis - Bruce Potter
• Encoded, Layered and Transcoded Syntax Attacks: Threading the Needle Past Web Application Security - Arian Evans
• SQL Injection Worms for Fun and Profit - Justin Clarke
• Mobile Phone Messaging Anti-Forensics - Zane Lackey and Luis Miras
• Get Rich or Die Trying - Making Money on the Web, the Black Hat Way Jeremiah Grossman and Arian Evans
• Playing by Virtual Security Rules: How Virtualization Changes Everything and What to Do About It - Steve Pate

It looks like there will be a lot of good information - and better discussion at the conference. I'll see many of you out there! I'll also be blogging the high points as the conference progresses, so stay tuned.

Aladdin acquires Secure Computing's SafeWord

Aladdin Knowledge Systems has announced their intent to acquire Secure Computing's Safeword product line, with an expected date in August or September. This merges two of the larger two factor token vendors into a single entity, and should make for a good combination of capabilities and technologies.

Planning around tokens: When your token fails

My organization uses Secure Computing's Safeword tokens. They're handy, and offer an increased level of security over simple password authentication. The problem with a token is that you can lose it or damage it. In my case, the LCD on the token that I use has a partial non-working character. I can work around it, but it made me appreciate the fragility of a token based system for secure remote access if the token fails.

How can you work around this? There are a few options:

1. If you have an operations or helpdesk organization, you can give them an emergency token, and provide the second half of the string to your team. Build appropriate controls in so that use is limited and is recorded, and simply call your on-site team to push a button and read numbers to you over the phone in the event of a token failure.
2. Provide a method to bypass the two factor authentication, either via a controlled VPN or other system, or via console access. You'll need to ensure that the bypass isn't used except when absolutely necessary, and it creates more exposure and more maintenance.
3. Ensure that you have enough staff to handle a single failed token by re-assigning tasks. In larger organizations, this is often workable. In a smaller organization, this can be a more difficult task.

Token based two factor authentication is an attractive solution, but as with any technology, you must plan for failure while designing for success.

Security Tools: VMWare ESXi for free

VMWare is one of my favorite tools for testing malware and for building test networks. Now, VMWare has released their ESXi hypervisor for free. The platform is very similar to ESX, with a smaller disk footprint.

VMWare also advertises ESXi's security features, citing the ability to "Enforce security for virtual machines at the Ethernet layer. Disallow promiscuous mode sniffing of network traffic, MAC address changes, and forged source MAC transmits."

I won't debate the differences in licensing models between VMWare's products and XEN or Microsoft's virtualization technologies here. Instead, I'll simply note that having virtualization capabilities and pre-built test environments for your common operating systems is where the real advantage is for malware analysis, architecture testing, and separation.

Malware Analysis and Response: A Quick Howto

A recent wave of spam has managed to bypass some central email AV systems. The virus, which Sophos calls Troj/Agent-HFZ, wasn't recognized by many of the larger players in the antivirus space until earlier today. Virustotal's list shows many players still don't recognize this specific variant. As I watched some of our staff work to deal with the infections that resulted from users running the infected executables, I realized that a few basic steps could really save them some time. Here they are:

1. Get a copy of the malware and submit it to:

• Norman Sandbox
• VirusTotal
• and your AV vendor's upload system, such as McAfee's Avert/Webimmune.

You'll see something like this - note that only 19 of 34 vendors recognized this malware when VirusTotal checked it.


2. Review the responses - often at least one or two vendors will have identified the malware, and some may have already written directions for removal. In this case, Sophos provided directions on removal that matched what was seen on infected systems.

3. Run strings on the malware. If it isn't packed or otherwise encoded, you may get enough information to either block remote contact sites, or you may learn more about it.

4. If you don't have a vendor provided removal process, and if you're technically proficient enough, you can test the malware out yourself. I like to use a locked down VM with network access only to a host that runs Wireshark. Here's an example of an outbound connection attempt from a recently infected host:


Note the attempts to connect to a .ru site - not something I would expect to see in a normal boot process.

I'll also use a utility that will monitor the host for changes - Wise's Installation Studio is a commercial example, and various freeware packages are also available . You may also find tools like Windows SteadyState to be useful, as they allow virtual sandbox environments for testing.

5. Once you've figured out what the malware does, and what it changed, you're ready to figure out a course of action. In most cases, this will be one of three things:

• Rely on 3rd party AV products to do the removal
• Create a scripted or manual removal process
• Reinstall or restore system state

You may also discover that there are outbound IP addresses or domains that you may wish to block to prevent outbound communications from occurring, or there may be specific strings you want to filter for on your inbound mail server. By now, you should know what you're looking for, and you'll be far more ready to handle further occurrences of the malware.

As for the malware of the day? The SMTP scanner servers are filtering it, the helpdesk has repair information, and our AV vendors are releasing updates to remove it. The users? Well, they're still occasionally clicking on their fake UPS invoices.

Phishing for Credit Union members

The scheme of the day today is an apparently VoIP based phishing attempt with the call asking victims to call 515-414-2182. The call claims to be from a local credit union, and that the victim's credit union card has been deactivated. Notes on this can be found on whocallsme.com's listing for the number.

I'll be spending some time today reminding staff that they shouldn't call a number provided in a voicemail or on the phone without verifying it, and this looks like a great opportunity for our next outreach and education project.

Is your Security Guy Beanie (tm) on too tight?

I work in a reasonably large dedicated IT organization. Often, the staffers that I work with understand the risks and the controls that they can use on their systems as well as, or better than I do. What they come to me for is a level of professional paranoia. They acknowledge the difference between the system administrator's "it must work" mantra, and my "it must be secure and it must work".

This results in the occasional moment where we both acknowledge that security concerns are over the top - but that they need to be expressed. We need due diligence, and we need a full awareness of the risks. Even so, we're all aware that some of the security concerns can sound silly.

I simply tell them that my Security Guy Beanie is on a little too tight, but that I have to wear it like that to keep my paycheck.

We all chuckle, we figure out a reasonable set of controls, and the admins know that there is somebody who is paid to worry about the obscure things.

Blinded by necessity: Avoiding Dr. No

Often requests come in for vetting that don't reflect any risk awareness on the part of the requesting party. In many cases, the person making the request is normally security conscious, follows the rules, and treats data and systems carefully. For one reason or another, this request is different, and it is needed right away!

Why the gap?

Necessity, or at least perceived necessity. In the end, most of these requests are driven by an organizational need for immediate response. A project needs to be completed, a new hire is in place and needs access, or senior management has made the project that caused the requirement a priority.

Dealing with these priorities is one of the more challenging day to day issues that security analysts face because they are one of the easiest ways to become known as the local security obstacle. Even if your normal answer is "yes, and here's how to do that securely", the high priority, snap decision requests will get bogged down due to their nature - they're different, they don't follow the rules, and they often involve unnecessary risks that could be easily avoided if normal processes were followed.

When I run into one of these cases, I ask a few simple questions:

1. What are you trying to accomplish?

2. Why are you requesting it this way?

3. How is this different from your normal operation?

4. What problems or costs are associated with not doing this the way you have requested it versus the via the normal process or rules?

Often, these answers will lead to a realization that the normal process does include what is needed. In other cases, it will be obvious that there is a need for a one-off variation, at which point risks can be properly gauged and handled.

Test Credentials? These looks a lot like yours...

At times, I realize that despite my best efforts, I still haven't gotten through to some of our developers. We do automated web application testing, and normally use test credentials created for that purposes to log in. This morning, I got a call from a developer who was working from home. "I'll just give you my username and password", said the developer.

I calmly noted that to do so was a direct violation of policy, and that I really needed alternate credentials. It looks like it is time to run the "Why you shouldn't share your credentials" class again, with an emphasis on the dismissal for cause part of the policy...

Flickr Creative Commons image credit to husin.sani.