About Brent Huston

I am the CEO of MicroSolved, Inc. and a security evangelist. I have spent the last 20+ years working to make the Internet safer for everyone on a global scale. I believe the Internet has the capability to contribute to the next great leap for mankind, and I want to help make that happen!

Do It Yourself Identity Theft Protection

By now you have probably heard the commercials. The CEO of the company gives you their social security number to prove that they have his identity locked down. He is so confident in their process that he is willing to give the world his name, information and SSN.

I probably get asked twice a week about this service, so I decided to take a look at it a bit closer. What I found was a pretty easy manipulation of the credit management system in the US combined with some customer service and consumer offloading of tedious work. What does that mean? It means that you can outsource your identity theft protection to them or you could save $10 a month and do it yourself – IF YOU REMAIN VIGILANT.

How does it work? It works like this. Inside the US credit reporting system, there exists a  mechanism called “fraud alert”. This mechanism can be placed on any account, at any time, by the consumer. The purpose of the mechanism was originally to give people who have already been a victim of identity theft a tool for ensuring that no further damage would occur. The mechanism works like this:

  1. The consumer, or someone with their power of attorney, contacts the major credit reporting agencies and requests a “fraud alert” be placed on their account.
  2. The credit agency places the “fraud alert” on the appropriate credit file. There is no charge for this, it is required by law.
  3. The credit agency MUST contact the consumer prior to approving any change, addition or new activity on the consumer’s account. Failure to do so is a violation by the credit agency of federal lending laws.
  4. The consumer must either approve or disapprove the addition or change. If they disapprove, the creditor should refuse the account activity – THUS STOPPING THE FRAUD.
  5. ** PAY ATTENTION TO THIS ONE ** The credit reporting agency removes the “fraud alert” after 90 days from the date of placement. The consumer, or their legal agent, may renew the “fraud alert” at any time after that 90 day period.

So, that said, you could save the $10 per month and contact the credit reporting agencies yourself. You simply call them and ask that the “fraud alert” be placed upon your own file. If you do that every 90 days, you will have protection from credit attacks caused by identity theft. The key is, you HAVE to do it every 90 days. Miss a day, and you have exposure…

Before you run to the phones, you should also know that having the “fraud alert” on your accounts can be a bit frustrating if you actually want to use your credit or open new loans, accounts, etc. Sometimes, creditors will simply refuse the accounts until the “fraud alert” is removed – regardless of your consent to open the account. Other than that, it is a pretty tight mechanism for protecting your information.

There has been a lot of media attention to the company in question that has made this service popular. They seem to be everywhere. Their marketing is certainly working – though I would estimate, mostly due to consumer fear. My guess is that it won’t be too long until the fears they seem to be playing to will lead to saturation and slower growth, but my friend Alex always told me “You can sell just about anything for $10 a month.”

So, at the end of the day, is this a service you buy or a task you manage yourself? Is it worth worrying about, or is it something you deal with if you have a problem? Only you can decide if you are capable of managing the work or if you would rather have someone do it for you. No matter what you decide, at least you know the facts. As with most security things, it is less magic and mystery and more of a common thing.

Should you decide to do it yourself, here are the contact numbers for the three primary credit reporting agencies and for the primary checking account verification house in the US (same thing applies)….

Equifax – 1-800-525-6285
Experian – 1-800-422-4879
Trans Union – 1-800-916-8800
Chex Systems (check fraud management) – 1-800-428-9623

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!

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….

The Ups and Downs of Security Research

So, here I am working on a vulnerability I discovered in OS X. I am deep into doing the final work of making sure it is exploitable and writing proof of concept code. My fuzzers had identified the issue a week or so ago, but with my busy schedule I just had not had time to pursue what was looking to be a local exploit with a little capability for malicious activity – like perhaps exposing the contents of file vault or other things that are based on user context.

But, low and behold, along comes an update from Apple that patches the vulnerability. Upon deeper research, it appears that they also discovered the issue (or blindly mitigated the hole) while they were repairing another problem included in this patch cycle! Congrats to Apple for fixing what appears to have been an unrelated issue and for seeming to actually be doing the right thing of performing additional testing or mitigation on code they are working on. To me it looks like they may actually have implemented a process where as one issue is found with a piece of code and addressed, the whole piece of code is more deeply inspected, tested and assessed. That’s FANTASTIC news!

So, while I am doing the “poor me” shuffle for spending cycles on an issue that has become NOT AN ISSUE, I am also bouncing around with joy that the right approach to securing code seems to be spreading. That alone, is worth a smile. I really like it when the right thing happens and some part of the world gets a little more secure!

That’s just another part of life as a security researcher. Things continue to break in new and exciting ways, but sometimes, even while you are working on the rabbit hole, someone comes along and fills it in….