Security Ripcord

I was learning how to use Mandiant’s Memoryze the other day and having a bit of trouble getting to know the XML configuration files.  My real task was to get Memoryze working with memory shared from a remote system using F-Response.  To do this I was pointing Memoryze to the memory instance, instead of an image file, and then using Audit Viewer to parse the information.  Unfortunately I was not able to get it working.  This was more likely due to user error and my not initially understaning how to implement the XML configuration file properly. (More on F-Response and Memoryze later!!)

Right when I thought I had figured out how to use the XML files I got a pleasant little surprise on the Mandiant blog.  Audit Viewer has been updated to run Memoryze automatically.  Now we have a quick and easy method to set up Memoryze’s XML configuration files automatically.   Parsing memory for valuable information has just become is as easy as it can get.

Before I was able to test this new version of Audit Viewer with F-Response I got a chance to use it on a memory dump from a system infected by the Conficker malware.  Conficker has been analyzed in detail by several organizations.  I like the series of blog posts on the Symantec blog as well as the very detailed analysis by SRI International.  Using the capabilities of Memoryze, however, I was able to see some Conficker activity that was not mentioned in any of the analysis that I have reviewed so far.

I’ll start out by mentioning, as most of you know, I am not a malware analyst.  I’m just pointing out a few things that appear to be interesting.

Let’s start with quick background.  The system that I gathered the memory from was a Windows XP SP3 system that was infected by Conficker via a USB drive.  I don’t have the system any more and although I could infect another system to confirm some of this information I don’t have a stand alone system readily available to infect.  We all know now that Conficker has some builtin virtual machine detection so I didn’t attempt to replicate using a VMware image.

The system showed the usual symptoms.  The Registry pointed to a randomly named service calling a randomly name DLL in the c:\WINDOWS\system32 directory.  In this case the DLL was named taqswng.dll.  The following image shows a listing of all the files that start with “ta” in the System32 directory.   Conficker marks the file as hidden so I had to use the “dir /A H” command to get it output with the rest of the files. (Right click on any image and select “View Image” to see a larger, more readable, image.)

Since I was here I ran two other commands.  First I wanted to see that processes were currently running.  Using the Tasklist command I determined that the process with ID 1484 looked interesting.  It is calling many other services that resemble the functionality outlined in many of the Conficker write-ups.  The image below highlights what I am talking about.

Next I wanted to know what the system would display as open connections.  Conficker is suppose to start an HTTP service on a random port between 1024 and 10,000.  The next image shows that the process 1484 does have a LISTENING port on 2980.

Now, I didn’t think that I would get any new information out of reviewing the memory of this system.  I just wanted to show myself what Memoryze could offer and how I could leverage it in the future when investigating processes.  After I used Audit Viewer to parse the memory for everything (use the PDF manual that is provided as part of the download to help you use Audit Viewer and Memoryze) the first thing I did was locate process 1484 and check the files tab to see if I noticed anything.  After review I noticed the taqswng.dll file was listed.

Excellent but I have to admit.  This would have been lost in the shuffle to me.  Basically, this is good verification that I have found the proper process.  Next I checked the Port tab.  This is where it gets interesting.  From the netstat command I know that I should be looking at TCP port 2980 and UDP ports 1023 and 1034 (both UDP ports on the loopback).  But look what Audit Viewer gives me.

But where does TCP port 1033 come into the picture?  I wish I still had this system so that I could try and connect to this port.  I did a quick review of all the analysis resources I am aware of and they do not reference a second listening service.  I can tell you that we did verify that this was Conficker.B and not Conficker.C.  Of course the varient does not matter because this would be different functionality.

The next interesting part came when I reviewed the Memory Sections tab.  The information provided here points to the process accessing the “index.dat” file.  Now, I’m not sure if this is to get the proxy settings to help access the Internet.  It very well could be and I have not researched to determine if this is the case.  But why Conficker is accessing the files listed in the image below are beyond me.  As with the extra port, there is no mention of this behavior in any Conficker resource.

If anybody has an answer to these questions I would like to know.  Post your explanation in the comments or, if you would rather speak with me privately, just include a valid email address in your comment and I will contact you directly.  I would have investigated this a little more deeply but due to time and resources I thought it better to get the question out there.

Good luck if you are still dealing with Conficker.  While you are addressing it, beware Virut.

Go forth and do good things,
Don

I have taken some time to write an incident response script using only the resources provided by the Windows operating system.  You can find out the why by reading the article I wrote titled Windows Incident Response With Only System Resources or the how by reviewing the code I wrote.  UPDATE: I broke the link when I did a bug fix.  So, this link may break in the future, please refer to the complete article for the most recent version.

I hope that some of you find this useful and that this centralizes a lot of the information necessary to understand the abilities inherent to the Windows operating system.  It is nothing ground breaking.  Just a few things that can be done if you do not have or are not allowed to obtain and use the number of very useful tools that are available online or through a vendor.

Go forth and do good things,

Don C. Weber

wmi, wmic, vbscript, Security Ripcord, incident response

To increase the security within my organization I decided to have PGP come down and give our administrators and IT manager a demonstration on all of the services that PGP provides. Since reading about it I have been very impressed with the way that PGP has integrated all of the aspects of encryption into a centrally managed solution. Many people, however, are not fully aware of the extent of PGP’s product line. Even after an online webcast the administrators within my organization just didn’t understand how the PGP solution could integrate with our services and centrally manage their Email, File Sharing, Full Disk Encryption, and Split-Managed Key Escrow capabilities for Windows and Macintosh notebooks, workstations, and servers as well as some PDAs.

PGP sent down Bob Adams and Nathan Daniels from their Dallas office. Bob is their Texas sales representative and Nathan was their technical expert. After briefly chatting with both I discovered that Nathan has worked for Network Associates, F-Secure, McAfee, and has been with PGP for about three years. Definitely an impressive background. Although I don’t remember the full extent of Bob’s background, I do know that he worked for IBM in their Internet Security Solutions department and he knows several people on their X-Force team.

“IBM ISS X-Force team? Hey, do you know David Maynor and Robert Graham?” Bob knew Robert and spoke very highly of him as well as the rest of the X-Force team. (I just noticed that the X-Force team has a blog.)

Then later, was we started talking about which companies in Texas handled the sales of their product I asked if they worked with Accuvant. Nathan responded that they have been working with them recently. “Hey, do you know Michael Farnum?” Indeed Nathan has meet Michael and, of course, spoke highly of him as well.

Now, I’m not going to tell you that any of this name dropping gained my organization any bargaining collateral. But I can say that talking to these guys about people that they had met, worked with, and liked did help in the fact that we had a little more in common than before. This made everybody a little more comfortable and the meeting went very well. I guess it is just one of the extra benefits of blogging.

Go forth and do good things,
Cutaway

PGP, blogging, encryption, Accuvant, IBM, ISS, F-Secure, X-Force, Security Ripcord, Michael Farnum, David Maynor, Robert Graham

On the last day of DefCon 15 I had time to stop by the Immunity booth in the vendor area. Although he was very busy Dave Aitel did take some time out to speak with me. After a little small talk he pointed out a few of the things that they were promoting to the DefCon attendees.

SILICA
First was the Nokia N800 running SILICA. This penetration testing device is going for a cool $3600 and Immunity is selling it directly on their website. According to Immunity:

Immunity SILICA is a hand-held penetration testing product that leverages Immunity CANVAS to provide a unique testing tool for networks. Currently it supports 802.11 (Wi-Fi) and Bluetooth, and Ethernet via USB is planned for the near future.

Its slim, PDA-like profile allows the penetration tester to perform testing while behaving innocuously.

Very interesting. I would love to get my hands on one but cannot afford the sticker price. Of course, it would be even more interesting to see if there is enough memory to also include Ruby and Metasploit as David Maynor has done. How could it hurt to have both of these tools at your PDA fingertips?

Immunity Debugger
After looking these over Dave pointed me to Immunity’s latest release, the Immunity Debugger. According to Immunity:

Immunity Debugger is a powerful new way to write exploits, analyze malware, and reverse engineer binary files. It builds on a solid user interface with function graphing, the industry’s first heap analysis tool built specifically for heap creation, and a large and well supported Python API for easy extensibility.

• A debugger with functionality designed specifically for the security industry
• Cuts exploit development time by 50%
• Simple, understandable interfaces
• Robust and powerful scripting language for automating intelligent debugging
• Lightweight and fast debugging to prevent corruption during complex analysis
• Connectivity to fuzzers and exploit development tools

Although I have very limited experience with debuggers Immunity seems to have put together a package that is very user friendly. Hopping between analyzing source code and GUI based flow charts seemed very helpful and I could easily understand how a vulnerability in one section of code affected and was accessible from throughout the whole program. One interesting aspect of the Immunity Debugger has nothing to do with actually analyzing code. Rather, it has to do with companies advertising for programmers and researchers right through the tool. As Immunity Debugger is free for download one way that Immunity has decided to support the product is to allow employers to insert advertisements for job openings. Now companies can have a direct link to the individuals they would like to locate, specifically, persons who are familiar with debugging programs. A unique and interesting approach. Although some companies would probably like to turn this feature off, this is just the cost of a free tool. I am willing to bet that Immunity would be willing to do it for a small fee, or perhaps there is a module that can be excluded when compiling the tool. That would also depend, however, on Immunity releasing the source code for this debugger and I am not sure if that is the case.

UPDATE: I just discovered something that was worth an update. I downloaded the Immunity Debugger. First it required a simple registration and then I received the Windows Installation file: ImmunityDebugger_setup.exe. Yes, Windows Installation Executable file. I would think that if this is written in Python that I would be able to run it in Linux at least. Big deal? No. But I was surprised.

Immplant
After reviewing the Immunity Debugger, Dave handed me a little piece of paper. It contained information about a future Immunity product that they are trying to drum up interest in. The product will be called Immplant. Here is what the paper said about the product.

A penetration tester often finds themselves in the position where they have access to a physical host for a short time, but they do not have a user name or password on that host. Immplant is revolutionary technology from Immunity, makers of the market leading CANVAS penetration testing software that allows penetration testers to leverage temporary physical access into permanent remote control.

Immplant is deployed as a PCI card, which can be quickly and easily installed on typical desktop machines. This card then wakes up when the machine is booted, and injects code into the operating system which causes it to call out to your listening post securely. Because Immplant is hardware based, software protections such as anti-virus cannot prevent it from operating and it leaves no traces on the hard drive to be analyzed.

Immplant, not being resident on the hard disk, ignores full-disk encryption, patches, and many kinds of OS upgrades and reconfigurations.

Basically, this is a hardware device that will pump a shell back to a remote computer. I guess this is the same premise as subverting video cards or other hardware devices. But I am a little concerned about the statement “it leaves no traces on the hard drive to be analyzed.” Certainly, this type of device will not require software written to the hard drive but there is still the issue of memory. Unless the device can insure that all of its activity is restricted to RAM then I guess it would be very difficult to detect during analysis. But if any of the information gets written to the page file or swap space then I imagine that there would be something to analyze. Even if it is not immediately obvious there should be a way to identify and correlate information with this device. After all, that is why we have forensic analysis. When I queried Dave about this he did not have the answer and the person who did was attending one of the sessions at that time. The next thing that interested me was the communications protocol. I assume that they will be tunneling the communications over HTTP or HTTPS. Dave also did not have a response to this question but this time I felt it was more due to the fact that they were still working out different methods for communications or, very possibly, he didn’t want to give out that information.

Personally, I don’t think organizations who are doing proper security will have a problem with these devices. Unfortunately, the average home user will not have the protections in place to prevent the installation and activity of this type of device making this a interesting tool for a private investigators, parents, or even the system administrators that want to maintain a guaranteed connection with a computer. This could have a positive impact on locating and controlling stolen computers. But, could you imagine if a small mom-n-pop computer service business started implanting these as a “service” to their customers? And, hopefully, Immunity has the common sense not to let the GeekSquad get a hold of any of these.

Go forth and do good things,
Cutaway

Immunity, SILICA, Security Ripcord, Immunity Debugger, Immunity Immplant, Nokia N800 DefCon15 Metasploit, Dave Aitel, David Maynor

One of the cool things about taking the SANS GCIH through their OnDemand classes is that you get 10 weeks to interact with the other students instead of the usual one week of a conference. Somebody in my class set up a YahooGroup and the students were able to post questions when they didn’t understand a subject and needed extra clarification. The teacher, Ed Skoudis, and experienced students monitored the group and help was almost real-time.

Although I have already achieved my GCIH Silver Certification I am still a member of the YahooGroup associated with the class. Yesterday one of the students posted a question. Since it was a good question I thought I would include it and my response.

swangods question:

Hi folks,
I don’t know how many of you might still pay attention to this group,
but here’s a question for you. The book recommends something like
$5-10k of available funds. I think some of this was for on the spot
purchases like storage media, hubs/switches, taps, maybe even a
server. Has anyone had any luck with justifying this spending ability
or authority, and how have you presented this to management and what
sort of discussions did you have to go through for this pre-approval?

My response:

Here are some things to think about that might help you in this situation.
This might be more information than you need but I got on a roll.

One think you might consider is combining the “jump bag” to operate as
tools for “incident response” and “disaster recovery”. This helps double
up the need for such a bag and it gives you a good excuse to keep people
from lifting items from it when they can’t find similar items that are
used for normal operations. Additionally, many of the items could be
pulled from duplicate stock or by upgrading old tools and hardware to more
current versions. As for servers and workstations you could also pull
systems when they are being updated. (Remember, you’ll need systems to
perform forensic duties as well as systems to do practice incidents.)

If you are trying to justify just building an incident response or
forensic work area then you are going to have to consider how many
incidents you expect in the next 5 to 10 years. As you should start a
working relationship with a forensic company anyway, ask them to brief you
on how much typical forensic responses to an incident will cost. Give
them a couple of likely scenarios your company might experience. Now
multiply that number by the number of incidents. Then do your research
about how much spinning up a workstation will cost (include training on
forensic tools as well as GCIH for other team members). When you have the
comparison have the forensic company come back in and give the same
presentation to your executives. Then you give a quick presentation after
the forensic company leaves about how developing a incident response plan
and preparing certain tools could reduce these costs. Before you go into
this meeting double check your costs and be sure you are not missing
anything. One or two changes down the road will not hurt anything but an
more than that and they will begin to wonder about whether it was a good
idea which they will remember the next time you ask for something.

Also, don’t go overboard. You might not be able to afford things right
away. Start developing a plan to acquire things through time. And
remember, if you need something during an incident your management will
generally be willing to fork over the money. Just be ready with
suggestions and acquisition recommendations. Use a purchase of necessary
equipment during a response as a part of your lessons learn. “We had to
purchase a 500 GB drive because the RAID we had to image was 450 GB. The
purchase delayed our response by 8 hours. The request for the external
hard drive was initially denied. Here is a list of other items that we
denied at the same time as the external hard drive but are also necessary
for incident response.”

Hope this helps,
Cutaway

I hope this helps anybody trying to justify their incident response toolkit, “jump bag,” or work area.

Go forth and do good things,
Cutaway

Security Ripcord, Ed Skoudis, incident response, disaster recovery

I recently mentioned that NIST had released Draft Special Publication 800-88: Guidelines for Media Sanitization.  This document outlines the concerns involving roles and responsibilities, data classification, and destruction of the information stored on any media.  We all know that this generally includes hard drives but when you start to sit down and think about it there are so many other media types that we must consider:  Floppies, CD/DVD disks, DVD RAM, MiniCD disks, tapes, Thumb drives, Zip/Super disks, iPods and other MP3 devices, external hard drives, etc.  One item (of many) that my list is missing is system memory.  Although this has not necessarily been an issue to this point, in the June 3, 2006 episode of  CyberSpeak Jesse Kornblum talked about retrieving residual process information from memory after a system has been rebooted.  (Check the CyberSpeak show comments for several links to more information about this issue as posted by several of CyberSpeak's listeners.) 

According to the NIST document there are three ways to deal with information on any of these media types.

• Clean – is achieved by overwriting the memory so that the information on it cannot be easily retrieved by attempting to access the data through normal system operations.
• Purge – involves degaussing or executing the "Secure Erase " feature on Serial ATA drives.
• Destroy – can be accomplished through disintegration, pulverization, melting, incineration, shredding, or sanding depending on the type of media being destroyed.

Each one of these methods has its own challenges and drawbacks.  Cleaning a system by overwriting the media can be very time consuming depending on the size of the media and the overwriting algorithm being used for the process.  Purging through degaussing is know to make certain media types unusable.  Destruction can be a huge and costly undertaking in resources and man-hours as well as the environmental issues.  However, it is the overall consensus of Pub 880-88 that any media leaving the control of the original owners should be destroyed to avoid any possible exposure of information.  

Let's face reality.  Destroying media can turn into a relatively expensive proposition.  Especially when the media can be reused in other departments within an organization.  We all know what is really going to happen.  When a person or department needs a new system for more processing or storage capabilities their old system is redistributed to replace an older system in a different department.  The older system is then redistributed in the same fashion or it is retired.  In these cases "cleaning" the media is generally the course taken.  Of course common sense needs to be used when redistributing a system.  It is probably not advisable to permit a hard drive or other media from a business or financial department to be rotated to another department that may not use the same types of media protection procedures.  However, end user activity can also increase the sensitivity of the stored information through casual personal use or outright inappropriate behavior such as was seen in the recent disclosure of Veteran's Affair information.

One method that can be leveraged to determine the sensitivity of a piece of media is to scan it with a tool that will search through its stored files and identify files that contain potentially sensitive information.  A tool that I have recently been exposed to is Spider which is maintained and distributed by Cornell University's IT Security Department.  This software has versions that run on Linux and Windows systems.  It will search through a mounted file system for specific information that includes:  Social Security numbers (SSN), credit card numbers, and any regular expression as defined by the user.  The results are output to a text or comma delimited file for easy investigation.  Investigation of the results is necessary due to the potential for false positives.

In an attempt to familiarize myself with this tool's functionality I created several files with a bogus SSN in it.  I created several different types of files:

• txt – text file
• doc – Microsoft Word document
• xls – Microsoft Excel document
• ppt – Microsoft PowerPoint document
• odt – Open Office Writer document
• ods – Open Office Calc document

For each of these documents I created two different files.  One that contained a SSN separated by dashes (123-45-6789) and one without dashes (123456789). All of these files were located in a folder on the Desktop of a Windows XP system.  After a full system scan was completed the results identified the txt, doc, ppt, and xls files that contained the dashed SSN.  Only one document that did not contain dashes in the SSN was flagged and that was the Microsoft Word document.  None of the Open Office documents were flagged as containing a SSN.  Additionally, six other files were flagged as containing a SSN but these were easily discounted as false positives.  We can conclude from these results that this is not necessarily a full proof solution but it is definitely a step in the right direction.

In conclusion, storage media has to be properly maintained and disposed of once it has reached the end of its life cycle.  Identify media containing sensitive information by monitoring how and who has used it and by utilizing software designed to help identify files containing sensitive information.  At a minimum "clean" any media that is going to be redistributed within your organization and "destroy" anything that is going to leave your control.

Go forth and do good things,

Cutaway 

NIST, CyberSpeak, Spider, Cornell, security, Security Ripcord, Jesse Kornblum

A few days ago we had Core Security give us a web demo on their product Core Impact.  Although I had watched the demo before, on a prerecorded webcast, this time my colleagues and I were able to ask the demonstrator questions.  Simply put, Core Impact is a tool that encapsulates scanning and exploitation capabilities.  Basically, the scanner will detect hosts, enumerate the information provided by the detected hosts, and version the operating system and accessible applications.  The tool will also accept input from other scanning tools such as, but not limited to, NMap and Nessus.  The exploitation part of the tool will confirm and perform the exploitation of any vulnerability it has been configured to detect.  The real power of this tool comes from the fact that once a host has been successfully exploited it now becomes a stepping stone for the tool to perform the same actions to any other hosts or networks connected to the compromised host.  If Core Impact can exploit a vulnerability on any of your systems you are truly 0wn3d.

Now, you may have seen a few recent blogs that talk about this tool already.  Roger Grimes talked about it in his article "Core Impact puts a vise grip on vulnerabilities ".  Larry Pesce talks about it on his blog and even offers a discount through the Pauldotcom Security Weekly podcast. I thought that I would list a few things that I didn't realize until we were able to ask a few questions.

• Core Impact can exploit a system and network in several manners.  The most common method is to exploit an application or operating system through a known vulnerability that the Core Security research and developers (R&D) have been able to write specialized shellcode.  By special I mean that the R&D team concentrates their efforts on exploits that will allow the shellcode to run "inside" of the exploited process.  This means that once a system is compromised there is no evidence that is readily apparent to human review and even most security related processes.  The shellcode that runs inside of a process is referred to as an agent because it can be used to perform Core Impact functionality from the compromised system.
• Core Impact agents come in two flavors (there may be more but this is what we went over) known as Level0 and Level1 agents.  Level0 agents live in the memory of the exploited process.  This means that no permanent changes have been made to the system or the exploited process.  They can be completely cleaned up either by a command or after a period of inactivity.  Because of the amount of memory they are limited to the communications between the client and server application are transmitted in clear text (important when you cannot trust the connection between the systems – i.e. don't transfer important information like shadow files unless absolutely necessary).  Level1 agents are actual executables that are written to disk.  These agents can be configured to start on system boot.  Because they are a running process and they are not limited in size due to memory they have a lot more functionality.  Although I am not aware of all of these extra functions the one I do know about is that these agents can protect their communications with a Blowfish cypher.
• All of the settings provided through the tool are configurable by the user.  If a service is running on a nonstandard port the user can easily make this adjustment.  Core Security has also provided the user with the means to develop their own modules by including code examples and development documentation.
• Although Core Impact is mainly geared towards exploiting remote and local vulnerabilities it can also be used to exploit client-side vulnerabilities.  An easy example of this is a browser vulnerability.  Once inside a network the tool can send out an email with a specific attack that is designed to exploit a browser vulnerability that is activated through user interaction.  The tool will wait patiently until an unwary user initiates the exploit and the browser then connects back to the tool which, now, 0wn3s that system.
• Every action, from scanning to command line interaction on the exploited system, is recorded and used to document all activity performed during a session.  This can, in turn, be included in the detailed reports that are automatically generated by the tool.
• Currently the tool has exploits for all variations of Microsoft Windows, Linux (x86), Solaris (x86 and SPARC), BSD (x86).  There may be more but that is all I could remember off the top of my head.  Upcoming versions will expand this list and these should include exploits for Mac OSX.

Of course, Core Impact does cost a pretty penny especially when compared to such open source projects as Metasploit.  But when you buy Core Impact you are doing more than just buying a fancy exploitation tool.  You are buying peace of mind that the exploits included in the tool have been rigorously tested by Core Security's R&D team.  If they say that an exploit will not bring down an application or corrupt a system then they mean that they have tested it over and over.  You are also purchasing a maintenance agreement and are thereby supported by this R&D team which makes up close to seventy percent of the company's staff.

That said, you definitely need to check out the new version of the Metasploit framework version 3.0.  This new version is a complete rewrite of the code in Ruby .  Although I have not had time to evaluate it I am getting very good feedback about it already.  Apparently they have taken a few pages from Core Impact and they are, or will be, including a few similar features.  For a list of features that have already been considered for this tool check out the Release Notes.  I am really interested in finding out about its ability to "Support automated network discovery and event correlation through recon modules."

As a final thought I also wanted to point out that these tools are not the end-all-be-all for penetration testing.  These tools are great for finally exploiting a service or operating system but they do not fully cover all aspects required for information discovery.  These tools should be used during the final steps of a penetration test after all other methods of discovery have been performed and the information they return has been analyzed.  Additionally, before using these tools to their full capabilities you must ensure that your customer wants you do perform these tests.  Many applications and system are critical to a company's infrastructure and even the possibility that the system or application may be taken offline might not be an option for them.  It is always good to identify possible vulnerabilities and then ask for additional permission to continue.  Most of the time you will be permitted but there may be a requirement that a system administrator be standing right next to the system in case there is a need to trouble shoot a situation. Getting this person in place may take enough time that you will have to save your session are restart at a later date.

 I sure hope that you find this helpful.  Please leave a comment and let me know.

Thanks,

Cutaway 

NMap, Ruby, Pauldotcom, Nessus, Metasploit, shellcode, MSF3, Larry Pesce, Roger Grimes, Core Impact, Security Ripcord, Core Security

Security Through Obscurity. You hear people tell you not to use it. You also hear people telling you that it is a useful layer of defense. Actually it is all of these things and none of these things. Obscurity can just happen or it can be planned. You can put a file within your web server’s root directory and if you do not refer to it on your webpage then it just happens to be obscured. You can plan to change the default port of an application to a non-standard port so that it does not appear to the average user that you are running that particular service thereby making the service obscured.

Obscurity only helps you as long as nobody else knows about it. A document can be found by simply guessing common file names. The web application security tool Paros does this when it is checking for backup files with common extentions such as files that end with “_bk.” These types of files are especially helpful to malicious hackers because they often contain useful information directly displayed or within HTML comments. Because there are a limited number of ports available to an application, non-standard ports can be discovered by expanding the port range during a scan. Most scanners now perform automatic banner grabbing and application versioning that will take the guess work out of determining what service a strange port is offering.
Lets face it. Everybody who uses a password is using security through obscurity. Think about it. A password is a fact that somebody else does not know. But they do have a means to access or attempt to access the information. Brute forcing authentication mechanisms, cracking password files, keystroke logging, and shoulder surfing are several examples of attempts to bypass this method of security through obscurity. Heck, you don’t even have to guess anymore. People are offering up rainbow tables of password lists. A rainbow table is a list of ALL possible password combinations. Yes, it is a very long list, but I guarantee that your password is in it. All it takes is time and a lack of log monitoring to determine which password matches yours.

In the military, new recruits often confuse concealment for cover. Concealment is the act of hiding in or behind something that does not readily protect the body from danger. A good example of this is leaning up against a wooden wall. The person on the other side cannot see you but he can still shoot you through the wall. Cover, on the other hand, usually provides concealment while also protecting the body from danger. In other words, replace the wooden wall with a brick wall. Now the wall provides you with protection by not allowing the person on the other side to shoot directly through the wall.

If you are not in the military then you can use the title of this article as your example. Just because somebody or something is invisible does not mean that they or it cannot be molested. In other words, invisibility does not make them or it invincible.

In the realm of computer and information security, obscurity relates to concealment or invisibility. It needs something extra to actually provide protection.

So, stop going out of your way deliberately considering security through obscurity as a layer of your network, operating system, or application protections. Let obscurity come naturally. Plan your deployments and limit your distributed information so that others are forced to perform a lot of queries to determine what you have available. After all, the more noise they make the more likely you are to catch them in the act.

Addition:
I see the Roger Grimes has addressed this issue in his latest blog entry. He brings up several good points that I think I have addressed here. Be warned, the database with a NULL SA password that he set up was a “honeypot.” Please do not try this at home.

press back at any time and then quickly press down,up,down(2),up,right,left,right,Y,X(2),A,

Cutaway

security, obscurity, NMap, Superscan, THC-Amap, THC-Hydra, Medusa, keykatcher, Cain&Abel, Shmoo, Security Ripcord, John The Ripper, Paros Proxy, Roger Grimes, Rainbow Crack, Security Through Obscurity

The lastest edition of the SANS Advisor is out. This time they used two of my articles: “Taking SNMP for a Walk” and “Please Don’t Decrypt My File.” The first article talks about the importance of treating SNMP community string as if they were passwords (which, in a sense, they are). Of course, in a perfect world everybody would be using SNMPv3 which can be configured to use encryption. Check out a quick README about this at the Net-SNMP site. The second article describes a personal blunder on my part. I was attempting to transfer a file securely but working too fast bit me in the butt. This is a good argument for slowing down and double checking when security is important.

A few of the links to the tools and references I talked about include:

• Securing Cisco Routers: Step-by-Step <- EDIT: I removed the link to this because the SANS store is no longer offering this text. Dang it!
  
• Hardening Cisco Routers
• Cisco SNMP configuration attack with a GRE tunnel
• Net-SNMP
• ADMsnmp
• SNScan
• GnuPG

An interesting side note, Paul Asadoorian also had an article published in this volume. His article, “Secure Instant Messaging for OS X,” stays on track with the theme which is Instant Messaging. You should definitely check out his Security Weekly Podcast.

Please let me know what you think about these articles.
Thanks,
Cutaway

Okay, I am getting a little sick and tired of the constant chatter about “this operating system is better than that operating system.” It is like the white noise in the background of any room where there is more than one technically savvy person. People just need to get over the fact that there is more than one tool out there and that a job can usually be done by any one of those tools. Sure, many times one of those tools does a better job than the rest, but guess what, that is true of everything else in life.

“Where is this coming from?” you ask. Well, this past week I had an interview for an Security Manager position and one of the system administrators asked the question, “So, how are you going to treat my linux server if you are hired to this position?” I told him that I didn’t have a problem with one operating system over another. I explained that any job can be done by any operating system and that a good security administrator will have to be ready to evaluate any system to determine how it is affecting the security of the environment. A pretty good answer in my mind but it seems that the statement “any job can be done by any operating system” raised a few hairs and ruffled a few tail feathers.

Look, in my heart of hearts I am a Linux man. However, I working in a Solaris and IRIX mixed environment that is moving to a Solaris and SUSE mix and periodically a Windows system will rear its ugly head. Do I mind? No. I am happy to secure or provided suggestions when securing any operating system. Has this hurt me a little in the fact that I am not completely conversant in any one operating system. Maybe, but I am ready for all encounters and I will overcome either with the knowledge in my head or a little bit of SANS Reading Room and/or Google.
Please get over it,

Cutaway