Blacklists, Clustering and The Matrix

Blacklists are the mainstay of many security technologies protecting enterprise networks today. Despite being used practically everywhere however, many people fail to understand what blacklists actually offer in the realm of protection - and how they're often used as a preemptive protection technology.

Add to that a complementary technology - one offering more advanced features in the realm of preemptive threat detection (and perhaps "protection") and used to aid and extend blacklists - is that of clustering.

To help explain these technological terms (and whats happening in this field of preemptive technology) I wrote a couple of technical blogs that were published in SC Magazine this week. With a bit of luck you'll find them educational and a bit of fun.

Part One: Blacklists, clustering and The Matrix

Part Two: Blacklists, clustering and The Matrix

Mobile Threats - Cellular Botnets

Smartphones are getting smarter. You know it, I know it, and every would-be criminal botnet operator knows it too. But why haven't we seen many cellular botnets? It's not as if it's difficult to exploit, compromise or otherwise socially engineer a remotely controllable agent on to the handset.

Thoughts on the topic went up on the Damballa blog site earlier today and are mirrored below...

Last month I gave a couple of presentations covering the current state of cellular mobile botnets – i.e. malware installed on mobile phone, smartphone and cellular devices designed to provide remote access to the handset and everything on it. While malware attacks against dumb and smart phones are nothing new, the last 3 years of TCP/IP default functionality, compulsory data plans, access and provisioning of more sophisticated development API’s, have all made it much easier for malware developers to incorporate remote control channels in to their malicious software. The net effect is the growing “experimentation” of cellular botnets.

I purposefully use the term “cellular” so as to focus attention on the botnet agents’ use of the mobile Telco’s cellular network for Internet access – rather than more localized WiFi and Bluetooth services. Worms such as Commwarrior back in 2005 made use of Bluetooth and MMS to propagate between handsets – but centralized command and control (CnC) was elusive at the time (thereby greatly limiting the damage that could be caused, and effectively neutering of any criminal monetization aspirations). More recently thoughh, as access to the TCP/IP stack within the handsets has become more accessible to software developers through better API functionality by the OS vendors, the tried and tested CnC topologies for managing (common) Internet botnets are be successfully applied and bridged to cover cellular botnet control.

Discussions about Smartphone botnets are making it to the media more frequently – albeit mostly the IT and security press – for example, “Botnet Viruses Target Symbian Smartphones“. Based upon the last couple of presentations I’ve given on the topic, lots of people are worried about cellular botnet advances – no more so than the Telco providers themselves.

Sure, there are plenty of ways of infecting a Smartphone – successful vectors to date have been through Trojaned applications, fraudulent app store applications, USB infections, desktop synchronization software, MMS attachments, Bluetooth packages, unlocking platform application downloads/updates, etc. – but relatively little has been publicly discussed about the use of exploit material. As we all unfortunately know, one of the key methods of infecting desktop computers is through the exploitation of software vulnerabilities. Are we about to see the same thing for Smartphones? Will cellular botnets similarly find that handset exploitation will be the way to propagate and install botnet agents?

In all likelihood, vulnerability exploitation is likely to a lesser problem for Smartphone – at least in the near future. Given the diversity in hardware platforms, operating systems and chip architectures, it’s not as easy to create reliable exploits that can affect more than one manufacturers line of product. That said though, some product lines are numbered in the tens of millions of devices, and the OS’s are becoming increasingly better at making the underlying hardware transparent for malicious software and exploitation. I’ll also add that there are plenty of vulnerabilities, “reliable” exploits up for sale and interested researchers bug hunting away – but at the moment there’s little financial gain for professional botnet operators compared to the well established (and much softer) desktop market of exploitable systems. But we have to be careful to not marginalize the threat, it’s worth understanding that botnets are already being developed and (in very limited and targeted distribution) are being used for installing botnet agents on vulnerable handsets.

This is of course causing increasing heartburn for the mobile telco providers – since their subscription models essentially mean that they’re responsible for cleaning up infected handsets and removing the malicious traffic, much more so than traditional ISP’s are. If a handset is infected, their customer will likely incur a huge bill and (as what typically happens) the Telco will not be able to recover the losses from the customer. Attempts to recover the cost from the customer will increasingly yield two results – 1) they won’t be a customer any longer and 2) the negative PR will have them rolling in pain.

Fortunately, as the cellular botnets become more common and sophisticated in their on-device functionality, they’re also going to become more mainstream and closely related to classic Internet botnets. What this means is that their CnC channels and infrastructure will increasingly be close to (or the same as) “standard” botnets. Which in turn means that cellular botnets can be thwarted at the network layer within the mobile Telco operator’s own networks (similar to what some major ISP’s are trialing with their residential customers) – thereby turning the threat in to something that they can protect against. How is that possible? Well, a quick browse of the Damballa website should provide a fair bit of insight in to that – and perhaps I’ll post a follow-up blog on key techniques sometime soon.

Forgotten Password?

The increased proliferation of malware and botnet agents designed to rapidly intercept, retrieve and copy the passwords you use on a daily basis to access Internet resources likely means that it may be time to revisit many of those longtime-standing password policies. Given all the "best practice" guidelines I've seen over the years, I think that (in practical terms) they're increasingly missing the mark in defending against today's threat landscape.

One particular "best practice" that I think needs to be re-thunk... "don't write your password down."

I blogged a little more on the topic over on the Damballa site... It's safer to write your password down...

-------

Common wisdom over the last couple of decades has been to never write down the passwords you use for accessing networked services. But is now the time to begin writing them down? Threats are constantly evolving and perhaps it’s time to revisit one of the longest standing idioms of security – “never write a password down”.

Back in the day, a password was a critical part of the corporate identity system. You supplied your user ID and password pair in order to get online and to access key corporate resources. Access controls then extended the authentication model to enable greater control of what users could see, do and change. As new systems came online, and as business extended beyond the in-house corporate networks, additional (i.e. separate) authentication systems came in to play. Despite multiple attempts at developing and deploying single sign-on (SSO), most employees still need to juggle a dozen passwords in order to do their work. If they have external Internet accounts as well, then they’ll be juggling several dozen additional passwords. Once you thrown in their personal Internet accounts (webmail, Twitter, Facebook, LinkedIn, PayPal, Amazon, etc.) you’re quickly neck-deep in password soup.

Whats traditionally been the problem with writing down password anyway? Well, since passwords are the critical ingredient for access control, corporate security teams have long “educated” employees in to never writing them down. To do so would potentially expose yourself to impersonation – and you’d ultimately be responsible for whatever (damage) the impersonator did in your name.

In the meantime, Internet guides, popular PC magazines, and practically every website that forces you to create a login account, all extol the virtues of never writing your passwords down. They also give you lots of additional advice – such as “use a strong password”, “use a unique password”, “never use the same password on a different site”, etc. All of which make it incredibly difficult for any practically minded human to keep track of which password belongs to which website. The net result being that the “password rules” are being repeatedly broken.

Now, to ease some of this burden, there have been a spurt of software tools that’ll help remember passwords on your behalf. For example, the popular web browsers all provide some capability in this area. The problem though is that the bad guys have better tools. Practically all of today’s malware(along with all those botnets you hear about each day) have the built-in capabilities of grabbing/stealing both the passwords you’ve remembered and type in each time you visit a favorite website, and the passwords being conveniently “remembered” by the software on your computer.

Why would writing down a password be good? Well, it’s not a question of being good – just better. Granted, anything you type on your computer can (and will) be grabbed by the malware it’s been compromised with- but the lowest hanging fruit for the bad guys lies with all the stuff you’ve already asked your computer to remember on your behalf. After 3 months of use, web browser “remember” functions may have captured 50+ sets of authentication details. Within a few seconds of computer compromise, all three moths worth of stored credentials will have been copied and stolen (oh, and they’re neatly formatted and sorted) – so the malware doesn’t need to do any work, and it doesn’t matter if your anti-virus software gets an update tomorrow capable of detecting the malware and removing it. The damage is already done.

Staying hidden on a victims computer is not a trivial task for many malware – particularly wide-spread Internet malware (anythingwith a name you may have read about). There are lots of things that can go wrong. AV updates may detect the infection, dropper websites may be taken down, uploading sites may be sinkholed, CnC domains may be hijacked, etc. so it’s become important for modern malware to steal as much information as possible within the shortest possible time. Factors such as conveniently storing all your authentication details on your computer and recycling popular (i.e. memorable) passwords reduce the time the malware needs to be operating in order to steal critical data.

What about a few high-level odds?

• 1:3 – home PC being infected with malware with password stealing capabilities in a given year.
• 1:4 – home PC being infected with a botnet agent in a given year
• 1:8 – corporate PC being infected with malware with password stealing capabilities in a given year
• 1:12 – corporate PC being infected with a botnet agent in a given year
• 1:160 – your car being stolen in a given year
• 1:700 – your home being burgled
• 1:600,000 – being struck by lightning

I think it’s time to revisit the “never write a password down” idiom. Prioritizing best practices in password management, I’d be inclined to list them in the following order:

1. Don’t use the same password on multiple websites
2. Don’t let your computer “remember” your password!
3. Use a “strong” password – preferably something with 12+ mixed characters
4. Don’t use a predictable algorithm – e.g. abc123
5. Change your passwords regularly. For sites with lots of personal information and associated monies, change every 2-3 months. For other sites, try every 6-12 months.
6. Don’t reuse past passwords – even if you think it’s a cool password.
7. Don’t write your password down.

Yes, that’s right – writing down your passwords come in at a distant 7th place. In practical terms, even if you only manage the first 4 on the list, you’re probably going to be juggling at least a couple of dozen passwords (or more thank likely that’ll be 40+ on a regular basis for most people that spend any time online). The probability that your computer(s) will be compromised and that the information will be stolen by the bad guys malware is much, much greater than the probability that someone will manage to break in to your house and target all the post-it notes you’ve stuck around your screen with all your passwords on them. In corporate environments there’s a higher probability that the evening cleaning crew would gain visibility of he passwords (so post-it notes aren’t to be recommended), but that risk of an insider threat is still going to be lower than your work computer being compromised.

The first 6 password recommendations would trump the 7th in most cases – provided you take care in how and where you write your passwords down. Be smart about it… but don’t underestimate the risks posed by modern malware either.

Gold dust or Nuggets? A Hackers Tell

After a hard day's conferencing, security folks will typically end up in the hotel bar and, with odds often appearing to be in excess of 3:1, the conversation will inevitably encompass a discussion of which internal corporate systems are the most hacked/vulnerable/indefensible.

If the migratory cluster of bar stools and hotel chairs encircling the obligatory way-too-small table contains more than a pair of reformed hackers or pentesters, by listening in you'll end up gaining quite a bit of insight in to why the better hackers are so often successful (and you'll probably also pick up a few tell's for future reference).

While there's much literature and many tutorials to be found that explain the technical aspects of how to successfully compromise corporate defenses, exploit systems and ultimately extract data, there's actually very little "guidance" on which systems should be targeted and why, once you've breached the network. Sure, there's plenty of discussions covering the technical aspects of how to raise privileges (e.g. locating and exploiting the Active Directory server in order to acquire corporate user/admin credentials etc.), but which systems really provide the treasure trove?

Quite a few folks I've been speaking with will initially (and specifically) target the systems used by the corporate security teams. These systems are important for a couple of reasons; 1) internal security folks often have good access to a wide range of other systems that may be valuable and 2) By keeping an eye on the "watchers" you'll know when you're close to being caught and can stay a couple steps ahead. Personally, I think it's a ballsy move if you can pull it off - but it's not something I'd throw in as a priority. There are a lot of inherent risks in trying to tackle systems maintained and watched by the professionally paranoid - so it may be more prudent to gather better intel first.

Another primary target for some folks is to go after the obvious corporate data repositories - the backend databases, business intelligence systems and storage facilities. This mode of attack I'd associate much more with the quick "get in and get out of dodge as fast as you can" - maximizing the potential reward by sacrificing (IMHO) a fair degree of stealthiness and persistence. If typically works very well - and is an ideal tactic for "compelling result" penetration testing or hackers looking for rapidly monetizable data.

A tactic that I've always preferred (dependent upon the specific objectives of the pentest of course) is to initially locate and target the QA systems. For the folks that target the corporate secuity systems or go after the official data repositories, going after the QA systems sounds not only unexciting but also like a complete and utter waste of time. But hear me out first. QA systems really are a veritable treasure trove of corporate data. Consider the following:

1. Like a smelly hobo camped outside a high-street McDonalds, both security analysts and helpdesk alike tend to keep their distance from (what are typically) "unmanaged" QA systems.
2. QA systems often contain complete copies of the high-value corporate data so that development teams and QA/Testing personnel can actually test the applications correctly. You'll often also note that the more "valuable" a particular suite of data, application or business process is, the higher the probability that the QA copies of the data will in fact be real-time mirror images of live data.
3. Nobody ever "owns" the QA systems. They're always the last systems to get patched (if ever) and access controls typically hover between poor and non-existent.
4. When was the last time anyone bothered to look at the audit logs? With so many ad-hoc system use, trials and testing, it's a nightmare from both a detection and forensics perspective. QA systems are an ideal place to recon an enterprise network from and retain a persistent toe-hold within the organization.
   
5. QA systems typically have "temporary" access to to all the core business systems and data repositories within a corporate network. By "temporary" I mean in theory if you listen to the server administrators - in practice they can be considered permanent gateways.
6. Testing systems are typically littered with copies of entire development source code trees - making it a piece of cake to acquire the latest business logic, intellectual property or hard-coded/embedded passwords to other critical systems within the corporate entity.
   

Sure, there's plenty of other opportunistic systems to go after within a target's organization once they've been breached, but with all other factors being equal, there are certain tactical tell's that can be readily associated with the types of hackers and pentesters out there (the previous three just being examples I heard/discussed repeatedly over the last couple of weeks).

The primary objectives and "styles" of the hackers/pentesters reminds me a little of those old Western gold-rush films. Rounding up the Sheriff and his deputies and locking them up in their own jail before robbing the bank is a little analogous to going after the security folks/systems. Meanwhile the priority targeting of the corporate data repositories reminds me of a stagecoach robbery - the pounding of hooves and guns blazing. Yet going after the QA systems reminds me of a movie in which the villains dig up the ground under the saloon and casino - hoovering up all the gold dust that patrons had lost over the years through the cracks in the floorboards.

Grab a beer with a friendly hacker or pentester and ask them how they'd earn their gold.

Anti-FUD FUD

Like the cycling of the moon, the security industry also exhibits periods of waxing and waning on particular issues.

At the moment it looks like were entering the Waxing Gibbous stage for anti-FUD (Fear, Uncertainty and Despair) movement. In recent weeks the proliferation of calls to deal with FUD within the security industry has picked up. Depending upon the particular sector, you'll encounter discussions about overcoming the fears associated with shifting data in to the cloud, why "advanced" threats aren't so important if the bulk of attacks don't need to be, etc.

As you'd expect, there are quite a few security folks who make their dime by being vocal about a particular topic, and it's that time of the cycle that the anti-FUD speeches get dusted off and replayed. That's not to say that the anti-FUD folks are unique. There's an biannual waxing and waning to the Full Disclosure movement too, along with annual revisits to the topic of Vulnerability Purchasing Programs, etc.

The anti-FUD movement consequently promotes their own kind of "FUD" - speculating that the world would be a better place if FUD ceased to exist in the security world, and that organizations would be better able to prepare their defenses without the distractions of the next biggest threat.

Some aspects of the anti-FUD cause I might just agree with, but in general I'm less inclined to to follow much of rhetoric from die-hard security officinardos. Why? Well, for the most part, many of their statements are naive in that they obviously fail to understand the world they live in. Listening to them you'd think this is an IT security problem - but in reality "FUD" is a critical element of the sales cycle - regardless of whether you're selling car tires or anti-zit cream.

Every second car advertisement on TV extols the virtue of their safety features, even drunk-driving and "wear your seat-belt" literature distributed state authorities cover the gruesome consequences of not following the rules and taking appropriate actions. FUD gains the attention of the viewer/reader, educates them in some capacity and makes them think more about the consequences of their actions (or inaction's).

FUD is everywhere - just watch the ads covering Zit cream and Tampons on TV, and you'll get the idea. FUD is a critical element of the sales cycle by eliciting a reaction to the message (generally - aiming for a buying reaction).

Folks that jump on their anti-FUD high horses, from my own experience, tend to struggle with commercial sales because they fail to understand what FUD is all about - education, compulsion and sales.

Having said all that, lets not go to the other extreme though. In order to make their FUD more compelling and elicit a greater compulsion for listeners, some sales folks will stretch the truth in to the realm of fiction. These folks need to be quickly reigned-in by the company paying their paycheck. To do otherwise would inevitably result in pissed off customers and a loss of business.

Final thoughts? The security industry is no different from any other industry with innovative products aimed at solving the problems of today and the future. FUD is a way of life, get used to it.

Rusting Credit Cards

OK, so you know that the back of your credit card has a magnetic stripe on the back of it. Did you know that it can store three tracks of data, but only two are actually used for credit card transactions? Did you also know that the third line of data was hoped to be able to contain a digital photograph of the the card owner? (but its damned hard to fit a photo in to that few bits of data).

If so, did you know you can actually see the data encoded on your card?

Over the weekend I stumbled upon a very interesting blog titled "Another Science Experiment" covering the use of finely ground rust dust to see how the data is encoded on to standard credit card magnetic tracks.

I'll let the photo's below do the talking...

Military Grade Malware (Part 1)

Not all malware is created equal. Of the 50k-80k new and unique malware samples received daily by the mainstream anti-virus companies, there's a lot of scope for variety. Most of the samples are merely serial variants being pumped out as part of a barrage of criminal campaigns, and then there's a sizable handful of custom crafted malware that (for the most part) is generally unsophisticated botherware and spyware, but occasionally you'll uncover a few very crafty and sophisticated malware samples mixed in there.

In a lot of cases, these particularly sophisticated malware samples only manage to get caught up in the wash of general malware samples because of some circuitous and "unlucky" compromise paths - or because they're several months old and the "discoverers" have finished reaping the reward of having investigated them. Most of the really interesting bespoke malware samples rarely come via mainstream discovery and sample sharing systems though - in fact the majority of them rarely go beyond the virtual walls of the organization or government department that were targeted or victimized by them.

Given all the discussions about Advanced Persistent Threats (APT), Advanced Malware and Next Generation Malware (NG Malware), I thought it was about time to disclose some of the techniques being used within the commercial world in the production of such sophisticated malware... hence this blog entry being the first in a series covering "Military Grade Malware".

Military Grade Malware
I use the term "Military Grade Malware" to encompass the following key concepts:

1. A legal contractual agreement exists between the professional software development team and the purchasing organization.
   
2. The expectation is that the "product" will be used for purposes beyond financial and criminal fraud.
3. The intended distribution of the malware will be limited in scope and typically only be deployed in very specific environments.
4. The malware is designed to be stealthy and continue to operate for extended periods of time - typically against a sophisticated adversary.
   

Why are these important? The vast majority of malware circulating around the Internet and infecting both home and corporate systems are clearly designed for criminal purposes. More often than not, they're heavily weighted towards data theft and financial fraud. While the authors of the malware may or may not be criminals themselves (e.g. many of the popular DIY construction kits are sold commercially, by licensed companies, as "Remote Administration" tools) - they are designed to operate on popular operating systems and commodity hardware.

In the past I've used the term "weaponized" to encompass malware that makes use of exploit material as part of its critical operations - but this term only extends so far.

Exploit Weaponization
There are plenty of boutique security consulting organizations out there that offer "weaponization" services. They will typically review and study the latest vulnerability disclosures, develop reliable exploits for use against specific operating systems (e.g. an exploit for a popular Vietnamese instant messaging client running on Microsoft Windows XP SP3 with the Vietnamese language pack installed), and pass the final QA-checked exploit on to their client.

Most of the organizations I've come across that provide this kind of service have strong affiliations with their local government. That said though, a handful of them are more mercenary and will provide their weaponized exploits to other "friendly" governments. I'll point out at this stage though that this is a wholly different arrangement compared to vulnerability research teams working within companies that develop commercial vulnerability scanning and exploitation tools.

The provisioning of (reliable) weaponized exploits will generally be governed by formal legal contracts. It's not easy work though. Many people see the plethora of public vulnerability disclosures and hear about the odd zero-day exploit doing the rounds, but the development of reliable exploits that meet the contractual demands of the client is not a simple task. A company that can deliver a half-dozen ruggedly reliable weaponized exploits each year is doing very well - and will be compensated accordingly.

Malware Weaponization
The weaponization of malware in my opinion generally only encompasses the binding of a "standard" malware component to a particularly good/reliable/weaponized exploit.

For example, a client may have a preferred Remote Access Trojan (RAT). This RAT is consequently bound to the latest weaponized exploit - i.e. the RAT is merely the payload of the successful exploitation.

In another example, a versatile malware agent may support a library of exploits that it can use to worm and propagate around a targeted network. In this case, the weaponized exploit is constructed to be compatible with the malware agent and is added as an "update".

Both examples would fulfill the generic term "weaponized malware", but there is a difference between this type of malware and what I'd tend to term "Military Grade" malware, since military grade malware may or may not actually make use of weaponized exploit materials.

What are the features and techniques of military grade malware? I'll begin to cover those details in subsequent blog posts...

Paste Bin & Card Dumps

Trawling around for stolen credentials and identity information - in the form of criminal cast-offs and sales samples - can be an interesting endeavor if you're looking to understand the current state of credential laundering. One growing repository for such information are all of the various paste bin repositories (of which there are dozens of popular sites).

Earlier this week I discussed the topic over on Damballa's blog site in the entry titled: A Treasury of Dumps. The blog provides a few samples of whats available and how the criminals are using them to augment their search for potential sellers.