Security Ripcord


Why Security Professionals Push Testing and Research

February 5th, 2012 cutaway Posted in Management, Penetration Testing, Research and Development, Security No Comments » 2,092 views

Once again I find myself pointing to tweets by Richard Bejtlich. This time it was actually a retweet of Hogfly who runs the Forensic Incident Response blog. Hogfly recently pointed out an article in Aviation Week titled “China’s Role In JSF’s Spiraling Costs“. This article demonstrates the actual cost for a specific project associated with industrial espionage, nation state infiltration of critical infrastructures, and general criminal activity. A blog post by Richard Stiennon, titled “The first thing we do, is hack all the lawyers“, also showed how these same threat agents are leveraging third-party relationships to impact specific projects. I like these articles because they provide specific numbers relating to cost of impact. “…$40 billion…” “…costs at tens of billions of dollars…”

These two examples show both ends of the information technology (IT) spectrum. The defense contractors responsible for the Joint Strike Fighter (JSF) should have had decent security in place to include security testing and monitoring. The majority of law offices will not have security practices that met these standards. In most cases the IT security considerations employed by law offices will actually fall at the other end of the spectrum: operating without significant information security considerations. But, in the end the result of both cases was the same.

I believe that it is pretty safe to conclude that the threat agents responsible for these and similar breaches did not just attach to the networks and start exfiltrating data. Rather, these successful attacks very likely required the use of a combination of known and discovered exploits to gain access, persistent, and propagate within these networks. It is also logical to conclude that their activities generated system and network-based artifacts that outlined their activity, even if that activity mimicked normal and authorized operational activity. Understanding these system and network-based artifacts is an important step to preventing and detecting attempts to infiltrate a network. Another key component is detecting exploitable vulnerabilities before they can be leveraged against the resources in a network.

Early detection is why security professionals encourage network mapping, vulnerability scanning, penetration testing, research and development, and monitoring. Security teams that provide penetration testing services should have an understanding of the techniques applied by current and past threat agents. They should also have a keen eye for leveraging the resources and services to their advantage to demonstrate the ingenuity attackers will implement after the initial compromise of a network. Tom Liston of InGuardians has a plethora of stories that demonstrate how he circumvented good security implementations using common sense and experience with a wide variety of technologies. The result of such penetration testing will generate system and network-based artifacts that can be leveraged to train a organization’s security and information technology administrators to detect and identify similar activity.

Research into technologies deployed in test networks and off-line implementations provide valuable information without impacting an organization’s business assets. It also reduces the cost of effort by providing beneficial information to all businesses employing a technology rather than a single instance where the organization hordes the information to prevent distribution to threat agents. When the results of research are presented to security professionals, IT administrators, IT management, and corporate executives all of these parties benefit from the knowledge and are able to leverage the information to assess and use it to improve their security and effectiveness of their business assets.

While writing this Richard tweeted (if you are not following him then you should stop reading and take care of it right now) to additional insights that are relative to my point. “Exploits aren’t as important as some think. I worked cases where not even active intruders on a corp network inspired appropriate concern!” and “Tech people should consider that IT and sec are one of many factors that mgt weighs. I fear it’s underweighted, but it’s not tech’s call.” Both of these are very true and have played a significant role in the persistence of many breaches including those pointed out at the beginning of this post. I too have experienced active intrusions with manual (rather than automated) system interactions, supported by specific system and network-based artifacts, that were downplayed and eventually treated as a malware infestation.  Even the experiences of multiple incident response professionals was not enough to change the opinions of the administrations, IT managers, and executives of these organizations. This attitude was born out of inexperience in the types of activities associated with a network’s initial compromise, persistence of the compromise, propagation to additional resources, and exfiltration of data.  Experience that might have been achieved by monitoring the data produced by penetration testing. Of course, it also requires a mind that is not specifically limited by business restrictions and is open to new possibilities that are born out of sublime and criminal research into information technologies.

Go forth and do good things,

Don C. Weber


TcpReplay – Replaying Ping

May 18th, 2008 cutaway Posted in Hacking, Networking, Penetration Testing, Security No Comments » 3,150 views

This will show the capture of ping requests to a specific host. This information will be captured using tshark to a pcap file. This pcap file will be edited to cut out the ping reply packets. This file will then be used to replay the ping requests and receive responses.

This should be the first step to many similar replays.

Run tshark to capture

[user@localhost tshark]$ sudo /usr/sbin/tshark -i eth0 -w ping_default.pcap
Password:
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
8
[user@localhost tshark]$

Ping remote host

[user@localhost tshark]$ ping -c 4 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.422 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=0.339 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=0.243 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=0.334 ms

— 192.168.2.1 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 0.243/0.334/0.422/0.065 ms
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_default.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 0.000370 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 1.000509 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 1.000783 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
5 2.001345 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
6 2.001524 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
7 3.001984 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
8 3.002263 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

Rip out only the wanted packets

[user@localhost tshark]$ ls
ping_default.pcap
[user@localhost tshark]$ sudo /usr/sbin/editcap ping_default.pcap ping_requests.pcap 1 3 5 7
Password:
Add_Selected: 1
Not inclusive … 1
Add_Selected: 3
Not inclusive … 3
Add_Selected: 5
Not inclusive … 5
Add_Selected: 7
Not inclusive … 7
[user@localhost tshark]$ ll
total 16
-rw——- 1 root root 936 2008-05-17 23:33 ping_default.pcap
-rw-r–r– 1 root root 480 2008-05-17 23:35 ping_requests.pcap
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_requests.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
2 1.000413 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 2.001154 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
4 3.001893 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

I am not sure why that happened. Grap the right packets with editcap.

[user@localhost tshark]$ sudo /usr/sbin/editcap ping_default.pcap ping_requests.pcap 2 4 6 8
Add_Selected: 2
Not inclusive … 2
Add_Selected: 4
Not inclusive … 4
Add_Selected: 6
Not inclusive … 6
Add_Selected: 8
Not inclusive … 8
[user@localhost tshark]$

Read pcap file with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_requests.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 1.000509 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
3 2.001345 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 3.001984 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
[user@localhost tshark]$

Replay with TcpReplay

[user@localhost tshark]$ sudo tcpreplay –intf1=eth0 ping_requests.pcap
sending out eth0
processing file: ping_requests.pcap
Actual: 4 packets (392 bytes) sent in 3.10 seconds
Rated: 130.2 bps, 0.00 Mbps/sec, 1.33 pps

Statistics for network device: eth0
Attempted packets: 4
Successful packets: 4
Failed packets: 0
Retried packets: 0
[user@localhost tshark]$

Capture replay with tshark

[userr@localhost tshark]$ sudo /usr/sbin/tshark -i eth0 -w ping_replay.pcap
Running as user “root” and group “root”. This could be dangerous.
Capturing on eth0
8
(process:8719): CaptureChild-INFO (recursed): Signal: Stop capture
aborting…
tshark: Child capture process died: Abort
[user@localhost tshark]$

Review what happened with tshark

[user@localhost tshark]$ sudo /usr/sbin/tshark -r ping_replay.pcap
Running as user “root” and group “root”. This could be dangerous.
1 0.000000 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
2 0.000332 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
3 1.001619 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
4 1.001905 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
5 2.002310 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
6 2.002494 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
7 3.003997 192.168.2.242 -> 192.168.2.1 ICMP Echo (ping) request
8 3.004201 192.168.2.1 -> 192.168.2.242 ICMP Echo (ping) reply
[user@localhost tshark]$

Go forth and do good things,

Don C. Weber


Core Impact at Southwest Regional CCDC

March 20th, 2008 cutaway Posted in CCDC, Core Impact, Penetration Testing No Comments » 1,841 views

Last month I was approached by a professor at Del Mar Community College here in Corpus Christi to participate in the 2008 Southwest Regional Collegiate Cyber Defense Competition (CCDC). The professor wanted me to be a part of the Red Team that performed external assessment and penetration testing against the teams while they tried to maintain a business environment and implement business requests for their mock business. Of course I jumped at the chance. To make up for some lost time associated with some of my tools skills I decided to get a demonstration copy of Core Impact. The guys over at Pauldotcom hooked me up with their contact and before I knew it I was off to the races.

At first I thought that I would just write a quick post about the experience so I started getting some screen shots of Core Impact and writing it all up in a Word document. Six pages into it I realized that it was just going to be a little too much for a blog post. So, I decided to make it a White Paper instead: Core Impact at the 2008 Southwest Regional Collegiate Cyber Defense Competition.

Although there are no ground breaking findings in this paper, I hope that I have demonstrated the usefulness of Core Impact. It really worked out well in the competition environment and I can now completely understand why people who have used this toolset are impressed by it. Of course, as I mention in my conclusion, there is definitely a need for all the other tools associated with penetration testing, but if you need something for quick and consistent results, Core Impact should be high on your list of considerations.

I would like to thank Core Impact for lending me a time limited version of their tool for this competition. I would also like to thank the professors at Del Mar Community College for putting on such a professional competition. I only hope that I added to the experience. If you get a offer to participate in a CCDC, please do so. You are helping future information technology and security professionals develop and grow.

Go forth and do good things,

Don C. Weber

Technorati Tags , , ,

Considerations for an Information Assurance Laboratory

September 21st, 2007 cutaway Posted in Education, Hacking, Patch Management, Penetration Testing, SANS, Security 1 Comment » 3,086 views

I find it interesting what professors will say and do when it comes to providing an educational experience to their students. On one hand I can understand that the professor is trying to discover the best way possible to quickly train their students about a specific topic. On the other hand I am concerned about the, at times, lack of intelligent thought process on how it is going to affect other students, faculty and staff that also use and maintain the same resources and network environment.

One of these situations arose in my organization the other day. A college is in the processes of providing computer security courses that will train the students in subjects such as risk assessment, programming, networking, and defensive and offensive tactics (to name a few). Because it is a new program the college faculty and staff are still gathering resources, deploying them in labs, and creating the teaching platforms. All of this while the courses are being taught.

When the college decided to start providing the students with this type of course work they did approach the university’s networking team to let them know what was happening. After a few meetings it was determined that it was necessary to operate any labs that would be doing offensive tactics from a lab that was completely isolated from the university network as well as the Internet. Although very good in theory, completely isolating a network in this manner really brings forward some interesting problems. Problems that require a lot of planning, coordination, work and money.

The following is a list of a few things that should be taken into consideration as you are developing security courseware.

1. Because of the types of network and other computer activities associated with information security the details on any lab deployments must be handled just like any other system development and bringing together all of the people and organizations involved and follow a life cycle. By doing this you will determine issues and identify problem areas in the design phase and before classes start. As with any system design, it is much harder to change or address issues during production. The whole “fixing the plane while it is flying” issue.

2. Labs that will be conducting offensive operations or monitoring must be completely isolated from the school’s network and the Internet. There are many reasons for this.

  • Network traffic will contain plain text personal information related to other students, faculty, and staff. I used the gmail attack tools developed by Robert Graham and presented at DefCon 15 as an example to drive this point home.
  • Student attack tool activities are hard to distinguish from malicious attack tool activities. Many tools are designed this way to avoid network and other protections.
  • Being convicted, or even just accused, of hacking a resource without permission could ruin the career of the student and any teachers involved with the incident. Each student is trying to learn and grow. The majority of them are youths who want to test their boundaries and skill levels. Sometimes the temptation is just too much, not to mention the potential for improper configuration, and they might scan or attempt to exploit a vulnerability. The school administrators and teachers must help protect their students from this.
  • The reputation of a school is involved. If the school’s students and professors are accused of attempting to hack computers connected to the Internet then the school is going to see a serious reduction in the amount of students attending the security courses and the rest of the school’s curriculum.

3. When you are building your labs be sure to take into considerations that students operating on an isolated network are still going to need access to the Internet. They will need this to obtain tools, read manuals and howtos, and interact with their Facebook/MySpace accounts. Although having a few computers off to one side is a good quick fix, it is not the optimal situation and you will be reading complaints about this in the class evaluations. Perhaps a better solution is to have dual input monitors that can be quickly switched back and forth by the students. Each system should have different backgrounds or operating systems so that the students are aware which system they are using. Considering thin clients is also a viable solution and would prevent network cables from being swapped around.

4. Create separate networks for security classes and regular classes. Nothing is more frustrating for a student or a teacher to come to a lab they have been working on most of the semester only to find that somebody has modified its configuration or hacked their resources. This is detrimental to the learning experience and will lead to finger pointing and bad blood.

5. Create update serves that can be a repository for OS and application patches. With properly document procedures these servers can be kept on the campus’ main network in order to retrieve updates via the Internet and then reconfigured to provide service to the isolated network. Updating in this manner is a great learning experience for the students and will prepare them better for real world experiences.

6. Start a tool repository to version control tools. Many tools change rapidly and also disappear. Maintaining this repository is a good way to show students product evolution. It is also a good way to monitor these for malicious activity. This helps keep developers honest. Let’s face it, eventually some tool will be updated with malicious intent. It is only a matter of time, and think of the publicity your school will get if you are the first to identify it.

7. Network isolation is a common practice in the security research field. Ed Skoudis developed his SANS GCIH class to be an isolated environment. The SANS Integrated Cyber Exercise (ICE) is conducted in an isolated environment. And the RootWars at Learn Security Online are conducted in an isolated environment. It can be done but it requires planning.

8. Finally, listen to and leverage the experience of the information security professionals within your organization. Teaching security courseware is one thing, but working as a security professional is completely different. There are different goals and different mindsets. If the information security professionals within your organization are good they will get you what you need while also maintaining an acceptable level of security for the entire organization.

Remember, you are training the future information security professionals of the world. You should show them that security is necessary as well as implementable. Circumventing a schools security and infrastructure policies and procedures just to provide additional or “real world training” to the students is not setting a good example. It is, in fact, sending the wrong message.

If you have any additional concerns or recommendations, please leave a comment sot that others can take it into consideration.

Go forth and do good things,
Cutaway

Technorati Tags , , , , , , ,

BackTrack 2.0 Final – Hard Drive Install Considerations

September 3rd, 2007 cutaway Posted in BackTrack, Penetration Testing 1 Comment » 5,691 views

BackTrack 2.0 Final has really pushed security toolkits to the next level. I get a couple hundred hits a day about installing BackTrack to a hard drive. I do think it is important, however, to understand Chris Gates‘ point of view on not relying on BackTrack to be your default operating system.

Running BackTrack as your default operating system is not a good idea from several points.

  • It is already configured and you are not learning what you could from building your own distro and writing and compiling your own tools. (Chris’ point)
  • It contains a bunch of security tools that you do not want on your network unless you are doing assessments or penetration testing.
  • You may be breaking your company policies by having a security toolkit on your network without authorization or need. If you do not have a policy like this then you should consider developing one.
  • Most people run as root to utilize the scripts and menu configurations set up by the developers. You should be using a normal user account for all activities that do not require administrative priviledges (and you call yourself a security professional).
  • BackTrack configuration and updating is at the whim of the BT developers. Modifying the kernel and updating the packages on your own is not recommended for inexperienced users.

Of course I think that BackTrack is an invaluable tool to have in your arsenal. And, there are advantages to having it installed on your hard drive.

  • Most of the devices work out of the box or with very little configuration changes.
  • Your updates and configuration changes are maintained across boots.
  • You can install encryption technologies to help store your results securely. (I usually install GnuPG. If there is another way I have missed it.)
  • You do not have to worry about a spinning CD-ROM or USB thumb drive sucking the life out of your battery when your pcmcia wireless card and GPS is doing a great job of it anyway.
  • You do not have to worry about damaged media when you pull up to a site (don’t delete that ISO, just in case).
  • Running virtual environments will probably be easier. I am only guessing at this one but being able to stay uptodate on your virtualization software seems important to me.

So, let’s try and find some middle ground. I recommend that you build a system that you can personalize and that will house a version of BackTrack 2.0 Final on the same system. Get a system with a large hard drive to hold two versions of linux. You can throw in a third area for your favorite distribution of Windows as well for some of the Windows specific security tools if you would rather not run it virtually in Linux.

Disk Partition Recommendations for 80 GB Hard Drive:

/boot 128MB – Large boot sector for multiple kernel versions to include the BT vmlinuz
/swap 1024MB – Linux swap to share between distibutions
/ 15360MB – Large root partition for Linux distribution
/backtrack 8192MB – Large partition for BackTrack 2.0 Final
/share FREE – The rest of the free space can be shared to leverage storage

You should determine which distro of Linux you prefer and install it first using the disk recommendations. As to my recommendations for which version of Linux to run, I whole heartedly point you to Gentoo Linux. Although getting through an installation of Gentoo is challenging the first couple of times, there is no better way to learn the ins and outs of Linux. You will learn things from kernel building to the necessity for correct software configurations. You will also get a deep appreciation for the value of strong documentation and developer communications.

Once you have your Linux distro installed you can quickly get BackTrack 2.0 Final installed by following the instructions provided on the BackTrack Wiki. Here is a breakdown of what will need to be done. These were lifted from the “Transcript of movie” Backtrack install tutorial.

Boot into BackTrack and log in as root. You do not need to “startx” as this will be all done from the command line. Of course you need to substitute your drive and partition numbers for the ones provided. In this example /dev/hda4 is where the BackTrack root will be located and /dev/sda1 is where the boot partition will be located.

  • # mkdir /mnt/backtrack
  • # mount /dev/hda4 /mnt/backtrack/
  • # mkdir /mnt/backtrack/boot/
  • # mount /dev/hda1 /mnt/backtrack/boot/
  • # cp –preserve -R /{bin,dev,home,pentest,root,usr,etc,lib,opt,sbin,var} /mnt/backtrack/
  • # (Note: this has to copy 600+MB and takes a little while, so perhaps have a coffee)
  • # mkdir /mnt/backtrack/{mnt,proc,sys,tmp}

You will not need to follow the LILO instructions that precede these steps in the original tutorial. Just put the BackTrack vmlinuz in the boot partition and configure grub to point to it. The grub.conf.example file shows how to point to a vmlinuz.

Of course there are still a few draw backs to this deployment. You still have a computer system with a security related toolkit installed. One way to mitigate this risk is to not install any security related tools on the linux distribution you will be using for daily operations. You can increase the protections by not mounting the BackTrack partitions when you boot into this distribution. If you do have a separate computer for normal business operations, I recommend that you treat this system as a security and development system. Keep it isolated from other systems and networks unless absolutely necessary.

Go forth and do good things,
Cutaway

Technorati Tags , , , , ,

IT Security – Moonlite Bunny Ranch Style

April 29th, 2006 cutaway Posted in Bunny Ranch, PDC, Penetration Testing, Security No Comments » 5,511 views

I know that I am going to get a lot of flack about this but I just couldn’t help myself.

The other night I was reviewing an assessment report when I looked up at the TV and I realized that it was on HBO and the series Cathouse was showing. This show is about “the Moonlite Bunny Ranch, a legal brothel located in a sparsely populated desert community outside of Reno” so, of course, I was transfixed for the rest of the show. Well, right at the end of the episode, one of the women was leaving the house when the owner asked somebody to buzz her out. The camera was pointing out the front door and the woman walked through an iron gate which automatically closed behind her. I was just about to turn the TV off and get back to my report when I started realizing something about the show. This show is a great lesson in practical security through proper implementation. Let me walk you through the steps that a client has to go through to have access to the services provided at the Bunny Ranch.

  1. The client is let in through the front door which is usually locked but, during acceptable access time periods, it is unlocked and traffic is allowed to enter through the single, monitored, entryway. I consider this the externally facing router.
  2. Next the client enters a waiting room where he starts talking to the women that are waiting there to provide a service. I consider this waiting room the firewall. The clients are briefly inspected to determine if they are acceptable. You could also make the argument that this area also acts as an intrusion detection or prevention system.
  3. Once it is determined that the client is acceptable he or she is lead back to the bedroom where a price is negotiated and payment is authorized. Here we are obviously talking about the service and how it is using proper authentication and authorization techniques to determine whether the client is permitted to use the service and how much privilege he or she will be given to perform the desired task.
  4. While the client and the woman and client are interacting they are using safe sex techniques. This represents input validation. (New)
  5. Once services have been rendered the woman who provided the service leads the client back to the waiting room and says goodbye. This resembles the proper termination of activity provided by the service.
  6. As I saw during the final moments of the show, all outgoing traffic has to be given permission before it is allowed to leave the building. Obviously egress filtering is just as important at the Cathouse as it is within a network.
  7. During the whole process the manager on-duty is moving around and talking to all the employees and keeping tabs on what is actually happening within the whole environment. This activity reminds me of log monitoring and a professional that is ready to take action at the first sign of trouble.

So, I feel that we could learn a lot from this very professional business. I am sure that the Bunny Ranch has come up with this process to protect itself and its clients. Need is the mother of all invention. So, if the oldest profession in the world is following this process out of necessity then we should all take heed.

This article is in honor of “Hack Naked” from Pauldotcom. Guys, this place obviously needs a penetration test (too obvious, no matter…it had to be said!).

Cutaway


Modifying the Paros Proxy User-Agent String

March 21st, 2006 cutaway Posted in Paros Proxy, Penetration Testing, Tools 6 Comments » 10,265 views

Paros Proxy is an open source web assessment tool that gives the user the ability to spider websites, analyze content, modify requests, and much more. This proxy is a necessary tool when performing assessments, penetration testing, code reviews, application deployment reviews, or any other website security tasks. As Paros Proxy is a java-based open source tool the developers have provided the community with executable versions for various operating systems as well as the source code for modifications and development.

Although the usefulness of this tool warrants a write-up, it is not the reason why I decide to talk about this proxy. The reason I have decided to write about this proxy is because during a recent assessment I noticed that I could not get a server response when making HTTP requests through the proxy. At first I thought that it was me or my connection but after I continued my assessment I noticed that other proxy tools (i.e. WebScarab, Achilles) were receiving server responses. Because these other tools could connect I turned my focus to there being a problem with the Paros Proxy.

A little situation background is necessary. The assessment I was working on had me analyzing multiple servers within one company. I initially performed a sweep of the web servers with the Paros Proxy using its site spidering and analysis functionality. Time was more important than stealth during this assessment so I was not concerned about the scans being identified. And, indeed, the amount and type of traffic produced by the proxy was detected by several developers during site maintenance. (They specifically noticed the requests for common backup files.) Word of the web analysis circulated through the company and I didn’t think much about it until I tried to return to a few sites for further analysis. This is where the fun began. I first confirmed that I could still reach the web site in question by browsing to it without a running proxy. Then I tried going to the site through the Paros Proxy but the session timed out. No information was returned at all. It was at this point that I started experimenting with other proxies which worked fine. Basically, I proved that the problem was Paros specific.

Now, during the assessment, I looked through variety of HTTP requests and responses. Each request is accompanied by a USER_AGENT string that identifies the web browser making the request. This allows the web server to create traffic specific to the web browser to which it is responding. Proxies generally do not touch the USER_AGENT field but they do have the capabilities to change this information as it does any other information within the request. The Paros Proxy provides this type of functionality and, as with most other proxies, it has a set of predefined browser strings so that the user can easily manipulate the request to see how the server will respond. Most proxies stop here, however, Paros takes it a step further. In addition to the desired USER_AGENT the Paros Proxy also appends its own application name and version number to each request after it has had any modifications. For example, a normal USER_AGENT string for Mozilla Firefox looks like

Original User Agent String

Original User Agent String

whereas the Firefox USER_AGENT used by the Paros Proxy looks like

Modified User Agent String

Modified User Agent String

Now, normally, if a server does not understand a part of the USER_AGENT string it will ignore it. That is the case here with the Paros Proxy. The web servers being assessed did not know the meaning of “Paros/3.2.8″ so it just returned the information requested. Additionally, it was quickly ascertained that the addition of the Paros Proxy name and version were hard coded into the tool and this feature could not be turned on or off with the click of a button.

Of course, nobody likes to be assessed and, if possible, they will attempt to find a way to avoid it. And, at this company, somebody did. A developer apparently noticed the extra string within the USER_AGENT and programmed the web server not to respond to requests through the Paros Proxy. This was easily replicated by using WebScarab and appending “Paros/3.2.8″ to the end of its USER_AGENT string. Success was proved with no response from the web server. Although the developers, and possibly their management, assumed that they were now protected from assessments using this tool they could not have been farther from the truth. Not only were they still susceptible to scans through other proxies, their web sites could still be accessed by the Paros Proxy. This, however, did require a little modification to the tool.

As I stated earlier, the Paros Proxy is a Java based application and the developers have provided the community with their source code. Fortunately for me, one of my colleagues (a Java programmer by trade) suggested that we just download and edit the source so that the USER_AGENT string did not send the extra information. So, in fifteen minutes we had downloaded all of the tools that we needed to program and compile a Java application. With a little searching we located the section of code that modified the USER_AGENT string such that the usual Paros information did not get sent to the server. From here it was just a matter of quickly editing the file, recompiling it, and replacing the original version with the new and improved assessment tool.

The following steps demonstrate this effort:

1. Download the Java SDK from Sun Microsystems.
2. Download ANT from the Apache web site.
3. Download the Paros Proxy source and executable versions from the Paros web site.
4. Install Java
5. Unzip “ant” and move it to C:\Program Files\Apache
6. Unzip the Paros souce files.
7. Edit C:\Documents and Settings\user1\My Documents\downloads\
paros\paros-3.2.8-src\paros\src\org\parosproxy\paros\Constant.java (make backup first).
Comment out the following line and replace it with:

// public static final String USER_AGENT = PROGRAM_NAME + “/” + PROGRAM_VERSION;
public static final String USER_AGENT = “”;

8. Change dir to
C:\Documents and Settings\user1\My Documents\downloads\
paros\paros-3.2.8-src\paros\build
9. Set JAVA_HOME to the java dir: set JAVA_HOME=C:\Program Files\j2sdk1.4.2_10
10. Compile with ant: C:\Program Files\Apache\apache-ant-1.6.5\bin\ant
11. Make backup of paros: move C:\Program Files\Paros\paros.jar to paros.jar_orig
12. Copy C:\Documents and Settings\user1\My Documents\downloads\
paros\paros-3.2.8-src\paros\build\paros\paros.jar to C:\Program Files\Paros\paros.jar
13. Test by running and checking the user agent.

The point that system and network administrators should take away from this effort is that any program can change its behavior patterns. This is one reason that Intrusion Detection professionals try not to base their identification rules solely on information provided within the “Content” part of the network traffic. Developers should also remember that not fixing bad or poorly deployed code cannot be solely protected by try to block detection, assessment, and penetration tools.

Comments and inputs are welcome.
Cutaway


Auditing Workstation Considerations

March 21st, 2006 cutaway Posted in Assessment, Penetration Testing, SANS, Tools No Comments » 2,334 views

As a part of the SANS Advisory Board I try to respond to questions whenever possible. Recently somebody wrote in about how to secure a workstation designed for auditing. The following was my response.

Securing an auditing workstation is important but you also want to
be sure that you do not limit services that you may need to use during
an audit or penetration test. I usually protect my system with a
host-based firewall and create a backup of the system should I need to
restore it to a known good state (Knoppix style security toolkits make
this easier still). Perhaps the most important thing is to control the
system and limit access to it to specific personnel.

Perhaps you should consider using a laptop for this type of
activity. That way you can control access to the system better and it
will not be constantly connected to your network. Two factor
authentication (fingerprint, smart cards, etc) using included or add-on
hardware is becoming more prevalent and easier to obtain. You might
take this into consideration to protect such a precious and potentially
dangerous system.

You may also have to consider your network configuration when doing
testing. Some traffic may be denied by your network devices. Although
this could stop an attack it does not necessarily mean that your system
or application is secure. You may need to permit unusual traffic to and
from this system so that you can fully test your environment. You
should be very careful making these types of changes and have procedures
and inspections to return the environment to the operation state.

If you still want to lock down the operating system and applications
on this system, I would take a look at the checklists provided on the
S.C.O.R.E site (https://www.sans.org/score/). This site also has links
to the CIS tools and guides mentioned by others.

Hopefully this is helpful to others as well. Another board member also pointed out that he has written an honors paper covering this topic: Auditing a Systems Security Consultant’s Laptop Running Fedora Core 2. Having written a paper for my GNSA-Gold certification and having voted on dozens of GSEC honors papers (under the old honors process) I know that this paper is thought of highly by the GNSA graders. After a quick review I think that it is a very good place to start. Although this paper is written for a laptop system most of the issues it addresses can and should be applied to any auditing system. Just because a system is not portable does not mean it cannot get up and walk away.

A system configured for auditing and penetration testing should be considered a high risk asset and treated as one. The capabilities of this system and the potential information that it contains are underprotected at your own risk. One other consideration should be made about how to restrict and protect information collected by this system and written to media. A perfect example of this is the recent activity at McAfee as outlined in the InfoWorld article Auditor loses thousands of McAfee employees’ data.


Where to find: Penetration Testing

March 21st, 2006 cutaway Posted in Penetration Testing, Security, Tools 1 Comment » 3,954 views

After a recent stint of performing authorized penetration testing I have come to realize that information is king. Of course, I already knew this, but the information on the Internet has made me an overnight “script kiddie.” Needless to say I know that I have more skill than a “script kiddie.” I know this because I have self control, I can talk to my superiors and customers in a manner that is not condescending and at times very helpful, and I can write up my findings in a thoughtful and informative matter without releasing my findings to the local IRC channel or news list.

That said, I also realize that everything I did during this penetration test was leaverage the knowledge and know how of many smart (or at least dedicated) individuals and groups. These people have posted their hard work, findings, and development for the public to use and learn from while securing their assets. The following is a list of resources that I found extremely helpful in the past few weeks.

Plenty of sites provide information about vulnerabilities and their exploits. They even provide scripts that perform the exploit. This is why the term “script kiddie” was invented. These scripts are available for anybody to download and use. Each of these sites and most of the scripts come with disclaimers stating that they are only intended for educational and non-malicious use only. The following sites fall into this category.
Packet Storm Security
Milw0rm
SecuriTeam
FrSIRT
Government Security.org

Still other sites are devoted to the smooth usage of exploits. They provide interfaces called “frameworks” that evaluates a target once the user provides the required information (i.e. IP address, port, secure or unsecure connection, type of exploit, etc). Metasploit is by far the most advanced of the open source tools. Security Forest has just started providing their framework but they contain a large collection of the exploits that are available.
Security Forest
Metasploit

There are several commercial tools that expand on this type of functionality. Although I have not used any of these tools, my understanding is that they combine scanning tools, vulnerability assessment tools, and exploitation tools into one package. This would prove to be very helpful for new penetration technicians and teams that want to streamline their efforts. Unfortunately, these tools tend to be too expensive for persons and companies that do these assessments periodically.
Canvas
BiDiBLAH
Core Impact

The next category contains sites that provide unique tools for assessment of targets. Obviously this list is not a complete list of all the tools that are out there. This is just a list of tools that recently came in handy for me.
Foundstone – provides a wealth of tools to evaluate sites and targets. Superscan 4 is a great tool for scanning the network, grabbing banners, and enumerating Windows hosts. There are many tools that will evaluate Windows host for specific vulnerabilities mainly due to missing Patches and Hot Fixes.
PAROS – This proxy is very handy for spidering websites and then evaluating them for vulnerabilities such as Cross Site Scripting and SQL Injection. It will also let you perform “Man-in-the-Middle” attacks on form data that is evaluated client side and not server side. Unfortunately there are a few features of this program that proved to be a bit flaky. The most annoying (to me) was the fact that saving sessions was very unstable. This is an important fault because of the need to maintain a trail of evidence.
OWASP – This project is one of the best for web developers. They provide a website framework that is designed for teaching the web developers and evaluators. They also provide a proxy that provides much the same functionality as PAROS with a few extras.
phenoelit – This site provides a wealth of well thought out tools.
Brutus – THE tool for brute forcing virtually any type of authentication. Be wared, it takes a while to understand how to actually use this tool properly. In the mean time there will be many failed attempts and it can be frustrating. But once you understand how to use it there are very few tools that can compete with it. Additionally, the word list generator is simple but extremely useful. User only need to evaluate the site they are evaluating and gleen a few key terms from it. Once these key terms are entered into Brutus’ word generator and detailed list can be generated or added to very quickly. This tool has been around for a while and development has stopped. But because it was designed so well in the beginning there are very few modifications that could be added to it. However, one feature that would be nice is the ability to restart if a scan was interrupted. Unfortunately, I do not have time to help with this one shortcoming.
Sam Spade – A cool tool for web evaluation. One feature that came in handy was its ability pull E-mail addresses from a spidered site. The great thing about this is that it only takes a quick edit to create a user list that can be used in any brute force tools when an account name is required for access.
Auditor Security Collection – Of course I would not have gotten anywhere without the tools in this collection. I would often find myself researching an application, locating a tools for evaluation, and then discovering that it was already installed in this collection. This allowed me to immediate start using the tool instead of downloading and installing, or in some cases, compiling and then installing. Although doing so would not have been too much trouble, when you combine all of the time I would have spent on the separate tools it really starts adding up.

It is very obvious that this is just a short list of all of the resources that are available on the Internet. For a more detailed list goto the
Security Forest Link Tree and scan the collection they have provided for the community. It makes my effort here pale in comparison. But, then again, you may not have found it on your own.