ClearNet Security

I hope all of you moved over to our new blog server without issue. The other blog software was causing us some issues so we decided to move to another setup. This one runs on Typo so it is more suited for us. Both Tate and I know Ruby somewhat so we should be able to keep this up and running.

I have been on a study path to try and reinforce my class I took at Blackhat on Reverse Engineering. Here is the list of books I have been using:

Book Title	Author	Book Cover
"Reversing Secrets of Reverse Engineering"	Eldad Eilam
"Exploiting Software"	Greg Hoglund and Gary McGraw
"Hacker Disassembling Uncovered"	Kris Kaspersky
"Microsoft Windows Internals 4th Edition"	Mark Russinovich and David Solomon
"The Art of Assembly Language"	Randall Hyde
"Write Great Code Volume 1"	Randall Hyde
"Write Great Code Volume 2"	Randall Hyde

If you are interested in disassembly or reversing then I highly recommend these books. The main book I am using is the "Reversing, Secrets of Reverse Engineering" and then I am following up with the other books as needed. The one book that might be disheartening is "The Art of Assembly Language". This book first teaches you a special language called High Level Assembly (HLA) and then slowly drops you down to low level assembly for the X86 thereby making you learn two languages. This is why it is so big..... I believe the reason is that it is hard to actually do something in assembly without knowing most of assembly so the author uses HLA to bridge the gap. I thought it worked out fine but I wish I had known that I had to learn HLA first then Assembly. By the time I realized this I was too far to stop.

Does security need to be baked in to a product from the very start? Or can you add it after the fact? Does the development model affect this? I think this is a really interesting question. My instinctual answer is that to build a properly secured application or system of applications you have to plan for it from the start. That's the parochial answer and I'm not sure that's it is 100% correct. The last few years various iterative development models have become more popular and while I cannot point to any examples of great success coming from that I also can't point out any failures that could have been avoided with any other development model. The trend is to rapidly develop with little or no up-front design, adapt to changing requirments dynamically and rapidly fix problems as they arrise. Do these development models lead to less secure products by their very nature?

The logical follow-up is how do you iterate security in to a product after the fact, if that's a valid way to do it? Any thoughts or experiences?

Sorry for the duplicate entries in your RSS reader. We migrated Sunday to a new server and built a new stack: Apache -> mod_proxy_balancer, mod_rewrite -> Mongrel, Ruby, Rails, Typo -> PostgreSQL. We used mod_rewrite to hopefully keep the RSS links and others working (old permalinks end up dropping you on the latest entry). We haven't added all the comments back yet.

If you want to update your settings, our new RSS link is:

http://blog.clearnetsec.com/xml/rss20/feed.xml

 

At Black Hat I took the "Reverse Engineering on Windows: Application in Malicious Code Analysis" course. The class was about reverse engineering malicious executable programs on the Windows platform just like the anti virus guys do for big companies like Symantec and iDefense. This was a very fun class for me as my background is not in reverse engineering or it's associated technologies like:

• IDA Pro
• OllyDbg
• WinDbg
• Import Rec
• Ollydump

I have taken many courses before for security and network related subjects but never from Black Hat. This was even my first Black Hat Briefings so I was very excited to see how it would turn out. Many times before I was disappointed with the classes I took as they tended to have a very interesting syllabus but then the classes ended up shallow on the technical depth that I thought I would get. This very thought process had me skeptical on the Black Hat course as well but man was I wrong! I think it took about 7 minutes into the class before we were launching IDA Pro and digging into the configuration of the tools we would use for the next 2 days. We didn't even introduce ourselves leaving us to guess who was even teaching us.

My teachers, Pedram Amini and Ero Carrera, were some very bright and intelligent guys that had been in the malware/virus reverse engineering circles for years. They were so adept at reversing things that they have written many tools to help with reversing such as:

• PaiMei
• Pydbg
• IDA sync
• Pydasm
• Pydot

As you can see they were both Python fans. Too bad Ruby rocks Python so much that Python needs to go bash the Perl guys to feel better.

So by the first half day I was already disassembling the Mydoom.A virus looking for what it was made of, what it did, how it worked etc... Now this was not a "live" analysis but rather it was loading the binary executable up in a disassembler/debugger called IDA Pro and dissecting the binary code looking for things of interest. Basically we learned two main methods of doing analysis, "top down" and "bottom-up".

Top down was where you start at the program's main function and start labeling all the functions that are called to see what they do. For example you eyeball a function and decide it is gathering the time from the system so you label the function "Gets the time" and so on. Once you do this for all defined functions you can then concentrate on the ones that perform actions of interest like opening sockets or creating processes.

The bottom up approach was where we look for interesting code snippets, items in the Import Address Table (IAT) and strings table. For example if you find a call to "htons" and above it you see the number 80 (in hex of course) being placed into a register, you can deduce that it is making a call out to port 80 on the network.

Yes I know this sounds hard and it was..... But anybody could possibly learn this skill with practice. I will try to write up some good snippets from my class if anybody is interested. Here are some interesting sites to peruse if you are intersted in reversing:

• OpenRCE - A site about reverse engineering software
• Rootkit.com - A site about malware things
• The Reversers Vault - A site with tutorials on reversing things

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.