‘Shellshock’ In Plain English: Latest Security Vulnerability is a Big One

September 25, 2014

Many network administrators and information security folks are feeling the effects of the ‘Shellshock’ bug, this morning.  The bug has been confirmed as ‘worm-able’, and proof-of-concept code is already bouncing around.
(source: Errata)

In many ways, Shellshock is worse than Heartbleed.  Here is a quick, plain English breakdown of the vulnerability:

What Shellshock Is:

It’s an attack that does not require the attacker to ‘authenticate’ to the system or server being attacked.  In other words- the attacker does not have to have a username/password, or break passwords.

What the attacker can do:

Everything up to full control of the compromised device/system/server.

What Shellshock affects:

Linux, Mac OS/X or any device that uses a ‘Bash’ Linux command-line (most internet connected devices).

If you read that it only affects Linux systems/servers- don’t breathe a sigh of relief just yet!  Most of the ‘Internet-of-things’ devices (Cameras, refrigerators, TVs, etc.) use a form of Linux, and are potentially vulnerable.  In addition, if you are running ‘SOHO (Small Office/Home Office)’ wireless access points, managed switches, and routers, or if you are using a store-bought Firewall/Cable modem then you may be vulnerable.

If you rely on IT support, and they tell you that there is ‘No problem- we don’t allow shell or terminal access to the outside world’, then you need to point out to them that is not the entire attack vector:  Any process, or program that IS accessible, that sends commands to the shell, is potentially vulnerable.  It is not always obvious which programs or services do this, behind the scenes.

So what can be done?

Review and Confirm: Check your systems, servers, and devices to see if they are, in fact, potentially vulnerable.

Patch:  A number of the primary Linux shell versions had patches available within hours.

Keep an eye out for firmware updates for your internet devices: Internet connected TVs, Wifi access points, SOHO-class firewalls, Network storage devices, internet connect cameras, etc.

Kill Non-essentials: Consider turning off, or disconnecting, non-essential ‘internet-of-things’ devices until a patch is available for them.

BE ALERT FOR PHISHING SCAMS:  So-called ‘spear phishers’, and scammers of every ilk, like to use these well-publicized security issues to trick people into downloading malicious programs.  Always deal with a known security site, or directly with the manufacturer.


Patch NOW (the Register)

Shellshock bug (the Mirror)

TECHNICAL: CVE-2014-6271 (NIST.gov)


Because One Thing Leads to Another: Data Breach and Password Re-Use

June 27, 2012

Dropping Your Breaches…

After the data breach of LinkedIn two weeks ago (6.5 million passwords leaked, a five million dollar lawsuit on the way), I have asked a simple question of some of my clients that I know are LinkedIn users: “Have you changed ALL your passwords yet?”.

The question has been met with confusion (“What data breach?”) and, in most cases, with indifference (“I don’t see what benefit having access to MY LinkedIN would provide a hacker.”). When I mention the phrase “password re-use”, I receive an almost universal response of “huh?”.

Single Point of Failure

Password re-use is seemingly an ingrained response to the presence of a password: You have hundreds of password protected resources, so it is natural that you would re-use the same password across multiple (or all) of those resources. This is the problem.

From the point of view of a hacker the world looks a little wider:

1- Breach LinkedIN passwords

2- Now leverage the email addresses, username conventions, etc. to test the password on:

Workplace accounts – Obvious information on LinkedIN. This could include work email systems, vpn access, extranets, etc.

Gmail and other webmail accounts – Possibly contains password/access information to online banking, work, other accounts

Mobileme and other “Cloud” services – Dropbox, anyone?

Online Banking – A pretty obvious target.

You can see how the seemingly “insignificant” breach can lead to much bigger issues.

In the case of the LinkedIN breach, the information obtained was posted for download by anyone that wanted to take a whack at them. Consider the scenario of an opposing party downloading your breached information and leveraging it for further access.

We know that information security is a balance between usability of information and systems, and security of those same areas. So how does one maintain separate use passwords but still easily access needed resources?

So Now What?

Fortunately there are some solutions. I have listed the top ones below:

Password Safe  (also known as PWSafe) – Windows, iPad, iPhone, Mac, Linux: This is actually my favorite. Syncing among the devices is supported by iCloud (of course then you need to make sure that Apple iCloud isn’t breached) so that a change on one device is rolled out to all the others. Password Safe is free for Linux and Windows (it’s always a nice thing to do to donate to the open-source team that keeps it going and evolving, though). The PWSafe version is $3.99 for Mac and $1.99 for iPad/iPhone.

LastPass  – Windows, Linux, Mac, iPhone, iPad, Android, PocketPC:  LastPass is perhaps the most “feature rich” password management systems out there, and even offers password management for common web-based forms. There is a free and premium version. The premium version runs $1 per month.

KeePass  – Windows, Mac, Linux, iPhone, PocketPC, Android: KeePass uses very strong encryption (SHA-256). It interested me for a couple reasons: Multiple user support and it keeps the password encrypted even in RAM memory. The only reason I don’t use this one is that I don’t find synching to be as transparent, and I was already in the habit of using Password Safe (since it’s creation by Bruce Schneier). KeePass is free for the desktop versions (I recommend donations to the open-source team that keeps it running).

So the question becomes: “How would you and your firm like to be at the center of a multi-million dollar lawsuit that could have been prevented by a series of easy to use software that costs nothing to use?”.

Coming next week: Information security breaches for law firms are on the rise. How vulnerable are you, and what easy steps can you and your firm take to defend yourself?

Financial Institutions Using Live Data Sets in Test Environments

March 16, 2010

A recently released survey finds 83% of financial firms use production data for testing.  What this means (for the non-developers) is that your customer data is used unmasked and in its full form to test systems that, by the very fact that they should be TEST systems, have an unknown level of security and integrity.

Even though the study was commissioned by a company that works specifically with data protection in test environments (important to call out bias!), I believe the numbers on this one – especially when I go back and research the number of financial institution data breaches that have occurred because “live” customer data sets were in the hands of a third party contractor, or other employee off-site.

I have done development work on health data and I understand full well the challenges of creating meaningful data sets (as well as the enormous expense) for testing purposes.  The bottom line comes to this:  There is no excuse that justifies exposing personal data in this manner.  Period.

In performing penetration tests a common tactic that we use during the “recon” phase is to look for servers that are obviously development systems.  We do this because patch levels and security are typically at a minimum on these systems and they are usually the “low hanging fruit”.

So it makes me wonder – just what justification can possibly make these guys think this is OK?

Here are some more stats from the study that should give you pause:

  • identity compliance procedures (used by only 56 percent of companies surveyed);
  • intrusion detection systems (used by only 47 percent of companies surveyed);
  • data loss prevention (DLP) technology (used by only 41 percent of companies surveyed); and
  • Social Security number usage (88 percent of those surveyed still use this as a primary identifier)

Remember these findings the next time you read a news release regarding a financial institution data breach and some chuckle-head says that they are quite certain no sensitive data was taken or misused.  The very next question to ask is: How would you even know?




Microsoft Powerpoint Vulnerability

April 3, 2009

IMPORTANT INFORMATION REGARDING: Microsoft PowerPoint Vulnerability

A vulnerability has been discovered in various software versions of
Microsoft PowerPoint.  Exploitation of this vulnerability can lead to
code execution at the rights level of the logged in user.  No patches or
workarounds have been released.

Microsoft has stated that exploit attempts have been seen in the wild,
on a limited/targeted basis.

Microsoft Office 2000
Microsoft Office 2003 Professional Edition
Microsoft Office 2003 Small Business Edition
Microsoft Office 2003 Standard Edition
Microsoft Office 2003 Student and Teacher Edition
Microsoft Office 2004 for Mac
Microsoft Office XP
Microsoft PowerPoint 2000
Microsoft PowerPoint 2002
Microsoft Powerpoint 2003

As previously stated, successful exploitation limits malicious code
execution to the rights of the logged on user. Steps should be taken to
ensure permissions for various account types are regulated per
applicable policies.

Successful exploitation of this vulnerability requires user interaction
with the specially crafted PowerPoint file.  Users would therefore have
to to click links in malicious e-mails, or otherwise convinced to visit
websites hosting malicious PowerPoint files.  The best defense against
this is educating users on the dangers of accepting files and acting
upon links to websites provided to them via e-mail, IM, or other means
from unknown parties.



Microsoft Security Advisory (969136)

Mac != Automatically Safe (Take It From a Mac Fan!)

April 1, 2009

I love my Macbook Pro – ask anyone who knows me.

Before you Windows users leave thinking that this is YAFBR (Yet Another Fanboy Rant) you should all know that I believe strongly in using the right tool for the job – which does not always mean using the trusty Macbook, and sometimes using MS Windows instead (lord help me, but I said it and there is no taking it back).  Sometimes it involves Linux or a BSD variant.  I love them all for different reasons.

I am concerned with the number of Tweets I saw related to Conficker this morning that stated (not an exact quote) “Thank goodness I have a Mac – it is safer than a PC…Macs never get viruses” and other sentiments that denigrated MS Windows in a sometimes more, sometimes less manner.

Before you get too happy consider the information discussed at CanSecWest last week and published by Milw0rm prior to vendor notification.  Check it out here (but come back!)

It is important to note that you are only as safe as your habits and software, Apple system or not.

I have worked a number of Apple forensics cases involving intrusion and interception of electronic communication.  In each case the firewall was turned off (the user wasn’t aware of how to control the firewall) and there was an astounding lack of logging (the user didn’t know how to control or review logs on the Apple system).

I can also tell you that the number of these types of cases is definitely on the rise.

Here is a quick test:  If your Apple (you can also insert Linux, *BSD, Windows) system was potentially compromised, how would you know?  Can you pull up, right now, failed connection attempts, firewall logs, running process logs?

If not, then take that as your sign and make sure to get yourself battle-ready.

As bot-nets become more and more prevalent if you are not part of the solution you are truly a large part of the problem.

Open Source and the Digital Forensics Lab

March 18, 2009

A while back I wrote an article for Evidence Technology magazine entitled “Seven Uses of Open-Source Software for the Digital Forensic Lab.” The article was primarily targeted towards law enforcement agencies that were having trouble getting funding for their labs.  In addition to building the case regarding cost savings, I discussed other advantages to running open sourced tools.

At recent conferences I have been increasingly approached by law enforcement as well as corporate investigation teams for advice on dealing with budgetary constraints, so it seems time to resurrect the topic.

Here is a summary of the “Seven”, the original article is here:

  1. Case Management: Although designed for CRM functions, SugarCRM actually makes a great inexpensive case management system.  It has the added advantage of allowing you to maintain a local copy instead of “the cloud”.
  2. Acquisition: The flexibility of “dd” for everything from imaging to memory and file carving makes it the number one contender in this category.  If you must have a MS based solution then you can also try FTK’s Imager lite (not mentioned in the original article).
  3. Analysis: Brian Carrier’s work on The Sleuth Kit with the optional graphical front-end of Autopsy is very worthy of support (tip of the hat to Dan Farmer and Wietse Venema for their original work on “The Coroner’s Toolkit”).  TSK has the added benefit of being scriptable (I use shell or PERL to get the job done).  You can check out TSK here.
  4. Miscellaneous: Stegdetect for dealing with steganography, Ophcrack for system passwords, Foremost or Scalpel for scriptable file carving.
  5. OS support: Linux.  You have access to libraries for NTFS, HFS++, etc. as well as everything you need for MS documents via OpenOffice 3.0. I have had great success with Ubuntu and variations (Mint).
  6. Virtual Platforms: At the time I wrote the article VMWare was offering their player and pre-made virtual systems for download.  If you are running off of a Mac you can use Parallels (not free, but very inexpensive) to run various pre-builds of Linux.  Even more compelling is Live View, which allows you to virtually mount and run a dd image without modifying the underlying image.  You can find Live View here.
  7. Mobile Acquisition and Analysis: Helix is no longer free, but those guys at e-fense  have given so much value to the rest of the world for so long via Helix that I say “Good on them!”.   You can also check out Backtrack 3 – just be aware that you run the risk of altering data if you boot up incorrectly with Backtrack.

What are some other “Can’t miss tools”?  Drop a comment in and tell the rest of us.

Government Denies FOIA Request For .gov Domain List

March 4, 2009

Information Week Article

I was sure that the concept of “security through obscurity” had been thoroughly debunked by now, evidently not.

A recent Freedom of Information Act request for a list of .gov domain names was denied by the GSA.  You should know this about me: I am all for state secrets – I think that, realistically, a government must have secrets.  This is perhaps an argument for another day.

Given the nature of DNS, cached DNS, etc. how long do you think before some of these “hidden” domains show up anyway?

Let’s be clear:  I really don’t think this is a huge deal, but it can be a source of mental fun for the rest of us.  So here is a “wake up it is hump day” mental exercise for you (This WILL be graded, you WILL need to know this for the test!):

What would be a more effective “security through obscurity model” for the government to use, while still listing the required domains?

I will start the ball on this (and therefore open myself up to immediate criticism!):

  • Register the domains as normal, but do not use obviously descriptive names: Instead of “trackingPrivateCitizens.gov” you might use “TPCProject.gov”, you may even consider using a completely sanitized CRC32 version: 13201934.gov  (Free Vidoc Razor T-shirt if you can figure that one out).
  • Keep an internal, classified document that maps out the “sanitized domains” with their true descriptions.

How would you set out to discover these “hidden” domains?

  • We will assume zone transfer is not available (Could be a big assumption).
  • Build a database of known domain names.
  • What next?

Feel free to post any ideas – or chide me for wasting your time and making you read this cruft!