Handling HTTP and SSL in the Shell

Posted on July 1, 2009 by The Shell Shakespear Leave a comment

The topic of this week’s shell1liners is handling HTTP and SSL in Bash:

#netcat scanner for HTTP servers
for i in $(seq 1 255); do nc -n -v -z "192.168.1.$i" 80 | grep "open"; done | tee webservers.txt
 
# Manually perform a HTTP Get Request
echo -ne "GET / HTTP/1.0\n\n" | nc www.redspin.com 80
# Manually perform a HTTP Get Request on a SSL Port
echo -ne "GET / HTTP/1.0\n\n" | socat – OPENSSL:www.website.com:443,verify=0
# Create a local TCP pipe to a remote SSL port (to allow netcat to probe a SSL service)
socat -vd TCP-LISTEN:8888,fork OPENSSL:www.redspin.com:443,verify=0
 
# Always connect to a given webserver PORT regardless if it is SSL or normal HTTP
(curl -iks -m2 "https://www.redspin.com:PORT" || curl -iks -m2 "www.redspin.com:PORT")
 
# Perform a check on a list of webservers (HTTP or HTTPS): HOST:PORT -&gt; HOST:PORT|WEB SERVER|HTML Title
# Includes a 2 seconds timeout using curl's -m2, and parallelization using xargs's -P10
cat webservers.txt | xargs -P10 -I'{}' bash -c '(curl -Liks -m2 "https://{}" || curl -Liks -m2 "{}") | grep -iao -e "^Server: .*" -e "" | sed "s#Server: \(.*\)#|\1|#i;s###ig" | tr -d "\r\n" | sed "1s/^/{}/;\$a\\" | sed "s/^\([^|]*\)|$/\1||/"' | tee webserver_info.txt
 
# Check if Trace is enabled on a given website
echo -ne "TRACE /something HTTP/1.0\nX-Header: Trace Enabled\n\n" | socat - OPENSSL:www.website.com:443,verify=0
# Check for the insecure SSLv2 protocol on a website
echo -e '' | openssl s_client -connect WEBSITE:PORT -ssl2 -no_ssl3 -no_tls1 2&gt;/dev/null | grep 'SSLv2'
 
# Bruteforce a given numerical webpath, printing the HTTP status code for each request
for ((i=0;i/dev/null | grep HTTP/1.1) | tee webbf.txt ; done
 
# Simple HTTP Listener
python -m SimpleHTTPServer
# Simple HTTPS (SSL) Listener without a server certificate
sudo openssl s_server -accept 443 -nocert
# Simple HTTPS (SSL) Listener with a bad self-signed server certificate
echo -ne "\n\n\n\n\n\n\n" | openssl req -new -newkey rsa:1024 -days 1 -nodes -x509 -keyout out.pem -out out.pem ; openssl s_server -cert out.pem -www

Simple Network Management Protocol – SNMPv3

Posted on July 1, 2009 by Nathan Drier 1 Comment

SNMP, or Simple Network Management Protocol, has been the go-to management protocol of choice for years. As its name declares, it is a simple and efficient way to monitor hosts. Most everything is SNMP capable these days, from servers to switches, and from firewalls to routers. Even most UPS’s and A/C units have it built in. Most installs of SNMP default to SNMPv2, which is dated technology. In 2004, SNMPv3 was introduced as a replacement for v2, touting increased security and better remote configuration. In an SNMPv2 setup, community strings (passwords) and data float by in plain text, allowing anyone in the right spot on the network to capture them. Once you have the community strings, you can query devices for information (and possibly make configuration changes!). SNMPv3 solves this problem by protecting the authentication handshake, and then encrypting all the SNMP data as it crosses the network.

In this quick how-to, I’ll show you how to setup SNMPv3 on a generic Debian Linux machine.

First, grab the snmpd package from apt:

 aptitude install snmpd

Right after SNMPD pulls down its dependencies and installs, stop the daemon:

 /etc/init.d/snmpd stop

Then we need to make a few configuration changes. For security reasons, SNMP only listens on the localhost interface by default. In order to monitor this Linux box remotely, we need to open that up. Crack open /etc/defaults/snmpd and edit the following line:

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 127.0.0.1'

to read

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid'

Now we need to disable the default SNMPv2, and create a SNMPv3 user. Open up /etc/snmp/snmpd.conf and scroll down and comment out all the lines starting with com2sec in this section:

#       sec.name  source          community
#com2sec paranoid  default         public
#com2sec readonly  default         public
#com2sec readwrite default         private

Since we just ‘disabled’ SNMPv2, we need to enable v3 and create a user. Use the command line utility, net-snmp-config to help to create a SNMPv3 user:

net-snmp-config --create-snmpv3-user -ro -A sadWFqeq3421 -X fferlGq5247 -a SHA -x  AES snmpv3user
 
-ro is read-only user
-A sadWFqeq3421 is the authentication passphrase
-X fferlGq5247 is the privacy passphrase
-a SHA is how the authentication passphrase will be stored (MD5 or SHA)
-x MD5 is how the SNMP data will be encrypted during transit (DES or AES)
snmpv3user is the name of our new user

And if the command went ok, the output should look like this:

adding the following line to /var/lib/snmp/snmpd.conf:
createUser snmpv3user SHA "sadWFqeq3421" AES fferlGq5247
adding the following line to /usr/share/snmp/snmpd.conf:
rouser snmpv3user

Lets start up the SNMPD service again:

/etc/init.d/snmpd start

Lets do a quick test to make sure it all worked ok. From another machine with SNMP installed, we can issue a command like the following to query the remote Debian machine, with our new SNMPv3 user, to check the amount of ram installed:

snmpget -v 3 -u snmpv3user -l AuthPriv -x AES -a SHA -X fferlGq5247 -A sadWFqeq3421 10.0.0.45 1.3.6.1.4.1.2021.4.5.0
 
UCD-SNMP-MIB::memTotalReal.0 = INTEGER: 516528 kB

Looks like it all went well! The output of the last command shows that the machine has 516,528 kB of RAM. For some added security, you can ACL the SNMP service to your query server with some quick iptables rules. These allow ssh from anywhere, SNMP from 10.0.0.42 (your query server) and established connections. Everything else gets dropped:

iptables -I INPUT 1 -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 10.0.0.42/32 -p udp -m udp --dport 161 -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -j DROP

With a SNMPv3 setup, the authentication process and PDU’s (SNMP data) should be encrypted. No more ‘public’ community strings floating by in plain text. The best way to query those SNMP clients is to use a network management application (Cacti is free and a Redspin favorite).

Cacti-Graph
Happy Graphing!

An Introduction to Shell One Liners

Posted on June 25, 2009 by The Shell Shakespear 3 Comments

The knowledge and use of the command line is a powerful tool that can aid in the creation, modification and automation of routine tasks that a security auditor or any computer user may come up against. The flexibility, simplicity, and leetness of the shell oneliner can replace thousand-line perl code which otherwise would be thrown away after the task is complete. We have decided to provide share some of our favorite oneliners that we have found useful, either culled from other sources or created by ourselves. All of these examples should run comfortably from a Linux bash shell or Cygwin-Windows equivalent, with the required applications listed in the oneliner.

The topic of this week is IP address manipulation:

# Sort by IP Addresses
sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4
 
# Sort by IP Addresses and Port like IP:PORT
sed 's#:#.#' | sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4 -k5,5 | sed 's#\(\([0-9]\{1,3\}\.\)\{4\}\)#\1:#;s#\.:#:#'
 
# IP2HOST: IP -&gt; IP (HOST) using 'bind-host' package built into Ubuntu
for i in $(cat ips.txt); do echo "$i ("`host $i | grep -v NXDOMAIN | cut -d' ' -f5`")"; done | sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4 | sed 's#()##' | tee ip_hosts.txt
 
# HOST2IP: HOST -&gt; IP (HOST) using 'host' package available in Ubuntu
for i in $(cat hosts.txt); do host `echo "$i" | tr -d [[:blank:]]` | grep -v -e 'alias' -e 'handled' -e 'timed' | sed 's/Host \(.*\) .*/\1 0.0.0.0/' | sed "s/;;.*/$i - - 0.0.0.0/" | awk -F' ' '{printf "%s (%s)\n",$4,$1}'; done | sort -n -t. -k1,1 -k2,2 -k3,3 -k4,4 | tee ip_hosts.txt
 
#Print IP addresses in a file
egrep -o '[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}'
 
# Print IP addresses in a file: Perl edition
perl -nle 'print $&amp; if /(\d{1,3}\.){3}\d{1,3}/'
 
# Print IP address in all files in the current directory tree with some pretty color matching
find . -type f -exec egrep -a -H -n --color=auto '[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}\.[[:digit:]]{1,3}' {} \;

Thanks to readers for suggesting the color syntax support implemented using wp-syntax. I furthermore learned that the Visual Editor of WP was oppressing my HTML code, stripping tags in the WP-Syntax <pre> tag that should be present, so I’ll be keeping my edits in HTML mode from now on.

Insight about IT security auditors – 10 things your auditor isn’t telling you

Posted on June 25, 2009 by John Abraham in Main | Leave a comment

Being auditors I thought it was worth noting Dave Shackleford’s insightful blog post 10 Things Your Auditor Isn’t Telling You. If you have had any experience with auditing or retaining security auditors you should be able to relate to his points.

The Gear Myth: does more gear = more security?

Posted on June 24, 2009 by John Abraham in Main | Leave a comment

AKA: Are you building a house of cards?

The gear myth is the mythical view that investing in more technology will inevitably make an enterprise network more secure. While there is a tremendous amount of new gear available to help make networks more secure, our perspective is that more gear, in fact, may not only fail to achieve your security goals, but it may even add risk.

First let me visually explain the gear myth, then I’ll discuss why layering additional technology into a network can be counterproductive.

Initial state: we have some security risk, lets address it by deploying some new technology.

The image at left is a graph that shows how someone, say an IT manager, might view their level of security for a specific component of their IT environment. The scale shows that the level of security is very low. Based on this assessment the IT department deploys some new technology.

The new gear is installed: everything is fine, no risk…. right?

After deploying some new gear, which in many cases is limited to buying expensive technology and lobbing it into the data center, the perceived level of security is much higher. Read more

Vendor Management: are your vendors secure?

Posted on June 24, 2009 by John Abraham in Main | Leave a comment

If you ask the 50 banks that recently had customer data exposed when their accounting firm lost a number of their audit laptops to theft, the answer is no. Incredibly, the accounting firm’s lost laptops apparently did not utilize data encryption even though they contained sensitive customer information. This left the banks in the un-welcomed position of having to notify customers of a data breach.

Anecdotally, our experience doing security audits across many industries indicates that much (maybe even most) of the risk of sensitive data loss in an enterprise is associated with their vendor’s lack of adequate security controls.

Ironically, when a company outsources a service they are also outsourcing much of the security risk. For example, Read more

DoS-ing over Dial-Up

Posted on June 21, 2009 by Nathan Drier 2 Comments

DoS, or Denial of Service attacks, are nothing new. The main idea behind a DoS attack is to exhaust a devices resources (be it HTTP, some database backend, or any other form of ‘service’) until it can’t respond to legitimate requests anymore. Typically, this is done from an application or link-saturation aspect, although it can be much more than that. Taking a sledgehammer to the A/C unit that serves a data center is pretty messy – but technically it is still a DoS attack.

The most popular form of DoS (i.e. the ones you read about in the paper) is link saturation. The plan is to send a massive amount of requests to a server, much more than it normally receives, in order to saturate either the server or its link. This requires LOTS of computers – usually sent from a botnet of some sort. When Amazon got hit with a DoS attack back in 2000, they had this to say about the amount of traffic:

“We had 800M bit/sec hit the site, which equals eight times our capacity. On average, our site runs at only 30% capacity, which gives you an idea of how unprecedented this traffic hit was.”

That is a downright amazing amount of traffic. To sustain that type of a DoS attack, you would need your own botnet. You would need thousands and thousands of computers on fast connections. The computers would have to be spread across the internet so they didn’t saturate the connection to the target site. This would have to be a huge, collaborative effort in the works for weeks. Recently, a new method of DoS-ing Apache HTTP servers has emerged that can take down a site with as little as 11.6Kb/s worth of traffic. That’s slow enough to be launched from a dial-up connection.

The idea has been around for a while, but just recently a tool has been developed to launch the attack. The tool works by exhausting Apache processes. Apache comes configured to only allow a certain number of processes (default install is 256) and not answer any more requests when that limit is hit. What this tool does is send the first part of a request header. While Apache waits for the rest of the header, one of those 256 processes it taken up. The tool, Slowloris, will send the partial header to the web server a few hundred times to hog the connection pool. By default, Apache will wait up to 5 minutes for those connections to complete. Once the tool has taken up all the available connections – the Apache server will not serve any new requests.

Lets dig in. Here, I ran the tool against a test web server:

acm@stash:~$ perl slowloris.pl -dns webdev

Welcome to Slowloris – the low bandwidth, yet greedy and poisonous HTTP client

Defaulting to port 80.
Defaulting to a 5 second tcp connection timeout.
Defaulting to a 100 second re-try timeout.
Defaulting to 1000 connections.
Multithreading enabled.
Connecting to webdev:80 every 100 seconds with 1000 sockets:
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Building sockets.
Sending data.
Current stats: Slowloris has now sent 658 packets successfully.
This thread now sleeping for 100 seconds…

Sending data.
Current stats: Slowloris has now sent 1059 packets successfully.
This thread now sleeping for 100 seconds…

Sending data.
Current stats: Slowloris has now sent 1283 packets successfully.
This thread now sleeping for 100 seconds…

As you can see, the tool makes 1000 requests every 100 seconds, more than enough to saturate our default Apache settings of 256 connections every 5 minutes. While this tool is running, the Apache server is completely unresponsive to any new requests. If someone is already at the site when this attack is launched, their connection will stay active until they request a new process. At this point, its a race condition between a legitimate browsing session and the Slowloris tool, one that Slowloris will always eventually win.

Another interesting point is that this type of attack doesn’t create any errors in the logs until the attack is over. Since the connections never complete – Apache never writes any of it to its logs. Once the attack is over, multiple 404 errors will pop up – but its a little too late at that point. First, I saw this in Apache’s error logs:

[error] server reached MaxClients setting, consider raising the MaxClients setting

This shows us that Slowloris was able to hog all the connections to the Apache server. Then, we see hundreds of these entries in access.log:

[error] [client 10.0.0.45] request failed: error reading the headers
[error] [client 10.0.0.45] request failed: error reading the headers
[error] [client 10.0.0.45] request failed: error reading the headers
[error] [client 10.0.0.45] request failed: error reading the headers
[error] [client 10.0.0.45] request failed: error reading the headers
[error] [client 10.0.0.45] request failed: error reading the headers
[error] [client 10.0.0.45] request failed: error reading the headers

This happens because Apache only got the first part of the request headers, and never saw the complete header. The following is all the 404 errors the tool generates:

“GET / HTTP/1.1″ 400 351 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)”
“GET / HTTP/1.1″ 400 351 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)”
“GET / HTTP/1.1″ 400 351 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)”
“GET / HTTP/1.1″ 400 351 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)”

This all happens well into the attack. It looks like you could keep a server down for quite a while before connections get reset and Apache writes anything to the logs.

I’ve seen some discussion about changing the connection timeouts on Apache from 300 seconds (our default 5 minutes) to something a little quicker – like 10 seconds. This way, Slowloris can only hog a connection for 10 seconds until it resets. Even so, limiting the timeouts to 10 seconds does little to stop the attack. Anyone with an average speed cable connection could still DoS a vulnerable Apache site. I’ve seen reports that with Apache timeouts set as low as 5 seconds, it still only takes less than 50kb/s of traffic to bring a site down.

If you have a good baseline on your web servers and know the limits of expected traffic – there is a quick and dirty fix for this. This fix assumes that the attack comes from the same source-ip. The following iptables rule limits the amount of connections from the same source to 20 connections.

iptables -A INPUT -p tcp –dport 80 -m connlimit –connlimit-above 20 -j REJECT –reject-with tcp-reset

With this in place, Slowloris can only take up 20 connections per source ip, leaving the other connections open for legitimate users. Now we see Slowloris only sends 35 packets to the web server vs the ~1000 it could do before:

Building sockets.
Sending data.
Current stats: Slowloris has now sent 35 packets successfully.
This thread now sleeping for 100 seconds…

While this is in no way a long-term fix, it takes the edge of a little. I’ve also heard of people having success with mod_limitipconn, mod_evasive and accf_http, so they might be worth investigating as well. Good Luck!

Information Security : Tracking Spam Origins

Posted on June 20, 2009 by Nathan Drier in Main | Leave a comment

Here is an interesting article on tracking down the source of spam:

It is very normal that more than 1/3rd of the domain names we see each day in spam messages come from China. When one also considers the many “.com” and “.ru” domain names which are also hosted in China, the problem is much worse. More than half of all spam either uses domain names registered in China, is sent from computers in China, or uses computer in China to host their web pages. The numbers above look much higher than half, but these are numbers about spam DOMAINS, not the actual number of spam messages. Some non-CN domains send a disproportionately high number of messages.

Honeytokens

Posted on June 16, 2009 by Nathan Drier in Main | Leave a comment

database

I’ve been thinking about honeytokens a lot lately. While I’ve always been fascinated by honeypots, honeytokens are a little different spin on the same idea. A honeypot usually functions as a machine or device just begging to get hacked. It usually emulates a machine that is missing a few patches and is very poorly configured. It can even be packed with services and data to make it look like a goldmine of sensitive information. The only catch is: none of it is real. All the information is fake, and the machine is usually very well segmented from any other critical devices. The whole idea is to attract a hacker to the honeypot, then keep them there long enough to alert the security team / trigger the IDS / call the police / blacklist them.

Whats different about honeytokens is that instead of emulating machines or devices, they emulate sensitive data. Their primary function is to identify the misuse of data or the failing of internal policies. In that sense, honeytokens are much easier to setup and monitor than its pot-derived brother. A good example of a honeytoken is as follows:

Steve works for Big Bank. While he is generally happy with his job, he feels underpaid and had always been curious about what his peers make. While doing some troubleshooting on one of the database servers, he notices a database named companySalaries. He checks over his shoulder, selects the database and tries to view its contents. It throws out a generic error, he shrugs it off and continues his work.

The database record named companySalaries doesn’t contain any real data at all. Its sole purpose is to alert a group of people when it is accessed. In normal operations, Steve has never been authorized to access this database – so triggering the alerts means something fishy is going on. In this case, Steve’s curiosity got the best of him, and most likely violated all sorts of internal privacy policies.

Their use doesn’t stop at salary information. They can be used in emails, databases, Intranet pages, customer records, medical patient information, financial details, core applications, and anything else you can think of. They can emulate the presence of all sorts of data, from Social Security numbers to credit card numbers, and from sensitive office documents to insider corporate information. They are very flexible, and can be integrated into any situation that has you worried about its confidentiality.

The legal ramifications around implementing something like this can be a little muddy. Do yourself a favor and chat up some legal assistance and make sure your Acceptable Use Policy is airtight before rolling out your domain-wide honeytoken install. Much like a honeypot, honeytokens are no replacement for proactive network security. Be sure you have the fundamentals of network security in place before you start stashing these honey-soaked easter eggs all around your network.

Mozilla Collections

Posted on June 14, 2009 by Nathan Drier Leave a comment

If you are anything like us, you can spend hours tracking down Firefox add-ons. Recently, Mozilla announced the release of ‘Collections‘, which allows you to create and store all of your favorite add-ons and customizations in one central place. If you need your add-ons installed in a new browser – just visit your Mozilla Collections account and one click will re-install all your plugins. In true Redspin spirit, I’ve made a Collections account chock full of add-ons that we use for the security testing of web-servers. Some of the add-ons included: