The RenderLab has updated and rewritten the previous Kismet Drone guide for modern builds of OpenWRT and Kismet Newcore.

Step One

First step is generic for all platforms and that is to get the OpenWRT development environment (herin refered to as ‘Backfire’)

The instructions are available at the OpenWRT development site at https://dev.openwrt.org/wiki/GetSource and that site should be assumed to be the source of truth but I will summarize here

Get the source, remembering that you will eventually need around 3-6 Gb of space once everything is built, so make sure you have enough there.

svn co svn://svn.openwrt.org/openwrt/branches/backfire

This will download the backfire source and build environment to build your own firmware with the Kismet Drone built in.

NOTE: Should you want to use a pre-built binary for your platform, feel free, however in some cases this will cause problems as they won’t have enough free space for the drone binaries unless they are built into the image. In addition, you will need to have the build environment anyways if you want to build an up to date Kismet Newcore drone binary, so might as well build it anyways.

Once you have the source and build environment downloaded, go into the directory and run ‘make menuconfig’

cd backfire
make menuconfig

This will build and run the firmware build configuration utility. From there, don’t change anything except the target system. Change it to your targets profile:

WRT54GL:
System: Broadcom BCM947xx/953xx
Profile: Broadcom BCM43xx WiFi (Default)

Ubiquiti Routerboard:
System: Atheros AR71xx/AR7240/AR913x
Profile: Ubiquiti Routerstation

Accton 3201A:
System: Atheros AR231x/AR5312
Profile: Default

Once you’ve selected your target profile, select exit, save your changes and then exit.

Note: The next step is to download the additional packages, but it sometimes fails horribly unless you do a make menuconfig first.

Backfire has a Kismet Newcore package built, but it is uaually out of date and it is recommended to use the newest version possible so as to get bug fixes, etc. For this reason, you will want to build your own to follow release versions or if you are really adventurous, SVN. The Makefile that is in the source only needs some minor tweaks to build the software with the latest version.

To add the package to the build environment, you just run a simple SVN command

make package/symlinks

This will download the Makefiles for the extended packages into the build environment. The next time you run ‘make menuconfig’, the new packages should hopefully be available in the menu to enable for building.

If you want to confirm that it worked successfully, just run ‘make menuconfig’ and you should see a bunch more packages available to build.

Since the Makefile included with the build environment pulls a very early version of Kismet Newcore to build, it needs to tweaks to use the newer and more mature code.

There are two ways to go about this. One is to use the latest release version (available on the Kismet site with the format kismet-YEAR-month-release number), the other is to grab a snapshot of the SVN version and use that. It all depends on your needs and ability to deal with ever changing code.

Release version:

If you want to follow a release version, you won’t be running the latest code from SVN which may fix any problems you encounter with the drone, however you will have some assurance that the code will work and not break suddenly.

In your backfire directory, edit the kismet Makefile which sits in feeds/packages/net/kismet/

We only need to edit some of the first lines in the file:

PKG_VERSION:=20010-01-R1

This needs to be changed to the latest release version on the Kismet site, which at the time of writing is Kismet-2010-07-R1

PKG_VERSION:=2010-07-R1

The Makefile already knows where to download the Kismet source, we are just adjusting the filename variable so we get the latest release source.

If you want to assure the integrity of your source tarball, you can edit the “PKG_MD5SUM:=” line to reflect the MD5 of the release package. If you don’t want to use that, you can simply remove this line and the tarballs checksum will not be checked.

PKG_MD5SUM:=

SVN version:

If you want to follow SVN, you will have the latest code and the latest bug fixes, however since it’s ‘live’, it’s possible for something to get horribly broken at any time. Also, this presents a problem of an ever moving target and of things changing too rapidly to track where any problems may be coming from. Because of this, I suggest and will show how to make a snapshot of SVN that changes only when you download and load a new tarball into the build system.

To start, you need to download SVN of the Kismet Newcore source:

svn co https://www.kismetwireless.net/code/svn/trunk kismet-devel

This will download the Kismet Newcore source into the kismet-devel directory. From there we will make a tarball of the source and use that:

tar czvf kismet-devel.tar.gz kismet-devel/

After we have made the tarball we need to make changes to the Makefile in your backfire directory. Edit the kismet Makefile which sits in feeds/packages/net/kismet/

We only need to edit some of the first lines in the file:

PKG_VERSION:=2009-06-R1

This needs to be changed to use our SVN tarball that we made

PKG_VERSION:=devel

If you want to assure the integrity of your source tarball, you can edit the “PKG_MD5SUM:=” line to reflect the MD5 of the SVN tarball we made earlier

PKG_MD5SUM:=

Now, you’d think that the Makefile will want to download the kismet-devel.tar.gz from the Kismet website, but that is where we get tricky on the system. The build environment, when it builds the system will download and unpack the source for everything it builds. Now if you make changes and do the build again, the system is smart enough to check if it already has the source downloaded. Once we have made the tarball, we have to put it somewhere to trick the system into using that source instead of trying to download from the Kismet site. Simply copy the kismet-devel.tar.gz file into the download directory (dl/) in your backfire source directory (NOTE: The DL directory is created when you start a ‘make’ and may not be there if you have’nt run ‘make’ yet).

Assuming your root is called ‘backfire’:

cp kismet-devel.tar.gz backfire/dl

The system will now see the kismet-devel.tar.gz package in the dl/ directory and use that. This prevents the system from going out to the web to try and download the file, and also gives you the ability to change out the source at the time of your choosing.

Once you have the Makefile adjusted and if nessecary, the source files in place, you can now run ‘make menuconfig’ again and select the kismet-drone package to build.

make menuconfig
Network -> Wireless -> kismet-drone

If you want to make a seperate module you can load with opkg, when you select the kismet-drone package, select it where it says “M”. If you want to build the drone binaries into the firmware image (recommended for WRT54G’s and any platforms with limited memory or for large productions) then make sure it is selected with a star “*” instead.

Once you have enabled the kismet-drone package, exit and save your configuration. Once you exit, start the build process

make download world

Once the build starts, it will download all the source for the packages it needs and the start compiling everything. This can take a very long time depending on your system, so go have a beer or seven as this can take hours, especially on the first run.

If the build process completes sucessfully with no errors, you can move onto loading your router with the OpenWRT software. Depending on your platform, this can vary, but the OpenWRT site has instructions for most platforms. They are the source of truth, so check them out for your particular platform.

The custom firmware you built is stored in the achitecture name under the “bin” directory in your build directory. This is especially important if you built the kismet-drone into the firmware as you should use that instead of a version off the OpenWRT site.

cd bin/

The OpenWRT site wiki has instructions for most platforms, however one that seems to be missing is the Accton MR3201A, the basis for the FON 2200 router and the OpenMesh OMP1 low cost router, so I’ll add it here.

To install on the Accton router, it’s not a simple tftp like most platforms. The easiest way is to use the Open-mesh flashing utility. Head on to the Open Mesh development site and download the open-mesh-flash utility (there is a windows version too). With this, you can upload the kernel and root fs to the router, which are the files ending in “root.squashfs” and “vmlinux.lzma”. You will need to configure the wired network interface on your system to the 192.168.1.0/24 subnet, anything except 192.168.1.1. When you run the open-mesh-flash utility and specify the interface your router is connected to along with the root and FS files, the program will connect and upload the new firmware.

./open-mesh-flash eth0 openwrt-atheros-root.squashfs openwrt-atheros-vmlinux.lzma

Once this runs, and the firmware is uploaded, you can continue on

If you chose to build a package, you can find it in your build directory under the “bin/Architecture/packages” directory. Copy it to your router with SCP:

scp kismet-drone.ipk root@ROUTER:/tmp

and install it with opkg

opkg install kismet-drone.ipk

Once you have the Kismet Drone package on the system, however you chose to do it, it’s time to configure it. Depending on your platform, configuration is pretty much the same few things.

After telnetting to your drone and setting and SSH password, SSH back in and you can edit the system to get monitor mode.

Assuming you are using this unit as a dedicated drone, you will want to enable and setup the wireless interface(s) to monitor mode at boot up.

To enable the wireless cards on your router, edit the /etc/config/wireless file and enable the radio(s)

# REMOVE THIS LINE TO ENABLE WIFI:
option disabled 1

This should be changed to:

# REMOVE THIS LINE TO ENABLE WIFI:
option disabled 0

You can also remove the line or just comment it out.

When you are editing the /etc/config/wireless file, you should also set the interface to be in monitor mode on bootup. To do this, change the following:

option mode ap

This should change to:

option mode monitor

In addition you can delete or comment out the following two lines since they are not needed:

option ssid and option encryption

Now that the radio(s) are enabled and set to monitor mode, time to configure the Kismet Drone. All options are set in the /etc/kismet/kismet_drone.conf file changing the following lines at a minimum.

dronelisten=tcp://<IP Address>:2502

This line sets what IP address/interface the drone will communicate with the server over. If you have multiple interfaces and/or static IP addresses, you can specify the IP you want to listen for commands from the server on. If you use DHCP (you won’t know what address you will get) or you have multiple interfaces you want to listen on, you can list several IP’s comma seperated, or use the address 0.0.0.0 which will listen on all available interfaces.

The next line sets which IP addresses can connect to the drone:

droneallowedhosts=127.0.0.1

If your server is not on the drone itself, you will need to add something here. Multiple addresses can be specified, comma seperated. Using the address of 0.0.0.0 will allow *any* IP address to connect.

NOTE: Using 0.0.0.0 allows anyone to connect, there is no authentication beyond that. If this drone is connected to a public IP, anyone can connect and listen to the traffic. This is probobly not a desireable situation as anyone on the internet can sniff wireless traffic that you may not want them to!

Depending on your drone, you may or may not have a GPS.

If you have a GPS, leave it as true and set your other options:

gps=true

If you don’t, to cut down error messages, disable it with:

gps=false

Last and most manditory, you will need to set the source line. The good news is that as long as you did’nt select the “Broadcom BCM947xx/953xx [2.4]” target system, you can get away easy. If you did select a 2.4 branch, read the Kismet README, section 7 and figure it out on your own and let me know.

If you picked any of the 2.6 kernel targets, you can generally get away with the following as your source:

ncsource=wlan0

There are many other options in the Kismet_drone.conf file that you can setup. Most are well commented and self explainitory.

Once you have the Kismet Drone configured, you can fire it up to test from the command line by typing:

kismet_drone

If all is well, no major errors should show in the output and the last line should be something like the following, but with your interface name:

INFO: Started source ‘wlan0′

In order to start the Kismet Drone on startup, you will need to add a startup script. This is actually very easy to do, simply copy the following into a new file called /etc/init.d/kismet-drone:

#!/bin/sh /etc/rc.common
# Kismet Drone Startup Script
# Copyright (C) 2007 OpenWrt.org + RenderLab.net

START=70
STOP=15

boot() {
echo boot
# commands to run at boot

# continue with the start() section
start
}

start() {
echo start
# commands to launch application
kismet_drone
}

stop() {
echo stop
# commands to kill application
killall kismet_drone
}

Once you copy the script into a file, save it, then make it executable:

chmod a+x /etc/init.d/kismet-drone

Then enable the script so it creates the realivant start and stop links in the /etc/rc.d directory:

/etc/init.d/kismet-drone enable

And with that you can restart the router and if everything is as it should be, the drone will start automatically.

Now that you have a Kismet Drone running, time to now connect a Kismet server. The line you need to now is:

drone:host=<IP Address>,port=2502

is obviously the IP address of the done. Just throw this line into the ‘Add new Source’ in the clent and it should connect and start feeding data.

:Port 2502 is the default, but in the kismet_drone.conf file you can change that for whatever reason you may need to, just make sure it matches here.

In addition to the client GUI, you can start Kismet with a drone from the command line with pretty much the same line:

kismet -c drone:host=<IP Address>,port=2502

If you use drones all the time, you can add a permanent entry to the kismet.conf file on your server:

ncsource=drone:host=<IP Address>,port=2502

NOTES

It seems that connecting to a drone over a wireless connection sometimes breaks the connection. The server will reconnect to the drone, but it’s kinda messy.  Also, connecting to nearby drones via wireless means they may end up sniffing themselves, which leads to alot of extra data!

If you have additions, or other platform specific tweaks, let me know @ render [at] renderlab.net

Thanks!

Many people contribted to this guide in meaningful ways and I wish to note thier contributions.

Dragorn, for Kismet and umpteen bug fixes and features. Michael Boyd for his early Kismet Newcore Drone work. The Whole OpenWRT team for thier work, especially whomever checked in the early Makefile for Kismet Newcore.

md5 sum
172468983190bc4d0e4c7f1b31dbe697

Katana v1.0 (Kyuzo) is a portable multi-boot security suite designed for all your computer security needs. The idea behind this tool is to bring together all of the best security distributions to run from one USB drive. Katana includes distributions which focus on Penetration Testing, Auditing, Password Cracking, Forensics and Honey Pots. Katana comes with over 100 portable Windows applications such as Wireshark, HiJackThis, Unstoppable Copier, and OllyDBG. Also included in this distribution are:

• – Backtrack 4 pre
• – the Ultimate Boot CD
• – Organizational Systems Wireless Auditor (OSWA) Assistiant
• – the Ultimate Boot CD for Windows
• – Got Root? Slax
• – Ophcrack Live
• – Damn Small Linux
• – Damn Vulnerable Linux

Here are the mirrors:

http://gextrade.thegoodhacker.com/katana/katana-v1.rar

http://psifertex.cns.ufl.edu/~jsawyer/katana

http://dc585.info/mirror/katana

http://newfe.kracomp.com/katana

http://www.d3vrandom.net/hfc/katana

* WNLA 3 is ~600MB (last releases were roughly 1~1.5GB)

* WNLA has many new GUI interfaces for things (helps people make the transition from Win32/64 to Linux)

* WNLA has instant servers including (MySQL, FTP, SSHd, FastTrack-GUI, Metasploit-Web Brick, and more)

* WNLA has it’s own PHP/MySQL Social Networking server that i coded (resembles Facebook) to use in the lab to teach people about web hacking PHP/MySQL and SQL injection.

* WNLA has new looks including Grub splash, Usplash, GDm and more.

* WNLA includes WardriveSQL GUI and Webserver that i coded (http://wardriveSQL.info).

* WNLA includes GUI interface to WiFiZoo that i coded (which is to be added into the next build/website, under 3rd party additions)

* WNLA uses fully customized/customizable FluxBox instead of bloated Gnome and less-bloated (but amazing) Enlightenment.

Links available to paid subscribers of Informer only. Click here to subscribe. It’s only $54 a year, and the proceeds go directly to HFC projects such as our food program in Kenya and our Classroom project in East Africa.

Check out the video here!
Here’s the links….

ISO: http://weaknetlabs.com/linux/eb49e6f3bd72e6c6da517774391e0441/WNLA3LITE.ISO
MD5: http://weaknetlabs.com/linux/eb49e6f3bd72e6c6da517774391e0441/WNLA3LITE.ISO.MD5

Douglas also makes a forum available for questions about the release. Be sure to check it out!

It is an honor for me to drive this initiative, with the support of Don Donzal (EH-Net) and Ed Skoudis (Challenge Master), and start posting the official answers of this challenge on The Informer. Then, in a few days, both the answers and winners will be announced on EH-Net as usual.

The “Prison Break – Breaking, Entering & Decoding” challenge answers are contained in a single PDF file (27 pages) plus three associated screencasts (“BTv4 802.1q (VLAN) setup”, “Metasploit meterpreter Windump/Winpcap sniffer”, and “Metasploit meterpreter built-in sniffer module”).

I hope you enjoy it, and we look forward to the participation of The Informer subscribers in future EH-Net challenges! Next up is the October Challenge by James Shewmaker based on the TV show Sliders, and then Ed Skoudis’ annual Christmas Challenge coming in December.
–
Raul Siles
www.raulsiles.com

After enjoying MDK3 but finding it way to blunt for many uses I decided to write my own python deauth tool using lorcon.

The advantage to airdrop-ng is the rule parser. It is smart enough to know that if you wish to allow a client on an AP but want to kick the others not to send a broadcast packet. This allows airdrop to act as a wifi nuke but also as a scalpel for very targeted work.

Another fun feature is the kick based on OUI. Using OUI lookups its possible to kick on device type. So say if you wanted to ensure that no Macs in the area have access to wifi while all other devices work fine. It really is quite fun.

Sadly this tool has not gotten as much testing as I would have liked so if you do manage to blow it up please double check your rules and make sure they are to the format of the example config file. Also ensure that you have read the readme. If those two items fail to clear up your issue email me the airodump csv file and the rule config file you are using and I will do my best to clear up the issue for you. I can be reached at thex1le a t  gmail DOT com.

This tool will most likely be working its way into the aircrack-ng suite at a later date.

The code can be downloaded here

!!!!! UPDATE

I found two serious bugs and have sinced fixed them. One was that if you tired to just kick a single client off an ap all clients would be kicked. The second was that if you had a rule for a client airodump couldnt see or just did not exist the program would die. Both have been fixed. Please use this new link

http://seattleit.net/airdrop-ng-9-22-1730.tar.bz2

Special thanks to SWC666 and http://seattleit.net/ for hosting the code base.

But, for this community, the more interesting part was the survey we conducted. We performed an open survey on patch management processes that included some of the biggest, and smallest, organizations around (and are keeping the survey open). While we released a summary analysis with the initial project report, we are now releasing the raw survey data.

This data has been anonymized, but otherwise unaltered. We had about 116 responses when I did this data dump, and keep in mind the results likely skewed towards more mature organizations (since they’d be more incented to participate). This data will be exclusive here at the Informer for one week before we release it to the broader community. The file includes the data in cvs and xls format, with an xls of summary results (the pretty charts).

[download id="30"]

Here’s the link:

http://www.paterva.com/maltego/about/maltego-mesh

The password is “yoshimi”, without the quotes.

Since I have a working prototype of a new tool available, I thought you all might like to play with it! (Warning: This is a prototype, it is still buggy, does not have a GUI, and may or may not explode your computrons.)

For my senior project, I’m writing a tool to extend the functionality of the RATS (Rough Auditing Tool for Security) vulnerability scanner. What GRaTS (Graphical RATS and Taint Scanner) does is to attempt to combine several approaches to finding vulnerabilities to help both experienced auditors and greenhorns to get quicker, more accurate results. By identifying points in code where users can affect the data flow (namely through input or things like signals, filesystem tomfoolery, etc) we can distill the code into a condensed version which shows only code dealing with tainted data. Once the code has been condensed, we scan it using RATS and format the output nicely into a GUI, including relevant line numbers, variable names, and any vulnerability information that RATS may have returned. This allows for novices to immediately identify dangerous code operating on tainted data, and allows more weathered folk to perform manual code analysis on tainted data timelines, making manual code analysis faster and more cost-efficient.

Hope you all get a kick out of it! Any new prototypes released will be on the same page, so check back periodically if you’re interested in seeing GRaTS progress.

Cheers!

–

Dan Crowley

http://www.offensive-security.com/blog/category/videos/

Check out the videos, and you can see that this is a HUGE improvement over BT3 and BT4 beta. We’re talking one-click installs, oh man oh man…

“Up and running with backtrack”
http://www.offensive-security.com/movies/upandrunning/offsec-backtrack-01.html

“BackTrack 4 Persistent USB install”
http://www.offensive-security.com/movies/persistent/offsec-backtrack-02.html

“BackTrack Dual Boot with Vista”
http://www.offensive-security.com/movies/dualbootbt4/offsec-backtrack-03.html

More videos coming soon! But here’s what you’re waiting for…Ready… set… here’s the links:

The BackTrack release is public now. You should have subscribed so you could have had it early!

The link and password to the video are:

[private]
Link: http://vimeo.com/4616236

Password: n0techh@ck
[/private]

The user security is the prime issue because millions of user were at risk if this attack persisted in the open environment. Integrated accounts were more susceptible as certain credentials could be used to access other accounts.

Thanks to Google for considering the recommendation and changing the working behavior of specific components at risk.

The detailed advisory is released here:

[private]

http://www.secniche.org/gmd_hijack/gc_hijack.xhtml

PDF: http://www.secniche.org/gmd_hijack/advisory_gmail_google_docs_pdf_repurposing_attack.pdf

[/private]

Well, apparently it was a real popular thing to give away a couple of 0day exploits, so more 0day is being given away! Again this is from the good old days at BindView when your buddy SN was on the RAZOR team.

[private]
There should be two like last time, so I will give away the first one real quick. I found this from a TODO list of mine from August of 2003. It simply reads “buffer overflow in netware smb authentication” and a few lines down says “large user name in nw smb auth, dos only?” That is all I have to go on. If I were really inspired I guess I could get out my box of drink coasters, erm sorry my box of old software no one ever uses, set up a NetWare server in a VM circa 2003 and start whacking away. But since I don’t want to terrorize Novell’s four remaining customers, I will let bygones be bygones.

No that one is rather lame, so here is a better one…

Todd Sabin. You know him, you love him. PWDump2 was his baby and laid the groundwork for numerous other hash dumping routines. He is a mad coder and knows Windows stuff like nobody’s business. If you’ve ever used Wireshark and looked at Windows DCE RPC decoded, you are looking at Todd’s handywork. Interesting Todd fact – instead of using some reverse engineering tool that performed a disassembly a la IDA Pro, Todd wrote his own. In LISP. The fucker is nuts.

Well Todd found a number of security issues while he was working at BindView, all properly reported to Microsoft. However Microsoft didn’t always issue a patch or fix Todd’s issues. This is one of those issues that Microsoft eventually patched but didn’t tell anybody about.

The bug, reported to Microsoft in the summer of 2004, impacted NT, 2000, XP, and 2003 versions of Windows. It seems a remote attacker could hijack RPC session handles and use them with no further authentication. Use an admin’s RPC session handle and you could have some fun with altering all kinds of things like user account permissions, registry keys, etc. You get the idea. Bad stuff.

RPC servers use something called “context handles” to represent handles to objects. So if an admin wants to change something, they get the context handle for that object they want changed, the RPC server impersonates the requester and checks permissions. The permissions are recorded with the handle, and later in the conversation permissions for the handle are checked as it does its thing. So you can see where this is headed.

Ironic part – on page 271-272 of “Writing Secure Code” (1st edition, written by very bright MS employees) it states in the section “Don’t Rely on Context Handles for Access Checks” to well, not rely on context handles for access checks, which is exactly what this flaw is all about.

So here are the steps to be evil:

• Sniff the network between the victim machine and the administrator, waiting for the administrator to do something to an object the attacker wants to do themselves. Social engineering could help speed this up.
• When the admin performs the RPC bind, the attacker performs a bind with the same association group as the admin.
• When the admin does the RPC call to open the handle, the attacker spoofs a TCP reset against the admin’s machine to prevent the handle from being closed, and records the context handle the admin had requested to use against that object in an evil fashion.
• Game over, man, game over!

Sweet, huh? Yeah I know, I think Todd fucking rocks too.

Oh sure you say, TCP connection hijacking could do the same thing. Well SMB signing defeats those types of attacks, but not this one. Bitchin’. The final sweetness is that all the attacker needs is minimally anonymous access.

So this sounds serious. It was, Microsoft said it was very serious to them. However (there always seems to be a however) this would require a massive amount of code changes — tons of subsystems would have to be touched. So Microsoft decided not to go the individual patch route. Like last time, Microsoft knew BindView RAZOR did not release vuln info unless it had patch info from the vendor.

I asked Todd about this recently and he told me Microsoft apparently did patch things, but no one was told about this. Todd’s guess was it went into XP SP2, some service pack for 2003, and probably some rollup patch for 2000. So XP and 2003 are good, 2000 possibly good, and NT is more than likely as fucked as the people who are still running a non-supported OS. You’ve gotta love those silent patches!

Ok, in Microsoft’s defense here, it probably did impact a ton of various servers and subsystems, and quite frankly there could have been other interesting examples of similar misplaced trust issues to be found in these same subsystems that Microsoft didn’t want people finding. So they fixed it and did not tell anyone (shame on you MS), but they at least shoved it into service packs which they knew would get loaded up for security reasons. Plus, all the reverse engineers are less likely to do binary diff analysis against pieces from a service pack than an individual patch, since there would be multiple security and even non-security updates to the various components, and it would be really fucked up to start looking for needles in that haystack. Granted, they now have at least one idea on where to look…

If you run into Todd somewhere, buy him a beer. He deserves it.

-SN
[/private]

[private]

Due to ingrained security mechanism in PDF Reader, it is hard to launch certain attacks. But with this technique an attacker can steal generic information from website by executing the code directly in the context of the domain where it is uploaded. The attack surface can be diversified by randomizing the attack vector. On further analysis it has been observed that it is possible to trigger phishing attacks too. Successful attacks have been conducted on number of web applications mainly to extract information based on DOM objects. The paper exposes a differential behavior of Acro JS and Brower JavaScript.

http://www.secniche.org/papers/SNS_09_03_PDF_Silent_Form_Re_Purp_Attack.pdf

[/private]

RT

[private]
0654-7205-3800-0900-5999-1
[/private]

Not one, but two 0days surpressed from the BindView RAZOR days….and I am letting them go now.

The ugliness, the ugliness of a stupid flaw you cannot control, one that will get you cool points but at the same time make your life miserable. Imagine finding a flaw that affects multiple vendors — major vendors — and no one wants to do anything to fix it.

[private] You work on it at a company that has a policy that prevents you from releasing the bug info since there is no patch. Release it anyway? Well, work will be pissed off, especially since they partner with one of these major vendors and do not want to piss off said partner. On top of that, it will cause your basic shitstorm among Internet users. And even have a direct input on your inbox with a metric fuckton of spam and scams. Oh that will get it fixed, most certainly, but you will be considered a complete asshole of a prick jerkwad deluxe. You go to CERT, and guess what, they run into the same fingerpointing that you do. It is “the other vendors fault, not ours.” And it is 2004 – the dotcom bubble has burst, and you are trying to justify that ridiculously high salary, and all your hacker friends are getting into that whole “responsible disclosure” thing.

Fuck it, BindView got sold off, at the end no one gave a shit about the RAZOR team. And it has been almost five years, plenty of time for vendors to silently patch. Disclosure time.

Discovered by yours truly in mid 2004, this was a gem of a bug. Imagine being able to bypass not only anti-spam and anti-virus products, but in some cases bypass IDS/IPS systems as well. Over a well known and usually open port on the firewall. Sweet. Before we get to the bug, a bit of explanation about the bullshit behind not releasing it.

As you might have guessed, this involves email since anti-spam was mentioned. An email message could be constructed that bypassed normal anti-virus scanning of incoming email. Many vendors were affected, so a couple of the major ones were contacted (if memory serves, since I no longer have the original emails, it was Trend Micro and McAfee, or someone like that). “Yes you are correct” they say, “we can be bypassed this way, however we can do nothing to detect it since our flagship product runs on Exchange and Microsoft will not give up the right API calls we need to update our engine.” Same thing for anti-spam.

So Microsoft is contacted. “Not our problem” they say, “we are not going to create additional libraries that use internal API calls that don’t exist but could also expose us to having our intellectual property copied.” Besides, the vendors apparently had to pay extra for what access to the APIs they currently get, and some were not even paying for those (they reverse engineered around them), so Microsoft had no incentive to write more APIs. The biggest disadvantage? All of these companies are aware of the BindView RAZOR team bug release policy — no advisory unless the vendor has a patch. So they all blamed each other and all say “we won’t patch.” Getting CERT involved did not help, they were told the same thing, knowing BindView would not release an advisory. CERT could not release anything independently as they need a vendor or vendors to blame, and they all blamed each other.

Isn’t the security industry wonderful?

The bug is ever so simple. Create an email message, stick in a huge X-* header, like X-Testing: VeryLongStringHere. You get the idea. Now end the message before adding a message body. That’s the trick. What happens is interesting. This is a completely invalid email message, and the X-Whatever spills into the area in an Outlook client that the message body is displayed. So you send the VeryLongStringHere thing with the EICAR test virus string on the end, no anti-virus is triggered, and you get the EICAR test string clearly visible in the message window. Why? Because the existing (at the time) APIs Microsoft gave the vendors did not allow for scanning of anything other than the body of a message, so if you stick stuff in the headers it is not scanned. The vendors could pay for APIs that allowed for inbound scanning and outbound scanning (some only would choose inbound), but no one had APIs to scan headers. Microsoft would not give them up. The vendors said Microsoft should fix Outlook to not display header info to the end user in the area where the message was, Microsoft said they did not handle invalid email and were following RFCs. Whine, whine, whine.

The main thing was this evil header message, although it actually lead to another bug. The easiest method to create it was to telnet into port 25 on a box running Sendmail and doing the whole MAIL FROM and RCPT TO thing manually, and shoving in a huge X-Header, followed by QUIT. Boom off it went on to its destination, an Exchange server with a waiting Outlook client to view it. The telnet-to-port-25 trick did not work in going directly to Exchange though. Why? More exploring found another bug…

Sendmail had an issue in handling headers, creating the mangled message. A very LARGE header caused a crash. What was the issue? A damned heap overflow. OMGWTF. I had a nice remote AV bypass, but now I had a heap overflow in Sendmail. Both port 25, which is ALWAYS open in the firewall. However I was told by BindView to stop working on the Sendmail bug.

The Sendmail flaw was never pursued to see what all was possible with it, as BindView said we would not publish details on it anyway as it could possibly lead people to figure out how to do the AV bypass thing. It was reported to Sendmail as is, they saw the potential implications and (according to them) did not even see if it was exploitable, they just assumed it was and they fixed it (quickly and without a bunch of crap, Eric and Claus were whom I worked with and they rocked it). Anyone with a bit of rev engineering skills could have figured out what was up, but no one did, or didn’t say anything publicly.

As a side note, the Sendmail folk thought that Microsoft should fix handling of the non-RFC compliant messages that were sticking the EICAR test virus into the message body in Outlook, being that Sendmail had tons of patches to correct problems caused by other mail systems, simply because they knew it would make life easier for the sys admins. Wow, what an attitude, caring about the users. This is the main reason I still use Sendmail to this day — they actually give a shit.

So the main bug in AV was surpressed. And a second bug, a potential remote code execution bug in Sendmail was surpressed as well. The funny part? I was trying to screw up the way Outlook handled the X-Message-Away header, thinking I could get a nice client overflow, and found two other bugs instead.

So there you have it. A tale of two bugs, and a small bit of insight into the politics of bug hunting. [/private]

]]> http://www.hackersforcharity.org/hackers-for-charity/a-tale-of-two-bugs/feed/ 0 http://www.hackersforcharity.org/hackers-for-charity/welcome-to-the-informer/ http://www.hackersforcharity.org/hackers-for-charity/welcome-to-the-informer/#comments Sun, 19 Apr 2009 03:08:11 +0000 Johnny http://johnny.ihackstuff.com/?p=12 The Informer is a fund raising effort run by Hackers For Charity. It is designed to give subscribers a “backstage pass” to the world of Information Security. 100% percent of the proceeds go into our food program in East Africa, designed to stand in the gap for children that are waiting for help from major aid organizations. Click here to learn more about the Informer, and thanks for considering helping out.