Pick the Right Tool for the Job: Penetration Tests, Vulnerability Assessment and IT Security Audits

December 15, 2008 – 1:05 am
Assessing Network Security book by Kevin Lam, et al.

Assessing Network Security book by Kevin Lam, et al.

I had a meeting with a potential Impacta client the other day and they were inquiring about getting a ‘penetration test’ performed against their network.  Upon talking more and more with them, turns out that they needed something much different than a penetration test and I told them this openly. Sure, I could have sold them a penetration test, but I think this particular industry could do with a little more integrity than what’s currently available.  I gave them a copy of my book and explained to them the different types of security assessments. No signed contract came out of the meeting, but at least I was able to help steer them in the right direction.

I think a lot of people can benefit from some of the same information I shared with this potential client, so if you have a copy of my book Assessing Network Security (Microsoft Press, ISBN: 9780735620339) then you’ll want to read up on chapters 1, 3, 4 and 5.  If you don’t have a copy of Assessing Network Security (shame on you ;P) then this blog was written especially for you.

Vulnerability Scanning

This is the most basic form of security assessment and usually carried out by some software package. These software packages assess networks and applications for known configuration weaknesses and vulnerabilities. They are useful for enumerating current assets, identifying common security mistakes, searching for computers with known vulnerabilities and testing for exposure to common attacks.

  • Benefits: Can be automated, finds known vulnerabilities
  • Limitations: Subject to frequent false positives, results depend entirely on the quality of the software, can report only commonly known vulnerabilities

Penetration Testing

Penetration testing differs from vulnerability scanning in that it looks at the security of a network or application as a whole, whereas with vulnerability scanning it is done on a per system basis. Penetration tests also typically begin without administrative rights (that’s the ultimate goal of a penetration test – to get administrative privileges!) whereas most vulnerability scanners require administrative privileges. Penetration tests answer the question of how detected vulnerabilities can be exploited and weaknesses in people and processes.

  • Benefits: Exposes weaknesses not possible with vulnerability scanning like social engineering weaknesses, exposes method with which vulnerabilities can be exploited
  • Limitations: Requires highly skilled security professionals, results depend on the skill of the penetration tester, may disrupt network services if done recklessly

IT Security Audits

IT security audits are much different from vulnerability scanning and penetration testing.  IT security audits focus on people and processes that support, manage and implement security on a network or applications. An IT security audit will help you understand if you have the necessary infrastructure to main a secure computing environment.

  • Benefits:Can be used to provide evidence for industry regulations (SOX, HIPAA, etc.), provide a snapshot of the appropriateness of current security policies and procedures
  • Limitations: Can be very time consuming

The book has a lot more detail than shown here, but I hope you still found this useful, enjoy!  If you have questions, please feel free to email info@impactalabs.com or submit a comment.

–Kevin

By Kevin Lam | Posted in Risk Management, Security | Comments (9)

How NOT to Conduct a Penetration Test: Recent Rises in a Disturbing Trend

December 9, 2008 – 12:56 am

I wanted to blog about a disturbing trend that I’ve been seeing recently. I might be slightly biased here, actually I know I am, but hear me out on this one for just a moment and I think you’ll agree with what I have to say. 

I had the chance recently to review the results of a penetration test report of a company as a ‘second opinion.’  Turns out the company hired the same company that developed their Web-site, a web-development company, to also perform the security testing for PCI evaluation readiness — yikes!  The web-development company used a formidable set of tools to do the analysis including prominent names like Nessus, Eeye’s Retina, Nikto, Nmap, GFI, etc., and yet I spent about 20 minutes on that site using tools developed here at Impacta and manual techniques, and dug up a handful of SQL injection, XSS and blatant configuration issues that were not included in the report. Worst of all, the penetration test was billed out as a 2 month engagement for a single online system.  So not only do they not have a good understanding of their PCI compliance (at least the Web portion), they probably wasted about $32-40k for work they will probably have to do again.

I’ll cut straight to the chase: do not hire Web-development companies to assess the security of your online presence, especially when they created that online presence!  That’s like:

  • Having students grade their own finals
  • Having baseball players test themselves for steroid use
  • Having a security assessment company design your Web site for you :P

None of these make sense. You can say I am biased (I am. Impacta does penetration tests, security code reviews and other security services), but the whole goal of penetration tests and other assessment activities is to have ”an independent assessment of the risks present in a system.” Keyword: independent.

Of course Web-development companies are going to say that they are experts in security.  Why?  Because that’s what their competition is also saying.  Just keep thinking ‘independent review, independent review’ and you’ll be fine.

–Kevin

By Kevin Lam | Posted in Risk Management, Security | Comments (23)

Don’t Get Too Caught Up in the Patch Game: How to Tell if a System is “Secure”

December 3, 2008 – 11:37 pm

An article from Webuser online magazine in the United Kingdom today reported that 98% of home PCs are not secure.  I don’t doubt that number, in fact I am surprised that it’s not higher. What I do disagree with is the definition of ”secure”.  In this report, secure is defined by measuring whether or not the system was up-to-date on current patches. In reality, “secure” is a relative term and it involves a little more than just patches.

I lied, it’s a lot more than just patches. Consider this: if I had a system attached to the network that was configured by the firewall running on that system to block all incoming traffic, and yet it was 100% not patched, is the system still secure?  That’s a foggy question.

The more relevant question, and this will help you better approach your organization’s network security strategy (psss, here’s how the real risk management pros look at it), is what is the actual risk? What are the controls that reduce that risk? The lack of patches for example create risks that a firewall can help reduce, but not completely eliminate. Even patching a system entirely doesn’t eliminate all possible risks. At the end of the day there will be some residual risk no matter what.  At that point you should be asking yourself is the degree of residual risk acceptable according to company policy and standards?  If not, then that system is not “secure”, if it is then it is “secure”. Not to over simplify things, but that’s about it.

–Kevin

By Kevin Lam | Posted in Risk Management, Security | Comments (3)

Secure Operating System Challenges

November 27, 2008 – 12:33 am

I am a big fan of innovation and according to an article from the WSJ at http://blogs.wsj.com/biztech/2008/11/19/making-pcs-as-reliable-as-brakes/, Green Hills, a software company that makes operating systems for medicial equipment and brakes, is planning to develop a “secure layer” for Windows operating systems, particularily the desktop environment.  While I think what Green Hills is trying to do is great, and the purpose of this blog posting is not to rain on their parade, I do see some key challenges in addition to those called out in the WSJ article, they are:

  • If your operating system has a defined, well known set of scenarios (as in the case with brakes, and medical systems) then it’s pretty easy to secure.  There’s a set of valid scenarios (white list) and conversely anything outside that set of valid scenarios is an invalid scenario (black list). But what if that set of valid scenarios is very large, as in the case of operating systems for the desktop market? What if that valid set isn’t even defined? How would you effectively secure something like this?
  • Operating systems for the desktop market need to integrate with lots of “stuff”.  People install third party software onto their operating systems, and it all needs to work together and do it all securely.  Each one of these foreign applications creates a new trust boundary that could potentially represent new attack surface.  Could a “secure layer” reasonably manage all these boundaries? And if it could, would that system still be performant enough to be usuable?
  • The Windows of today (security-wise) is nothing like the Windows of before. I remember doing penetration tests in early 2000-2006 and praying that somewhere in the list of targets there was a Windows system, because compromising them was just so easy.  Nowadays, it’s almost reversed — Windows is a lot harder, not impossible, to compromise (mostly due to the guidance, tools and best-practices prescribed by the Microsoft SDL). So if you buy into the notion that Windows systems are more secure these days, what additional value could a “secure layer” provide?  Better question, what additional value could a “secure layer” provide that someone would be willing to pay for?
  • It’s no longer just about security. Modern day operating systems for the masses need to also be cognizant of threats to privacy — could a “secure layer” account for privacy concerns?
  • Even if all of the above could be accomplished, how usable would that operating system be? Functionality and security share an inverse relationship: the more secure an application is made, the less functional it becomes. Could average users like grandma still easily use this highly-secure system?

If Green Hills can take their experience and expertise in building highly-secure operating systems for single function systems, and successfully transition that expertise to highly-secure multi-function systems, then kudos to them!

–Kevin

By Kevin Lam | Posted in Security | Leave a Comment

Outlook 2007 IMAP Spam Bug Workaround

November 5, 2008 – 1:48 am

Update (11/05/08): This solution should work for very small user bases, and it’s what worked for me.  It might not work for you, and definitely won’t be practical if you have a large user base to manage.  If you have a large user base (some have reported 4200+) then I suggest that you contact your Microsoft technical account manager (TAM) and they should get you connected with the right people, if not get your issue escalated.

This blog posting is in response to the thread on MSDN forum regarding an Outlook 2007 IMAP bug that was reported by someone else. As of October 31st, 2008 this issue still seemed to be active so I decided to share the workaround that I created, and that has worked for me (no one else on the thread from what I can tell indicated something similar, but if they did my apologies).  I hope readers who have this same issue will also benefit from this (comments appreciated) until a patch is available from Microsoft.

Finally, please read and accept the disclaimer and terms of use before following any of these steps.

–Kevin

The Issue:

outlook2007bug-rejectedspamreceipt1If you’re using Outlook 2007 over IMAP (say for instance you’re using Google Apps, or syncing with Gmail) you may have noticed that you’re getting bounced spam messages from message gateways indicating that a spam message (supposedly from your account) was received and rejected by the message gateway.  Upon inspecting the details of the receipt, you’ll see indeed that the spam message did originate from your computer’s IP, and from your Outlook account.  Turns out that there appears to be a bug with Outlook 2007 in how it handles incoming spam messages.  The bug is simply that Outlook tries to send out read receipts to all the recipients of the spam message, which in turns makes the spam appear to have originated from you.  No spam messages ever appear in your Outbox or Sent folder.  This thread on MSDN forum documents similar experiences from several others.

The Workaround:

outlook2007bug-interestingbehaviorI was able to reproduce this on my lab computers, and noticed an interesting behavior. If I had two IMAP accounts, then the spam read receipts would only be sent from the account that had an email address that appeared last alphabetically.  That is, if I had an account that was named foo@impactalabs.com and another named bar@impactalabs.com, then the spam receipts would only be sent from foo@impactalabs.com (since f appears later in the alphabet than b).  There was nothing special about foo over bar, in fact both accounts pointed to the same IMAP server.

outlook2007bug-bogusimapaccountSo as an experiment and a workaround for this spam issue I create a third ‘spam trap’ IMAP account in Outlook that was assigned the email ‘z@junk.com’.  Since it started with the letter ‘z’ it would ensure that this account appeared last alphabetically in my IMAP accounts (see screenshot below).  I assigned it bogus IMAP and SMTP servers (imap.localhost, see screenshot) and it has seemed to do the trick. I haven’t seen any such reject messages now for close to 2 weeks. 

outlook2007bug-workaround1

The only side affect I’ve noticed so far is that you’ll get the occaisionally complaint from Outlook indicating that imap.localhost is not accessible, but well worth it in place of re-spraying spam across the Internet :P.  I also removed this IMAP account from the account that gets synchronized when you press Send/Receive and that helped reduce the number of complaints.

By Kevin Lam | Posted in Innovations Lab, Security | Comments (2)

Security Awareness Plays Called Out for What They Really Are: “Gimmicks”

October 29, 2008 – 8:42 pm

Ben Worthen from the Wall Street Journal posted an interesting article about the fact that anti-virus companies were turning to gimmicks to try to raise awareness to the number of recent data security breaches.  In this article, Worthen calls them out for what they really are — “publicity seeking moves”.

Worthen cites anti-virus companies in his article, but I’d like to also point out that several security companies are also guilty of this.  How many times have we seen security companies purposely or “accidentally” release information to the public about a vulnerability they’ve discovered in some widely used system or application, only to justify their actions later when stuff hits the fan as an attempt “to raise awareness”?  Or in some cases, release a working exploit of that vulnerability as a proof of concept “to raise awareness”.  It asymmetrically damages the reputation of the security profession as a whole, and worse, it creates more net risk than it actually reduces.  Let’s face it, there rarely are any accidents, especially amongst security folks who are not a dim bunch by any stretch – the only awareness they’re trying to raise is awareness about themselves or their company.

–Kevin

By Kevin Lam | Posted in Security | Leave a Comment

Why Economic Bad Times Means Good Times for the Bad Guys

October 22, 2008 – 3:34 pm

If you’ve ever heard any of my presentations, one of the things I like to say is that malicious hackers, or any other types of criminals, are like electrons — they tend to, if not always, take the path of least resistance.  That is, if given the choice between attacking system A, which requires 1 day of effort, versus a similar system B, that requires 10 days of effort, malicious hackers will gravitate towards attacking system A.  It’s really just a matter of return on investment (ROI): What’s the least amount of effort or resources I can put in to achieve the same results?

With the economy taking a downturn, expect see more of these least resistance systems and applications for the bad guys to attack.  The eternal challenge for security is measuring ROI, and in the absence of metrics like these, line items such as these are usually the first to go — especially in hard economic times.  Think about it, if you’re an organization and you had the choice of spending money on (A) something that could make more money and help you survive, versus (B) spending money on something that won’t make money (i.e., securing an existing or new system), which would you choose? Most, if not all, organizations will choose A. A blog post by Ben Worthen from the Wall Street Journal posted an interesting article about the recent number of attacks increasing in step with the downturn of the economy that would seem to support this notion.

Finally, not only do harder economic times means good times for malicious hackers attacking systems, they also mean good times for the malicious hackers attacking the users of those systems.  In particular, the economic downtown should produce more successful victims for phishers and online scam artists.  Desperate times make desperate people unfortunately, and so it’s reasonable to predict that people will become more willing to try anything — especially the get-rich-quick schemes a la phishing attacks.

–Kevin

By Kevin Lam | Posted in Security | Leave a Comment

Ohio Secretary of State’s Web site Hacked

October 22, 2008 – 1:53 am

Hi everyone, Kevin here.  If things weren’t interesting enough already with this coming US presidential election, CNN reported this week that the Ohio Secretary of State’s office Web site was hacked (http://www.cnn.com/2008/POLITICS/10/22/ohio.website.hacked/).  Government site hacking is pretty common, but what was particularly interesting about this was in the article Ohio’s Secretary of State reported that “fortunately no sensitive information was breached in the incident.”  I hope that this really is the case, but I am wondering how they know this so soon, especially less than a day after the original hack. Kudos to the office for reporting the issue promptly, but in my experience a forensics investigation that would enable someone to make such a definitive statement (by the way, a PR security no-no) would require much more effort and time.

By Kevin Lam | Posted in Security | Leave a Comment

Not Your Typical SQL Injection Vulnerability

October 13, 2008 – 3:36 pm

Hey everyone, Kevin here.  I took our assessment product prototype out for a spin the other day, and it detected a fairly interesting SQL injection vulnerabilty on an extremely popular Web site (Alexa top 100 in the United States at least).  The SQL injection vulnerabilty revealed itself in a HTTP 500 error response, similar to the following (site directory and affected file name have been changed):

— START —

<font face=”Arial” size=2>

<p>Microsoft OLE DB Provider for SQL Server</font> <font face=”Arial” size=2>error ’80040e21′</font>

<p>

<font face=”Arial” size=2>Invalid character value for cast specification.</font>

<p>

<font face=”Arial” size=2>/sitedir/file.asp</font><font face=”Arial” size=2>, line 31</font>

— END —

A couple interesting points regarding this particular vulnerability:

  • Applications using mshtml.dll won’t be able to detect this. Since the SQL error was buried inside a 500 HTTP error response, if you’re using Internet Explorer (i.e., you’re a security consultant) or a scanning tool built on top of mshtml.dll (most, if not all) you won’t see this error response. Mshtml.dll will serve up a generic error message and evidence of this vulnerability will be essentially masked.
  • The error message is spread across formatting HTML tags.  This is the most interesting aspect of this issue.  If your tool is looking for specific SQL error messages such as, then the more interspersed the message is in between HTML tags, the more unlikely your tool will be able to detect the SQL error message. 

Our tool was able to detect this instance primarily because of the way our patent pending scanning engine was designed, but if say every other word (or worse every other letter) was interspersed between HTML tags, even I would start having doubts on our tool and every other tool.  To detect vulnerabilities like this would require something more innovative than just string searches. Anyhow, a little food for thought.

–Kevin

By Kevin Lam | Posted in Innovations Lab, Security | Leave a Comment

Official launch of the Impacta company blog!

October 13, 2008 – 2:59 pm

With the alpha version of our product almost complete, and our company well positioned for some significant growth in the next year, what better way to start things off than with a company blog?

We’ll be using this blog to write about company news, share our innovations in online risk assessment, and to reach out to the industry — and of course, have a little fun doing it!

–Kevin

By Kevin Lam | Posted in News | Leave a Comment
Follow

Get every new post delivered to your Inbox.