.:Computer Defense:.

Virtualization. A technology that is supposed to save organizations money... take 10, 20 or even 50 physical servers and run them on a single virtual server. The concept seems to make sense; after all, as someone recently pointed out to me... virtualization has existed in the mainframe world for quite some time. The problem today is that everyone is moving their servers to flawed virtualization software. Flawed software that poses a security risk... a risk that opens the door to ‘hackers' and ‘crackers'.

Even if we ignore some of the vulnerabilities that we've seen in the past 12 months, we can look at the ones that came out only a few days ago. Vulnerabilities in Samba, Python and a SCSI driver, all of which ship with VMWare ESX Server, were published/announced and while VMWare has issued patches, there was a period when these vulnerabilities introduced a new threat into any environments utilizing the software.

Everyone (primarily the virtualization companies) keeps talking about how great virtualization is, but how many people are actually weighing the security risks. In every IT prediction blog for 2008 we saw mention of virtualization and virtualization security.... this means the security people are thinking about it, but how about the enterprise world... are their IT staffs considering it?

I'm a big fan and I'm hoping we'll see VMWare ESX 3i introduce a new level of security, being a 32MB hypervisor we'll hopefully see limited vectors of attack. That doesn't mean that we won't see people continue to run ESX 2.x and ESX 3.x, after all ESX 3.x can still be purchased.

I also have to wonder how people prioritize the installation of virtualization software patches. If the hardware is responsible for 20 virtual servers, how willing are people to risk applying a patch that might have issues. This is why enterprises have patch testing cycles before they implement them... Even if people are willing to install the patches, how often are they aware that there ESX server needs patches installed? Do they monitor the updates, do they receive email notifications? Even when they do find out, do they act on the provided information? I've seen internet facing Exchange servers more than 2 years behind on their patches, and I've seen Linux systems that have never been patched. Where do people place ESX? First? Second? Third? Does it depend on the systems hosted on the server? I honestly don't know the answers to these questions, but I'd be curious to find out.

Up until this point, I had written this post over the weekend... Seeing as we'd seen a couple of ESX vulnerabilities that are somewhat serious. What made me revisit this post and continue it was the release of a VMWare Workstation vulnerability by Core Technologies. A vulnerability that could have negative impacts on malware researchers that have shared folders enabled. This is another example of a negative impact that virtualization technology has, that a physical installation wouldn't have.

We're rapidly pushing forward with virtualization, but how prepared are we for it? I've noticed there are a couple of VMWare related talks at CanSecWest this year... Yet is anyone outside of the research community seriously thinking about this? I guess we'll have to wait and see.

Brian Krebs has an interesting article up over on SecurityFix.  Entitled, "How Not to Write a 'Geek Wanted' Ad", it discusses companies that identify the hardware / software running within their infrastructure and how this is a bad idea. Now before I disagree entirely with the article, I do want to preface it by saying that I'm a huge fan of SecurityFix and the majority of the articles that Brian writes.

My issue with Brian's posture is that, I think, it's going a step to far. How to we decide what is and isn't useful information to a ‘malicious individual'? Let's think of some of the other things that we could withhold. How about contact information? These could be used for a unique social engineering attempt or even just run of the mill spam/phishing. The same reason could apply to withholding the HR contacts name or even the company name. You do see some job postings with this information missing, just as you see some job postings with job related equipment missing.

Now in the example that Brian mentioned a few things were mentioned: Cisco PIX, Cisco IOS, Norton and McAfee AV, Network Associates packet sniffer. In the end does it matter if an attacker is aware of these? Not really... there are fingerprinting tools available, nmap is a great example, which will attempt to identify what OS is running on a device. A Cisco router or PIX will be easily identified. The AV doesn't matter... not in the long run... the odds of it being exposed outside of the corporate network are minimal meaning outside attackers aren't going to reach it, and someone who's already inside will know what they are looking at. The exception there would be email AV, however they've listed the two most common AV engines available... the odds are pretty good that the company is using one of those anyways. Lastly, the packet sniffer... who cares? It's not going to be running all the time, only to diagnose problems... and if you have access to it, again you probably already have access to the internal network.

If there is any benefit to an attacker from this information... I'd say that it's pretty minimal... definitely less than a 1% increase to the chance of a successful attack occurring. Companies have identified for years that sys admins require experience with Windows, Linux or OS X (depending on the environment), so why is this any different?

Now let's look at the benefit to the company...  The hiring process is expensive... that's why hiring agencies, head hunters and websites like NotchUp exist. Providing as many details as possible in the initial job ad seems like a smart idea to me. I'm not in HR but it seems logical that if I post my requirements, fewer people that don't have the requirements will apply. Let's take Mr. X, for example, and say he was looking at the job mentioned at SecurityFix. Mr. X was previously a Windows Network Administrator and had Nortel Routers... he's never performed packet captures and they had Trend Micro... immediately he knows that he's got the right generic skill set (if they had said routers and AV he may have already been sending his resume)... but he realizes he needs to improve his skills in a few areas before applying. This saves both Mr. X and the company's HR department time and, at least in the company's case, money.

I think that today we're too afraid that every little bit of information gives a malicious individual an edge. We have to remember that the edge it gives them needs to be significant before it really starts to matter. Disclosing some information related to your internal infrastructure in a job posting isn't the end of the world... in the grand scheme of things it's so minimal that it's basically nothing. Brian, while you usually write some great stuff... this time you missed the net by quite a bit.

Today there are a lot of people talking about the release of the Windows Server Protocols and the Windows Communication Protocols. They are series of specs defining various proprietary Microsoft protocols. There are plenty of them and they are rather in depth. These are being released right on the heels of last week's release of the Microsoft Office file format specs. The release of these is, of course, tied to the EU decision that Microsoft has to be more open to interoperability.

Most people, who are talking about the protocol specs so far, are security researchers. This plays a major role in the research game for us. I can remember a few MS Tuesdays that were spent with IDA Pro attached to some listening service, trying to figure out how to generate valid data that would traverse the service to a specific breakpoint. In a lot of ways this will make that research quite a bit easier... and this is what most people are talking about.

While researchers are sitting saying, ‘WOW, this is amazing.' There are a few things that we need to remember:

The improvements we'll see in open source projects. Projects like Samba, mod_ntlm and others will most likely undergo changes to implement portions of the protocols that were never properly understood, or never properly implemented. Someone did point out, however, that developers on some open source projects who enjoyed reversing the protocols may fade away from the projects, bringing in new developers who ‘just want to code'.

Another interesting thing will be the updates to packet analysers and protocol dissectors. I'm sure that we'll see some impressive updates out of Wireshark... but I'm also guessing we'll see the introduction of several small protocol-dependant sniffers. The specs are there, so why not write them?

While security researchers are excited... I'm willing to bet that will stop on the first or second MS Tuesday following this release. Something tells me that this will lead to better fuzzers and more vulnerabilities. This will create a lot of work for those of us in Vulnerability Management, IDS/IPS, etc.

We may also see malware authors looking at various services for new covert channels in which to hide their phone home capabilities... I guess we'll just have to wait and see.

In the end this is really exciting... I will probably spend my entire weekend staring at my new 22" wide-screen monitor reading some of these specs. It'll be interesting to see what the next few months hold.

Does anybody have any thoughts or concerns over these protocols opening up? Any project ideas they are willing to share or propose?

I just installed the comment plugin from Intense Debate... It seemed to be a fairly painless install... I'm hoping that this post will tell me whether or not it's working. It looks like it's pretty cool, feel free to check it out on the Intense Debate website.

An article from the NY Times entitled, 'Scanning Your Money to the Bank' recently came to my attention. The gist of the article is as follows: There's an Act (Check Clearing for The 21st Century) that allows for the exchange of electronic images of checks rather than the physical checks... Numerous banks and big business are already doing this, and one bank, which serves the US Military, has also implemented this.  A company called Fiserv has recently announced that they have a way to bring this ability to online banking customers. I find this to be very, very frightening...

Someone can submit an image of one of my checks and they will get the money for it? It seems to me like we're making check fraud easier... The company claims that the software will detect if the image has been modified, but I'm guessing it won't be perfect... a lot of digital edits are difficult to detect, especially when done by pros.. and I'm betting even more so when done by pros who stand to make some money.

Let's say that someone has been out mailbox fishing and they've collected a check that I've sent to the utilities company for $250.00. They have an account with the same bank (or have stolen blank checks from the same bank)... They write their name in the Payee field and scan it. They now select a perfect square around the Payee field and cut it, pasting it into the scanned copy of my check. Since the checks are from the same bank, and are (for arguments sake) of the same style... the paste can be done flawlessly... no need to edit signatures, no need to modify names and make the edits look normal... it's nice and easy.

Now what if Pay Day loan companies start using this technology... they are already more lax than  your standard bank... what will be allowed to slip through and be cashed now.

Another example...  What happens if someone gets one of my checks and I put a stop payment on check #10 (the one I lost)... the criminal, before cashing the check, simply modifies the check number and payment proceeds.

There are definitely some things that should exist online... even related to banking... and email money transfers are a great example of this... but scanning checks... that seems slightly ridiculous to me. What happens if I give someone a check and they scan it over a network printer... or they store the check in a shared folder... or a worm browses their hard drive and uses OCR to recognize check images and forward them on? My check information (which includes my account information, full name, phone number and email address) now falls into the hands of someone who is malicious.

I've always thought that in this day and age, checks were an out-dated and antiquated method of handling monetary transactions...  This just makes it worse... and it's not something I'm looking forward to seeing made available to the mass market.

The other day I posted the Port Scanner Challenge, and a follow-up article declaring a winner.

This lead to a couple of things...

First, Robert E. Lee (who is associated with UnicornScan) started a blog to perform his own independent tests. I encourage everyone to look at the results... but I remind everyone that Robert is tied to UnicornScan and therefore you may have to take some of the results with a grain of salt.
Second, Fabian, of Recurity Labs (Author's of PortBunny), contacted me regarding the results I had seen, specifically the Vista results. They had reproduced the results in their lab, and ended up releases an update to PortBunny. The updated version showed significant improvements. On the Vista host, with default settings, PortBunny scan times were reduced from ~18.3 seconds to ~1.2 seconds, and on a full port scan (1-65535), scan times were reduced from ~642.5 seconds to ~30 seconds. The updated version of PortBunny can be downloaded here.

Additionally, Fabian included an explanation of how packet retransmission works with PortBunny, which I found rather interesting:

PortBunny sends so called packet-batches which consist of a couple of
probes (usually 9) and a trigger-packet. If a trigger-drop is detected
either because a timeout-clock is hit or due to the fact that 3 later
trigger-responses have been received, all probes which did not get
responses are retransmitted. This is done to acknowledge that, when
firing at this rate, the trigger dropped, so its possible that any other
packet of the batch may have dropped as well.

However, retransmission is not done straight away: That wouldn't be too
wise because the response may just be a couple of milliseconds away.

Instead, we just add the port to the back of the list of ports to scan.
As a result, we can wait the maximum amount of time for the response to
still reach us before we resend.

We only assume that a port is filtered if no response is received for
the probe but the trigger-response for the batch the probe was in was
received.

Now, we do this until all ports have results and then we check whether
the total amount of filtered ports is smaller than 30% of the total
number of ports. If this is so, we perform two rounds of rescanning of
the filtered ports.

Lastly, Fabian also included some of the more interesting changes in this updated version of PortBunny:

(1) The Python-UI contained a Bug which drastically decreased
performance on gigabit-ethernet: To query the device-file, a python
FileObject was used and its read-method was called without specifying a
buffer-size. In fast networks (such as gigabit-ethernet) this lead to
the situation were a huge amount of results was delivered to userspace
in a single read. The information was then parsed using a regular
expression which, due to the size of the buffer, took way longer to
complete than the actual scan

(2) The development-version now discards bad triggers as soon as better
ones are found. This means that ICMP or UDP-triggers as well as
TCP-SYN-triggers which produce TCP-SYN-ACK responses are discarded as
soon as a single closed port is found (in which case we can use this
port for triggering). This increases performance on the one hand (when
ICMP-traffic is limited which is quite frequently the case for
destination-unreachable messages) and accuracy on the other hand because
triggers are preferred by the scanner which are handled just like the
probes so rate-limitations on TCP-SYNs are detected correctly.

(3) Scans were too "bursty" for many setups which included
burst-limitations. Especially when the round-trip-time was small, the
target would feel like it was processing an (almost) never ending burst
of data. We've made some changes to reduce the "burstiness" as you can
see in the Vista example.

(4) TCP-Reno was taken a little to literally: Reno says that the initial
congestion threshold should be close to infinity so that the sender can
find the limitations of the network quickly (and "muscle" itself into
the connection). NMAP chooses 50 as an initial congestion threshold,
PortBunny chose 80000. While 80000 was closer to infinity than 50, it
doesn't seem like a good choice in many environments when using Reno for
port-scanning because the accuracy of the start-phase of the scan is
reduced drastically. NMAP was totally right to choose a lower number so
we've changed that as well.

(5) We've included a new trigger: The TCP-ACK trigger. This works in
many situations where we had to use fallback-triggers such as the
UDP-trigger in the past.

I was bored the other day, so I've setup a silc server. You can use the silc client or Pidgin to access it. My client is idling on there in lobby, so feel free to come by and see if I'm floating around. The server is @ securitysentience.com