ClearNet Security

I'm going through my notes from the conferences and here is my beginning list of tools to checkout (some new):

• MatriXay:  web app and db pen-test tool (in beta, not free, not sure of cost, but it looked interesting)
• PDB:  protocol debugger (free)
• tattoo: traffic analysis toolkit (free)
• Suru:  mitm proxy and web app fuzzer (not free, but cheap - $200)
• Crowbar:  web brute force tool (free)
• SP_LR (can't find a link yet): proxy framework targeted for malware analysis and fuzzing    

If you want to bump up your exploit writing skills – Saumil Udayan Shah is an excellent teacher.  His style of teaching brought out memories of my time as an ECE student at CU, Boulder.  He presented very clearly, kept the pace moving, and quipped often.  Great class.

The majority of time is spent on using GDB and WinDBG to inspect Intel 32-bit x86 CPU registers for opportunities.  The end game was always accompanied by netcat and metasploit (along with a decent amount of scripting to facilitate quick retries when trying to line up all the exploit code to ensure success). 

Here is the full class description:  http://www.blackhat.com/html/bh-usa-06/train-bh-us-06-ss-el.html

I don’t want to repeat what everyone else is writing about regarding attending BlackHat and Defcon, but several were freakin’ cool:

• Joanna Rutkowka’s Blue Pill stuff. Totally own x64 Vista on AMD (Pacifica) using the new AMD processors virtual machine technology. Undetectable. “Writing signatures to detect things is rookie” -- an awesome quote by Joanna.


• johnny cache and David Maynor’s layer 2 exploit. Get remote shell root access to a Mac, Windows, or whatever if the wireless card is simply ON (no need to associate or anything). Damn I would love to have this exploit on hand.


• HD Moore’s talks:
  • Thermoptic Camoflauge: IDS and IPSes suck for lots of reasons. Signature based IDS and IPS systems really suck. Joanna’s quote from above kind of says it all, “rookie”. With the new metasploit, you’ll be able to evade anything and everything on the market.
  
  
  • Six Degree of XSSploitation: Cross site scripting is freakin’ dangerous. Douse with lots of browser vulns, and well, it’s getting ridiculous to have fun on the Internet. Nothing is safe, so unplug.
  
  
  • Metasploit Reloaded. The metasploit story is just getting better – it is the best framework to build exploits. The 3.0 version is being completely rewritten in Ruby so that is good for us.
  
  
• Jeremiah Grossman’s Hacking Intranet Websites from the Outside. I haven’t seen this before – using JavaScript to serendipitously enumerate internal IP addresses, perform port scans, retrieve portions of the user’s browser history via checking CSS values, and even login and modify the DMZ rules in home DSL routers to allow external connections to a particular ‘live’ internal device. All done without exploiting anything – just using plain valid JavaScript.

I've been setting up  SELinux from scratch for a machine lately.   Here is the quick and dirty way to let an application run that doesn't have permissions.

 

Copy the log messages for the blocked application to a file, say tomcatlog.msg which looks something like this:

avc:  denied  { ioctl } for  pid=6256 comm="su" name="tomcat.log" dev=tmpfs ino=23418 scontext=system_u:system_r:initrc_su_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file 

 

run audit2allow which compiles the log message in to an selinux package:

 

audit2allow -M tomcatlog < ./tomcatlog.msg

 

Then load the new selinux package into selinux with semodule:

 

sudo /usr/sbin/semodule -i tomcatlog.pp 

 

 

I don't recommend building a whole system this way but after beating on it for a while this is just a really easy way to allow something to run. 

technorati tags: linux, selinux

OK so I guess I have touched a nerve with this subject as our traffic to our blog has spiked since Richard Bejtlich's blog linked to my "VA and Bureaucracy" post. As one to not let a good story go to waste I will finish the story in 2 more parts before I leave for BlackHat 2006.

As you remember from my previous post on the subject Tate and I were part of a large team of people contracted to go audit the VA computer networks and systems at every VA facility in the country. We had thought that we would be working with other individuals of our technical caliber on a comprehensive audit process that follows along with the NIST SP 800 series of documents. As we flew from Colorado to Virginia we had some expectations of this project that were brutally shattered in the coming days.

Before the trip our expertise had been doing security in the corporate space, i.e. a company would hire us to conduct a penetration test or a vulnerability assessment, etc. The government space with its money capital and processes at its disposal must be better, at least in my mind. However, it quickly became apparent that what we were really tasked to do at the VA would get us fired at any of our other private corporate space clients for negligence. One note about the ethics of what we could do in this particular situation. Two things:

• First is that in the initial meetings with VA respresentatives there was spirited push back on the VA and contract companies that this whole thing was just not right. In fact I think that many people just gave up after the introductory meetings because no one was listening.
• Second is that we stayed on the project at this point mostly because we just couldn't forsee that it could be as bad as it turned out to be. We were always looking for the gotcha that would dispel the myth and make the project make sense.

And on with the story...

So Tate and I were flabbergasted at the first meeting with the VA but we were at least optimistic on what the next day would hold as we were being trained on the specific audit procedures for each technical area we would be qualified to test in. The technical areas we were going to test were Windows, network, and policy. So the next day bright and early we had to report to the main office of the chief company controlling all the audit teams.

First up for us was Windows testing. We had a lot of ideas of what we would want to hear, like which scanners were going to be run, what tools to follow up results with and what kind of forensic analysis would happen if a computer was exploited, infected, or warez'ed. Well basically a checklist was handed out and a so-called “trainer” read through the procedure. It went something like this:

• Write down info about computer like name, room location, date, OS installed.
• Run MBSA.
• Dump Registry.
• Dump users and groups
• Dump logs if any are even there
• Take a screenshot of the screensaver properties

Gee that sure is comprehensive huh? At least it is super expensive so it must be good. Basically our job as high paid and trained security professionals was to dictate step-by-step procedures (click here, click there, click save-as, etc.) to a VA employee while shoulder surfing. Then after they completed a step we would check it off along with the time it took to run it. The hardest part would be to get the room number and address of the computer we were on as a lot of the VA facilities did not label every room.

Right after our "training" a person asked how many computers we would have to do this to at each facility. The answer was a sampling and possibly all the Windows Servers. Later on at my first facility I went to I tested 10 computers at a VA facility that was about a ~1000 computer facility. I will tell more detail on this in my next entry.

Then another person in the room brought up scripting, "Hey you could write a script that could be run on logon or log off to grab these results from every computer in the facility"

The trainer replied "Scripting is not allowed because it is too dangerous; it could bring down a critical computer"

"OK then why not just leave the critical computers out and do those by hand and leave the non-critical computers in the script"

"No. No scripting can be done as was agreed earlier."

That was the end of that. No scripting because it is too dangerous. The network training was basically the same thing but added in that architecture was not to be looked at. For example if a facility left their network on the Internet with no firewall, it was not to be noted. Just stay to the checklist, don’t look left or right.

At this point we were seriously considering dropping off the project but we decided to give it a shot and remain open-minded. But I can tell you it was hard. I mean if I saw by happenstance (and I am not saying I did) that a computer was running a warez site, if it wasn't caught by the checklist then according to the VA’s audit procedures, it was OK. Again concerns were raised to the company we were contracted under and I believe they had sent it up the ladder but I never heard anything. The checklists were even revised multiple times because many people still had a hard time following it step by step, but the revisions they made never really meant much with respect to security.

In the next part I will talk about my first experience at a VA facility - as a screenshot properties collector, err I mean security auditor.

I’ve involuntarily joined the club of stolen personal account information.  I received a letter from my student loan holder:

[…]
"We are writing to inform you that a computer tape containing personal account information about your current or former student loan was apparently lost while in the possession of United Parcel Service (UPS)." 
[…]
"This situation arose during the routine shipment of a data tape which contained borrower names, Social Security numbers, and other related account information. "
[…]

I’m excited to hit BlackHat this year; we’re in for the full week.  BlackHat Training, then Briefings, followed by DEFCON. 

I’m back to writing.  I took a hiatus to deal with a heart issue (I’m recovering from a short Hospital stay).  Thanks to a fantastic doctor in Boulder, Dr. Oza, we caught an electrical condition in my heart that was potentially fatal; particularly to my case when I engaged in hard cardio activities (playing hockey triggered the worst symptoms).  Anyway, back to work, to enjoying life, and hopefully in the near future to juking opponents.

Fab is an interesting book by Neil Gershenfeld.   It chronicles a class Neil designed and taught at MIT called "How to build just about anything"  and then some "field experiments" where they take some industrial fabrication equipment, make some easy to use software and deploy it to various communities around the world.   Very similar to Hole in the Wall.  

It's an easy read that you'll blaze through.   The basic idea is that if you give people tools to build stuff, they will build stuff and in general in the world, that ability to fabricate tools and various other artifacts is probably a lot more important than something like internet access or DRM.  Further, the people who want to build things aren't always the people you think as Neil's class was filled with non-engineers.  I'm not sure the MIT campus is a good sampling of the public though.

To be fair and critical though.  A lot of the work is kind of swept aside.  Giving someone a sign cutter gives them a tool to produce circuit boards but actually building a useful set of circuits and debugging them is a different kind of problem.  Maybe I'm a bit pessamistic, having seen the industry work and done my part to debug custom hardware in the past. 

It's still an interesting read and an optimistic one.  I couldn't help but think Neil swept a lot of the complexity and difficulty away as he wrote it to make it look easier than it is but I also kind of wanted to have access to one of his "fab labs" to play around with stuff.

technorati tags: book, fabrication, fab, gershenfeld,

So it has been awhile since I blogged. Sorry! So anyways I have been following the security breach that happened to the Veterans Affairs (VA) with interest. For those of that do not know, basically a VA worker had been taking veterans data like SSN and name etc, home so that he could work on his project from home. What happened was his laptop with USB drive got stolen from his house and the VA data went with it. No one knows what if anything happened to the data but it does leave millions of veterans open to identity theft. More info here.

This is near and dear to my heart as it was one of the first projects that Tate and I worked on. The project was at the time the largest Certification and Accreditation (C&A) process for the federal government was happening at the VA. Tate and I jumped onto a contract with a company that had head count and we were off to Virginia for training. Now for those of you that do not know, the C&A process is very large and detailed. It is created and kept by the National Institute of Science and Technology (NIST) and is the process all federal agencies need to follow to be compliant. The documents themselves are actually really well written and freely available. Basically the C&A process is summed up as this: develop a policy, test against it, determine risk points, and then remediation plans. The certification part is where the auditors, audit against the policy and the standards set by the C&A documents. The accreditation part is where the big hunchos of the agency either accept the risk and keep their IT going or stop it until the risk is remediated. This process was what we were "thinking" we were getting into. At this point we did not have C&A experience so this was worth it for us.

Ok.... so we get to Virginia and start what we thought was going to be some hard security work. In fact the company we were working under thought that our skill sets might not be up to par enough.... We had to go to a meeting with all the auditors and the VA staff where they were going to let us in on the work involved and this is where we had our first exasperating moment on this project. The main person involved on the VA side stands up and tells us this is the biggest C&A process ever and blah, blah......Oh yeah, no one other than VA personnel is able to touch ANY computer either physically or virtually! Wait a sec! I still remember the whole crowd of 200 or so auditors all collectively looking around and I think some people in the back row made a run for it at this point. Everyone was thinking exactly what you are thinking at this moment, how can you test "technical controls" without actually testing... Well they came up with the answer, which was to pair us up with our very own set of VA hands, still attached to a VA employee at each site we visit. Yup, now instead of us actually typing and testing a computer we were supposed to relay commands to a VA staff person and they would type it in! Sweet, I can give my carpal tunnel a rest and set my jaw wagging. I can just see it now, "Oh look, it looks like this computer has some malware. Click here, load this tool, select this hex field and check the registry....NO NOT THAT KEY! Run!"

Right about this time the second bomb shell went off.... The guy up front promptly says that all test results we collect are to be given to the VA. This makes sense as it is their computers and they are entitled to our analyzed results right? Wrong! The guy corrects himself and says that the results are not to be analyzed by the auditors but by VA personnel. Hmm...so at this point I am not touching a computer nor am I analyzing the results for risk or what is wrong. Something seems very broken about this process at this point.

In the next part I will explain the next day and our first site experience. In reading this I am sure you are now not surprised to hear about data breaches and lameness on the part of the VA. After all they pretty much subverted the C&A process to insure they pass.

I just completed The World is Flat: A Brief History of the 21th Century by Thomas L. Friedman.   

Quite a fascinating read, it reads very quickly.  Friedman is great columnist, one of the ones I regularly read and in this quick read he breaks down globalism, consumerism,  technology, insourcing and outsourcing very nicely.  It's not an academic work and it's not journalism either but Friedman's style tends to be somewhat (at least as I read it) fair in his treatment of the issues.   For example he talks about the good things and the bad things Walmart does and he doesn't come across as if he has a strong stance one way or the other, he simply presents some things and the various good and bad sides; so long as you see globalization as something that is happening rather than something we might stop or do away with.  If you're a protectionist you might disagree with the whole thing..  

I like the allusion,  leveling the playing field in a grand scale is really flattening the world.   It's definitely a worth while read if you conduct business in today's world.
 

So this is totally skag,  knocking off someone else but I was pleasantly surprised.

Do this, with GNU Grep:

export LESS=-R

export echo $GREP_OPTIONS=-i --with-filename --color=always

 The -i and --with-filename might screw some scripts up but I'm sick of typing them.

 

technorati tags: gnu, grep, options, color

Jeremiah Grossman wrote an article titled: "Technology alone cannot defeat Web application attacks: Understanding technical vs. logical vulnerabilities" (requires registration). I pulled a couple sections out which explain why automated scanners can not find 'logical' vulnerabilities (hence, capture < 50% of the potential vulnerabilities present):

[...]

"This has made the automated process of finding simple vulnerabilities hard -- and finding difficult ones impossible.

Consider the following example. If we visit a Web site and are presented with the following URL:
http://example/order.asp?item=50&price=300.00

Can we guess what the application order.asp combined with the parameters item and price do? Using intelligence unique to humans, we can quickly deduce their purpose with relative certainty. This is a product ordering application. The item parameter is the particular product we are interested in. In our case, let's say an iPod. The price parameter is the amount we are going to pay for our portable music player. What happens if we changed the price of 300.00 to 100.00? Or 1.00? Does the Web site still sell us the iPod? If so, we can easily understand that the Web site should not have allowed the price alteration. As humans, we possess a natural ability to assess context, and we aptly refer to these types of issues as "logical vulnerabilities," issues that only humans can identify.

Now, if an automated scanner attempted the very same attack in a generic fashion, how would it decide if a custom Web site's response was good or bad? How would it know if the attack worked or was adequately defended? Or what the item and price parameters were supposed to do in the first place? The answer is clear: Scanners cannot reliably make these assumptions."

[...]

"Scanners are great at tackling technical vulnerabilities such as cross-site scripting and SQL injection, and not effective at identifying price list modification, credential/session prediction, insufficient authorization, and other logical vulnerabilities.

It would be nice to fully categorize which vulnerabilities (or classes of vulnerabilities) can be checked for via automated tests and which only a human can check.

A recent thread found on web app security reveals some insights regarding web app scanners.  It is really more of the same (i.e. they suck with out lots of manual help), but this thread includes vendor opinions.  It kicked off when Dr. Holger Peine published a comparison report on web app security scanners which triggered some defensive posts.  I care less about the defensive posturing, but what is interesting to read is the post by Ory Segal on how to properly configure AppScan.  It’s another notch on why these tools are not just ‘click and go’ tools.  You need some level of prior knowledge of the app you’re going to scan in order to configure whatever tool for maximum accuracy. 

Even if you scan with “optimal” settings (i.e. fully customized) you’re likely missing lots of true vulnerabilities.  From Jeremiah Grossman (develops web app scanning tools):

“In my experience, scanners can only reliably TEST for about half of the possible vulnerabilities in a website.”

So, to state the obvious, lots of manual work is required.  I agree with Jeremiah’s other statements:

“These observations have brought us to the following conclusions:

1. Scanners find vulnerabilities and save time.
2. Experienced security engineers must find the “logical flaws”

Only by combining the two is it possible to achieve comprehensiveness and due diligence.”

However, comprehensiveness for me would include code analysis.  I’m taking his statement out of context a little, but it would be the only way to capture certain risks.  Say for example, a developer was testing a piece of code or had setup a backdoor for whatever reason.  A ror example:

if @params[:post][:login] == “letMeIn”
  flash[:notice] = “Superuser login successful”
  redirect_to :controller => “admin”, :action => “setup”
end

Superuser privileges.  Automated web app scanners will always fail to capture things like above.  It’s possible some brute force tool or fuzzer tool may get lucky and discover a backdoor like above, but this is a simple contrived example. Another post asserts:

"I remember I encountered one case in which the session id is sequential; the scanner did not even pick up such an obvious flaw. In another case, after user login, the user id is embedded as a hidden value and used to authenticate the user. And the scanner failed to pick this up again."

Martin O'Neal summarized it well:

Automated tools are essential for making the assessment process achievable in a reasonable period of time, and are an important part of the process, however (and it is a big however) they should never be seen as being "the process" in themselves.

I had a conversation with a law enforcement friend the other day and I learned of two trends I wasn't aware of: one is the increasing number of people sending threats via email and two, the number of people installing key loggers illegally. He mentioned many of the key logger cases are couples in the midst of divorce or separation. I was unaware the police will always respond if you report receiving an email threat. The statute:

Under 18 U.S.C. 875(c), it is a federal crime, punishable by up to five years in prison and a fine of up to $250,000, to transmit any communication in interstate or foreign commerce containing a threat to injure the person of another. Section 875(c) applies to any communication actually transmitted in interstate or foreign commerce - thus it includes threats transmitted in interstate or foreign commerce via the telephone, e-mail, beepers, or the Internet.

Regarding key loggers, it is unclear to me whether their use always violates federal wiretap laws or not. The most recent article I found discussing this in general is here: http://www.theregister.com/2005/10/04/secfocus_keyloggers/print.html

I’m seeing RFPs (Request for Proposal) with language like:

"Exploitation should be performed using tools and techniques for which there is a reasonable expectation would mirror common tools and techniques used by potentially malicious users."

Ok, that’s loaded. What are 'common tools and techniques'?  For tools, is it Fyodor's Top 75 Security Tools? Metasploit is not listed there, CANVAS and Core Impact are mentioned but are not listed as one of the 75, so are those reasonable?  How about app specific tools like WebInspect or Appscan?  What about converting a PoC exploit from FrSIRT's database?  You have no developer friends? Alright, but if you're a steadfast malicious user and somewhat savvy, I'd bet you would pay for a nice VulnDisco Pack, especially if what you're after is more valuable to you or someone else.

This gets tricky to accurately nail down – the what is reasonable part – and think about the costs of using, say, 5 of these commercial tools.  You’d be at $20,000 after negotiations.  That’ll sure win you the bid.

My point is you can easily make arguments for any of the tools listed above, not to mention the 100s of free tools available.  Technique likely has less common ground.    Some like to say penetration testing is worthless, but I think that argument fits the idealist versus realist debate.  If there is a demand for this service, I see no reason why not to try win work if you play in this field.  It is just super hard to succinctly provide enough information to a client to enable them to differentiate and make a quality decision. 

Probably a good question to submit when responding to similar RFPs goes something like:  ‘Ok.  You want reasonable assurance you can’t be compromised.  Considering your definition of a ‘malicious user’, what do you consider the greatest amount of resources (i.e. time and money) a malicious user may dedicate?’  I think that get’s you closer to what the client really wants.

There have been some recent newsgroup postings about consistency problems with nmap results (especially when scanning over the internet). In my experience, if you want the best chance of obtaining accurate nmap scan results, you need to:

• check the latency to your targets (ping some device on the target net block for awhile, what is the average rtt value?)
  • use the average to configure the --max_rtt_timeout nmap option (e.g. if your ping time is 300ms, you obviously want to set this option to more than 300ms to prevent nmap for missing an open port if/when a probe takes longer than 300ms. Maybe set it to 500ms or even higher. Speed suffers, but we're chasing accuracy)
• if you can, check the available bandwidth limit for you and the target net (e.g. T3:45mbps, T1:1.544mbps, DSL, etc.)
  • use this to configure the --min-hostgroup and --max-hostgroup nmap options and the --min-parallelism and --max-parallelism options (i.e. the more bandwidth each side has available, the more hosts and ports you can scan in parallel). This can significantly reduce overall scan time while keeping accuracy as the highest priority. I typically use IPTraf to watch pps (packets per second) to guage my bandwidth usage. If my options are too aggressive (i.e. consuming too much bandwidth), I'll kill the current scan and start over with different tuning values. The objective here is to set --min-hostgroup and min-parallelism to something that both sides can handle without sacrificing accuracy. If bandwidth permits, I like to set min_parallelism to 100 (number of parallel SYN requests or whatever scan type you're doing). I've gone up to 300 for --min-hostgroup (had lots of bandwidth and plenty of server horsepower). You don't want to cause your scan server, the target, or any device the probes traverse to drop packets, so the more information you have about all the components involved the better you'll be able to tune these values.
• if you can, verify there are no 'smart' devices impeding scans (e.g. IPS, rate limiting device, etc.)
• run multiple nmap scans of the same target, preferably at different times of the day and different days of the week (e.g. nightly backups can saturate certain hosts/links which causes nmap to fail to discover open ports). I like to run multiple services scans (~1600 ports) and do one or two 65k scans depending on circumstances. If time permits, the confidence boost you get knowing you've maximized accuracy by running repeated scans is satisfying. It also shows your assiduity; you can tell your customer you fired off 5 scans at different times to obtain your final list of exposed services. If you missed something after repeated scans (assuming you used safe tuning values), something is likely wrong.
• set --host_timeout to something you are comfortable with.
  • if you determine a scan may take 20 hours to perform a 65k port scan of the target device, then set this option accordingly. Note: you can use 's', 'm', or 'h' to specify seconds, minutes, or hours.
• set --max-scan-delay to something low if nothing is impeding scans
  • I typically set this option to 0 because I'm confident in my other tuning values (no delay between probes, just fire them off)

While tuning nmap options can do lots of good things it is still important to verify your scan server can keep up. We've knocked down 8-way Opteron systems w/16GB of RAM, so optimal nmap options may not be realistic for your hardware.

 

 

I've been playing with a batch of OpenPGP cards that  I got a while back.   Very cool.   You can use it for secure storage of your normal PGP keys but you can also integrate it with PAM and SSH to use it for securing logins to your computer.  Passwords aren't enough anymore.

I haven't got it working with OS X yet but it looks like a pretty straight forward operation to get it setup.

Here is some more info. 

 

technorati tags: gnupg, openpgp, smartcard,

Sloshing around in rails and playing with AJAX is fun and all, but we hit a roadblock the other day when trying to view the html source of AJAX rendered components. You can't just hit cntrl-u in Firefox to see the source. After some googling, FireBug is the tool that rocks.

FireBug lets you explore the far corners of the DOM by keyboard or mouse. All of the tools you need to poke, prod, and monitor your JavaScript, CSS, HTML and Ajax are brought together into one seamless experience, including an error console, command line, and a variety of fun inspectors.

Not only is this helpful for debugging web applications, but it'll help when performing web assessments. I particularly liked the feature which highlights the elements on the html page when you select the corresponding code in the FireBug console.

I shouldn't be shocked, but I am. A piece of the conversation today we had with a client went something like this:

client: yeah, we also just found out we have an ex-employee logging in from the internet to our servers and helping other nurses with some computer tasks

us: um, you have an ex-employee logging into your servers remotely?

client: yes

Talk about scary. I wish I could say more. Let's just say this is relatively minor compared to other illegitimate activities this particular client is suffering from (e.g. knowledgeable attackers with clear targets).  It is quickly turning into one of those scenarios whereby you can’t trust the integrity of anything electronic.

On top of that, it’s another flare on why it is so important to just know what is and should be happening on your network.  Forget about all the fancy security solutions; what is important first is to understand why and how devices talk.  Do these systems over here need to talk to these systems here?  No.  Why are they talking then? 

This client has security point solutions in place, but they haven’t a clue what is happening or why.  If you spend the time to define the relationships, catching potentially illegitimate activity is a LOT easier.