VMWare Virtual HoneyPoint Host Appliance

MSI is proud to announce a VMWare appliance based on Damn Small Linux (DSL) for HoneyPoint hosting.

The VM appliance is available free from the HoneyPoint FTP site provided in your license documents. The appliance currently has all available HoneyPoints installed and configured to autostart with the installation.

Root and “dsl” account passwords are “hpss”. Obviously, please change the passwords when you configure the system!

All HoneyPoints have basic configurations provided, and will need to be edited for the location of your console. Currently, they point to 127.0.0.1.

The appliance is capable of being used in any of the VMWare products from Player to ESX and includes use in the OS X Fusion environment.

You can use the VM to emulate entire workstation(s) on the network using Player and such, or use ESX to sprinkle them around your virtual environments en masse. The image is smaller than 60Meg and needs less than 128 Meg of RAM at full utilization. In testing, we easily ran 10 of them on older machines still waiting in the lab for death or recycle….  😉

Let us know if you have any questions, or comments. We really dig this idea and folks seem to really want it.

Book Review: IT Auditing by Davis, Schiller & Wheeler

This book is an interesting read, especially if your organization is concerned with SOX, GLBA or other regulations. It is written in the Hacking Exposed series style and features excellent examples and a user friendly layout.

Detailed examples of how to audit systems, applications and policies lie inside. From the basics of the audit process and function to command-line details, it’s all here. All the layers of the IT department are covered, in deep enough detail to be useful.

If you are new to IT auditing, this could become your handbook. If you have been around the block a few times, it is still likely you will find something new inside. Published by McGraw Hill and Osborne, the book is well worth the $59.99 cover price. It should do fine for a fireside read.

A Month in the Life of a HoneyPoint Deployment

Hello. I am a HoneyPoint deployment. My administrator has deployed me on a small business network of a financial institution. I have around 25 HoneyPoints deployed throughout their network, all reporting back to my console. It has been an interesting first 30 days of my life, indeed.

It all started when I was initially deployed. The admin started my listeners on a small group of servers and a couple of virtual workstations. Almost immediately, there was trouble! In my first few hours, I picked up scans of my web server psedo-service HoneyPoints. I was getting continually bombarded by four workstations from the sales group that were probing my pseudo-web services for a whole bunch of PHP files! I alerted the admin, and she found that those four laptops had been infected with an evil bot-net that was systematically scanning our networks for vulnerable PHP applications that the human controllers would later exploit. Good thing I came online when I did, because those four sales folks had just returned from a conference in Las Vegas, and it looks like their systems should have been running my younger cousin HoneyPoint:Network Trust Agent, because they had really been compromised. Ah well, what happens in Vegas, stays in Vegas I always heard. I guess not this time.

All went well for a couple of weeks, but then I had to alert the admin again. This time I had some joker consultant who was poking at my SMTP HoneyPoints. From the looks of it, that guy was trying to send email to the Internet and was looking for an open mail relay inside our network that would let him get through our firewall. The admin had a stern conversation with him and he behaved from then on.

Then, things got really exciting!  Yesterday, a new event came into my proxy from our DMZ segment. My admin had stealthily added some HoneyPoints into the DMZ that listened for SQL database traffic on the appropriate ports. Sure enough, I suddenly caught wind of some odd packets that were hitting my listeners out there. Nothing sets me off like SQL traffic to systems that are not running SQL. I hated to have to bother the admin again, but she told me afterward that her old IDS used to send her thousands of alerts a day (and many of those were false positives!!!) – so I didn’t feel so bad after all when I sent an email to her cell phone with the news.

She came running and through some quick analysis found that an attacker had compromised one of the web-applications in the DMZ and had gained control of the web server! Of course, not knowing that I was on guard, they began to use SQL tools to search for database servers that might hold valuable data – like human credit card numbers or something called Social Security Numbers. Either way, their plan was foiled and my admin took the web server offline and rebuilt it – this time with the missing patch for the web-application hole.

So, that’s my story so far. Not too bad for my first 30 days, huh? Who would have thought that I would have such an interesting story to tell. I always feared I might not see much action, but it looks like I have found my home. I have a good admin, a cool server rack and enough security work to keep me busy. Heck, since I don’t have any signatures to update and don’t require my admin to do more than “deploy and forget” about me, I wonder what she will do with all of her new found time? Maybe she will take up a new hobby, or get to learn about something called vacation. No matter, I will be here, ever vigilant, just waiting for the next security issue to arise. Yes, sir, who could ask for more?

Blast(s) From the Past

A few of my HoneyPoints delivered an interesting blast from the past to me this morning. Around 2pm Eastern yesterday, one of our IP ranges got hit by a scan with this signature on port 80:

GET /level/16/exec/-///pwd HTTP/1.0

The web connection was then followed by a series of connections on port 23, though the tool did not do anything more than banner grabbing on the telnet port.

While the scan was obviously an attempt to exploit the old Cisco HTTP vulnerability (circa 2001), I had not seen probes for those issues in quite some time. I also had not seen a tool that also connected on port 23 of the same host and did banner grabbing, so thus why this stood out above the usual noise.

This brought about a very interesting point that many of these old vulnerabilities are making comebacks. Scans for old web vulnerabilities like Unicode issues, Double Decode, Code Red and the ASN.1 worm continue to be among the most seen probes on the Internet. Other folks have talked about the idea that perhaps as more third world countries become more Internet connected, that technology may not be updated there as rapidly – which could cause the lifecycle of older vulnerabilities to either be reborn or at least, eek out a longer existence. Could ancient vulnerabilities like RDS and .HTR buffer overflows still be leveraged for Internet compromise? The possibility is high that some small percentage of systems is likely available as a vulnerable target.

Does this mean that vulnerabilities will have a lifecycle that approaches infinity? If there are still systems out there that are vulnerable, why would some attacker without general worries of discovery not just keep building a super-worm that continually crawls the net looking for every known web vulnerability to date? If incorporated and distributed through bot-net style approaches, this is likely pretty feasible – particularly if you can make the attack smart enough to adapt its vulnerability testing to the specifics of a target – much like a modern scanning tool.

How will some of these older vulnerabilities fair? It remains to be seen, but my bet is that blasts from the past are likely to keep on rolling in some diminutive way. Let’s just say that I think it will be a long time before we live in a Code Red free world.

VMWare Guest Security Problems

A few more problems seem to have been identified in VMWare and the potential isolation of the Guest systems. This article discusses how malicious code can be spread to Guest hosts via the scripting API of VMWare products.

This is especially dangerous given that many security researchers use VMWare and other virtualization mechanisms to study malware, attack code and other less-than-friendly mechanisms, but it has ramifications for everyone else too. VMWare claims, according the author of the article, to stick to their design decision that allows the issues to exist. They believe that the good of the feature outweighs the risk of compromise. I am not so sure they are right.

VMWare and other solutions are quickly moving into the core of most organizations and their IT spectrum. They have long evolved from geek-centric tool to mainstream deployment. As such, a vulnerability of this magnitude should be treated as severe. Guest OS isolation has always been a deep value to be maintained if virtualization is to reach even higher market penetration. Organizations simply can not afford, in today’s regulatory environment, to not be able to depend on isolation in their virtual systems. Without it, they will be back to deploying multiple physical systems to manage compliance – and we have already seen that this is not the way we want to go.

While work-arounds for fixing this specific issue exist (read the article for details), I think all IT folks should make it very clear to VMWare and other virtualization vendors that we can not accept issues with host isolation, no matter the cost to features and shortcuts. The risk is simply too high. Please, if you are a user of VMWare, let them know your thoughts. Drop them, or us, a line.

Oh, and don’t forget to modify your config files to disable the feature that makes this vulnerability possible!

More People Supporting Honeypots for Corporate Use

Got this off of the wire today. Pretty cool that other folks are beginning to weigh in on the power of honeypots in the corporate world.

Too bad this article doesn’t cover HoneyPoint. Hopefully, more folks will come to see the power of our solution. We just seem to need more marketing around our particular flavor of honey…   😉

Read the article here.

How Can We Get It Right?

The job of the venerable TSA agent seems to be nearly impossible to me. I am just back in the office from a couple of weeks of travel and man, there are just so many issues with airport security I am just amazed that there have been no repeat airline attacks.

In Charlotte, a man made it through the security screening a couple of weeks ago and got on board an aircraft! To make matters worse, the TSA response was to create a process of “Reverse Screening” where the passengers would be screened as they came OFF of the aircraft. Huh? What? Off of the aircraft? Isn’t it likely to be a little too late by then?

Meanwhile, it also came to light while I was traveling that another US airport shut down their security posts at night and that anyone with an official badge was allowed through unscreened. Apparently this had been going on for years, but had only become an issue when a local newsperson penetrated the area in this manner on video. I guess this security team had never heard of social engineering or counterfeiting of badges. Hey, it’s only airline security, right?

The problem is just so large, and the variables so very complex. Add to that the pressure from the American public to get it right – but without inconvenience or delays and you have a patented recipe for failure. I truly believe that the TSA issues are so bad and that the system is so broken that we may need to step back and rethink the entire approach to the solution. What we have now clearly is not working and it seems to me that we have been very “lucky” that there have been no further incidents. The problem with luck though, is that it often runs out…

What do you think about airline security? How much are you willing to tolerate in the name of safety? What do you think we should do to make it better? Drop us a line and let us know your thoughts!

What are spammers thinking?

Are spammers getting desperate? Recently we’ve seen spammers switch from text based spam, with random paragraphs to images, and then to pdf, which seemed like the new hot spam format. But this morning I had a couple interesting spams get through the spam filter.

One of them looked like this:

H,E_R’E WE GO AGAIN.!

T.H_E B*I-G O.N+E BE_FORE T*H+E SEPTEMBER.R ALLY’!

T*H-E MAR KET IS ABO,UT TO P*O_P’, A’N+D SO IS E X,M’T+!

T ick: —-

5-d+ay po.tentia.l: 0.. 4’0

Firm : EXCHA*NG,E ——- (Ot+her O.T-C*: —–.P K)

A+s+k_: 0..+1+0 (+.25.0.0%) UP TO 2*5.% in 1 day

N*o.t o,n,l*y d’o e+s t,h,i_s f i*r’m h-a v’e gr*eat fu-ndamen’tals,

b u t getti*ng t-h.i s opp+ortunit,y at t,h e righ,t t-i.m e-,

righ_t bef.ore t_h e ra*lly is w+h-a-t m,akes t.h i s d.e a l so sw*eet!

T+h-i.s a gr eat o.,pportunity to at leas,t do’uble up!

I can barely make out what that says, it’s harder to read than 1337 5p34k mxd w/ AOL spk. The PDF spam, while effective at getting through, required the end user to actually open the pdf and read it, but it was actually, you know, readable. I would really like to know who is still making sending out spam like this worthwhile. Do people sit around and decipher it because they think they’re going to get some secret thing nobody else does? Is it still cost effective for spammers to buy email lists from the black market? Ah, If only I had the time to do research on spam. Maybe somebody already did it for me.

VoIP Research on the Rise

So, if you watch any of the vulnerability lists that are out there, you may have noticed a recent spike in vulnerabilities that have been identified in various VoIP implementations from various vendors. If you’re not sure what I’m talking about, you might think about heading on over to http://www.microsolved.com and downloading our free threat intelligence tool, Watchdog.

If you’re already a Watchdog user, you may have noticed that MSI decided to go from green to yellow earlier this week. That decision was based upon the release of several vulnerabilities that have been identified in Cisco’s implementation of various VoIP protocols (oh yeah, and it’s patch Tuesday). Those issues ranged in vulnerabilities that could allow remote code execution to denial of service. We’ve also seen several problems arise in Avaya’s implementation of VoIP protocols over the past couple of months as well.

MSI has been saying that VoIP vulnerabilities were going to start popping up, for some time now. If I remember correctly, we started addressing this in our State of the Threat presentations about a year and a half ago. Over that time we’ve seen significant progress in the tools that have been developed to assist in managing VoIP deployments. While those tools have helped a lot of companies with their VoIP implementations, we’ve also seen them introduce unintended risks into their environments. We’ve also seen many more much more nefarious tools that are allowing attackers to gain access to the VoIP system. And if you consider how useful fuzzing has become at identifying unknown problems in network traffic and applications, the sky is the limit when trying to determine where VoIP vulnerability research is going to end up. That is why MSI is ecstatic to have been approached by several different entities to perform VoIP Risk Assessments on their VoIP systems.

While a VoIP specific Risk Assessment may be a fairly new thing, the premise is not. It’s simply a way of applying a proven methodology to assess whether the new (or old) VoIP system hasn’t introduced unknown risks into the environment. The methodology that we use is very similar to our normal Risk Assessment of an Information Security Program, though there are some minor steps that had to be added and tweaked. The primary goal of these responsible organizations is to ensure that they are performing their due diligence by having a third party assess their VoIP implementations, and we applaud them for their initiative.

New Attack Tools Getting More Sophisticated

Yesterday I followed up on some HoneyPoint traffic signatures that have been floating around for a while. I have been seeing a pretty steady increase in various scans for several types of PHP vulnerabilities over the last few months, so I started looking around at some of the script kiddie PHP scanners that were out there.

Interestingly, I found a couple of scanners on a forum that were pretty advanced. They each include 250 – 300 signatures for PHP vulnerabilities, several modes of “IDS evasion” that are minimally successful, at best, but do have options to adjust scanning speeds, manage scan target lists and other useful stuff. Overall, I was actually impressed with the depth, stability and capabilities that these script kiddy style tools possessed.

I will continue to troll through some more lower end tools and check them out for how their coding has improved. I think it is likely that compared with the many of the script kiddy tools of yesteryear, I will find that even the basic development and coding skills in the lower end of the attacker pool has improved. The attackers who develop basic tools and feed the script kiddy crowd seem to be becoming more and more capable of in-depth coding and development. While far from a shock to infosec folks, it does represent a phase shift that we should be aware of. Likely, their tools will continue to grow in stability and sophistication – all of which makes for more formidable opponents.

Just something to think about….