Keeping ssh connections running

This week has been pretty exciting, we've had a large number of players in Round 1 of SANS's Netwars competition. The game is half Capture-the-Flag and half King-of-the-Hill shoot em' up!

One of the defensive techniques a player has been using during the game will manipulate the other player's terminals and eventually cause them to drop their connection. There are a few different techniques that will help work around that particular defense.

First, an infinite while loop will keep in you a shell (this will work
until he starts killing based on the "while")

ssh playa@netwars.sans.org "while(true);do sh; done"

Or, you could make your own shell, either by uploading one from a
compatible box of your own or the local one (he still needs to
run commands, so there should be a shell _somewhere):

ssh playa@netwars.sans.org "cp /bin/sh ~/.blah;~./blah"

You don't get prompts for those shells and some commands will expect
"terminal" screens, but you can still interact quite a bit more than
single ssh commands. One could step it up a bit as well and use something like this in the ssh command to make the name of the shell random:

export NEWSH="`head /dev/random|wc -c `";cp /bin/sh./".${NEWSH}";"./.${NEWSH}"

But don't forget you probably need to escape all the backticks and doublequotes.

This has been a blast, hope to post a lot more about Netwars soon.

Stego Using TCP Retransmissions

Follow the title link to an article that describes steganographic techniques using TCP ACK packets. Remember, these are the packets that are designed to either positively acknowledge how many bytes are received and even negatively acknowledge which byte is expected next. The article claims how the researchers can smuggle data as a covert channel in ACK to circumvent filtering and censorship.

If you HEARD my SCALE 7X presentation Custom FileSystems (slides), you would have heard how I described injecting spoofed ACKs to create an ACK storm that actually sustains a filesystem until the storm subsides. To create a sustainable filesystem, you would only need to create mirrors or parity storms ala RAID to give you a chance to restart the fallen one.

The reasons this is particularly more attractive than an alternative:

1) Transport layer--nobody knows you are using their webserver to bounce bytes off of unless they are looking at the transport layer.
2) Spoofable--you can spoof the ACK, ignore the resets, which allows you bounce the filesystem around a little and potentially avoid detection.
3) Troubleshooting ACK storms (if they are even noticed) usually involve part swapping network hardware--which won't affect the filesystem.

The next month is very busy, so I don't know if I'll have a chance to roll out a hello-world for this, but since I promissed it in February, I'll try to make it happen while stuck on a a long flight or two.

It's always good to have options

When it comes to being creative, it's always good to have options. I hadn't ran into a really good alternative to the WayBack Machine for pulling up old versions of pages. I have used ChangeDetection.com to keep an eye on sites I wanted to know were updated, but weren't updated often enough to have as a favorite. But today I realized they had added a lot of features I hadn't taken advantage of yet.

For example, one site I highly recommend to pentesters, can be tracked as it is changed by using:
"http://www.changedetection.com/log/uk/co/vulnerabilityassessment/penetration%20test_log.html"

The thing is, somebody must have already started monitoring of the page for there to be any history, but it's something work checking for research and finding lost pages. It also can help you sift through information overload. There is an RSS feed option if that is something you use as well.

re-pwning the box you already own

Friday I was called to handle a malware situation. This was essentially a mission-critical workstation and the goal was not to fully reverse engineer or preserve the machine for evidence. The McAfee antivirus product identified a malicious .js and .exe, but the logs didn't show the detection. The behavior I was called to fix was that most executables failed to run.

I started experimenting with other useful commands, and found that wmic was not affected in the same way but still provided a shell. So start->run->wmic.exe. Once I had a wmic shell open, I could execute the following:

process call create cmd.exe

Which did spawn a shell where start-run failed. Once I'm in this shell I ran a few commands to look around to confirm there wasn't still a separate malicious process that didn't belong. It appears the McAfee client did successfully kill separate executables.

Here I ran via the cmd.exe shell a reg.exe command to enumerate drivers:

reg.exe query "hklm\software\microsoft\windows nt\CurrentVersion\Drivers32"

Here, most things seemed normal except for one value named "aux6" that was something like "../isgerh.exe" (parent directory then a random executable). On different systems, this will be a different aux device, so the important thing to remember is if the infection just happened, it will be the highest-numbered device.

To delete this device from the registry, I simply typed:

reg.exe delete "hklm\software\microsoft\windows nt\CurrentVersion\Drivers32" /va aux6

After a reboot, things behaved normally.

If you boot into safe mode you can make the registry edit with the regedit.exe or reg.exe without running wmic. A full scan of the drive in safe mode likely would have removed the malicious driver, but the registry would still attempt to load it and would result in an EventLog entry about a driver failing to load. It is also possible that a stager execuable could re-dowload the malicious driver as well. So far, it seems that the combination of the commercial scanner and the registry edit completely removed the malware that prevented most executables from running.

Often I'm asked why/how I ended up focusing on Incident Response/Handling plus Penetration Testing. Well, sometimes you have to re-pwn your machine you own. The command line building blocks are great for both. A good reason to follow the Command Line Kung Fu blog.

I have two majors projects I'm trying to wrap up today, and I promise I'll post info on them as soon as I can. Meanwhile, have you registered for the SANS Penetration Testing Summit?

Back to Basics - Essence of Hacking

I was listening to a recording of a portion of pauldotcom's episode 150--and there was a good discussion on hacking basics. What would you focus on if you were starting in the security industry?

For me, I would say, be surrounded by academia. Not necessarily in a four-year degree program, (although I'm very grateful for what I got out of it), but I find I learned the most be surrounded by folks striving for knowledge. I learned more about compilers trying to survive running javac on HPUX 10.X than actually making a java compiler that compiles java (so yes, it was supposed to correctly accept itself as input). I learned how to tunnel services remotely with ssh just to read email remotely, not to bypass an IDS or firewall (ok, it did do that also which was nice).

So how to do any cyber-thing better--even if it is just getting started--surround yourself with information, but be careful not to drink the coolaid--use the information and apply it to your environment, exceed original designs and documentation, explore, improvise . . .

I know I blogged this before---but stay tuned for an announcement of an initiative with regards to entry level \cyber\S+\ig

If you are at a SANS conference, ask around about this--you may get a sneak peak. Or maybe you should just watch http://twitter.com/sanshacknet and get an idea of what's to come . . .

Cyberwarfare

Interesting posts are starting to show up out there about a surge of interested in the US armed forces and cyberwarfare. There's a lot of momentum building up. If you were at SANS in Orlando last week, you might have heard about a new project SANS is going to launch very soon. Stay tuned--expect an official announcement sometime in the next week or so.

Last week I had the pleasure of presenting at the SecureIT Conference in Los Angeles, CA. A keynoter, Randy V. Sabett, J.D., CISSP, made some very interesting points about US law with regards to defense. Generally, US federal laws tend to favor the fact that the individual can do anything necessary to defend his person. For Cyber Law issues, this is contrary to the history of case law established for non-Cyber issues.

So what I'm saying is that playing the Devil's Advocate or to role play a bad guy just to understand an attack is a very useful thing. But what about offensive skills? Does the properties of Mutual Assured Destruction apply to Cyberwarfare? Is it possible to display offensive strength and still be legally OK?

Now don't get me wrong, I'm not standing next to an ankle biter saying "Sweep the leg, Johnny!" But I think some interesting things are in motion . . . Stay tuned . . .

Audio Watermarking for Triangulation

This is an interesting thing that uses practical steganographic techniques to pinpoint the location where a recording device is in a movie theatre. It's not entireably unbelievable that this is possible, given that we have surround sound. I imagine the accuracy varies, though, not all theatres are equal and you may have the folks disapproately located.

The ways around this seem obvious to me: heavily convert the audio, and record from multiple locations, mixing it down. Of course, that likely affects the sound quality of the final bootleg product, but it would do the job. Or the bootlegger could mix in interesting signals that would skew the triangulation (like my previous post about how a certain sine wave prevents youtube.com from compressing the audio in a video).

Not to wave-off their work, but we really need to be moving forward and not lateral right now, like most security issues--it's an arms race.

The past week was good, enjoyed speaking at SecureIT. This week I'll be at TUG U2U then Charleston, NC for SANS Sec 504, see http://bluenotch.com/events for more info.

When your backup method is not out-of-band=FAIL

So I spent quite a bit of time traveling lately, last week I was in Edmonton, AB. When I return to my office there are two labels from UPS saying they tried to deliver the package. What really seems silly is their policy states (according to the unhelpful and unlucky person who answered my phone call) is that they hold onto the package for 5 business days, waiting for you to respond to the postcard they just mailed you--TO THE SAME PLACE THEY HAVE NOT BEEN ABLE TO GET ANYBODY!

You would think that either the collection of UPS stickies on the door, or the fact their excellent tracking database records the delivery attempts, that mailing a postcard to the same address is a terrible idea. All you catch there is somebody who wasn't available at the time to receive the UPS package, not people who are gone for a simple week!

Of course, by chance, they came during a week when nobody was in the Bluenotch Corp. office, and the killer is that the package spends more time in transit from shipper to me, then a measly 5 business days at a UPS location 20 miles away, then twice again as much time going back to the shipper. This package has spent more twice as much time on a UPS truck than waiting to be picked up, and it is going to double again when the shipper-reships it. The thing is, I know that email address and phone number is included in the shipping documentation, so if they really wanted to try to resolve the situtation, they could.

So try to get the most value out of this little incident--Don't have your backup system or your communications in same flawed mechanism, be SURE it is truly as out-of-band as possible.

Had a great discussion during my File Systems with FUSE talk at SCALE and this week I'll be at Secure IT Conference in Los Angeles. Next week is a series of workshops put on by The User Group at TUG 2009: Users To Users.

Working on a killer project I hope to post about at the end of the week once I get a few more details pounded out.