December 4, 2007
Malware headaches
I`m still amazed by technical aspects of STORM worm , and following related technical news . This new generation malware really made serious problems out there , and is still on top . Following this topic , I`ve to mention an article on another interesting headache cause in malwares wild world known as FLUX , posted by McAfee guys at AVRT-Labs blog. I don`t usually post about other blog posts and simply transfer interesting ones to you by bookmarking it in "My Browsing History" list, but this is another exception I believe worth double-bookmarking :) Here you can read part-1 and part-2 .
November 27, 2007
New beta version of Burp-Suite !
Today I saw an interesting blog post from PortSwigger , finaly announcing new beta release of Burp-Suite . Reade details here . I`ve not got the chance to fully review new beta release but some known bugs I was aware of , are hopefully fixed . And Burp-suit now have it`s own integrated cookie & session analyzing tool , named as "Burp Sequencer" . "Burp Decoder" is another addition . Although a encode/decode tool was really missing in suite but I still prefer using IO-Active`s Morf for this purpose , among the Decoder .
There are many web-application auditing packages and suites out there. Skipping Burp , here is list of some of well-designed and usable ones :
There are many web-application auditing packages and suites out there. Skipping Burp , here is list of some of well-designed and usable ones :
- WebSarab & WebSaurab-NG by OWASP
- SPI-Toolkit by SPIDynamics ( now HP!)
- Suru by SensePost
- SPIKE-Proxy by Immunity
- ParosProxy by Paros
- ... { Add tens of other known personal suites here ! }
Based on nature of audited application , and depending on our plan on how to audit the web-application , #1 suite changes usually . For example , if you`re going to fuzz parameters SPI`s fuzzer is second to none . If you look for automated traffic mannipulation and data replacement while relaying traffic , Burp-Proxy is the best answer , and so on . Although we usually have all or most of these tools available in our tool-box , but there`s usually a suite that`s used more occasionally than others , and I`ve to say for me , Burp-Suite is the one !
There are two exceptions in mentioned list . SPI-Toolkit is a commercial suite, and SPIKE-Proxy is actually a web-application fuzzer more than auditing suite , although it have powerful features for manipulating traffic while relaying through it`s web-interface .
Time to leave office . till next post...
There are two exceptions in mentioned list . SPI-Toolkit is a commercial suite, and SPIKE-Proxy is actually a web-application fuzzer more than auditing suite , although it have powerful features for manipulating traffic while relaying through it`s web-interface .
Time to leave office . till next post...
November 22, 2007
Embedded fun - Hacking MP3 players (MuVo-v200)
As I promised , here`s first post on hacking embedded systems.
In a very brief sentence , embedded systems are family of devices , designed for very specific tasks. read Wikipedia article on embedded systems if you`re not familiar with them.
Every single embedded system (or device, if you like this word more) you may find around , have it`s very specific operating system , which is designed based on a core component ,usually a SoC (System On Chip) . I`ll call it 'chip' from now on . Depending on functionality of device , different chips are used , and depending on used chips different operating systems are loaded and executed . In case of embedded systems , operating system is called Firmware .
It may look funny but from your MP3 player or digital camera to your micro-wave oven , all have their specific OS and are considered an embedded system . Basically most of those digital devices around you are some kind of embedded system . You got the point ,right ? ok let`s continue .
Focusing on multimedia players , it`s easier to break them apart and study every single piece of an embedded system. Everybody out there have some story about hacking complex embedded devices such as wireless routers or IP cameras , and everybody try them because it`s actually some kind of linux hacking and programming challenges IMO . There are many creative and cool hacks out there for IP cameras or printers , turning them to your attack platform for further internal compromises. Hacking IP cameras is really fun and I`ll dedicate another post explaining how to convert an AXIS ( or any other brand ) camera to a proxy , for browsing and attacking internal networks.
Back to mp3 players, I consider them very popular devices ,every one carrying one in his pocket or bag . So finding any possibility and vector on them to turn them into evil devices would affect very high number of people. Enough theory , let`s get our hands dirty a bit .
So I decided to know my Creative MuVo-v200 better. Although I learned how to do it the lame way , but I`ll tell you how not to do it , without voiding guarantee of your device. First attempt to hack my MuVo was just to learn internals of an embedded system , but the more I learned about them , better ideas appeared on abuse possibilities .
First step was checking used chips and hardware parts . well , an mp3 player is nothing but a mix of a flash-memory , LCD , and a DSP ( Digital Signal Processor ) . DSP is heart of every mp3 player and can be considered the SoC I`ve mentioned before . DSP is the part boot and use firmware of your device from it`s internal memory . Note that flash-memory used for storing firmware is apart from the flash-memory used for storing songs or files. In case of MuVo-v200 , file storage flash-memory can be unplugged and used as a normal flash disk .
As I didn`t knew I can use Google to find used chip on my device, I opened the cover to take a look :
Heart of device is a SIGMATEL STMP3510 DSP chip .
As usual , checking vendor site returned nothing interesting but few technical marketing papers. There I just learned few tips about internals of STMP 35xx chips. Not bad , but far away from 'enough' . So I googled for more technical details about chip and found interesting notes here . Now I know that my MuVo-v200 is using Motorolla DSP56004-compatible 24-bit signal processor as it`s actual heard of SoC . This also tells me that I should look for technical notes on developing code based on Motorola chips . This piece of information will be used later on studying firmware . Searching for more information about used Motorola chip landed me here . Not every line of this document was interesting for now , but at least gave us the point on what other documents we should look for , for farther technical details. These two data sheets ( 1 , 2 ) also had interesting information inside but second one was really boring and actually had nothing to do with what I was looking for. Finding information about your chip some times may not be this simple, and usually some documents are provided only to resellers or manufactures. Here`s the time to try p2p file-sharing networks . Reading and reviewing these hardware specifications is really boring so that`s enough for now . Now we have enough information about capabilities of the chip and the way it really works. Poor firmware developers, they should study them line by line .... :-/
Time to check firmware ,and software part of the mp3 player. At first glance you may think where the hell from , I can find the firmware of my device ? Well , there are some known ways but we all prefer the most lame tricks :)
The hard way is using some USB device debuggers , which are consisted of a hardware device ,and some software parts using the hardware as their source . We can use them to gain direct access to memory of chip , and dump it . hmm not so interesting for somebody like me know any shit about this topic. so let`s find easier method.
Checking vendor web-site, I noticed that they provide updates for firmwares . cool ! In general you should always go check "support" or "downloads" section of your vendor`s site . If they release anything related to our mission , it`s usually placed there . Files related to my mp3-player are published here .
As you see , among new firmware package there`s another package called "Mass storage Driver" . We get them both . later I`ll tell you more about second package . Now we have a setup package for upgrading firmware . I installed it and instantly checked packages contents . An executable file responsible for handling GUI works, and two other executable files looking like to make the device ready for upgrade process . Other interesting contents of package was two device-driver files , and checking related .ini files beside them told me they are used for loading/unloading device in repair-mode . Before attempting to really upgrade firmware , don`t forget to backup files stored on memory of your devices . Upgrade will usually erase them (although not necessary) . Second , try to find current version of your fimware from vendor site or any other trusted place , and have it for unexpected situations . It`s because some times new firmwares just fuck your device and REMOVE some functionalities you had before , and if you miss old firmware version , you`ll loose them for ever . In case of MuVo , new firmware reduced power of output sound level ! Although they did it to take care of health of my ears but I really missed old loud sound . If you don`t know current version of firmware, firmware upgrade program usually tells you , before upgrading to new firmware .
When you attach USB device to system , OS detect it as a simple storage media , let you upload your files to device . But as you`ve already guessed , this way we can not access memory-chip to upload/download firmware files . Firmware upgrade program actually look for attached device , and try to mount it in a specific way , to be able to access ( read/write) low-level data through USB interface . After successfully mounting device in raw mode , it will attempt to upload new firmware files .
MP3-players firmwares are usually consisted of four binary files. Although files I`ll mention are specific for MuVo players , but usually any device which is build based on same chip (SIGMATEL in our case ) have same or alike names and have exactly the same functionality . The reason is that , although different vendors ship different options and packages , but if they use same chip , they must have follow same specific rules provided by chip manufacture. Let`s review firmware files .
Monitoring firmware upgrade software with simple tools like regmon.exe and procmon.exe (SysInternal tools) you can easily monitor activity of software and upgrade process. Watching upgrade process with these tools , it`s possible to see names and location of files software use as firmware and upload them . Although firmware binary files are really obvious and can be easily differentiate from other files in installer package , but I just mentioned this way in case they are not easily located in your environment or package .
As you see , after some junk events , software finally begin reading small blocks of data from firmware files , and write them to chip memory in raw mode . So now we have name of pieces of firmware files and we can turn back to contents of setup package . There are four files , and I`ll briefly explain their purposes .
Bootmanage.sb is self explaining . This piece of firmware acts like a boot manager in your pc , for mp3 player . When device is powered on , this binary is loaded in memory and try to load the right next-stage of firmware in memory of device. The point is that these devices usually have two working modes . One working mode is when you attach device to your system as a removable media, and the other mode is when you power-on device by battery and listen to music ... . Device have two different firmwares for above modes , so Bootmanager check and see which working mode it`s in , and load appropriate firmware.
usbmsc.sb is the firmware bootmanager load , if it detect device is connected to a USB port . This is actually the firmware introduce your mp3-player as a removable storage media , when you plug it in your pc .
stmpsys.sb is the firmware loaded by bootmanage , when you normally use your player . this is the part we should plan for evil modifications .
resource.bin is a binary file containing resources as it names tell us . When you use your mp3 player you`re working with some menus, you see some images ,texts and etc ... . This is the file holding them all . I`ll explain how to have some fun with this file .
Here you can find more information related to MuVo and other players based on STMP chip.
So far , we learned how to find information about hardware part of our device, check used chip , find it`s capabilities and finally grab firmware files and do a sample upgrade. what next ?
Easy task is to hack visual effects of your mp3-player and customize it to amaze your friends by some odd contents on LCD of your mp3-player. In order to do this , you don`t need to know much details about firmware itself . All you have to do is modifying right contents on resource.bin file , and upload new firmware to your device.
Of course , modifying resource.bin is not as simple as opening it in your favorite editor and change binary data . Firmwares and linked files are usually packed and encoded (some times even worse , encrypted ! ) so modifying raw binary data will corrupt the binary image . In case of SIGMATEL , the hard work of identifying used mechanism to decode firmware and resource files is already done , and to hack your resource.bin file , you simply need to download and use a tiny program . As an example , you can modify and replace resources "0651" and "0652" to replace Creative logo , with your own image . So when you power-on your player you`ll see modified image .
There`s only one note to remember before attempting to resource-hack your mp3-player :
If upgrade process terminated before successful finish by ANY reason (system crash in my case!) be warned that your mp3-player will NOT be usable after failed upgrade process . Not as mp3-player nor even simple flash-disk . But don`t panic , it`s easy to recover and clean-up messes . Remember "Mass Storage Driver" I mentioned before ? Here`s where you need it . All standard mp3-players have a recovery mode for such times. By using a special set of instructions ( like pressing and holding a key on player) while plugging it to USB port , you can switch to recovery mode . In case of MuVo , it`s holding and pressing 'play' button while plugging it to usb port , and you should hold the key until system detect device . Now you can run firmware upgrade software again , and upload firmware again . This instruction may be different for other manufactures , so ask google .
Here the easy part finishes .
Hacking MP3-Player firmwares:
Let`s discuss some serious works and review possible real attack vectors . This is where things get really interesting . Abusing portable media/devices as attack vectors for infecting and attacking end-users is not a new idea nor a new unknown techniques. I`ll briefly review finished works on this topic and finally explain my idea .
Portable devices , or to be more specific flash memories , are well-known for being abused to attack users. A simple and easy vector is infecting file contents and using the Autorun , to execute our malware . Since availability of U3 flash memories, things changed a lot , and new vectors discovered and implemented . But they all were using same trick : using Autorun to execute a file , when plugged to system by user . My favorite story about this trick was the way some attackers tried spreading some infected flash disks among corporate users , and almost all of them curiously plugged the infected flash disk ,and game was over .
The other known attack vector based on using removable devices (This time focusing on a more general vector , USB interface ) was hacking the flash chip itself, to cause overflows on guest operating system . This is also discussed publicly and some demos also presented , in BlackHat 2005 . I contacted Barral recently and he was nice enough to provide some detailed information about their previous work and findings . A detailed post is required to cover findings in this field and some more technical details, which are not presented anywhere else yet . As this vector require extensive work on developing code in kernel land , and I`m a lame at that , I`ve almost paused research on this vector , till get another chance to work on this with other researchers like Barrel ( Thanks for your help Darrin , if you read here! ) .
Back to my own idea , I`ve not been looking for yet another way to autorun malwares placed on flash-disk , nor exploit any flaw through USB interface or device-drivers, as Darrin and Dave presented in BlackHat .
Recently I came across an interesting article titled "Attacking consumer embedded devices" in INSECURE MAGAZINE 14 , covering this topic (hacking embedded devices) . I highly recommend you read it , if you`re not familiar with embedded device hacking techniques .
The new idea is hacking (customizing) firmware of mp3 players in some way that they act as our infection engine. Looking at current available SDK packages for developing mp3-player firmwares , confirm this possibility . New mp3-players ( like MuVo-v200 ) are now capable of writing to flash , among various reading capabilities . And implementing _writing_ to files means much ! Current firmwares are capable of doing complex encode/decode of music files , or browse and modify (currently only delete ) files on attached flash memory . So why not add new module to their firmware to do our tasks , say modifying stored files on memory ?
An output of this research will be a customized version of firmware , which is capable of doing following tasks :
In a very brief sentence , embedded systems are family of devices , designed for very specific tasks. read Wikipedia article on embedded systems if you`re not familiar with them.
Every single embedded system (or device, if you like this word more) you may find around , have it`s very specific operating system , which is designed based on a core component ,usually a SoC (System On Chip) . I`ll call it 'chip' from now on . Depending on functionality of device , different chips are used , and depending on used chips different operating systems are loaded and executed . In case of embedded systems , operating system is called Firmware .
It may look funny but from your MP3 player or digital camera to your micro-wave oven , all have their specific OS and are considered an embedded system . Basically most of those digital devices around you are some kind of embedded system . You got the point ,right ? ok let`s continue .
Focusing on multimedia players , it`s easier to break them apart and study every single piece of an embedded system. Everybody out there have some story about hacking complex embedded devices such as wireless routers or IP cameras , and everybody try them because it`s actually some kind of linux hacking and programming challenges IMO . There are many creative and cool hacks out there for IP cameras or printers , turning them to your attack platform for further internal compromises. Hacking IP cameras is really fun and I`ll dedicate another post explaining how to convert an AXIS ( or any other brand ) camera to a proxy , for browsing and attacking internal networks.
Back to mp3 players, I consider them very popular devices ,every one carrying one in his pocket or bag . So finding any possibility and vector on them to turn them into evil devices would affect very high number of people. Enough theory , let`s get our hands dirty a bit .
So I decided to know my Creative MuVo-v200 better. Although I learned how to do it the lame way , but I`ll tell you how not to do it , without voiding guarantee of your device. First attempt to hack my MuVo was just to learn internals of an embedded system , but the more I learned about them , better ideas appeared on abuse possibilities .
First step was checking used chips and hardware parts . well , an mp3 player is nothing but a mix of a flash-memory , LCD , and a DSP ( Digital Signal Processor ) . DSP is heart of every mp3 player and can be considered the SoC I`ve mentioned before . DSP is the part boot and use firmware of your device from it`s internal memory . Note that flash-memory used for storing firmware is apart from the flash-memory used for storing songs or files. In case of MuVo-v200 , file storage flash-memory can be unplugged and used as a normal flash disk .
As I didn`t knew I can use Google to find used chip on my device, I opened the cover to take a look :
Heart of device is a SIGMATEL STMP3510 DSP chip .
As usual , checking vendor site returned nothing interesting but few technical marketing papers. There I just learned few tips about internals of STMP 35xx chips. Not bad , but far away from 'enough' . So I googled for more technical details about chip and found interesting notes here . Now I know that my MuVo-v200 is using Motorolla DSP56004-compatible 24-bit signal processor as it`s actual heard of SoC . This also tells me that I should look for technical notes on developing code based on Motorola chips . This piece of information will be used later on studying firmware . Searching for more information about used Motorola chip landed me here . Not every line of this document was interesting for now , but at least gave us the point on what other documents we should look for , for farther technical details. These two data sheets ( 1 , 2 ) also had interesting information inside but second one was really boring and actually had nothing to do with what I was looking for. Finding information about your chip some times may not be this simple, and usually some documents are provided only to resellers or manufactures. Here`s the time to try p2p file-sharing networks . Reading and reviewing these hardware specifications is really boring so that`s enough for now . Now we have enough information about capabilities of the chip and the way it really works. Poor firmware developers, they should study them line by line .... :-/
Time to check firmware ,and software part of the mp3 player. At first glance you may think where the hell from , I can find the firmware of my device ? Well , there are some known ways but we all prefer the most lame tricks :)
The hard way is using some USB device debuggers , which are consisted of a hardware device ,and some software parts using the hardware as their source . We can use them to gain direct access to memory of chip , and dump it . hmm not so interesting for somebody like me know any shit about this topic. so let`s find easier method.
Checking vendor web-site, I noticed that they provide updates for firmwares . cool ! In general you should always go check "support" or "downloads" section of your vendor`s site . If they release anything related to our mission , it`s usually placed there . Files related to my mp3-player are published here .
As you see , among new firmware package there`s another package called "Mass storage Driver" . We get them both . later I`ll tell you more about second package . Now we have a setup package for upgrading firmware . I installed it and instantly checked packages contents . An executable file responsible for handling GUI works, and two other executable files looking like to make the device ready for upgrade process . Other interesting contents of package was two device-driver files , and checking related .ini files beside them told me they are used for loading/unloading device in repair-mode . Before attempting to really upgrade firmware , don`t forget to backup files stored on memory of your devices . Upgrade will usually erase them (although not necessary) . Second , try to find current version of your fimware from vendor site or any other trusted place , and have it for unexpected situations . It`s because some times new firmwares just fuck your device and REMOVE some functionalities you had before , and if you miss old firmware version , you`ll loose them for ever . In case of MuVo , new firmware reduced power of output sound level ! Although they did it to take care of health of my ears but I really missed old loud sound . If you don`t know current version of firmware, firmware upgrade program usually tells you , before upgrading to new firmware .
When you attach USB device to system , OS detect it as a simple storage media , let you upload your files to device . But as you`ve already guessed , this way we can not access memory-chip to upload/download firmware files . Firmware upgrade program actually look for attached device , and try to mount it in a specific way , to be able to access ( read/write) low-level data through USB interface . After successfully mounting device in raw mode , it will attempt to upload new firmware files .
MP3-players firmwares are usually consisted of four binary files. Although files I`ll mention are specific for MuVo players , but usually any device which is build based on same chip (SIGMATEL in our case ) have same or alike names and have exactly the same functionality . The reason is that , although different vendors ship different options and packages , but if they use same chip , they must have follow same specific rules provided by chip manufacture. Let`s review firmware files .
Monitoring firmware upgrade software with simple tools like regmon.exe and procmon.exe (SysInternal tools) you can easily monitor activity of software and upgrade process. Watching upgrade process with these tools , it`s possible to see names and location of files software use as firmware and upload them . Although firmware binary files are really obvious and can be easily differentiate from other files in installer package , but I just mentioned this way in case they are not easily located in your environment or package .
As you see , after some junk events , software finally begin reading small blocks of data from firmware files , and write them to chip memory in raw mode . So now we have name of pieces of firmware files and we can turn back to contents of setup package . There are four files , and I`ll briefly explain their purposes .
Bootmanage.sb is self explaining . This piece of firmware acts like a boot manager in your pc , for mp3 player . When device is powered on , this binary is loaded in memory and try to load the right next-stage of firmware in memory of device. The point is that these devices usually have two working modes . One working mode is when you attach device to your system as a removable media, and the other mode is when you power-on device by battery and listen to music ... . Device have two different firmwares for above modes , so Bootmanager check and see which working mode it`s in , and load appropriate firmware.
usbmsc.sb is the firmware bootmanager load , if it detect device is connected to a USB port . This is actually the firmware introduce your mp3-player as a removable storage media , when you plug it in your pc .
stmpsys.sb is the firmware loaded by bootmanage , when you normally use your player . this is the part we should plan for evil modifications .
resource.bin is a binary file containing resources as it names tell us . When you use your mp3 player you`re working with some menus, you see some images ,texts and etc ... . This is the file holding them all . I`ll explain how to have some fun with this file .
Here you can find more information related to MuVo and other players based on STMP chip.
So far , we learned how to find information about hardware part of our device, check used chip , find it`s capabilities and finally grab firmware files and do a sample upgrade. what next ?
Easy task is to hack visual effects of your mp3-player and customize it to amaze your friends by some odd contents on LCD of your mp3-player. In order to do this , you don`t need to know much details about firmware itself . All you have to do is modifying right contents on resource.bin file , and upload new firmware to your device.
Of course , modifying resource.bin is not as simple as opening it in your favorite editor and change binary data . Firmwares and linked files are usually packed and encoded (some times even worse , encrypted ! ) so modifying raw binary data will corrupt the binary image . In case of SIGMATEL , the hard work of identifying used mechanism to decode firmware and resource files is already done , and to hack your resource.bin file , you simply need to download and use a tiny program . As an example , you can modify and replace resources "0651" and "0652" to replace Creative logo , with your own image . So when you power-on your player you`ll see modified image .
There`s only one note to remember before attempting to resource-hack your mp3-player :
If upgrade process terminated before successful finish by ANY reason (system crash in my case!) be warned that your mp3-player will NOT be usable after failed upgrade process . Not as mp3-player nor even simple flash-disk . But don`t panic , it`s easy to recover and clean-up messes . Remember "Mass Storage Driver" I mentioned before ? Here`s where you need it . All standard mp3-players have a recovery mode for such times. By using a special set of instructions ( like pressing and holding a key on player) while plugging it to USB port , you can switch to recovery mode . In case of MuVo , it`s holding and pressing 'play' button while plugging it to usb port , and you should hold the key until system detect device . Now you can run firmware upgrade software again , and upload firmware again . This instruction may be different for other manufactures , so ask google .
Here the easy part finishes .
Hacking MP3-Player firmwares:
Let`s discuss some serious works and review possible real attack vectors . This is where things get really interesting . Abusing portable media/devices as attack vectors for infecting and attacking end-users is not a new idea nor a new unknown techniques. I`ll briefly review finished works on this topic and finally explain my idea .
Portable devices , or to be more specific flash memories , are well-known for being abused to attack users. A simple and easy vector is infecting file contents and using the Autorun , to execute our malware . Since availability of U3 flash memories, things changed a lot , and new vectors discovered and implemented . But they all were using same trick : using Autorun to execute a file , when plugged to system by user . My favorite story about this trick was the way some attackers tried spreading some infected flash disks among corporate users , and almost all of them curiously plugged the infected flash disk ,and game was over .
The other known attack vector based on using removable devices (This time focusing on a more general vector , USB interface ) was hacking the flash chip itself, to cause overflows on guest operating system . This is also discussed publicly and some demos also presented , in BlackHat 2005 . I contacted Barral recently and he was nice enough to provide some detailed information about their previous work and findings . A detailed post is required to cover findings in this field and some more technical details, which are not presented anywhere else yet . As this vector require extensive work on developing code in kernel land , and I`m a lame at that , I`ve almost paused research on this vector , till get another chance to work on this with other researchers like Barrel ( Thanks for your help Darrin , if you read here! ) .
Back to my own idea , I`ve not been looking for yet another way to autorun malwares placed on flash-disk , nor exploit any flaw through USB interface or device-drivers, as Darrin and Dave presented in BlackHat .
Recently I came across an interesting article titled "Attacking consumer embedded devices" in INSECURE MAGAZINE 14 , covering this topic (hacking embedded devices) . I highly recommend you read it , if you`re not familiar with embedded device hacking techniques .
The new idea is hacking (customizing) firmware of mp3 players in some way that they act as our infection engine. Looking at current available SDK packages for developing mp3-player firmwares , confirm this possibility . New mp3-players ( like MuVo-v200 ) are now capable of writing to flash , among various reading capabilities . And implementing _writing_ to files means much ! Current firmwares are capable of doing complex encode/decode of music files , or browse and modify (currently only delete ) files on attached flash memory . So why not add new module to their firmware to do our tasks , say modifying stored files on memory ?
An output of this research will be a customized version of firmware , which is capable of doing following tasks :
- Scan contents of flash-memory , locating interested file formats
- Based on detected file-format , select a pre-defined payload and inject it into stored files
- Modify flash-memory content and inject (write) new autorun files to it . (Smart implementation of old hack!)
- Load appropriate modified usbmsc.sb , to trigger classic overflow attack vectors
- Some rootkit functionality! , to steal interesting files and hide .
- {Many other interesting options...}
In order to achieve any of above tasks , extensive work is required for two main reasons. First , all works should be done under ASM , and even more painful not normal ASM , but a limited version due to architecture of used processor which is NOT a general purpose processor . Second problem is learning how to implement functionalities which require learning current codes through reading them , a tedious and hard work even for ASM experts !
In order to be able to write assembly code for used chip , developer must first locate a reference . As these chips are designed to be re-packaged , hopefully it`s easy to find such reference manual . I could find assembler reference for used Motorola DSP chips here . Such references can not be used to learn assembly from base , but should be used by an experienced assembly developer , to migrate his knowledge to new platform .
Next step would be finding a SDK , providing a base for developing new firmware . Don`t even think about developing a firmware from scratch , because developing new firmware based on available SDK is complex enough ! SKD packages are usually commercial and are not available to public . Creative for example , in order to develop his custom firmware for branded mp3-players should purchase SDK specifically designed for Sigmatel chips , from Sigmatel . And prices are not usually much end-user friendly ! But p2p file-sharing networks are not died yet ;) I could find and download an old version of Sigmatel player SDK easily . it shouldn't`t be hard to locate and download it for other manufactures.
If you remember first paragraphs of this post , I mentioned that there are some documents related to technical details of DSP chip which are not provided free and are classified in some way . Hopefully these documents ( like STMP35xx users manual) are provided with SDK . The SDK package I downloaded had these documents among some other useful PDF files .
So far , based on gathered information , we can build our own mp3-player and customize and develop a custom firmware for it .
Next step , would be building new firmware from source code . If we modify provided codes from SDK or simply want to test raw firmware available in SDK , we should first built it . As we`re cross-compiling , we should find and use a custom compiler supporting target platform and architecture . Asking Google again , reveals that an old customized version of GCC compiler ( 1.x version ) is usually used to compile and build the firmwares based on Motorola 56xxx chips. Here is where I got above note from , but it helped me to find many other resources related to compiling firmwares for Motorola 56xxx chips ,and finally here`s the compiler we need for our work , DSP56k-gcc .Turning back to functionalities of customized firmware , I`ll review some of them with more details .
Scanning contents of flash-memory for interesting file formats , let us locate files in root and sub-directories and reserve their path and extension for later tasks. Some interesting file formats to look for are exe, linux PE files , dll , doc , shell scripts (bat,cmd,sh, etc...) and any file that let us inject payload inside them . The list can be longer , covering media files like mp3,mov,... and possibly ANY file-format that there`s a known vulnerability exist for it !
Injecting payloads based on detected file formats is the main goal of whole of these tasks . A quick and easy implementation in customized firmware may try to infect .exe files as they are easy to modify and it`s easy to code it in asm . You may think that who`ll store .exe in his mp3-player ? The truth is that nowadays mp3-players and flash-disks are actually mixed together and most of people use memory of their mp3-player as their portable stirage media . So many popular file formats may be stored there , among music files . Skipping this possibility ,there are still many known vulnerabilities affecting multimedia file formats ! you can find some interesting samples targeting mp3 , mov and other popular formats in gnucitizen.org blog . Skipping the file-format story and focusing more on injected payload , it can be virtually ANYTHING . the only limitation would be storage of multiple payloads in limited space available for storing firmware files . Payload can be a self-spreading trojan , a key-logger , or anything you imagine .
Infecting file formats is really devilish because like other classical methods , attacker will not make any noise on target system . Classic methods can be blocked with simple prevention methods like disabling autorun . Attacking overflow vulnerabilities are also very unstable , and drawback on using this method is that an end-user can not actually be victim of such attack . because a modified flash-disk will no longer be able to serve it`s legitimate usage if it`s designed to attack device-drivers . Finally it`s not easy to build such flash-disk to be able to attack many different targets(and platforms) . In order to target different systems you must re-program your evil flash-disk .
But using discussed technique , end-user will not notice anything wrong , or even suspicions . Do you really check size of mp3 files every time you listen them? I bet you don`t !
Injecting Autorun files can be used if injection is not possible , for example when there`s no file stored in flash-memory . or when there`s no victim file-format available . this functionality can be used to write autorun files , so when flash-disk is attached , defined tasks/commands are executed .
Load appropriate modified usbmsc.sb , will let us use classic overflow attack in more stable and reliable way . First good point about using multiple usbmsc.sb files , is that we don`t have to re-program our flash-disk for every different target . We can implement a module inside firmware to automatically load best second-stage . Even if we can`t implement an auto-detect method for a smart attack , we can still manually select the right stage from mp3-player menu !
Since this technique (customized firmware) is stealth from user point of view , it will last much longer than classic attacks based on flash-disks . Even a sharp expert will have trouble back-tracing infected files back to firmware of an employee`s mp3-player ! Most people will quickly format the flash-disk you may have gifted them anonymously , but how many of them may really upgrade firmware of device ?
I`m still working on this topic very slowly ,and there are some parts that I can not handle alone. So if you`re interested in this topic feel free to contact me . I may present findings and results of research among some demos in an official upcoming con. , of course if I find a way to bypass my soldier-work and get out of country !!!
hmmm this post is a bit longer than usual , isn`t ?
/* I may update contents of this post to keep it updated or fix errors , or add new items */
In order to be able to write assembly code for used chip , developer must first locate a reference . As these chips are designed to be re-packaged , hopefully it`s easy to find such reference manual . I could find assembler reference for used Motorola DSP chips here . Such references can not be used to learn assembly from base , but should be used by an experienced assembly developer , to migrate his knowledge to new platform .
Next step would be finding a SDK , providing a base for developing new firmware . Don`t even think about developing a firmware from scratch , because developing new firmware based on available SDK is complex enough ! SKD packages are usually commercial and are not available to public . Creative for example , in order to develop his custom firmware for branded mp3-players should purchase SDK specifically designed for Sigmatel chips , from Sigmatel . And prices are not usually much end-user friendly ! But p2p file-sharing networks are not died yet ;) I could find and download an old version of Sigmatel player SDK easily . it shouldn't`t be hard to locate and download it for other manufactures.
If you remember first paragraphs of this post , I mentioned that there are some documents related to technical details of DSP chip which are not provided free and are classified in some way . Hopefully these documents ( like STMP35xx users manual) are provided with SDK . The SDK package I downloaded had these documents among some other useful PDF files .
So far , based on gathered information , we can build our own mp3-player and customize and develop a custom firmware for it .
Next step , would be building new firmware from source code . If we modify provided codes from SDK or simply want to test raw firmware available in SDK , we should first built it . As we`re cross-compiling , we should find and use a custom compiler supporting target platform and architecture . Asking Google again , reveals that an old customized version of GCC compiler ( 1.x version ) is usually used to compile and build the firmwares based on Motorola 56xxx chips. Here is where I got above note from , but it helped me to find many other resources related to compiling firmwares for Motorola 56xxx chips ,and finally here`s the compiler we need for our work , DSP56k-gcc .Turning back to functionalities of customized firmware , I`ll review some of them with more details .
Scanning contents of flash-memory for interesting file formats , let us locate files in root and sub-directories and reserve their path and extension for later tasks. Some interesting file formats to look for are exe, linux PE files , dll , doc , shell scripts (bat,cmd,sh, etc...) and any file that let us inject payload inside them . The list can be longer , covering media files like mp3,mov,... and possibly ANY file-format that there`s a known vulnerability exist for it !
Injecting payloads based on detected file formats is the main goal of whole of these tasks . A quick and easy implementation in customized firmware may try to infect .exe files as they are easy to modify and it`s easy to code it in asm . You may think that who`ll store .exe in his mp3-player ? The truth is that nowadays mp3-players and flash-disks are actually mixed together and most of people use memory of their mp3-player as their portable stirage media . So many popular file formats may be stored there , among music files . Skipping this possibility ,there are still many known vulnerabilities affecting multimedia file formats ! you can find some interesting samples targeting mp3 , mov and other popular formats in gnucitizen.org blog . Skipping the file-format story and focusing more on injected payload , it can be virtually ANYTHING . the only limitation would be storage of multiple payloads in limited space available for storing firmware files . Payload can be a self-spreading trojan , a key-logger , or anything you imagine .
Infecting file formats is really devilish because like other classical methods , attacker will not make any noise on target system . Classic methods can be blocked with simple prevention methods like disabling autorun . Attacking overflow vulnerabilities are also very unstable , and drawback on using this method is that an end-user can not actually be victim of such attack . because a modified flash-disk will no longer be able to serve it`s legitimate usage if it`s designed to attack device-drivers . Finally it`s not easy to build such flash-disk to be able to attack many different targets(and platforms) . In order to target different systems you must re-program your evil flash-disk .
But using discussed technique , end-user will not notice anything wrong , or even suspicions . Do you really check size of mp3 files every time you listen them? I bet you don`t !
Injecting Autorun files can be used if injection is not possible , for example when there`s no file stored in flash-memory . or when there`s no victim file-format available . this functionality can be used to write autorun files , so when flash-disk is attached , defined tasks/commands are executed .
Load appropriate modified usbmsc.sb , will let us use classic overflow attack in more stable and reliable way . First good point about using multiple usbmsc.sb files , is that we don`t have to re-program our flash-disk for every different target . We can implement a module inside firmware to automatically load best second-stage . Even if we can`t implement an auto-detect method for a smart attack , we can still manually select the right stage from mp3-player menu !
Since this technique (customized firmware) is stealth from user point of view , it will last much longer than classic attacks based on flash-disks . Even a sharp expert will have trouble back-tracing infected files back to firmware of an employee`s mp3-player ! Most people will quickly format the flash-disk you may have gifted them anonymously , but how many of them may really upgrade firmware of device ?
I`m still working on this topic very slowly ,and there are some parts that I can not handle alone. So if you`re interested in this topic feel free to contact me . I may present findings and results of research among some demos in an official upcoming con. , of course if I find a way to bypass my soldier-work and get out of country !!!
hmmm this post is a bit longer than usual , isn`t ?
/* I may update contents of this post to keep it updated or fix errors , or add new items */
November 21, 2007
Women and Security (Nmap case)
While browsing Nmap changelog, I came across this paragraph which looked very cool to me:
Reworded an error message after a woman reported that it was "highly offensive and sexist". She also noted that "times have changed and many women now use your software" and "a sexist remark like the one above should have no place in software." The message was: "TCP/IP fingerprinting (for OS scan) requires root privileges. Sorry, dude.". I checked svn blame to call out the insensitive, chauvinistic jerk who wrote that message, but it was me :).
Things change, and women too ! :-)
Btw , today Nmap is trying to be confusing . I tried to do a normap ping scan against some internal firewalled hosts ,and nmap was responding me like an idolt ! normal ICMP through 'ping' command works fine , but Nmap failed to find any live host .
Trying different ping scan methods and switches didn`t help so I became more suspicious. running favorite sniffer told me that Nmap is not sending any ICMP packet at all !
Here`s what Nmap is sendinf as ping proble :
Noticed highlighted protocol type (in red) ? Legitimate flag should be 01 ( ICMP ). What`s going on ? Am I missing something ?
I`m suspected to used platform (win2003 SP2) . I`ll check it from another host and update post if anything new appeared .
Reworded an error message after a woman reported that it was "highly offensive and sexist". She also noted that "times have changed and many women now use your software" and "a sexist remark like the one above should have no place in software." The message was: "TCP/IP fingerprinting (for OS scan) requires root privileges. Sorry, dude.". I checked svn blame to call out the insensitive, chauvinistic jerk who wrote that message, but it was me :).
Things change, and women too ! :-)
Btw , today Nmap is trying to be confusing . I tried to do a normap ping scan against some internal firewalled hosts ,and nmap was responding me like an idolt ! normal ICMP through 'ping' command works fine , but Nmap failed to find any live host .
Trying different ping scan methods and switches didn`t help so I became more suspicious. running favorite sniffer told me that Nmap is not sending any ICMP packet at all !
Here`s what Nmap is sendinf as ping proble :
Noticed highlighted protocol type (in red) ? Legitimate flag should be 01 ( ICMP ). What`s going on ? Am I missing something ?
I`m suspected to used platform (win2003 SP2) . I`ll check it from another host and update post if anything new appeared .
November 19, 2007
An overview of using zero-day exploits in penetration tests
This is yet another post focused on penetration tests and misleading points about them .
I`m hearing a lot about zero-days , un-patched bugs , in the wild exploits for just reported vulnerabilities and many alike terms that finally will lead to a painful compromise , in case the target is not someone with "Defense in depth strategy" in mind. At the other hand I`m faced with people, thinking about professional penetration testers and skilled auditors as magicians !
Talking about pen-tests , many people think that pro. auditors are successful at their tasks because they always have some 0-day kind of bug/exploit/technique/trick available in their hands. It`s really common to hear that "He has probably used a 0-day to own them..." , "You`re ling me , I checked for every single possibility and could not find anything useful. Do you have any 0-day exploit for service X ?!! " , and so on ...
Yes , zero-day stuff will some times guarantee success of missions , but are they really used every time ? Will pen-test fail if every single host/software is updated to latest version ? Will you be hacker-proof if you monitor everything and keep your softwares and systems immune against zero-hour threads ?
I`ll instantly answer NO , to above questions. Doing pen-test for at least 4 years and successfully compromising many banks , government & military services , mission-critical infrastructures and tens of individual companies , I have to say that success of mission was very rarely depended on using private or zero-day stuff ! I`m not saying 'never depended' because some times customers specifically ask for being tested against unknown and zero day vulnerabilities and techniques , but that`s not a general case .
I divide customers into two groups . Those who understand the risk of zero-day attacks and willing to pay enough so their pen-test (and R&D behind tests) cover it, and those who blindly tell you "Try every possible way to break into network " and don`t care about unknown vulnerabilities , assuming being safe against attacks on latest-versions is enough .
So how tests lead to successful compromise , if we`re faced with a patched infrastructure and we have not used ANY zero-day exploit (Although we may have some) ?
Reviewing past projects results, and watching the way most teams manage their networks will tell us that there are always some design flaws and management problems , guarantee the success of hackers .
When I mention design-flaw , I usually mean the way networks are planned and designed , or the way small pieces of a big infrastructure are putted together . This is really common in big networks. Telecommunication or banks networks for example, have many entry/access points among many back-end systems . Assume a bank , have X number of services available to customers , and customers can access these services in Y different ways , and there are Z number of known attacks/vulnerabilities available for every combination .
Therefore we have X*Y*Z number of ways to gain access to interesting data ,and we`re always allowed to test at least few of them. Insecurely allowing branches to connect to central office , is an example for this group of vectors , causing serious risks that affecting infrastructure .
I mentioned management problems too . And I mean the way networks are managed . This covers they way a password-policy is deployed ,to the way administrators keep their systems up-to-date ,configure services and devices ,and monitor & take care of human-factor mistakes . Even a single insecurely configured service can put whole of linked systems at risks , or a single missed security patch can be used as entry point for digging other systems & services .
If you search enough and investigate everything carefully you`ll always find an out-dated thing ! Yes , out-dated means something that have some KNOWN vulnerabilities . This thing can be a firmware , a third-party service or software , an active-x , or even old version of a protocol .
And finally about weak/default/missing passwords ?
There`s yet another interesting vector to investigate , which is not taken seriously by many people trying to break into a network . Foot printing .
I wrote multiple paragraphs right above this sentence about finding X and Y , checking this and that , looking for design flaws and etc ... . Have you ever imagined where all of those information may come from ? They all depend on a good foot-printing process which is the very first of every penetration test . The more you focus on it and do it carefully , the more findings you`ll have to work on for next steps.
I personally had some experiences that effective and deeply foot-printing a target , resulted in finishing pen-test at first step ! Yes , believe me or not , if you search enough and carefully there`s chance to gain access to some critical knowledge about target , without touching a single host in target`s network which may result in instant compromise of data/systems/users . Even if this case do not apply , you`ll always learn very much about your target .
So what`s the point behind writing all these ?
The point is that , why should you use zero-day stuff at all , when there are MANY ways to get close to target without using it ? If a hacker/auditor correctly try every mentioned vector , I can guarantee that he`ll be inside and intruded enough BEFORE reaching the end of first loop of try & discovery !
Some people may ask "why should we waste that much of time & energy, when there`s chance of almost instantly 0wning final targets by using few zero-day stuff ? "
Nice question . The answer is that zero-day stuff are not provided freely or even easily and even more important , not only they are not free but they are usually very expensive ! So the point is that zero-days have their own value and cost and can`t/should n`t be used like normal stuff unless it`s really necessary or asked by customer. Value of every single zero-day thing , should make you think that does it really worth using it against target ? Let me be more clear in providing an example here . Will you use a zero-day vulnerability that costs 20.000$ against a 10.000$ target ? It`s highly depended on you but most people will answer no . Of course you may answer like you use this 20k $ vuln 5 times and you`ll be the winner . This way I`ll wait for you to come back later time , willing to pay 50k $ for same flaw because you have wasted and burnt it previously for multiple cheap targets , and now you`re faced with a hardly locked down target which costs 200k $ ! got the point ?
There`s usually so much time,energy,knowledge and experience behind every single zero-day you gain access to (Either by finding it yourself or paying for it) . So they should be used like golden and final bullets , when there`s no way not to use them .
So , next time you failed in your intrusion attempt , it`s better to look back and see how you`ve finished previous steps and how much careful you`ve been in reviewing and working on your findings , rather than asking God a zero-day . Did you really tried every possible way ? I bet no !
There is still much to write about zero-days , like why/when we should look for them , or the idea behind current zero-day markets and clubs . I`ll prefer to leave these topics for another post. I`d appreciate your comments telling me how to continue this topic or even completely stopping it :)
I`m hearing a lot about zero-days , un-patched bugs , in the wild exploits for just reported vulnerabilities and many alike terms that finally will lead to a painful compromise , in case the target is not someone with "Defense in depth strategy" in mind. At the other hand I`m faced with people, thinking about professional penetration testers and skilled auditors as magicians !
Talking about pen-tests , many people think that pro. auditors are successful at their tasks because they always have some 0-day kind of bug/exploit/technique/trick available in their hands. It`s really common to hear that "He has probably used a 0-day to own them..." , "You`re ling me , I checked for every single possibility and could not find anything useful. Do you have any 0-day exploit for service X ?!! " , and so on ...
Yes , zero-day stuff will some times guarantee success of missions , but are they really used every time ? Will pen-test fail if every single host/software is updated to latest version ? Will you be hacker-proof if you monitor everything and keep your softwares and systems immune against zero-hour threads ?
I`ll instantly answer NO , to above questions. Doing pen-test for at least 4 years and successfully compromising many banks , government & military services , mission-critical infrastructures and tens of individual companies , I have to say that success of mission was very rarely depended on using private or zero-day stuff ! I`m not saying 'never depended' because some times customers specifically ask for being tested against unknown and zero day vulnerabilities and techniques , but that`s not a general case .
I divide customers into two groups . Those who understand the risk of zero-day attacks and willing to pay enough so their pen-test (and R&D behind tests) cover it, and those who blindly tell you "Try every possible way to break into network " and don`t care about unknown vulnerabilities , assuming being safe against attacks on latest-versions is enough .
So how tests lead to successful compromise , if we`re faced with a patched infrastructure and we have not used ANY zero-day exploit (Although we may have some) ?
Reviewing past projects results, and watching the way most teams manage their networks will tell us that there are always some design flaws and management problems , guarantee the success of hackers .
When I mention design-flaw , I usually mean the way networks are planned and designed , or the way small pieces of a big infrastructure are putted together . This is really common in big networks. Telecommunication or banks networks for example, have many entry/access points among many back-end systems . Assume a bank , have X number of services available to customers , and customers can access these services in Y different ways , and there are Z number of known attacks/vulnerabilities available for every combination .
Therefore we have X*Y*Z number of ways to gain access to interesting data ,and we`re always allowed to test at least few of them. Insecurely allowing branches to connect to central office , is an example for this group of vectors , causing serious risks that affecting infrastructure .
I mentioned management problems too . And I mean the way networks are managed . This covers they way a password-policy is deployed ,to the way administrators keep their systems up-to-date ,configure services and devices ,and monitor & take care of human-factor mistakes . Even a single insecurely configured service can put whole of linked systems at risks , or a single missed security patch can be used as entry point for digging other systems & services .
If you search enough and investigate everything carefully you`ll always find an out-dated thing ! Yes , out-dated means something that have some KNOWN vulnerabilities . This thing can be a firmware , a third-party service or software , an active-x , or even old version of a protocol .
And finally about weak/default/missing passwords ?
There`s yet another interesting vector to investigate , which is not taken seriously by many people trying to break into a network . Foot printing .
I wrote multiple paragraphs right above this sentence about finding X and Y , checking this and that , looking for design flaws and etc ... . Have you ever imagined where all of those information may come from ? They all depend on a good foot-printing process which is the very first of every penetration test . The more you focus on it and do it carefully , the more findings you`ll have to work on for next steps.
I personally had some experiences that effective and deeply foot-printing a target , resulted in finishing pen-test at first step ! Yes , believe me or not , if you search enough and carefully there`s chance to gain access to some critical knowledge about target , without touching a single host in target`s network which may result in instant compromise of data/systems/users . Even if this case do not apply , you`ll always learn very much about your target .
So what`s the point behind writing all these ?
The point is that , why should you use zero-day stuff at all , when there are MANY ways to get close to target without using it ? If a hacker/auditor correctly try every mentioned vector , I can guarantee that he`ll be inside and intruded enough BEFORE reaching the end of first loop of try & discovery !
Some people may ask "why should we waste that much of time & energy, when there`s chance of almost instantly 0wning final targets by using few zero-day stuff ? "
Nice question . The answer is that zero-day stuff are not provided freely or even easily and even more important , not only they are not free but they are usually very expensive ! So the point is that zero-days have their own value and cost and can`t/should n`t be used like normal stuff unless it`s really necessary or asked by customer. Value of every single zero-day thing , should make you think that does it really worth using it against target ? Let me be more clear in providing an example here . Will you use a zero-day vulnerability that costs 20.000$ against a 10.000$ target ? It`s highly depended on you but most people will answer no . Of course you may answer like you use this 20k $ vuln 5 times and you`ll be the winner . This way I`ll wait for you to come back later time , willing to pay 50k $ for same flaw because you have wasted and burnt it previously for multiple cheap targets , and now you`re faced with a hardly locked down target which costs 200k $ ! got the point ?
There`s usually so much time,energy,knowledge and experience behind every single zero-day you gain access to (Either by finding it yourself or paying for it) . So they should be used like golden and final bullets , when there`s no way not to use them .
So , next time you failed in your intrusion attempt , it`s better to look back and see how you`ve finished previous steps and how much careful you`ve been in reviewing and working on your findings , rather than asking God a zero-day . Did you really tried every possible way ? I bet no !
There is still much to write about zero-days , like why/when we should look for them , or the idea behind current zero-day markets and clubs . I`ll prefer to leave these topics for another post. I`d appreciate your comments telling me how to continue this topic or even completely stopping it :)
November 14, 2007
Web-applicatoin Vulnerability Scanners War
Do you remember Larry Suto`s paper on comparing few commercial web-app scanners ?
Suto evaluated actually three scanners (NTOSpider,AppScan,WebInspect) , by targeting 3 web-apps while monitoring scan process with Fortify Tracer product .
Well , a paper full of big names !
At first glance , paper looks interesting to anyone unfamiliar with web-app testing , or new to automated tools . I was also surprised how one of evaluated products (NTOSpider) remained anonymous before release of the paper . believe me or not , MANY people changed their minds and refreshed their ratings based on published paper . I think including "code coverage" among "Fortify Tracer" in paper , fooled many readers .
After releasing paper , I was expecting evaluated companies to respond to it , as paper made a lot of noise in community , but we saw a strange silence since release date , till today . As the winner (based on paper ratings), NTOobjective was just busy responding to hundreds of trial-request emails and calls ,and also happy about being rated #1 ! Why shoud they care about accuracy of published paper , when they`ve got their free marketing chance ?
About WatchFire (IBM) and SPI (HP) two companies being supported by world leading researchers in their teams and also unlimited budget for their work , a technical response was expected soon or later . SPI was the first ,to present their response .
Today I noticed SPI released the paper , revealing some realities about the process of evaluations , and how a real evaluation report should be . At first glance you may assume it being a paper to save SPI from being the bad looser in test , but if you finish reading it you`ll notice how clear and more-accurate real results are. And to save your time Jeff Forristal is trying to tell you "WebInspect is not really as bad as mentioned in previous paper!" and also "Suto`s methodology for evaluation was not effective and accurate."
Using WebInspect for so long time as part of my tool-box for (automated) assessments , I was curious about this new scanners war , and the way competitors are going to prove themselves the better one. I`ve to mention that I`ve used all of named scanners in real assessments and personal hard-core evaluations , among some other scanners not mentioned in this war . So I know very well what I`m talking about here .
Focused on technology and logic behind scans and of course accuracy , I`d instantly filter out only WebInspect and NTOspider , leaving other commercial products. Talking about AppScan I`ve to say that it really disappointed me every time I tried to get close to it and evaluating new versions/features released by vendor .
The day I began using WebInspect (back in 2004), most of automated (web-app) scanners were nothing but polished crawlers with capabilities to manipulate/inject some parameters in HTTP protocol and audited application , armored with number of hard-coded vulnerability checks related to known web applications , web servers and few application servers. There was not much intelligences nor effective methodology in background , and you had tens of false positives and missed critical vulnerabilities per scan . WebInspect and NTOspider were a little bit better and faster than other lame scanners and had few optimizations and customization capabilities inside , making them better than others . That was the reason I turned to SPI .
Other interesting point about WebInspect was SPI`s focus and continuous work on enhancing scanner engine and making scan modules more intelligent , rather than releasing burst of new vulnerability checks and hard-coded scan signatures . NTO was almost like SPI , but never as active and productive as SPI . So while closely monitoring NTOspider development and releases , I kept using WebInspect . ( feel free to call me a fan of SPI and their research team! )
Nowadays , scanners changed a lot . They no more try to relay on a massive database of known vulnerabilities and try to check them against target . They`re being designed to crawl and parse web application parameters smartly and check for common vulnerabilities by AI and few hard-coded tricks ,among common brute-forcing .
No need to mention that non of these automated tools are ultimate answer for a customer trying to audit and assess his web-app . IMO web-app scanners are not still effective enough to be able to leave them scan target and give back results we can trust on . They`re not even close to this point ! The truth is that they will never reach this golden point . Web 2.0 technologies as an example , made many of these scanners useless and ineffective , and I`m not going to include tricks and mechanisms recently being used to defeat automated scanner and attack tools . AppScan had some honors on being the only automated scanner for scanning AJAX technology but farther checks showed that it was just a marketing buzz , and it`s scanning methodology is still very poor .
As you saw in SPI`s evaluation paper , from beginning lunching the scanner till analyzing final reports , there must be some knowledgeable expert guiding the scanner , optimizing it in every scan step and finally confirming findings to check for false positives . Even at final step you can`t be sure everything is fully tested and you must repeat whole of audit process manually , to reveal vulnerabilities that can not be discovered by automated tools . Of course this last part is for those who have enough budget to hire an expert and look for something more than just an automatically generated report with tens of junk notes being injected into final report.
Here`s how I usually relay on my automated tools in an assessment targeting web-applications:
Step 1: Try to fingerprint web-server and deployed web-applications by lightly queering application and server and also using common online services such as NetCraft.
Step 2: Try to learn as much as possible about target domain/site/web-app by looking at indexed contents by Google and other search engines. Google is really enough , but I never relay only on it.
Step 3: Try to learn the logic of web-app by grouping step-2 findings and manual browsing web-app , and slightly manipulating parameters.
Step 4: Here`s where I switch to selected automated scanner (based on findings) , if it should be used at all ! I`ll optimize settings and include customizations ,and some times develop custom scan/check modules for scanner, if I notice that current scanner checks are not covering what I`ve found in previous steps . Finally I`ll define new scan policy to include/exclude checks available in vulnerability database .
Three points here .
Point One: There`s really no reason to use automated scanners at every assessment you do unless it`s really required .
Point Two: You must know the scanner you`re using very well , and be able to use all of it`s functionality . Not just following default settings and using provided scan policies.
Point Three: Do not relay on only one automated scanner (commercially or free) ,and do not try to waste your time customizing the scanner. Some times there are simply better choices out there for the purpose you`re trying to customize your scanner for. It`s highly dependent if point two apples to you .A good example is auditing web-sites with very limited dynamic contents or completely static contents . Light free scanners for crawling and brute-forcing directories are much more effective than your giant commercial scanner . This is a sad truth while you remember amount of $ spent for product :) SensePost tools are my favorite replacements at this step.
Step 5: Checking and confirming automated-scanner findings (if used) and identifying missed checks and poorly audited functions .
Step 6: Beginning manual auditing (raw traffic/parameter inspection and manipulation) in order to check for vulnerabilities that are usually missed by automated scanners , or not possible to detect them by scanners at all . Session management and handling vulnerabilities , or flaws in logic of application are good examples for this point. Downloading and auditing source-code of identified web-applications (if available) also fits in this step.
Step 7: Documenting findings and exploits , and preparing initial report. repeating step 2,3 and 6 to discover more items, considering gained knowledge about target.
Step 8: Documenting and preparing final report.
Of course these steps are for a black-box assessment . In other scenarios things really change.
I`m going to finish this post with a well-known sentence :
"Security tools and applications are as effective and good as the person using them."
Suto evaluated actually three scanners (NTOSpider,AppScan,WebInspect) , by targeting 3 web-apps while monitoring scan process with Fortify Tracer product .
Well , a paper full of big names !
At first glance , paper looks interesting to anyone unfamiliar with web-app testing , or new to automated tools . I was also surprised how one of evaluated products (NTOSpider) remained anonymous before release of the paper . believe me or not , MANY people changed their minds and refreshed their ratings based on published paper . I think including "code coverage" among "Fortify Tracer" in paper , fooled many readers .
After releasing paper , I was expecting evaluated companies to respond to it , as paper made a lot of noise in community , but we saw a strange silence since release date , till today . As the winner (based on paper ratings), NTOobjective was just busy responding to hundreds of trial-request emails and calls ,and also happy about being rated #1 ! Why shoud they care about accuracy of published paper , when they`ve got their free marketing chance ?
About WatchFire (IBM) and SPI (HP) two companies being supported by world leading researchers in their teams and also unlimited budget for their work , a technical response was expected soon or later . SPI was the first ,to present their response .
Today I noticed SPI released the paper , revealing some realities about the process of evaluations , and how a real evaluation report should be . At first glance you may assume it being a paper to save SPI from being the bad looser in test , but if you finish reading it you`ll notice how clear and more-accurate real results are. And to save your time Jeff Forristal is trying to tell you "WebInspect is not really as bad as mentioned in previous paper!" and also "Suto`s methodology for evaluation was not effective and accurate."
Using WebInspect for so long time as part of my tool-box for (automated) assessments , I was curious about this new scanners war , and the way competitors are going to prove themselves the better one. I`ve to mention that I`ve used all of named scanners in real assessments and personal hard-core evaluations , among some other scanners not mentioned in this war . So I know very well what I`m talking about here .
Focused on technology and logic behind scans and of course accuracy , I`d instantly filter out only WebInspect and NTOspider , leaving other commercial products. Talking about AppScan I`ve to say that it really disappointed me every time I tried to get close to it and evaluating new versions/features released by vendor .
The day I began using WebInspect (back in 2004), most of automated (web-app) scanners were nothing but polished crawlers with capabilities to manipulate/inject some parameters in HTTP protocol and audited application , armored with number of hard-coded vulnerability checks related to known web applications , web servers and few application servers. There was not much intelligences nor effective methodology in background , and you had tens of false positives and missed critical vulnerabilities per scan . WebInspect and NTOspider were a little bit better and faster than other lame scanners and had few optimizations and customization capabilities inside , making them better than others . That was the reason I turned to SPI .
Other interesting point about WebInspect was SPI`s focus and continuous work on enhancing scanner engine and making scan modules more intelligent , rather than releasing burst of new vulnerability checks and hard-coded scan signatures . NTO was almost like SPI , but never as active and productive as SPI . So while closely monitoring NTOspider development and releases , I kept using WebInspect . ( feel free to call me a fan of SPI and their research team! )
Nowadays , scanners changed a lot . They no more try to relay on a massive database of known vulnerabilities and try to check them against target . They`re being designed to crawl and parse web application parameters smartly and check for common vulnerabilities by AI and few hard-coded tricks ,among common brute-forcing .
No need to mention that non of these automated tools are ultimate answer for a customer trying to audit and assess his web-app . IMO web-app scanners are not still effective enough to be able to leave them scan target and give back results we can trust on . They`re not even close to this point ! The truth is that they will never reach this golden point . Web 2.0 technologies as an example , made many of these scanners useless and ineffective , and I`m not going to include tricks and mechanisms recently being used to defeat automated scanner and attack tools . AppScan had some honors on being the only automated scanner for scanning AJAX technology but farther checks showed that it was just a marketing buzz , and it`s scanning methodology is still very poor .
As you saw in SPI`s evaluation paper , from beginning lunching the scanner till analyzing final reports , there must be some knowledgeable expert guiding the scanner , optimizing it in every scan step and finally confirming findings to check for false positives . Even at final step you can`t be sure everything is fully tested and you must repeat whole of audit process manually , to reveal vulnerabilities that can not be discovered by automated tools . Of course this last part is for those who have enough budget to hire an expert and look for something more than just an automatically generated report with tens of junk notes being injected into final report.
Here`s how I usually relay on my automated tools in an assessment targeting web-applications:
Step 1: Try to fingerprint web-server and deployed web-applications by lightly queering application and server and also using common online services such as NetCraft.
Step 2: Try to learn as much as possible about target domain/site/web-app by looking at indexed contents by Google and other search engines. Google is really enough , but I never relay only on it.
Step 3: Try to learn the logic of web-app by grouping step-2 findings and manual browsing web-app , and slightly manipulating parameters.
Step 4: Here`s where I switch to selected automated scanner (based on findings) , if it should be used at all ! I`ll optimize settings and include customizations ,and some times develop custom scan/check modules for scanner, if I notice that current scanner checks are not covering what I`ve found in previous steps . Finally I`ll define new scan policy to include/exclude checks available in vulnerability database .
Three points here .
Point One: There`s really no reason to use automated scanners at every assessment you do unless it`s really required .
Point Two: You must know the scanner you`re using very well , and be able to use all of it`s functionality . Not just following default settings and using provided scan policies.
Point Three: Do not relay on only one automated scanner (commercially or free) ,and do not try to waste your time customizing the scanner. Some times there are simply better choices out there for the purpose you`re trying to customize your scanner for. It`s highly dependent if point two apples to you .A good example is auditing web-sites with very limited dynamic contents or completely static contents . Light free scanners for crawling and brute-forcing directories are much more effective than your giant commercial scanner . This is a sad truth while you remember amount of $ spent for product :) SensePost tools are my favorite replacements at this step.
Step 5: Checking and confirming automated-scanner findings (if used) and identifying missed checks and poorly audited functions .
Step 6: Beginning manual auditing (raw traffic/parameter inspection and manipulation) in order to check for vulnerabilities that are usually missed by automated scanners , or not possible to detect them by scanners at all . Session management and handling vulnerabilities , or flaws in logic of application are good examples for this point. Downloading and auditing source-code of identified web-applications (if available) also fits in this step.
Step 7: Documenting findings and exploits , and preparing initial report. repeating step 2,3 and 6 to discover more items, considering gained knowledge about target.
Step 8: Documenting and preparing final report.
Of course these steps are for a black-box assessment . In other scenarios things really change.
I`m going to finish this post with a well-known sentence :
"Security tools and applications are as effective and good as the person using them."
October 21, 2007
0+1 Day local privilage escalation exploit on XP/2003
While browsing my bookmarked feeds , I notices this new (actually replaced!) post on Symantec . First I though it`s another post about the case I`ve previously read on their blog but checking my history told me It was same old post, completely changed since my last visit !
I`m really confused about their action . This vulnerability is already well-known and I can say actively being used even BEFORE some companies (Eeye, Symantec , etc. ) report about it . Disclosing yet another toy from black-hats toy-box nor withhelding technical details of an already known (and in the wild )0day flaw is not something new.
What make me confused , is how a big security company like Symantec react . At early discloser time they put a clear screen-shot plus enough technical details on how to trigger/exploit the case like a surprised child getting his new toy , and few hours later (seems dad punished him!) they completely REWRITE (No I don`t mean update) their post , trying to keep safe the new case till Microsoft patch it. Hmm I call it Partial-Full Discloser .
here`s a snip of their silly rewrite :
"At this time, we will not disclose the details of the vulnerability; however, we'll just say that the affected component is a driver that is shipped in many Windows installations by default. It is also included in the \i386 folder. Under some circumstances, this driver can write into the kernel memory without proper restrictions."
Dude , you`ve already published anything a sharp mind needs to exploit the flaw before rewriting your post :>
I was thinking about revealing full technical details about the case , but seems Eeye updated related "Zero-Day Tracker" page and provided enough technical details among PoC and samples.
No need to say that you can reproduce Symantec 0day by help of Kartoffel a usefull tool built to fuzz/test/exploit driver bugs and vulnerabilities . feel free to fill the blanks with your custom shellcode from Metasploit . Checking Ruben`s post will give you cleaned-up technical details.
Hands up for first Milw0rm post !
Have fun.
I`m really confused about their action . This vulnerability is already well-known and I can say actively being used even BEFORE some companies (Eeye, Symantec , etc. ) report about it . Disclosing yet another toy from black-hats toy-box nor withhelding technical details of an already known (and in the wild )0day flaw is not something new.
What make me confused , is how a big security company like Symantec react . At early discloser time they put a clear screen-shot plus enough technical details on how to trigger/exploit the case like a surprised child getting his new toy , and few hours later (seems dad punished him!) they completely REWRITE (No I don`t mean update) their post , trying to keep safe the new case till Microsoft patch it. Hmm I call it Partial-Full Discloser .
here`s a snip of their silly rewrite :
"At this time, we will not disclose the details of the vulnerability; however, we'll just say that the affected component is a driver that is shipped in many Windows installations by default. It is also included in the \i386 folder. Under some circumstances, this driver can write into the kernel memory without proper restrictions."
Dude , you`ve already published anything a sharp mind needs to exploit the flaw before rewriting your post :>
I was thinking about revealing full technical details about the case , but seems Eeye updated related "Zero-Day Tracker" page and provided enough technical details among PoC and samples.
No need to say that you can reproduce Symantec 0day by help of Kartoffel a usefull tool built to fuzz/test/exploit driver bugs and vulnerabilities . feel free to fill the blanks with your custom shellcode from Metasploit . Checking Ruben`s post will give you cleaned-up technical details.
Hands up for first Milw0rm post !
Have fun.
10 IT security companies to watch
NetworkWorld has published an interesting article on security industry.
They have tried to collect top 10 companies offering various security services/solutions and briefly describe each company . Although this article is not the ultimate reference nor something to relay on , but it`s just cool . As I mentioned before this list is not so carefully designed and I see some top ones being missed there .
Here you can read the article .
btw, expect some posts about having fun with embedded devices soon .
They have tried to collect top 10 companies offering various security services/solutions and briefly describe each company . Although this article is not the ultimate reference nor something to relay on , but it`s just cool . As I mentioned before this list is not so carefully designed and I see some top ones being missed there .
Here you can read the article .
btw, expect some posts about having fun with embedded devices soon .
October 15, 2007
BlueHat Fall 2007 Audio records are online
You`re probably aware of MS BlueHat , and you may like to actively follow it .
Fall 2007 session had some interesting ( but already presented at BH2007 ) presentations on DNS rebinding attacks ,fuzzing an few other talks ,good enough to pay attention on .
There are also new topics presented , like interesting talk on win-CE kernel . following that ,next interesting talk IMO would be from Ollie Whitehouse .
Microsoft updated BlueHat page with audio recordings of talks.
Here`s direct download link to them , in case you`re interested in listening to them.
Fall 2007 session had some interesting ( but already presented at BH2007 ) presentations on DNS rebinding attacks ,fuzzing an few other talks ,good enough to pay attention on .
There are also new topics presented , like interesting talk on win-CE kernel . following that ,next interesting talk IMO would be from Ollie Whitehouse .
Microsoft updated BlueHat page with audio recordings of talks.
Here`s direct download link to them , in case you`re interested in listening to them.
DanKaminsky.wma
HalvarFlake.wma
JeffForristal.wma
LureneGrenier.wma
MarkRussinovich.wma
MattMiller.wma
OllieWhitehouse.wma
PedramAmini.wma
PetrMatoucek.wma
RobertoPreatoni.wma
ShaneMacauley.wma
October 10, 2007
SQL Server 2005 & CAIN
CWE List - Dictionary of Software Weakness Types
You all know CVE very well , as one of the most well-know resources about published vulnerabilities and related details . CVE , US-CERT , OSVDB , SecurityFocus BIDs and others are all out there to help you find what`s going on around the world in the filed of information security and vulnerability researches and discoveries . They also briefly categories published information based on their severity, attack surface and few other parameters . Surprisingly most of them leave the reader alone with labels and titles about main category of the vulnerability, for example "Web-app XYZ remote file inclusion" . Well, most users of such resources are people familiar with these basics and they really no need to read what "remote file inclusion" or other titles means, among every item they browse. But how about those who know any about the category ? or any other user visiting the database and getting lost in these long lists of directories and categories ? Some people will shout "Google!" but hey , what if some body looks for a directory of "categories" and their brief descriptions ? Not everyone is interested to follow a long technical paper on CSRF to understand wtf it is !
So, miter community came up with CWE , The solution for this case . read about their approach to get familiar with other aspects of this project .
This directory is also useful for people looking for a brief learning reference to know more about common vulnerabilities . What make CWE useful for this purpose is the way that they have prepared items in directory. Items Containing sample CVE , reference to technical papers , relationship with other categorized items and if the item is parent/child of other items make them a great reference for people looking for those who like to learn more about the item they just got familiar with.
The cool thing about CWE is that, it let you have the directory off line , by simply saving the entire HTML version of directory , and browse it off line . Other interesting materials are also provided in the Sources section .
So, miter community came up with CWE , The solution for this case . read about their approach to get familiar with other aspects of this project .This directory is also useful for people looking for a brief learning reference to know more about common vulnerabilities . What make CWE useful for this purpose is the way that they have prepared items in directory. Items Containing sample CVE , reference to technical papers , relationship with other categorized items and if the item is parent/child of other items make them a great reference for people looking for those who like to learn more about the item they just got familiar with.
The cool thing about CWE is that, it let you have the directory off line , by simply saving the entire HTML version of directory , and browse it off line . Other interesting materials are also provided in the Sources section .
No Describtion ...
This one was a warn ,but this one is really funny !
Wish I could consider it a anti-anti-stupidity (read it honeypot) prepared for collecting some feedback you may easily guess, but the truth is much more disappointing than what I "wish" ...
Do I need to repeat what does "Policy" means ?
Mailing-lists are really dangerous toys, echoing your mistakes to thousands of people , some times leaving no chance for recovery! Some times it`s me hitting "replay-to-all" mistakenly and leaking a just-published E-book to every list member (Yes I`m talking about my foolish replay on MSF list) , and some times it`s somebody like Amir spreading info like that.
Wish I could consider it a anti-anti-stupidity (read it honeypot) prepared for collecting some feedback you may easily guess, but the truth is much more disappointing than what I "wish" ...
Do I need to repeat what does "Policy" means ?
Mailing-lists are really dangerous toys, echoing your mistakes to thousands of people , some times leaving no chance for recovery! Some times it`s me hitting "replay-to-all" mistakenly and leaking a just-published E-book to every list member (Yes I`m talking about my foolish replay on MSF list) , and some times it`s somebody like Amir spreading info like that.
October 1, 2007
Hacking like in the movies
This is what I mean , when ever I`m talking about black-hats , or those we call cyber criminals. An eye opening story about how criminals may disarm you, when they decide to do so . Cyber wars are not just about stealing classified documents by spamming targeted gov emails with 0day client-side vulnerabilities .
Many people keep watching hacker movies and get excited about how a team of talented criminals break into mission-impossible targets and rule the world , and at the end they may say "hey it`s just movie..." . But the truth is that real-world cases and scenarios are really much more sophisticated, exciting and eye-opening than what people see in Hollywood movies .
Many people keep watching hacker movies and get excited about how a team of talented criminals break into mission-impossible targets and rule the world , and at the end they may say "hey it`s just movie..." . But the truth is that real-world cases and scenarios are really much more sophisticated, exciting and eye-opening than what people see in Hollywood movies .
September 18, 2007
Old WEP VS new PTW
We all know that WEP has died long ago, but we all see that it`s still being widely used. Maybe that`s because some administrators can`t imagine the risk of using it on their network. Since 2001, we've seen different implementation of attack methods on WEP , each one boosting previous method , and there are still some ways to improve it ! yes, not all of known academic attacks against WEP are implemented. The most recent attack was released on April 2007 as an academic research paper. Later original researchers of this method implemented this attack and released their proof of concept as a tool named Aircrack-PTW, which is based on famous Aircrack suit ( Aircrack project discontinued and developer moved to Aircrack-NG which is a complete rewrite of previous project ).
Depending on used old attack methods , attacker had to capture number of IVs between 500,000 to 6,000,000 based on used key length and old or new techniques . Simply listening for IVs to arrive may takes days of non-stop sniffing and over 1gig of data packets being captured. Using techniques like arp-request replay injection and other replay attacks in tools like Aireplay it's now possible to force target network ( associated clients ) to generate required number of weak IVs in few minutes. Although documented IV generation rates are very high , but in a real-world scenario and a network with inactive clients it may take more than 30 minutes to gather enough packets. There are many factors affecting the speed and efficiency of attack, which are beyond scope of this post.
The new PTW attack how ever , made this old WEP game even more cool . I remember my old tries on WEP in pen-tests , always having problem on getting enough IVs fast enough. Since release of latest attack , I hadn`t chance to test it in a real-word scenario ,as things in lab do not make me really happy.
So I finally had a target running multiple access points ,one of them still using old WEP configuration. A quick try lead to capture about 50,000 IVs and it was time to give PTW a try . This attack technique has been merged into Aircrack-ng in recent versions , so no need to use PoC code. Compared to old attacks, new one extracted the 128b key almost instantly ! great :)
As you see only ~177Mb of packets captured ,which is about 1/10 of size of captured packets require to extract key with old attacks. The only note on using new PTW attack is that you must use arp replay injection + full header packet capture ,to make clients generate IVs. PTW attack won`t success if you use IV generation techniques other than arp-replay. Sorry, I`m not going to rewrite aircrack-ng & kismet documents on how to play with them!
Btw, CAIN in windows also support arp-replay attack technique , but who's crazy enough to pay ~300$ for a AirPcap-TX while it`s possible to make everything work fine in linux with 0$ ? Are you ?
And a good news for fans of Kismet : expect a brand new release in few days. Although there would be not much for you , if you`re such a SVN guy like me . last Kismet-2007-01-R1b release had some serious bugs which are fixed now . If you follow SVN and missed kismet tree in last days, there was a mysterious bug in kismet_server , making X crash ! thanks to dragorn (the guy behind kismet ) this one is fixed too in latest svn tree.
Depending on used old attack methods , attacker had to capture number of IVs between 500,000 to 6,000,000 based on used key length and old or new techniques . Simply listening for IVs to arrive may takes days of non-stop sniffing and over 1gig of data packets being captured. Using techniques like arp-request replay injection and other replay attacks in tools like Aireplay it's now possible to force target network ( associated clients ) to generate required number of weak IVs in few minutes. Although documented IV generation rates are very high , but in a real-world scenario and a network with inactive clients it may take more than 30 minutes to gather enough packets. There are many factors affecting the speed and efficiency of attack, which are beyond scope of this post.
The new PTW attack how ever , made this old WEP game even more cool . I remember my old tries on WEP in pen-tests , always having problem on getting enough IVs fast enough. Since release of latest attack , I hadn`t chance to test it in a real-word scenario ,as things in lab do not make me really happy.
So I finally had a target running multiple access points ,one of them still using old WEP configuration. A quick try lead to capture about 50,000 IVs and it was time to give PTW a try . This attack technique has been merged into Aircrack-ng in recent versions , so no need to use PoC code. Compared to old attacks, new one extracted the 128b key almost instantly ! great :)
As you see only ~177Mb of packets captured ,which is about 1/10 of size of captured packets require to extract key with old attacks. The only note on using new PTW attack is that you must use arp replay injection + full header packet capture ,to make clients generate IVs. PTW attack won`t success if you use IV generation techniques other than arp-replay. Sorry, I`m not going to rewrite aircrack-ng & kismet documents on how to play with them!
Btw, CAIN in windows also support arp-replay attack technique , but who's crazy enough to pay ~300$ for a AirPcap-TX while it`s possible to make everything work fine in linux with 0$ ? Are you ?
And a good news for fans of Kismet : expect a brand new release in few days. Although there would be not much for you , if you`re such a SVN guy like me . last Kismet-2007-01-R1b release had some serious bugs which are fixed now . If you follow SVN and missed kismet tree in last days, there was a mysterious bug in kismet_server , making X crash ! thanks to dragorn (the guy behind kismet ) this one is fixed too in latest svn tree.
September 14, 2007
BackTrack 3 ...
I've previously blogged a bit about BackTrack 2 , a must-have for any security auditor. I`m not going to rewrite on how and why BackTrack is perfect for assessment task and why it`s the #1 in available free/commercial live security distributions for penetration-test. If you remember I've previously noted that I use a local-install of "Auditor" which was based on Debian. things change, and mee to . I decided to move to slack and play with it for a while . So I replaced old Auditor with BackTrack2 and customized it to feet my needs. Here`s how it looks now :
Yes, that`s latest released paper of pdp on hacking web2.0 . If you you've followed my "browsing history" you've probably got it fresh.
Thanks to Max & Muts , I got chance to join BackTrack 3 and get a beta version. I`m not sure about schedule of publicly releasing first beta , but current state of work shows that it`s at least 1-2 months. wait for cool updates & upgrades , including various new tools and scripts .
Thanks to Max & Muts , I got chance to join BackTrack 3 and get a beta version. I`m not sure about schedule of publicly releasing first beta , but current state of work shows that it`s at least 1-2 months. wait for cool updates & upgrades , including various new tools and scripts .
I just added a complete set of tools for owning web2.0 applications, all based on FireFox. At the moment I`m trying to see if I can integrate new qKismet into a stable working state, based on latest kismet development tree. I`ve some interesting plans which are not still discussed but I hope to be able to implement them.
anything you missed in BackTrack 2 and like to see in BT3 ? shoot me a comment and I`ll try to forward to developers.
and few 0day screen-shots ...
anything you missed in BackTrack 2 and like to see in BT3 ? shoot me a comment and I`ll try to forward to developers.
and few 0day screen-shots ...
I hope muts forgive me for leaking :p
[ Update : ]
After more than 5 hours wasting time and playing with BackTrack , Qt installation and preparing slax packages, qKismet is now showing it`s lovely interface . Just have my friendly advice and prevent compiling Qt 4.3 from source as far as you can ! it took near 4 hours on my 1.8 Dothan laptop. I`ll share the Qt-4.3.1 Slackware package as soon as I get some place to safely host it for long time.
After more than 5 hours wasting time and playing with BackTrack , Qt installation and preparing slax packages, qKismet is now showing it`s lovely interface . Just have my friendly advice and prevent compiling Qt 4.3 from source as far as you can ! it took near 4 hours on my 1.8 Dothan laptop. I`ll share the Qt-4.3.1 Slackware package as soon as I get some place to safely host it for long time.
September 12, 2007
On recent Tor exit point sniffing attempt
Probably you've heard about recent attempt on trying to extract useful information from Tor exit points traffics. The technical aspect of this attempt ( attack !? ) is well-known and even documented and is not something new. The point making it interesting is that gov people use Tor to route their traffic. The day I read this title on SANS it didn`t look much interesting to me as I`ve had the same experience but collecting different set of information from traffic and also trying to cover some encrypted channels like SSL protected stuff. Later I told myself "hey, is any .gov.ir affected by this attempt? " and guess what ? ...
Wish I could publish some of my research results too but as I`m not sure about local gov reaction I prefer to stay silent for now.
And hey, this is not the first time Iran gov is made fun of , because of their lame policies and broken infrastructures. If you follow related news, there are tons of blames against iran. I remember old BlackHat talks , exposing classified informations and maps of IT infrastructures of the country, and my personal investigations lead to even more horrible live results. But after all, who cares ?!!!
Wish I could publish some of my research results too but as I`m not sure about local gov reaction I prefer to stay silent for now.
And hey, this is not the first time Iran gov is made fun of , because of their lame policies and broken infrastructures. If you follow related news, there are tons of blames against iran. I remember old BlackHat talks , exposing classified informations and maps of IT infrastructures of the country, and my personal investigations lead to even more horrible live results. But after all, who cares ?!!!
September 8, 2007
Cna yuo raed tihs?
I cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht I was rdanieg. The phaonmneal pweor of the hmuan mnid, aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it dseno't mtaetr in waht oerdr the ltteres in a wrod are, the olny iproamtnt tihng is taht the frsit and lsat ltteer be in the rghit pclae. The rset can be a taotl mses and you can sitll raed it whotuit a pboerlm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe. Azanmig huh? yaeh and I awlyas tghuhot slpeling was ipmorantt!
Defcon 15 videos now online
It maybe be interesting for those who've missed BlackHat/Defcon for any reason. I`m sure most of you have already reviewed BlackHat/Defcon papers but in some cases papers and slide-shows are not self-explaining very well . so here`s the list of talks available online thanks to Google-video. You may like to watch my favorite talk "Tactical Exploitation" as the first video. This is the short version of BlackHat talk and as Moor comments, "you can record and playback slowly" ;)
Defcon 15 videos
BlackHat US-2007 contents
thanks to mcgrewsecurity.com blog for pointing this out.
Defcon 15 videos
BlackHat US-2007 contents
thanks to mcgrewsecurity.com blog for pointing this out.
September 3, 2007
Core dump
Here's why I've been almost idle recent days .
I've just recovered from a BSOD (read Blue Screen Of...) kind of thing in my real life.
here`s the core dump of the case, for those interested in analyzing it :)
Thanks to God, non of 6 running sub-processes closed and only three of them required some hot-fixes, one being analyzed in I.C.U research-labs for 10 days crash recovery analyze! three critical security holes has been identified and successfully closed on I.C.Ued process . and me... ? I`m not sure why I`m still alive.
just to note : I`m the black one
I've just recovered from a BSOD (read Blue Screen Of...) kind of thing in my real life.
here`s the core dump of the case, for those interested in analyzing it :)
Thanks to God, non of 6 running sub-processes closed and only three of them required some hot-fixes, one being analyzed in I.C.U research-labs for 10 days crash recovery analyze! three critical security holes has been identified and successfully closed on I.C.Ued process . and me... ? I`m not sure why I`m still alive.
just to note : I`m the black one
August 26, 2007
Breaking SQL Server 2005 hashes
Yes, I`m still alive
and yes, this is an old known topic . The only reason made me post about it was that I found no good note about this on security community.
Back to SQL Server 2000 and based on published paper on it`s hashing mechanism , we learned how to gain and crack these hashes. In SQL Server 2005 how ever , things changed a bit.
Let`s have a quick review of password hashes in SQL Server 2000 before we continue.
In order to dump hash of 'SA' account we used to query :
SELECT password from master.dbo.sysxlogins where name='sa'
And the result :
0x010034767D5C0CFA5FDCA28C4A56085E65E882E71CB0ED2503412FD54D6119FFF04129A1D72E7C3194F7284A7F3A
If we break given hash into smaller sections ( [6][8][40][40] ) we`ll have :
0x0100 -->(Constant value)
34767D5C -->(Salt)
0CFA5FDCA28C4A56085E65E882E71CB0ED250341 -->(Case sensitive SHA hash)
2FD54D6119FFF04129A1D72E7C3194F7284A7F3A -->(Upper case SHA hash)
Above is result of "Test" beeing the clear-text password, generated by pwdencrypt() . To make it more clear , here's the result of pwdencrypt() for clear-text password beeing "TEST" which is all uppercase password :
select pwdencrypt('TEST');
0x0100
34767D5C
2FD54D6119FFF04129A1D72E7C3194F7284A7F3A
2FD54D6119FFF04129A1D72E7C3194F7284A7F3A
Now you know how things works. So how to crack these hashes ? well, there are tons of free and commercial tools already released for auditing ( read cracking ) SQL Server 2000 passwords . My favorite commercial one is NGSSqlcrack and as always CAIN being the freeware choice. Non of them are best in performance, but they both work well. Let`s try CAIN for cracking "Test" from SQL Server 2000 case :
And passwords cracked:
Now let`s move to SQL Server 2005. As you may already know in many cases SQL Server 2005 stopped backward compatibility with older versions of the product, and mixed in many security options and features that are beyond scope of this post . The only thing we`ll focus is the way SQL 2005 saves password hashes .
First of all , there`s no more a 'sysxlogins' out there , and you have to query a pre-defined view named [sql_logins] to gain access to usernames and their stored hash values , and this is only accessible for sysadmins . Second note about SQL 2005 we care here is the way it stores hash of password.
Let`s try and see how things changed :
In order to get hash of the password for account 'SA' we query :
SELECT password_hash FROM sys.sql_logins where name='sa'
And the result will be :
0x0100993BF2315F36CC441485B35C4D84687DC02C78B0E680411F
As you see, length of the hash is reduced . A closer look to string (comparing to SQL 2000) and referring to SQL 2005 documents, you`ll notice that the upper case hash has been removed from the string . The reason is obvious; making it harder to guess passwords, but still possible. as nothig changed about the algorithm we can simply use SQL 2000 methods and tools for breaking the hash . so , clear-text password being "Test" we have :
0x0100 -->(Constant value)
993BF231 -->(Salt)
5F36CC441485B35C4D84687DC02C78B0E680411F -->(Case sensitive SHA hash)
[ removed in SQL 2005! ] -->(Upper case SHA hash)
Looks pretty simple, right ? And how we`ll crack this new hash ?
Turning back to CAIN as our cracker , we'll insert hash and salt value from interface as following. the only change since SQL 2000 is that you have to leave "Uppercase Hash" box empty and continue:
And the expected result after successful crack :
That`s it ! the only remaining note you should remember is that if you want to try either brute force or dictionary attack the hash using CAIN , you must use "MixCASE Hash" from menu, or you`ll fail as there`s no "UpperCase Hash" .
Now let's wait and see when Mao ( www.oxid.it ) update his great CAIN to support SQL 2005 and dumping hashes through ODBC connections ;)
cheers to him for such a great project, and keeping it FREE.
April 3, 2007
ShmooCon07 "Hack it" Contest
During Shmoocon2007 there was a contest open to interested hackers. If you're curious about it but hadn`t chance to join the con, well it's still open for you to check your skills but don't expect any reward :> If you like to get familiar with challenges in Cons, you can try this one. It's consisted of 8 levels, each one require different class of skills. you can try it HERE .
If you're not 31337 enough to solve them, here's the answers for you but I highly recommend you NOT to get it before giving the challenge a try . Such challenges are cool until you do not have the answers and should get them yourself . Finally because this challenge comes from ShmooCon does NOT mean it's something magical or hard to solve.
If you're not 31337 enough to solve them, here's the answers for you but I highly recommend you NOT to get it before giving the challenge a try . Such challenges are cool until you do not have the answers and should get them yourself . Finally because this challenge comes from ShmooCon does NOT mean it's something magical or hard to solve.
WOVB - A good learning refrence
Referring to my previous post , here's their first release :
WOVB #01: 2007-04-02 Bypassing Vista Firewall, Flying over obstructive line
Well, to save your time , here's the top result of #1 :
"remote crash(BSOD) by a malformed IPv6 packet on default firewall configuration"
....
Oh wait ! something looked wrong somewhere...
please read this and come back . I'll wait.
Haha , how do you feel now ? :>
Yes, I've been tricked too while quickly reviewing their first advisory. But Jerome's try showed us clearly that HUMAN FACTOR is still the case we should worry about more than anything. Although I believe this try was not a fair one , but still a GREAT example of real world cases! why? because intruders always hit us from the point we never expect. We all knew so called "WOVB Team" and it was the _trust_ a real attacker looks for, as a sample attack vector. As Jerome noted, what if there was some kind of attack-script behind this scenario to infect your system? while reviewing my own weblog's hits, I see >70% of my visitors critically vulnerable to different KNOWN attack vectors. I'm sure he have done such analyze on his own logs too.
I'm too sleepy to continue blogging , but still thinking/laughing about this eye-opening case and the way I've been tricked !
Nice try Jerome ! thanks for not sharing screen-shot of my e-mail as well :D
WOVB #01: 2007-04-02 Bypassing Vista Firewall, Flying over obstructive line
Well, to save your time , here's the top result of #1 :
"remote crash(BSOD) by a malformed IPv6 packet on default firewall configuration"
....
Oh wait ! something looked wrong somewhere...
please read this and come back . I'll wait.
Haha , how do you feel now ? :>
Yes, I've been tricked too while quickly reviewing their first advisory. But Jerome's try showed us clearly that HUMAN FACTOR is still the case we should worry about more than anything. Although I believe this try was not a fair one , but still a GREAT example of real world cases! why? because intruders always hit us from the point we never expect. We all knew so called "WOVB Team" and it was the _trust_ a real attacker looks for, as a sample attack vector. As Jerome noted, what if there was some kind of attack-script behind this scenario to infect your system? while reviewing my own weblog's hits, I see >70% of my visitors critically vulnerable to different KNOWN attack vectors. I'm sure he have done such analyze on his own logs too.
I'm too sleepy to continue blogging , but still thinking/laughing about this eye-opening case and the way I've been tricked !
Nice try Jerome ! thanks for not sharing screen-shot of my e-mail as well :D
April 2, 2007
wtf ?! it sucks :) ... ( Yet Another Post about ANI case )
If you've been blind reading this from my previus "brwosing history" , then I've something more interesting . I don't know I should like this or get worry , but as author says :
"Update: It also bypass eeye security ani patch!"
I'm sure you know where above line comes from!
Well, Eeye warned us multiple times about NO GUARANTEE on their patch, but I bet non of us expected their guarantee to expire that soon :> anyway feel free to try ZERT patch till the day MS release their patch (if they don't patch their patch again, of course!).
After all , since long time ago I don't care about IE nor it's bugs no matter how serious or wild they may be(although this one is not IE ones, but IE is the most used attack vector). consider this just a note for IE lovers/p0wners...
And I hope you still remember about April's ...
"Update: It also bypass eeye security ani patch!"
I'm sure you know where above line comes from!
Well, Eeye warned us multiple times about NO GUARANTEE on their patch, but I bet non of us expected their guarantee to expire that soon :> anyway feel free to try ZERT patch till the day MS release their patch (if they don't patch their patch again, of course!).
After all , since long time ago I don't care about IE nor it's bugs no matter how serious or wild they may be(although this one is not IE ones, but IE is the most used attack vector). consider this just a note for IE lovers/p0wners...
And I hope you still remember about April's ...
March 31, 2007
Sniffing Bluetooth
I noticed a new paper from Max (of remote-exploit.org) mentioning that it's possible to turn those cheap USB bluetooth dongles into a working clone of commercial sniffers. This and this are samples of a commercial BT sniffer. As you may know it was believed that sniffing remote bluetooth connections (just like what we have for WiFi) is not that straight-forward (but still possible and proven ) and a _normal driver/device_ available in markets will NOT allow us to sniff other connections. Here you can read why it's hard to sniff Bluetooth. There are some commercial solutions to do that, but so far there's no free/open project making that possible. So that's why Max's piece of research is interesting. As he mentioned in his papers , the myth is solved by flashing commercial firmwares onto a normal compatible (chipset) USB dongle. Of course those vendors always tell us that their hardware and software parts are covering each other and they use something SPECIAL ! but it's not like that really ( as Max showed us ) .
I may update this entry once again...
I may update this entry once again...
The Week Of VISTA Bugs.
I'm sure you're now as curious as me about the upcoming event.
After nice talks on Black-Hat 2007 EU on Vista , some of mistries about Vista are well-discussed now. So researchers now have the hard parts solved and we should expect more on Vista. Few guys joined together to announce the first vista-focused vulnerability discovery week, coming as TWOVB . I can almost guess what will be announced but let's wait till they begin the show ;)
After nice talks on Black-Hat 2007 EU on Vista , some of mistries about Vista are well-discussed now. So researchers now have the hard parts solved and we should expect more on Vista. Few guys joined together to announce the first vista-focused vulnerability discovery week, coming as TWOVB . I can almost guess what will be announced but let's wait till they begin the show ;)
March 30, 2007
Happy New Year
I'm still alive ;)
In case of me , The new year was not that happy for some reasons but anyway let's cheer! I wish everyone a completely different new year as I expect it for myself too.
I know how bad it is to keep a blog idle, but I believe keeping blog idle is better than filling it with useless entries. To prevent blog from getting too much dusty I added a "My browsing history" section as you may have already noticed it. There you`ll see my favorites while reading other people's blogs,lists and news. This widget is really a mini copy of my shared items on Google-Reader, so if you hate my blog and just want to follow my browsing habits feel free to directly visit this link . Finally in case you're a paranoid surfer like me , don't forget to white-list "blogger.com" in your NoScript or you'll miss it while watching my blog.
And yeah I love Google-Reader ! I finally came to this conclusion that it is the best choice for managing a massive list of feeds. It's portable,flexible and If you're on a low-speed link it's surprisingly bandwidth-saving while loading your long list of feeds and of course, anonymous.
In case of me , The new year was not that happy for some reasons but anyway let's cheer! I wish everyone a completely different new year as I expect it for myself too.
I know how bad it is to keep a blog idle, but I believe keeping blog idle is better than filling it with useless entries. To prevent blog from getting too much dusty I added a "My browsing history" section as you may have already noticed it. There you`ll see my favorites while reading other people's blogs,lists and news. This widget is really a mini copy of my shared items on Google-Reader, so if you hate my blog and just want to follow my browsing habits feel free to directly visit this link . Finally in case you're a paranoid surfer like me , don't forget to white-list "blogger.com" in your NoScript or you'll miss it while watching my blog.
And yeah I love Google-Reader ! I finally came to this conclusion that it is the best choice for managing a massive list of feeds. It's portable,flexible and If you're on a low-speed link it's surprisingly bandwidth-saving while loading your long list of feeds and of course, anonymous.
March 8, 2007
BackTrack 2.0 is out.
After about 5 months of watching developers log , seems it's finally out !
Today while checking my mails I noticed new mail from Max, announcing this new ( final ) release of version 2.0 . and I was glad to see that ISSAF is finally there . After releasing v1.0 of ISSAF I had talks with Max, on joining these two projects. The idea was adopting both BackTrack and ISSAF in a way that tools in ISO and documents in ISSAF cover each other, so that all an ISSAF reader require , will be a copy of BackTrack to finish all of tests explained in ISSAF. seems it's going to happen .
For those who don't know, ISSAF is a project of OISSG , which provides a complete documentation for penetration-testing , or a so called "Assessment/Pen-test framework"and I've authored few chapters of it. I've been idle on ISSAF project after v1.0 but I hope to be able to get my hands dirty again and try to upgrade documents/tools in draft, as much as possible.
It's not all about v2.0 . I found a fantastic addition since their beta release. BackTrack finally added support of cool USB wlan devices . Here's the snip from announcement :
"By supporting the new ALFA USB hi-power devices there is now a great USB wireless dongle available which allows us to connect an external antenna and use BackTrack to attack even on my Intel Macbook or VMware"
If it's still not clear enough for you, here's what it means for me : Attach the usb device to your system , run your VMware , start your your local-hd-install of BackTrack 2.0 which has been previously installed , and enjoy the power of BackTrack on owning wireless network, while having fun with your windows based tools.
Before this, you had no chance to use wireless capabilities of BackTrack while it's working inside VMware.
I've been a remote-expl0it.org fan since their early Auditor days and I've always enjoyed their works. Although I'm still using their Auditor since 2005 but I have always an up to date version of BackTrack with me. Long time ago I replaced my debian linux with a local-hd-install of Auditor and began boosting it in my own way, and it's still cool and useful in 2007 :)
You may ask why I didn't simply upgraded my local installed version to a BackTrack release? The answer is as simple as " I like Debian more than Slackware" . So I decided to keep my debian installation up2date rather than installing new slackware, and just kept upgrading/adding tools mentioned in newer releases of BackTrack.
Making a raw laptop to a pen-test station is so easy these days. All you have to do is downloading an ISO, burning it and booting it. If you don't feel comfortable with booting cd/dvd for every session and you can't sleep well while running a linux customized by someone else, there's always a "Local-HD-Install" option for you. IMO a live copy is not stable enough for a real-world pen-test, but it's just good for demonstrations, demos or using while training sessions.
It's painful to reconfigure live version every time you use it, and after all user is limited in some aspects of configurations. Yes I know we can save configs to a flash or local partition, but why making everything hard for ourself when there's chance of booting a live pen-test cd from HD, with no limitation?
Beta release of BackTrack 2 was nice experience for me. I tried to replace it with my current tool-set for a while, to be able to fuly evaluate it. And now I can say that it will cover >90% of your requirements for a complete professional pen-test session. There were few bugs and missing tools but I'm sure v2.0 is good enough to hold it for a while.
Read about more upgrades since beta release on BackTrack's page.
Today while checking my mails I noticed new mail from Max, announcing this new ( final ) release of version 2.0 . and I was glad to see that ISSAF is finally there . After releasing v1.0 of ISSAF I had talks with Max, on joining these two projects. The idea was adopting both BackTrack and ISSAF in a way that tools in ISO and documents in ISSAF cover each other, so that all an ISSAF reader require , will be a copy of BackTrack to finish all of tests explained in ISSAF. seems it's going to happen .
For those who don't know, ISSAF is a project of OISSG , which provides a complete documentation for penetration-testing , or a so called "Assessment/Pen-test framework"and I've authored few chapters of it. I've been idle on ISSAF project after v1.0 but I hope to be able to get my hands dirty again and try to upgrade documents/tools in draft, as much as possible.
It's not all about v2.0 . I found a fantastic addition since their beta release. BackTrack finally added support of cool USB wlan devices . Here's the snip from announcement :
"By supporting the new ALFA USB hi-power devices there is now a great USB wireless dongle available which allows us to connect an external antenna and use BackTrack to attack even on my Intel Macbook or VMware"
If it's still not clear enough for you, here's what it means for me : Attach the usb device to your system , run your VMware , start your your local-hd-install of BackTrack 2.0 which has been previously installed , and enjoy the power of BackTrack on owning wireless network, while having fun with your windows based tools.
Before this, you had no chance to use wireless capabilities of BackTrack while it's working inside VMware.
I've been a remote-expl0it.org fan since their early Auditor days and I've always enjoyed their works. Although I'm still using their Auditor since 2005 but I have always an up to date version of BackTrack with me. Long time ago I replaced my debian linux with a local-hd-install of Auditor and began boosting it in my own way, and it's still cool and useful in 2007 :)
You may ask why I didn't simply upgraded my local installed version to a BackTrack release? The answer is as simple as " I like Debian more than Slackware" . So I decided to keep my debian installation up2date rather than installing new slackware, and just kept upgrading/adding tools mentioned in newer releases of BackTrack.
Making a raw laptop to a pen-test station is so easy these days. All you have to do is downloading an ISO, burning it and booting it. If you don't feel comfortable with booting cd/dvd for every session and you can't sleep well while running a linux customized by someone else, there's always a "Local-HD-Install" option for you. IMO a live copy is not stable enough for a real-world pen-test, but it's just good for demonstrations, demos or using while training sessions.
It's painful to reconfigure live version every time you use it, and after all user is limited in some aspects of configurations. Yes I know we can save configs to a flash or local partition, but why making everything hard for ourself when there's chance of booting a live pen-test cd from HD, with no limitation?
Beta release of BackTrack 2 was nice experience for me. I tried to replace it with my current tool-set for a while, to be able to fuly evaluate it. And now I can say that it will cover >90% of your requirements for a complete professional pen-test session. There were few bugs and missing tools but I'm sure v2.0 is good enough to hold it for a while.
Read about more upgrades since beta release on BackTrack's page.
Subscribe to:
Posts (Atom)