ClearNet Security

Microsoft may scan you

tate@ClearNetSec.com (tate) — Sun, 31 Jan 2010 11:43:00 -0700

A client this month was observing strange FORM submittal activity and asked if I was still doing security testing of their web application.

Since I was not, I participated in investigating. I received a copy of their Apache log file.

I downloaded apache-scalp:

“Scalp! is a log analyzer for the Apache web server that aims to look for security problems. The main idea is to look through huge log files and extract the possible attacks that have been sent through HTTP/GET”

From viewing the output of Scalp! it was obvious an automated application scanner was being used. Three bits struck my curiosity:

The scanner was one I hadn’t heard of: netsparker
Netsparker is commercial, implying someone was willing to pay money to find vulnerabilities
The source of the scans was Microsoft

My client was dumbfounded why MS was doing this. I suggested they send an email to abuse@microsoft.com with the details and request their assistance.

Lo and behold, Microsoft replied and was responsible. Their Online Services Security and Compliance (OSSC) team was actively scanning, unbeknownst to my client .

Given this client has a relationship with MS, my guess is they signed something with fine print explicitly allowing MS to perform ad-hoc vulnerability assessments.

Good to know this can happen.

recap of a scope call

tate@ClearNetSec.com (tate) — Wed, 30 Dec 2009 15:30:00 -0700

It’s been some time, but I just had one those scope calls from out of left field. University, mid size, private, budget sensitive, one security engineer and he is relatively new.

He is unsure of the state of his domain.

Me: Have any security assessments ever been performed?
Client: No.
Me: pause Do you trust the integrity of your servers?
Client: No.
Me: pause You are processing credit cards?
Client: Yes.

Calls like this one ensue brain freeze in me. I get so hung up on them I mumble for a bit until I catch a clear thought.

On cue, this question soon followed: “I was thinking of starting with vulnerability assessments, but where do you recommend I start?”

Is this not a scenario security aficionados are to love?

I dread them now. I’m being tasked with teaching everything a functioning adult is to know on a phone call. Don’t get me wrong, I do love the flood of ideas this scenario stimulates, but I’m weary of working for clients so far behind in the game. My experience with like clients is they come to the play with little budget, support, and with even fewer resources.

But in the spirit of the holidays, I’m going to draft a list of tasks I’d recommend he do and I’ll share it here.

need to do a GET before POST, fuzzing with BURP and WebScarab

tate@ClearNetSec.com (tate) — Thu, 19 Nov 2009 16:16:00 -0700

A recent web application I was testing was generating a unique hidden token on every render of the login page (revealed in the pink section in the screenshot below by WebScarab).

I had setup a BURP intruder run to iterate through a list of attack strings when I noticed a few of the responses contained a message displaying “unable to verify session”.

That is when I checked for a hidden value, and when discovered, guessed it was a dynamic key identifying each individual form submit.

The fuzzers in WebScarab and BURP typically work by repeatedly POSTing to a web form, like the login form above, then capturing and/or analyzing each response. Commercial scanners do the same. Repeatedly POSTing fails to work in this case.

Screenshot showing BURP’s intruder and that I want to run a sniper attack (i.e. send one attack string at this position (red text below) per POST request).

Screenshot showing a few custom attack strings loaded into BURP

Screenshot showing the execution and results of an intruder attack (i.e. looping through the attack string list and submitting each via a POST request)

Screenshot showing WebScarab’s fuzzer setup.

The problem in this scenario is the hidden token is only good for one POST request. Maybe I missed it, but I didn’t see an easy way to tell WebScarab’s fuzzer or BURP’s intruder to first perform a GET request (so I can capture a valid one time token value) then submit a POST request.

A few lines of Ruby along with the Mechanize library made for a simple work-around.

#!/usr/bin/ruby
require 'rubygems'
require 'mechanize'

agent = WWW::Mechanize.new
agent.set_proxy('localhost', '8008')

File.open("fuzzlist.txt") do |file|
  file.each_line {|fuzz_string| 
    agent.get('http://target/signin') do |page|
      form = page.forms.first 
      form.field_with(:name => 'data[user][email]').value = fuzz_string
      form.field_with(:name => 'data[user][password]').value = fuzz_string
      form.click_button
    end
  }
end

I configured mechanize to use my preferred proxy (BURP). The script loops through the fuzzlist.txt file, performs a GET request (now we have a valid token), then submits the form. Problem solved.

Signing things

ian@ClearNetSec.com (Ian S. Nelson) — Wed, 07 Oct 2009 00:48:00 -0600

I just saw that Thawte is ending their Web of Trust email keys program. I think they should have sold directory services in addition to providing keys, perhaps I'll write about that next. It got me thinking about SSL/TLS. I've always felt that the openssl program does a lot more than most people know to do with it.

For example:

openssl dst -sha1 yourfile

is about 20% faster than "sha1sum yourfile" on my OpenSuse 10.1 AMD Opteron system. That might not be terribly interesting but 20% adds up on bigger files, like DVD images.

Another thing is in this world of automatic updates and appstores, it's more important than ever to have a verification mechanism in place. OpenSSL provide all of the tools for some simple, yet strong, verification. A lot of people I know are confused by certificates and don't fully understand the different formats and what you can do with them but OpenSSL provides the raw basics to simply perform signing and verification.

Generate a 2048bit RSA key:

openssl genrsa -out rsapriv.pem 2048

Extract the public portion:

openssl rsa -in rsapriv.pem -pubout -out rsapub.pem

Sign a file and store the signature in testsig.bin:

openssl sha1 -sign rsapriv.pem -out testsig.bin yourfile

To verify:

openssl sha1 -verify rsapub.pem -signature testsig.bin yourfile

There you go, signing and verification without any of the "complicated" PKCS stuff. It's only marginally more work to actually add a CA to the mix.

Man vs. web app

tate@ClearNetSec.com (tate) — Sat, 22 Aug 2009 16:59:00 -0600

For me, it’s hard to downplay my joy from successfully assailing a web application and finding valuable faults: more so when nothing of value is reported from scanning using the most expensive app scanners.

On a recent gig I was focusing on finding issues with a couple of forms. Wielding BURP, I was intercepting all the GETs and POSTs and noticed the server responding with JSON data (i.e. http://[…]/data.json)

I tossed the JSON blob into an online JSON validator (http://www.jsonlint.com/) to make it easier to read (below is a small snippet).

"sanitized": 
  { “aaaDetail": 
    { "aa_id": "276060", 
      "bb_id": "103065", 
      "cc_id": "515ad8933c821b2f72a8cbb7054zed3c", 
      "x_time": "2009-08-12 21:42:40",
      "y_time": "2009-08-12 21:47:34",
      "full_name": "T H", 
      "comment": null, 
      "country": "United States", 
      "state": "Colorado",
       "city": "Broomfield"
       [...]
     }
  }

I soon realized the JSON objects contained great information for crafting precision attacks.

The JSON data reads like they are database column values. I wondered for a moment what would happen if I just use the strings in the JSON objects for POST keys, came up with logical values matching the keys, then started POSTing the modified form data.

Bingo. By simply intercepting POST requests and appending new key/value pairs to the list of key/value pairs already being submitted I was able to modify database values unattended by the developers. In this case, it meant I was able to modify information inserted and owned by other users of the site.

I’m not espousing Harry Potter skills here, rather illustrating one of many examples of why Man is needed to go beyond where automated web app scanners stop.

keep passphrases ‘in the mind’

tate@ClearNetSec.com (tate) — Mon, 03 Aug 2009 06:13:00 -0600

I’ve always heard from friends that a court could compel a person to divulge a passphrase to get to their encrypted information.

I learned that is not exactly true while attending Tyler Pitchford’s presentation at Defcon 17.

Encryption keys are products of the mind and are protected by the Fifth Amendment.

The case from which these assertions are derived is United States v. Boucher. Sebastien may have to give up his passphrase in the end because he made a terrible decision in the beginning by consenting to talk.

Never talk. Never. If you haven’t already, watch this video presentation by Professor James Duane titled Don’t Talk to the Police to learn all about why.

Why I am proud to admit that I will never talk to any police officer. In Praise of the Fifth Amendment Right to Not Be a Witness Against Yourself.

tech notes on vSwitches and layer 2 attacks

tate@ClearNetSec.com (tate) — Thu, 23 Jul 2009 09:47:00 -0600

I recently completed a pen test from the sole position of possessing remote administrative privileges to a few guest VMs.

I fired up yersinia to learn if launching layer 2 attacks could disrupt normal operations. While doing that I grabbed a copy of this book:
VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment

vSwitches are reportedly immune to layer 2 attacks.

"Currently, a vSwitch will protect you from the following types of attacks by not providing the underlying functionality that these attacks require."

MAC Flooding
Double Encapsulation attacks (multiple 801.q envelopes)
Multicast Brute Force Attacks
Spanning Tree Attacks
Random Frame Attacks
DTP/VTP

I was able to perform MiTM via ARP cache poisoning on other visible guest VMs sharing the same network segment (because the attack targets the guest VM and not the vSwitch) – but in this case, each segment was allocated to a unique customer and therefore not a valuable test (i.e. poisoning one’s self was not in scope).

You can configure VMware to further limit attacks within a broadcast domain:

Security | Promiscuous Mode (default is to reject) : Reject
Security | MAC Address Changes (default is to accept): Reject
Security | Forged Transmits (allow outbound frame w/a source MAC that is different) (default is to accept) : Reject

Best to skip the pen test gigs with too short of attack windows

tate@ClearNetSec.com (tate) — Thu, 02 Jul 2009 16:27:00 -0600

I just completed an external pen test whereby the rules of engagement limited the scan windows to two hours per night. Requests for longer were rejected.

I hadn’t run within this tight of windows in some time and now I remember why I hate it so much.

I spent more time jacking any and every configuration setting I could tweak to boost each tool for balls out speed and baby-sitting (because failing seems to be a popular thing to do if you’re a tool sprinting at 50 threads and spending 0ms between requests) that I didn’t get nearly the time I wanted to concentrate on what I was paid to do: bust in.

As a case in point I was working a SQLi point that was allowing me to download their entire database, alas, I only ever retrieved four of the 200+ tables during any one window. Worse is I spun my wheels for several critical hours exerting fervent trial and error effort tweaking tool options, largely in vain, in hopes of making things go faster. The consequence was tool tweaking dominated my attention. Creativity, the force summoned for powersploiting, remained unconscious.

Staffing and teams

ian@ClearNetSec.com (Ian S. Nelson) — Tue, 30 Jun 2009 04:28:00 -0600

I was listening to a podcast on Agile Staffing last week and they succinctly stated a couple things everyone sort of knows but doesn't say that often.

On small startup type teams, the team is everything, a bad team member can kill the product and the company.
On particularly agile teams, having agile people is better than having technology experts.

The first point is really clear, be it the leadership of the team or contributors to the team, if any one piece is broken then the whole thing won't work well. The second point is something I think people tend to dismiss, people like to list desired skills in job descriptions more so than desired attitudes and in an interview it's far more likely you'll be asked to write some code or explain some sort of process than you will be given a personality profile. One pattern that I've seen at a number of companies I've worked at is that new people will be some how challenged and asked to do some heroic amount of work and the company sort of over reaches. After that challenge project is done the team never fully recovers, the team is skeptical of everything and doesn't want to work that hard again. All future projects are exercises in work reduction, not so much in product improvement. The team is reluctant to do anything like the challenge again. You end up with something that's fundamentally not repeatable. Even if you end up with a great result, the team is fried and you can't follow it up. Another pattern I've seen is the so called "analysis paralysis." The desire to find a singular, "perfect," solution to a problem outweighs the desire to do anything else. Rather than attempting to fix problems or "solve the problem multiple times," or put "band-aids" on problems there is a desire to wait until an ultimate solution is created, which is usually never. With the problem, there are usually some fairly easy things that can be done to make some sort of incremental improvements along the way. Back to that second point, there are personality traits that help you find people that help you break those patterns. There are people that are willing to iterate on solutions and try to repeat success and those are the people you want to put on teams. Now this is all software talk but does it apply to security and network teams? Is a security policy something that has to be iterated on and changed over time or is there a "perfect" solution that can be reached? You can have the best security guys in the world working for you but if you've overextended them do they still actually work?

Defending data? Incentivize.

tate@ClearNetSec.com (tate) — Sun, 31 May 2009 06:41:00 -0600

Defending boils down to skill and incentive.

Tools that provide visibility are required, but that’s another topic. Skill is also an obvious requisite.

How about incentives? What incentives are in place for security engineers to really dig in and be great defenders?

Tier one engineers working out of traditional MSSPs are paid in the $20 per hour range or lower and by the nature of their position they have minimal understanding of anything of substance about their clients’ networks.

Opposite that, I know a very talented group of engineers working at an expensive outsourced IT/software company whom are responsible for their company’s top paying customers. They breathe uptime. Heads roll and the company loses money when downtime occurs. Security is barely an afterthought. Lest they do see a security issue, they may skip notifying for why create more support tickets and work.

It doesn’t make sense to punish defenders for failing to prevent infiltration – that is to be expected today. Simply detecting one is a great accomplishment.

To move defenders to be great defenders, reward them for detecting infiltrations.

I think it would be great for company’s to hire an outside party to perform unauthorized activity at an increasing pace and breadth until someone responsible for monitoring sounds the alarm. Reward those who discovered the activity. Do it frequently. Change it up. Make a competition out of it. No doubt this would help weed out bad performers, be they internal or external.

This is very similar to what I’ve seen a few hospitals implement. If an employee stops and challenges a person without a badge then they receive a $100 bonus.

I’m not promoting pen. testing here, though it’s a good example of a challenge. I think simple and frequent small scale tests tied to rewards would work wonders for many security groups and for the company’s wanting to keep their assets protected.