Back to Basics

I tend to lurk on a bunch of email based discussion groups where I watch threads that talk about "what should we used instead of the broken MD5 hash" or "what the alternatives to broken SSL". I see lots of focus on the new 0-day sploit and techniques involving intercepting communications, cracking something or other, then using that to compromise something else. There is no question that when it comes to "cyber security", it is an extremely dangerous world and getting more so. Unfortunately, I think the industry of computer security has lost its way.

A article about recent Booz Allen Hamilton compromise, Anonymous was quoted as saying "We infiltrated a server on their network that basically had no security measures in place. We were able to run our own application, which turned out to be a shell and began plundering some booty. Most shiny is probably a list of roughly 90,000 military emails and password hashes (md5, non-salted of course!). We also added the complete sqldump, compressed 50MB, for a good measure." Yesterday, a colleague of mine stated that he found a basic authentication bypass SQL injection bypass vulnerability in a clients payroll server and found that the username/password combination of GUEST/GUEST worked on that same client's VPN. From what I saw or could infer from news about many of the Lulzsec compromises, they seemed to be using SQL injection or similar attacks.

I know 0-day compromises are possible and a threat. I know there are ways to break different types of encryption. I also know that people, generally, can tend to be a little lazy. I don't mean lazy in a bad way but if given the choice between cracking passwords and typing 'or 1=1 into a password field, which would you do? Would you rather research and use an new 0-day exploit or leverage the fact that the target hasn't patched Adobe Reader in 3 years.

As a penetration tester, there are some basic techniques that make my life a lot harder:

• Good patching practice, not only for Microsoft but for all technologies
• Basic hardening, particularly something as simple as changing default passwords
• Security focused web and email filtering.
• Strong firewall rules for both ingress and egress
• Network segmentation and access controls between segments
• A decent web application firewall
• Updated endpoint protection

How many recent (publicized or otherwise) attacks could have been prevented by these fairly basis measures? Am I saying that this is all that is necessary for security? Absolutely not, but I do think that as security professionals, we tend to miss the obvious and focus on the complicated leaving the bad guys with big holes to walk right through. Perhaps we should spend a little time getting back to basics and make sure that the foundation of our security program, the policies and the security infrastructure, are in place because all too often when doing risk assessments for my customers, I find that is not even close to being the case.

Cisco Identity Services Engine: What it Means To You

The recent introduction of Cisco’s next generation network access control system (ISE) raises the bar for internal network security controls and should make you examine whether this system is appropriate for your organization.

ISE is an integrated network access control system. The system is designed to restrict network access based on criteria defined by the organization. These criteria typically includes any combination of the following:

· Correct user ID & password authentication

· Windows group membership

· Up-to-date operating system patches

· Antivirus software functioning & up-to-date

· Machine owned and managed by the organization

· Operating system and/or browser

Based on these criteria, the level of network access is defined commensurate with risk. For example, machines that do not have updated patches might be permitted to only “talk” to the patch server so that updates can be installed. Further, network access can be defined dynamically based on the users role (i.e., only Human Resources users are permitted access to the servers containing personnel data.) Restricted network access for guest users is a natural extension of this technology, allowing visitors to access the Internet using existing infrastructure while protecting internal resources.

In legacy NAC systems, this control is implemented through dynamic VLAN assignment in conjunction with a separate control point, typically a dedicated firewall or NAC appliance acting as a primitive firewall. More modern 802.1x NAC systems control access at the switch-port level, but have proven difficult to implement and maintain, requiring multiple disparate systems to manage.

Cisco ISE is innovative in that it implements everything mentioned above in a single integrated platform with a rich, flexible set of policy controls. ISE has broad hardware support, including the most common Cisco switches & wireless devices. Further, tools to accommodate non-NAC and/or non-802.1x compatible devices, such as printers, IP phones, or CCTV systems, are cohesive and mature, requiring minimal effort to maintain.

Employing security consultants and engineers with broad cross-functional experience, NWN STAR is uniquely qualified to design and implement Cisco ISE systems. Our engineers have implemented NAC systems across a variety of industries, including government, education, banking, retail, and healthcare environments. NWN recently became one of the first Cisco partners to be trained and certified to implement these systems for both small- and large-scale environments.

Gmail Users Beware

Recently I discovered that a Gmail account I use for subscriptions to newsletters and similar non-critical content had been hacked by someone in China. That, by itself, isn't that interesting but there were some interesting aspects of the "attack".

I would like to think that I am fairly security savvy, given that is what I do for a living but this event has opened my eyes to how vigilant we must be as defenders and the true advantage attacker have over us.

I first discovered that this Gmail account had been compromised when I started receiving bounce-back messages from a strange email address - 451231738@qq.com. I know I didn't send any email address so I did some digging. It turns out that QQ is a popular instant messaging site in China. Hmmmm, that's not good. I then checked out the setting on my Gmail account and discovered what actually happened.

Typically, I view the email from this particular Gmail account on any of various other devices (iPad, laptop, etc.). As a result, I don't usually log in to Gmail itself. When I did, I was presented with a big, red flashy sign that said, basically, Danger Will Robinson, someone has recently logged into your account from China - click here to see what happened. I clicked there and found that my account had been accessed at least 3 times from China starting around 10 days before I detected the problem. That, of course, prompted additional investigation.

I looked in the setting of my Gmail account and found a lot of bad things. I first noticed that someone had set up the QQ email address as an address that mail sent to the Gmail account could be forwarded to. Next, I discovered that the password recovery email address was also set to the QQ email address. Finally, I found a number of filters set up to forward any email containing the words "password", "info", "account" and "paypal" would be sent automatically to the QQ account. Also, any email from @blizzard.com or @battle.net would be forwarded.

Given that I don't use this Gmail account for anything critical, I'm not terribly concerned about the impact of this hack. I suppose someone in China could steal my subscription to a newsletter or discussion group but that's not that big of a deal. There are a couple of things that really do have me concerned.

First, how did the attacker manage to compromise my account without me knowing about it? Perhaps my password could have been better but doesn't Google have a setting to prevent brute force attacks?

Second, it scares me that the attacker was able to modify the settings of my Gmail account such that I would not have found out about the attack if the QQ address hadn't been shut down. How many others don't log into the Gmail web site but rely on Mail.app, phone mail clients, Outlook or similar mail clients to get their mail?

Third, how many people use their Gmail accounts to conduct real business (either professional or personal)? How many people use Gmail to reset the passwords on their bank accounts, to pay bills, etc. This type of attack had little real negative impact on me but that we partially dumb luck in that I don't use Gmail for anything really important.

Finally, is this problem specific to Gmail? Are other web-based mail services less vulnerable? Equally vulnerable? More vulnerable?

To wrap things up, if you are reading this and use a web-based email service like Gmail, check you settings as soon as you can. I'm not saying you've been hacked but it is better to be safe than sorry. Remember to check the settings and change your password to these sites regularly.

And Google, if you are by any chance listening, please include an account lockout function (if you don't already have one) and please allow me to include a setting that alerts me if settings are changed. It doesn't have to be fancy - just a quick email stating that "we just wanted to let you know that your settings have been changed - if you didn't do this, you've been hacked!".

Nessus Parser V0.10

Cody Dumont from the NWN STAR team just release the latest version of his Nessus Parser. The parser can be found at www.melcara.com. Here is an expert from his blog posting.

Nessus Parser v0.10 – This is a program to parse a series of Nessus XMLv2 files into a XLSX file. The data from the XML file is placed into a series of tabs to for easier review and reporting. New features with this edition are better reporting of policy plugin families, user account reporting, summary graphs, and a home page with summary data. For more information and questions please contact Cody Dumont from the NWN STAR team.
Email – cdumont”AT”nwnit.com

Access Granted

Back in April, I discussed the March breach in security at RSA. After I posted my article, I was contacted by a friend of mine that works for a certain “Three Letter Acronym” agency whose name and organization will remain un-named. My friend asked me if I might happen to know exactly what was compromised at RSA? While I couldn’t be certain, I suggested what I (and maybe most of you) had already heard via news channels, media, and security contacts. While I know more details on what actually happened, I don’t know specifics. From my knowledge, what was known to be compromised was possibly the algorithm seed, and maybe the key generation time. The algorithm itself, has been publically known for years. From a security standpoint, this is like having a key, but not sure which lock it fits into.

I told my friend that there shouldn’t be too much to worry about, because while there’s enough pieces compromised to launch a brute force attack (basically, an educated guess that is retried until you succeed), there shouldn’t be enough to do a more damaging attack. Brute force attempts are fairly easy to spot, mitigate, and deny access. My friend was put, at least a little, at ease. That was until last week…

I received notification that sometime last week, a very large U.S defense contractor that uses SecureID tokens from RSA to provide two-factor authentication (something you have, and something you know; think of your Bank Card and your PIN) for remote VPN access to their corporate networks. Before Monday morning an alert went out, and all remote access to the internal corporate network was shutdown. Employees were notified that remote access could be down upwards of a week, possibly more. For telecommuters, this meant you either came into a branch office, or you simply could no longer work. Two days ago, my friend told me, a notification that every person who had an RSA SecureID token, would be getting a new one. This process, as I discussed in my earlier article, would take at least a few weeks to funnel out to everyone.

Along with this, all users (over 100,000 of them) would be required to change their passwords. The amount of help desk related issues this causes, simply means that administrative level files and access have almost assuredly been compromised.

From what I can tell, whomever hacked RSA, had now come into possession of the algorithm for the current tokens, and had then managed to install a key-stroke logger somewhere on the network. With both of these pieces, that unknown lock I discussed earlier in this article was now known.

While this was an expected outcome (most security folks like myself, have been awaiting such a breach), it was not enough to circumvent this from occurring. Shortly after the RSA breach became public knowledge, most companies that relied on SecureID for authentication, started requiring a second form of password before access to the network was granted. This, though as you can probably tell, would not resolve the issue if a key-logger was in place, as the hacker would know the password the minute it was typed.

I am a “Glass Half Full” sort of person, so I guess the silver lining in this story is that my friend and his staff were able to spot the intrusion, and acted appropriately to mitigate any further incidents. Kudos are warranted for such a feat as this is not an easy task. Although the aftershocks caused by this incident will be many, and far into the future.

While I am sure this is not an isolated incident, it is a major one, and one of the first public ones. At the time of this writing, I can state I know of others as well. This is not the first successful hacking attempt using the compromised SecureID technology. It certainly won’t be the last…

What concerns me most though, is that RSA has not been as forthwith in providing full disclosure about what was compromised and how vulnerable we are. RSA, if you’re listening, pretending like this didn’t happen and keeping it all secret, does not help things, it only makes them harder to track.

Even given all of the issues raised in this article, I don’t see anyone abandoning RSA or the SecureID product it sells. While most networks exchange token information over a secured and encrypted network path, this is only a false sense of security. My friend, and his organization can now attest to this.

If this can happen to a very secure network, employing some really talented security staff and products, it can happen to others as well. How far this will lead, and what sort of national secrets will be exposed now that such an attack has publically been proven to work, only time will tell.

Thus Quoth the Token Nevermore

Traditional tokens are a dying breed

There is an oft used term that a recent event is a 'sign of the times'. In 2011 though, technology has dictated the ringing of the bell announcing the dead - at least in terms of the traditional token. Gone are the days of the telltale SecurID key fob dangling from your house keys. The recent hacking of RSA exposed data that could ultimately compromise the security of the widely used SecurID token. In their defense, it's not the first time tokens have been attacked; and yes, compromised. Tokens are, in fact, still around. So, why, you may ask, is this year different from previous ones?

Let us review:

• During the 70's the 8 inch floppy was king




• The 80's gave way to the 5 inch floppy disk & later, the 3.5 inch




• The 90's took it a step further and gave us the CD, USB, and DVD for media alternatives




• All hail, the Blu-ray of the new millennium

What this shows is that all things change. Nothing, especially where technology is concerned, is constant. Two factor authentication is no exception. While two factor authentication has seen improvements since the days of yore with complex and cumbersome challenge tokens, we're still relying on this antiquated technology in the majority of physical tokens today.

If you think that a solution is great only because it's stood the test of time longer than most, think again. Columbus thought that, and he ended up only 9,000 miles away from his goal. This sure isn't India...

The simple fact is there are several issues with physical tokens and the way they are, and continue to be, implemented. Some of these problems have been around for almost the entire 30 years we've been using them.

Here are a few examples:

• Token deployment, even as simple as issuing a SecurID token to an employee, is tedious, and time consuming; sometimes even relying on snail mail which could take in excess of many months for distribution over an entire enterprise




• Over 10% to 15% will be damaged, lost, or stolen every year




• Barring all this, at best, a token's lifespan is 3 to 5 years




• Users forget their tokens - even ones attached to key rings; Contractors lose track of which token is for which client, adding more confusion




• Physical token systems require updates, maintenance, re-synchronization, and replacement

To every problem, a solution exists. How can we, as a global enterprise, still be secure, yet use technology that is already in place? The answer is simple - and you already own it.

Enter: The Mighty Cell Phone.

SMS has been in use for years, but with the global community reaching in excess of well over 5 billion devices currently in use, it seems most of us have overlooked one thing SMS is good for - that being to act as an authentication token. A passcode is sent to your Droid phone, for instance, thus eliminating the need for a physical token. SMS alone is not the answer, though. SMS does, in fact, have its pitfalls. The real answer lies in an ability to create similar (or even better, stronger) security that is already inherent in devices we already predominantly use. The unreliable nature of delays in messaging, cellular dead zones, or network issues with your provider are actual issues you may very well face. I am certain that those who wish to still cling to an antiquated technology, such as key fob based tokens, are sure to use as a rallying cry. At what point, though, do you stop bailing the sinking ship, and find a newer, better, stronger one?

Now Entering: MobilePASS.

MobilePASS by SafeNet, is a technology that still uses the same methodology of tokens, that being a two-factor authentication system. It simply does it in a better way. With MobilePASS, there's no additional hardware to lug around with you, the technology is easily deployed (and furthermore, managed), and the learning curve is non-existent. You do know how to download an app, don't you?

Strong encryption is still on the playing field. The tried and true two-factor authentication is still in the mix, yet the cumbersome, expensive, and dare I say, recently compromised hardware token, isn't.

"But what about my Windows Device?"

"There's an App for that".

In fact, not only is there an app for that old desktop of yours, but there's one for the iPhone, Blackberry, Windows Mobile, Android, Java 2ME, and even Out Of Band devices via SMS. Did I mention that it also covers Windows Server based platforms as well?

To log on to a secure network, from a laptop, PC or even an iPad (with the right software installed of course), users generate a One-Time Password (or OTP for short), via the MobilePASS app on their phone, and then enter this in the login screen thus creating a secure connection. Out of band delivery can also be granted via SMS or even email.

While MobilePASS by SafeNet is only one solution out there that utilizes cellular technology to end the need for the traditional token, this sort of solution is great for many reasons.

It is estimated that such a solution as moving to an SMS based method such as this can reduce the ongoing running costs of authentication means by over a whopping 40 to 60 percent! Lower cost, higher convenience, and utilizing technology already in place.

SafeNet is a global solutions partner of NWN Corporation. As such, NWN can leverage this partnership to assist our clients in lowering their bottom line, ensuring the security of their infrastructure, and delivering the best technology-based solutions currently available.

From ShmooCon - URL Enlargement

Well, ShmooCon started almost a week ago and it's about time to post something. First and foremost, all of the talks were outstanding and I'll probably wind up talking about most of them but I wanted to start with one that stuck out - URL Enlargement: Is it for You? by Daniel Crowley.

We all have seen URL shorteners. Many Twitter clients utilize them automatically. If you haven't seem one, check out www.tinyrul.com. Basically, you put a URL of any length in and you get a shortened version back out. For example, if I enter http://nwnsecurity.blogspot.com, I get back http://tinyurl.com/4v9e7w7. Now that's a savings of only 5 characters. That's not much but could help when using something like Twitter. If you are talking about longer URLs, the savings can be significant.

OK, that's convenient but what does that have to do with information security? Here's where the fun part begins. Check out this link - http://tinyurl.com/4g8gfpk No, really! I promise there's no malware there. In fact, it won't actually point to a web page. Just check out the URL that it resolves to. If you don't want to actually click on the like, check out http://www.longurlplease.com/ or http://www.longurl.org/.

OK, so we've established that URL shortening can be used to circumvent DLP systems. What else can it do? Well, a while back Billy Hoffman (a.k.a. Acidus) created a tool called TinyDisk. It is basically a file system that utilizes TinyURL (or other shortener) for storage. Now you can upload large data files to a stealth file system. That's cool. Unfortunately, I did some quick checking and couldn't find TinyDisk available for download. I'm sure it's out there but I couldn't find it with the 2 minutes of checking I did.

We've established that URL shortening can be used to establish covert channels but there are some other uses that I found to be particularly interesting.

When performing social engineering, will a user click on a link to http://www.somethingevil.com. Probably. But let's assume that the user is paying attention. They might think twice about clicking on somethingevil but what about clicking on http://tinyurl.com/o5h7wv. Now that's a completely different story. URL shorteners can be used to hide the javascript tags in a cross-site scripting attack or other URL parameters that might give away what you are really trying to do.

Also, when a user clicks on a shortened URL, their browser actually connects to the URL shortening service server and that server refers them to the final destination. If you are doing penetration testing and want to track who clicked on what, you can send different people URLs to the same site that were shortened by different URL shorteners. That way, tracking the referred will allow you to identify who clicked what.

One last point. What would happen if you encoded malware in base-64 and shortened that via a URL shortener? Hmmmmm.

Thanks Daniel for an excellent talk. Now off to the URL shortening.