Security tools: BartPE - Bootable Windows on a CD

I'm attending offsite training this week, and the class is full of a lot of people who do security work for their organizations. A frequent topic is how their organization do things, and what they use to do their jobs.

I was startled to learn that some of my classmates had never heard of BartPE, which is a tool that any security staffer who works with Windows systems or needs a bootable Windows toolkit should have.

What is BartPE? Is it a "Preinstalled Environment" - which doesn't tell you much up front. In short, it is a Windows environment (XP or 2003) packaged to run from a CD, much like a Knoppix live CD. It has a wide variety of plugins that are ready to go, or which can be easily added if you have appropriate licenses or downloaded free software, and you can add tools of your own quite easily. The advantages of this including the ability to run Windows native programs without touching the host system's filesystem, native NTFS support, and familiar Windows tools will be obvious to anybody who needs to work with Windows systems, either for recovery, repair, or on-host forensic or incident response work. This is also a useful way to boot Windows on non-Windows systems if you are traveling and need a Windows system on the go, but don't have to have a fully installed system, or have only non-Windows x86 systems handy.

This is one of the tools that is usable in its basic form (which does require a local build and setup), but which can be a much more powerful tool with some work. Put this one in the list of tools that are worth your time and effort to learn and build before an incident.

Shared security standards - learn from the DoD

GCN points out that the DoD and ODNI are establishing a collaborative security standard policy. There are a few useful points made here that any organizations seeking to work together on security would do well to observe. The bullets below are from the article, with commentary interspersed.

• Define a common set of trust levels so both departments share information and connect systems more easily.

This is crucial when working between different organizations or systems. Building a mapping of trust levels and a policy and procedure for how to map those levels should be a part of any security program that has to interface different entities.

• Adopt reciprocity agreements to reduce systems development and approval time.

Trust is at the heart of this bullet. If your organizations have equivalent security policies and have a trust level to match this will work. If not, then sharing systems development and approval will likely fail. Shared standards and practices are absolutely vital if your organization attempts this!

• Define common security controls using the National Institute of Standards and Technologys Special Publication 800-53 as a starting point.

Another good place to look for security controls would be the CIS benchmarks or the NSA security configuration standards. The keys here are establishing a standard, keeping it up to date, and making sure that you adjust the boilerplate to fit your needs if you use a standard. No matter what standard you use, documentation is key. I like to suggest wikis as a great way to develop and maintain living documents for standards.

• Agree to common definitions and an understanding of security terms, starting with the Committee on National Security Systems 4009 glossary as a baseline.
  

The glossary can be found here in PDF form. This is a handy tool - it helps eliminate semantic debate (we've seen it ourselves in our comments). Arguing over the meaning of the word vulnerability might be avoided with an agreed on definition.

• Implement a senior risk executive function to base an enterprise view of all factors, including mission, IT, budget and security.
  

This might involve organization wide risk assessment, communication, and possibly most important - ownership and responsibility by senior management. Without strong upper management support and ownership, any large scale security project will fail.

• Operate IT security within the enterprise operational environments, enabling situational awareness and command and control.
  

In short - use operational security monitoring. There are technical, administrative, and policy/procedure elements here - all the elements of a full information security program.

• Institute a common process to incorporate security engineering within life cycle processes.

Lifecycle design is one of the most crucial things for security to be involved in. Establishing security reviews and consultation into the project management and lifecycle will help ensure that new projects are build on a solid foundation, and that existing systems and designs will receive periodic review.

It is good to see government agencies planning ahead, and the outline above is a good high level starting point for organizations seeking to share security practices. Standards, trust, and executive backing are key to this entire process. It will be interesting to see what comes out of the process.

Risk Assessment: EULAs and contracts

One of the often neglected parts of a security program is the contracts that your organization enters into with vendors. Often organizations accept the standard boilerplate rather than negotiating a more favorable position, or accept a EULA that contains conditions that the organization may regret. This is a great place to apply some of the tools and tactics that you apply to other security projects - checklists, risk assessment, and standards.

One tactic I like to recommend is to work with your legal representation to create a checklist to review EULAs and other agreements - being able to filter out those with issues that are easily found up front can save significant amounts of time - your lawyer's time is often expensive, and doing a first round check can save you money and pain in the event the contract becomes an issue. The EFF provides a good user level guide to dangerous EULA terms which can be a good starting point. Once you have a checklist, you can pull risky or questionable clauses out.

When you develop the checklist, make sure to separate your categories - terms that are completely unacceptable should be noted, and terms that are questionable, or that you prefer alternate language for should be marked as such. If a clause that your company requires isn't present, that should be accounted for as well.

While a checklist isn't a substitute for proper legal review, it can help weed out some of the worst EULAs and contracts.

Along those lines, check out the OWASP Secure Software Contract Annex. Organizations that hire third party developers should have a well understood contract, and projects like this help smaller organizations with something they might not have the resources or in house expertise to handle.

Securing your Mac: benchmarks and guides

While Macs aren't as heavily used in the corporate world as Windows and Unix systems, they've been steadily penetrating the security world over the past few years. Where security conferences used to be dominated by IBM and Dell, these days a quick visual survey shows a high percentage of Macbooks and Macbook Pros.

For those of us who use a Mac, securing MacOS is an interesting topic. It is regularly claimed to be safer than Windows or other Unix/BSD systems, but that doesn't mean we can ignore locking down our systems. There are some good tips and tweaks out there.

As with any lockdown guide, you should review your usage and needs against the assumptions of the guide. If you are doing this for yourself, you may not need to formalize the process. If you are building a lockdown process or security benchmark for an organization, you will need to document what sections you retained and which sections you discarded, and possibly why. You will also need an exceptions process if you will allow exceptions, and a means of properly documenting alternate acceptable configurations.

So how about some lockdown guides?

Apple's guide is available at http://images.apple.com/server/pdfs/Tiger_Security_Config.pdf
Fair warning, this is a 167 page PDF

The CIS standards are available at:
http://www.cisecurity.org/bench_osx.html - note that unlike other popular operating systems, the CIS benchmark is only available at level 1 (a "prudent level of minimum due care"), and that there is no automated tool for benchmarking.

The NSA released an updated guide for 10.4, available at http://www.nsa.gov/snac/downloads_macOSX10_4Server.cfm?MenuID=scg10.3.1.1

What about NIST you ask? Their linked guides are outdated. Check out the configurations above for a more current checklist.

Common file overflows and social networking exploits

If you haven't installed the OS X 10.4.9 patch yet, you should - don't forget to back up first! Exploits are already being reported in the wild. While a number of the vulnerabilities fixed are exploitable in interesting ways, the one that really caught my eye is (from the SANS @RISK update):

"A specially-crafted GIF, PICT or RAW image file could exploit an integer overflow in the ImageIO subsystem or a heap overflow in the QuickDraw manager subsystem. Successfully exploiting these overflows could allow an attacker to execute arbitrary code with the privileges of the current user. Note that this flaw may affect images embedded in web pages." (link)

Any time you have a common image format bug that can result in a arbitrary code execution, you have a scary possible exploit. How long will it be until a hole like this is found in IE or Firefox, an exploit is crafted, and someone pays a Digg bot to get it dugg enough to infect thousands of machines?

An Inexpensive Forensic toolkit

What should you have in a basic homebuilt forensic toolkit? What can you do without specialized tools? We'll cover what you should have in a portable IR forensic toolkit if you're on a tight budget, with an emphasis on freebies and using inexpensive commodity tools and software. In our next article, we'll talk about what a well equipped forensic toolkit might contain if you aren't budget constrained.

A full kit composed only of commodity items many systems administrators have at hand:

• Screwdrivers (Phillips at the very least)
• USB 2.0/Firewire drive enclosure or a USB 2.0 -> IDE bridge device and 12v molex power adapter. Remember to check that your enclosure works with your Linux LiveCD.
  
• SATA->IDE Adapter OR USB 2.0/Firewire -> SATA enclosure - having the adapter is lighter than carrying two enclosures.
  
• 2.5" -> 3.5" laptop hard drive adapter
• Spare hard drive jumpers
• Known good ATA and SATA cables - in my experience, problem ATA cables are one of the most annoying issues when imaging drives.
  
• A capacious thumbdrive - a 1 GB drive is a good start, and one with write block switch is a good idea.
• A portable external USB/Firewire hard drive - larger is better - try to have at least the maximum size drive that your environment has deployed for a single desktop or server. You can cheat a bit and carry just one enclosure and a drive to put in it if you are attempting to travel light and don't anticipate needing to copy from a drive in the enclosure while you're using the big drive.
  
• IR and forensic LiveCDs.
• A notebook and pens - do not use pencil!
• A laptop with supported chipsets for your forensic CD of choice for USB/Firewire, NIC, and other critical hardware.
• A crossover network cable, in case you need to connect your laptop to the system you're imaging. If you don't have a crossover cable handy, a pocket hub or switch and some standard ethernet cables will work nicely.
  
• Anti-static bags for transporting drives. I like to carry the plastic clamshells that drives ship in to put drives in when I have to take them with me.
  
• Stick on labels to label drives and devices - something that will stay on, but peels off easily.
• A black fine tip permanent market for labeling devices
• Blank CDs and DVDs
• An extension cord and/or power strip with a long cord
  
• Business cards to leave so that you can be contacted
  

Total toolkit cost should be <$300 excluding the laptop, even if you have to buy all of this new. This toolkit provides the hardware you need to get a system open and to pull most commodity drives, and to walk away with a good image. If you're just doing forensics as part of an incident response investigation, and don't have to maintain evidenciary standards, this will get you where you need to go in most cases. This is also the sort of toolkit that many administrators could scrape together on short notice out of their standard administrator's toolkit, meaning that the tools you need are likely already at hand. In addition:

• If you frequently work with SCSI, you should have SCSI adapters - a SCA -> 68 pin adapter, a HD50 -> 68 pin adapter, and spare terminators. You'll also need a SCSI card or SCSI adapter. Sadly, I haven't run into a quality USB 2.0 -> SCSI bridge device yet.
  

What you don't have in this kit:

• Commercial analysis software like FTK or Encase
• A commercial disk duplicator with MD5 sum capabilities.
  
• Write blockers (although these can be had for less than $200 now)
  
• Large scale long term mass storage

We'll discuss a pro level forensic kit next time! Don't forget to check out our earlier posts on digital forensics tips.

Incident Reponse - counterpoint

Richard Bejtlich, one of my favorite security bloggers posted a list of observations about incidents. I'm going to try to provide a little counterpoint - see his original points here.

1. Anti-Virus is (or should not be) an incident response tool.

In many cases in less advanced, lower funded, or simply smaller organizations, AV may be your first indicator that something is wrong. During a Hacker Defender outbreak I helped handle, many folks that I worked with found machines that kept getting the same AV hits, even after being cleaned. They were, in fact, Hacker Defender protected hacks, and the AV was just removing the tiny portion of the rootkit that it could see.

AV is an IR tool - if only because it can help you find portions of a compromise. Is it the best tool in your toolkit? I should hope not. Is it useful to see what AV thinks about that odd file you just found? Yes! Norman Sandbox or Virustotal are your friends, but so is a command line AV client.

2. Your default incident recovery strategy should be to rebuild from scratch.

Every IT person I know recommends rebuilding after a compromise. This is becoming increasingly easy with the growing use of VMs and imaging software. The gotcha now is that your last image probably has the same vulnerability that let the bad guy in last time - I've seen administrators put the same box up and act mystified when five minutes later it is owned the same way its identical twin was.

Your default incident recovery strategy should be to rebuild in a secure environment and to ensure that you have done your best to fix the problem that let the last event occur. Note that rebuild from scratch may carry overtones of "do it all over again the hard way". That's not the point - use that pre-built VM copy, your Ghost image, or your standard install - the key is learning from the last incident and following standards and best practices so you can repeat the build process effectively and securely.

I've been a fan of a simple solution - give your systems administrators and techs commodity broadband routers - a Linksys for example. Have them put machines they need secured for a short while behind the router (which, of course, has had its password changed) and tell them to rebuild there. Yes, it may slow down your link a bit, but the system won't get knocked over before they manage to install that patch that the standard image is missing. Best of all, the routers are cheap and light enough to carry around in a laptop bag or toolkit, meaning your administrator will have it with them. The security you have and use is the best security you have - and when you can pick up a router on Sundays for $10-20 at the local big box electronics retailer, it is one of the cheapest tools you can give your admins.

3.SPAN ports should not be the default traffic access option.

Span ports are realistically the best available option for smaller organizations that cannot afford a tap, or, more often do not have a tap available. This is why you'll find information security folks stashing old hubs in their toolkits - sometimes you have to work with what you have.

So, yes, span ports aren't what you should want, but they're often what you get. Plan ahead, and have options available. Know what is possible with network gear - and be ready to discuss it with the local network engineers (or lack of network engineers). Have a backup plan - that old hub may be your only chance to get inline with traffic. And yes, a gigabit span port makes the network guys a lot happier than a 100 meg hub sitting in front of your gigabit uplink.

4. A Linux live CD is not a substitute for a real network security monitoring platform.

Nor is a Linux live CD a substitute for a real forensic system. But I do like them.

The rise of inexpensive gigabit capable laptops and small form factor systems means that given even a small budget, a security professional can have a portable, reasonable performance network security monitoring platform that they understand and have configured for performance. Get a Mac Mini, a Shuttle XPC, or a low end laptop with gigabit onboard and have it ready for tasks like this (pay attention to your NIC chipset - and for laptops and the Mini, remember that you're writing to a laptop drive if you have a high traffic load.). If you have a pre-built portable system, you won't find yourself scrounging at the last minute, and you'll have a known good system that you have locked down and can trust. Even these systems aren't a true substitute for a dedicated platform for hardcore network security monitoring, but they're a lot closer than a LiveCD on a random old desktop you pulled from the junk closet on short notice - and normally, in an IR situation, you don't need to monitor for weeks on end at super high speeds.

This goes back to an earlier post - build your toolkit now, not during the incident. You're going to have to learn new tools during a lot of incidents anyway, so get as much as you can out of the way in advance. And while you're at it, burn some up to date copies of those Linux live CD IR distros.

5.When you are compromised, you are probably not facing a zero-day exploit unique to you and not capable of being prevented.

There's a good chance your management might think you are! Remember to keep your management in the loop, give only truths and not supposition - or, if you must theorize, make sure you're clear that you are, and keep it plausible and non-panic inducing, and provide clear, concise documentation that you want publicized. Most organizations leak information like a sieve so you need to get ahead of the rumor mill, provide the information that is appropriate, and make sure that what does get communicated is accurate.

And then my own:

6. Pretending an incident didn't happen doesn't help.

I consistently deal with and hear about organizations that attempt to conceal compromises from their constituents, customers, or management. While this may make it look like IT is competent, it also means that the threat environment that you face isn't being effectively represented, it may be contrary to the law (for example Indiana's SSN disclosure law), and it may violate your organization's policy.

Worse, if the incident is reported on later, it may cause distrust from your customers or your management. Security staff and systems administration both need the trust and cooperation of users and management to remain effective.

Tackle incidents head on - you don't have to be completely transparent, nor do you have to broadcast your problems, but you should notify responsibly and respond professionally.

OpenBSD Remote Code Execution Vuln

This advisory from Core Security came across my irssi window earlier today. Looks like a difficult, but possible remotely exploitable vulnerability in OpenBSD default installation.

I encourage you to read the time line, as it warmed my heart in a somewhat perverse way. Interesting to note that OpenBSD does not consider remote DoS attacks as vulnerabilities. From the advisory timeline:

"OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack"

A quick glance at the OpenBSD site didn't find that documented anywhere, but I do find it somewhat surprising. What if I could send a malformed packet to any OpenBSD box and instantly trigger a kernel panic. That wouldn't be a vulnerability?

Digital Forensics: A few more tips

I wanted to throw out a few more tips to add to those from the previous post, but first here's my own take on the SecurityFocus article.

First, of course storage is expanding rapidly. This has been the case for years and it can be a problem for forensics as you typically have to deal with full drive images. However, my belief is that law enforcement is still dealing primarily with individual's desktop systems and not large corporate servers. You still have to deal with large drives, but probably won't come across massive RAID arrays anytime soon. In these cases, you can always keep ahead of the desktop user if properly funded. To save on space though...

Tip 1
1) A number of forensic tools now allow for capture to a compressed image format such as AFF or Encase's Evidence File Format. If space is an issue, then use compressible formats for analysis and archival. You can always compress images for archival, but the formats above (and others) can be indexed and searched while still in a compressed state as well.


If you happen to be doing forensics in the corporate world, however, then dealing with servers and computer intrusions may be the norm. But there's still hope for you! If you're doing forensics primarily for business or incident response purposes rather than a legal matter then you might be able to get away with something less that a full drive image for analysis.

"But wait!", you cry, "can't all cases end in possible legal action." Certainly, but you just can't image everything and need to be able to take action rather than being frozen with fear of corrupting a hypothetical legal action.

Tip 2
The key is to have documented procedures for doing live forensics on a system. Even better is to capture those procedures through an automated first response process. Perform the initial live data collection from the system with a script. Some generic scripts are already available such as IRCR or FRUC.

Digital forensics: when users put the mass in mass storage

An article popped up across the SecurityFocus security news feed this week titled "Digital forensics plagued by expanding storage". This rang a bell, as I've conducted forensic analysis on arrays and drives that were impressively large.

There are a few basic things you can have in your toolkit to help out:

1. As much storage as you can afford - I like to have a large portable drive as well as an even larger network accessible drive that I can dd to. These days, it isn't unreasonable to carry a 500 GB drive as your portable forensic storage device, and 750 GB drives are starting to hit reasonable prices if you have to deal with large datasets. Remember, bitwise copies are the best route if you really need a deep analysis, but if you're forced to and having that level of accuracy is not required, you can use tools that copy only the live filesystem.

It is worth noting that vendors have begun to bring out enclosures with decent hardware RAID built in, meaning that you can have a terabyte or more of real space for images in a single reasonably portable box.

If you're imaging from the host, rather than a forensic workstation, a good USB/Firewire enclosure is a must, as well as a bootable Linux or Windows IR CD. Check out Helix or PenguinSleuth, or any of the host of other liveCDs out there.

2. A method of getting to arrays. In many forensic analysis situations, you need to copy from a RAID array, either on a dedicated controller or from an onboard host based controller. For Windows, BartPE is your friend once you locate the right drivers and load them. Some arrays may be hardware based - if they're not, you'll need to get the configuration and drivers loaded to deal with them in most cases.

3. A plan for how to handle oddball systems. Sometimes, getting an image is going to be impossible, and if analysis is your key issue, rather than preservation of a pristine image, you should have a plan for how to conduct live system analysis.

4. Last but probably most important - you need a way to take useful notes, and a plan of attack that you can follow. Standards will save you, and documentation and careful notes are critical.

Don't forget your screwdrivers!

Panic!

Just to be contrary, here's a few reasons to panic.

1. If you've never had a security incident, and have never spent a dime on securing your infrastructure.
2. You store credit card numbers and social security numbers of all of your customers.
3. Fire-what?
4. You've written web applications, but don't recognize at least one of the following attacks: XSS, XSRF, SQL Injection.
5. You think Solaris and Telnet are a winning combination.
6. You believe there is no reason to need any "security" on a private network.
7. You believe in your WEP-protected wireless network.
8. You are more than six months behind in patches for your windows workstations.
9. Your security solution is driven by a single GUI.
10. Your break room budget exceeds your disaster recovery budget.
    

Don't Panic!

Network World's recent article on keeping your senior management calm during an emergency rang true to me. In major security events in which I've been involved, communication with managers and senior staff was absolutely critical. In many cases, the CIO will become personally involved in an incident, and may request that you break your normal incident response practices to keep him informed. At other times, fighting rumors may take almost as much time as the incident itself does.

Dealing with incidents large and small led to a few basic observations that can help you weather the storm.

Things to do ahead of time:
1. Create a written process.
2. Establish clear lines of communication.
3. Make sure your CIO and others know when and why you will get them involved.
4. Establish who has a need to know, and how to do rumor control.
5. Make sure to have an emergency contact and communications plan.

During an incident:
1. Follow a written process.
2. Communicate early, clearly, and often.
3. Do not speculate - only communicate facts, even if the fact is "we do not know".
4. Avoid blame - the goal is to handle the incident, not to pin it on some person, department, or policy.
5. Make sure that those effected are communicated with appropriately. Observe "need to know" as appropriate, but realize that anything that you release is likely to travel far more widely than anticipated.

After an incident:
1. Write up a post-incident report. Note failures in the response plan, and work to fix them.
2. Communicate with those effected and those who may be effected by similar incidents.
3. Use data from the incident to assess other risks of a similar nature.

While you're thinking about handling incidents, check out the NIST guide to handling computer security incidents.

HTML based portscanning - who needs Javascript?

Most of us are used to disabling scripting in our browsers, and a lost of security folks use the Firefox NoScript applet. Jeremiah Grossman's recent experiments with CSS based port scanning are interesting, and others are delving into the possibilities based on his original post. When you can pull browser histories without scripting, you have a whole new set of issues, and if this can be made to be cross domain, then we will need a whole new set of security techniques to protect our browsers. For now, be aware that browsing to a hostile site could mean that you are revealing more information than you may think that you are.

Thus begins the MOPB

The Month of PHP Bugs (MOPB) has begun at php-security.org today. Like MOAB and other Month of $thing Bugs at least one bug will be released each day.

The first installment of MOPB leaves us with 3 bugs, one of which can be exploited via a remote file include to crash PHP and execute a shell code.