ClearNet Security

It can take some digging to discover if you’ve successfully injected any code into a web application. I was using the ALL-FUZZ-STRINGS that comes with Suru (added additional strings from sources like ha.ckers.org XSS Cheat Sheet) to run through a list of popular input validation attacks.

Suru is a Man In The Middle (MITM) proxy that sits between the user's browser and the web application.

I was keying on the fuzzy logic results window in Suru which helps the assessor determine if any attacks were successful.

The Fuzzy logic trigger box is used to fine-tune the results received during a fuzzing run. The user has multiple options that range from content extraction to brute force fine-tuning. The results from the fuzzing run can be mined or filtered for false positives, positives or false negative findings.

Here is a screenshot of the some of strings that are included in the ALL-FUZZ-STRINGS

During this phase of testing I was interested to see if any of the XSS type attacks succeeded. The fuzzy logic results window shows calculated scores that are derived from running an equation on each response and on a base response.

In order to conduct Fuzz logic or content extraction runs, Suru needs to compare the results to a base response. For example, if we need to brute force an application we need to compare a failed attempt with a successful attempt to gauge successes or failures.

I was surprised when all of the scores were basically the same – implying that none of the attacks caused a response which was measurably different from the base response. I already knew XSS/code injection vulnerabilities existed in this part of the application.

Upon a little investigation, it was clear the reason why Suru’s fuzzing scores were remaining more or less the same. For this particular web application, the response page created from submitting values was simply an acknowledgement of the POST request.

This response page was always the same -- there was no deviation from the base response. But by manually crawling the site and clicking on deeper links, I ran across a link where the injected code was executed and displayed in the response. One of the attacks was successful.

The take-away here is that it is important to manually walk the web application after performing XSS, code injection, etc. attacks to really see if any were successful. The attacks may cause the web application to respond with the exact expected attack string (i.e. if you put in as part of the attack the string “URL=javascript:alert('XSS-IS-HERE');”, then you can scan the HTML response for the string “XSS-IS-HERE”), but the web application may modify the string enough to evade automated checks yet still be vulnerable.

And in the case above only discovered by manually crawling the app to see where the attack successfully surfaces.

A lot of folks seem to be interested in booting linux devices faster right now. Be it by parallel init processes such as SMF, launchd and initng, or various other techniques. One thing that drives me nuts and has for ages is how long my computer spends doing who knows what in the BIOS.

I've done a little BIOS work in my career and I honestly don't know what they do that takes so long. Other than drives spinning up, most things that are reset and configured by a BIOS can be done in times that are faster than a human can notice. I have an IBM system that takes about 3 minutes before the BIOS is done. I support some Gateways that I think take longer. It's long enough that I almost always get a little bit angry waiting for it. I don't reboot systems that often but if it takes 5 minutes, that is 5 minutes you have to wait to make sure it comes back. I'm fairly certain that there are intentional delays to display vendor logos which is sort of funny to me because they've already got my money at that point. Then on the other side of the fence, a normal kernel (BSD, Linux or any that I can really think of) seems to boot as fast as you can get it off the disk and then it's running user space code like init or launchd.

There is a great way to skip that time and it seems completely under utilized. kexec was written by Eric Biederman over the last 5 years and it is in the main line Linux kernel. Since 2000, I know of at least 3 other projects that reached different degrees of maturity that do the same thing: LOBO, bootimg, and "2 kernel monte." They all do fundamentally the same thing but kexec is by far the most complete and polished. Kexec replaces the current kernel in memory with a new one. You select a kernel off of a disk, load it in to memory in a specific way, turn off protected mode and re-enable real mode on the processor and then jump to the new kernel. Effectively this is a reboot, only it completely skips the BIOS.

Kexec is included as an RPM in Fedora Core, so you probably don't have to do very much to use it. It's very simple though. You just run kexec and specify a kernel, an initial ramdisk image (if you run with one) and other kernel arguments and then issue a normal reboot (look in your grub menu.lst file if you don't know what these are). The system will go through the normal shutdown process and then at the end you'll immediately see the new kernel booting up.

It doesn't take much imagination to think of other uses for this kind of technology. If you were to use some exotic filesystem like NILFS or OCFS2, or reiserfs4 that grub won't boot, you could boot any partition you can mount with any kernel that can read that partition. Kexec and LOBO were born to help with clustering problems, boot to some small version of linux that downloads the version of linux that does the work from the network and then boot to it. You also could very easily build a DVD that verified your system's integrity before booting it. Or you can just skip those annoying BIOS messages.