(In)Security

  1. Device Drivers Vulnerability Research, Avast a real case

    In the past days I worked intensively on Antivirus’s Device Drivers bugs, at the actual state of art the major part of well known AVs suffer of basical and more hidden bugs. The totality of AVs that I’ve checked presents defects that could be maliciously used to takeover an Antivirus Infrastructure and in some case the entire Operating System with attacks like DoS and/or Remote/Local Privilege Escalation.

    I want to make a precisation here, exists an important difference between Bug and Vulnerability, simply bugs does not affects the integrity of a system and does not constitute a true danger. Vulnerabilities constitutes an effective risk for systems integrity, included informations contained inside it. When we are dealing with applications specifically devoted to security, every bug could be considered a vulnerability, because an attacker could block/kill overcome checks performed by the application itself and propagate in system and produce damages. Just think to a basical crash that could affect an Antivirus could be implemented into a malicious application that checks the presence of AVs and induces the bug.

    In this little post we are going to see some defects of last device drivers used by Avast, I’m precisely talking of

    Build Number: 4.8.1351.0

    Avast loads the following drivers:

    • Aasvmker4.sys
    • aswMon2.sys
    • aswRdr.sys
    • aswSP.sys



    Avast loads the following Drivers could be tested by fuzzing IOCTLs, for this task could be used IOCTL Fuzzer and Kartoffel. Let’s disassemble the first driver, Aavmker4.sys that from DeviceIoControl hook appears to be heavy used. This is the DriverEntry()drivers

    Code:
    00010748 mov eax, [ebp+DriverObject]
    0001074B push offset NotifyRoutine ; NotifyRoutine
    00010750 mov dword ptr [eax+70h], offset sub_1098C ; DriverObject->MajorFunction[14] = (PDRIVER_DISPATCH)sub_1098C;
    00010757 call PsSetCreateProcessNotifyRoutine
    sub_1098C contains the switch statement to handle various IOCTL notifications, essentially IOCTL check is structured in form of nested If and Switches.

    Code:
    001098C ; int __stdcall sub_1098C(int, PIRP Irp)
    000109C4 mov ecx, 0B2D6002Ch
    000109C9 cmp eax, ecx
    000109CB ja loc_10D12
    000109D1 jz loc_10CE9
    Checks if IOCTL is less or equal to 0Χ0B2D6002C, if condition is true checks if IOCTL is exactly 0Χ0B2D6002C a certain task is performed by the device driver and finally ends with a classical
    epilogue:

    Code:
    IofCompleteRequest(X, 0);
    return value;
    By monitoring Aavmker4.sys activity, with a DeviceIoControl hook emerges that the most used IOCTLs are:

    • 0xB2D60030
    • 0xB2D60034



    Now we have two possibilities the first is to fuzz these IOCTLs and check crash dump if happens and after check code for more details, the second possibility is to invert the check order.

    This the xml configuration to test Aavmker4.sys

    Code:
    <allow>
    <drivers>
    <entry>Aavmker4.sys</entry>
    </drivers>
    <devices>
    <entry>\Device\AavmKer4</entry>
    </devices>
    
    <ioctls>
    <entry>0xb2d60030</entry>
    <entry>0xb2d60034</entry>
    </ioctls>
    <processes>
    <entry>ashServ.exe</entry>
    </processes>
    </allow>
    launch fuzzer and Avast Scan, as you can see Driver resists to Fuzzing attempts, its time to see code referred to 0xB2D60030 and 0xB2D60034.

    0xB2D60030

    Code:
    00010D25 cmp eax, 0B2D60030h
    00010D2A jz short loc_10DA8
    00010D2C cmp eax, 0B2D60034h
    00010D31 jz short loc_10D5B
    00010DC5 mov edi, [ebx+0Ch]
    00010DC8 cmp esi, 878h
    00010DCE jz short loc_10DDA ;Check buffer size
    00010DD0 push offset aIoctl_aavm_sta ; “******* IOCTL_AAVM_START_REQUEST_AND_SE”…
    00010DD5 jmp loc_10ABA ;Jump to Io Completion
    If buffer size differs from 878h Dbg Prints an error message, else supplied buffer is correctly sanitized via MmUserProbeAddress, MmIsAddressValid. We can say that this IOCTL is correctly handled.

    0xB2D60034:

    Code:
    00010D5B cmp esi, 8
    00010D5E jnz loc_10AC0 ;If differs from 8 return STATUS_INVALID_PARAMETER
    00010D64 call PsGetCurrentProcessId
    Now let’s test aswSP.sys. In Device Driver vulnerabilty research it’s fundamental to have a complete log of all activities of a driver, this can be obtained by correctly planning a battery of test unit. Each test should correspond to a primitive logic operation performed by an application that makes use of driver. I usually build several mini logs for each activity and finally a complete log. Here a little list of monitoring primitives:


    • On Load
    • On apparent Idle
    • On Working
    • On Shutdown
    • Various, like On Surprise Stop



    This will give us a complete report of all activities and involved IOCTL. In the specific case of aswMon2.sys we can isolate the following:


    • * 0xb2c80018
    • * 0xb2c80014
    • * 0xb2c80020
    • * 0xB2c800C0
    • * 0xB2c800C4
    • * 0xB2c800C8


    From IOCTL Logger we can see that 0xB2c800C0 is heavly used, time to locate Ioctl Dispatcher:

    Code:
    0001178B and dword ptr [ebx+34h], 0
    0001178F mov dword ptr [ebx+6Ch], offset sub_11FB6
    00011796 mov dword ptr [ebx+28h], offset off_18988
    C like:
    Code:
    v2->DriverUnload = 0;
    v2->MajorFunction[13] = (PDRIVER_DISPATCH)sub_11FB6;
    v2->FastIoDispatch = (PFAST_IO_DISPATCH)&unk_18988;
    with a bit of research we land to sub_10B82 that contains the switch for Ioctls.

    Code:
    00010BBD mov eax, 0B2C80018h
    00010BC2 cmp ecx, eax
    00010BC4 push edi
    00010BC5 ja loc_11066
    00010BCB jz loc_10F70
    00010BD1 cmp ecx, 0B2C80008h
    00010BD7 jz short loc_10C3C
    00010BD9 cmp ecx, 0B2C8000Ch
    00010BDF jz short loc_10C16
    00010BE1 cmp ecx, 0B2C80010h
    00010BE7 jz short loc_10BFF
    00010BE9 cmp ecx, 0B2C80014h
    00010BEF jnz loc_111AC
    00010BF5 call sub_108BC
    From logs emerged that the most frequently used is 0B2C8000C so it’s obvious that we will study this for first:

    0xB2C8000C:

    Code:
    00010C16 cmp [ebp+arg_C], 1448h
    00010C1D jnz loc_111AC ;check len
    00010C23 mov esi, [ebp+SourceString]
    00010C26 mov ecx, 512h
    00010C2B mov edi, offset dword_18A58
    00010C30 rep movsd
    00010C32 call sub_108F0
    00010C37 jmp loc_112C1 ;go out
    In this case user supplied input is correctly sanitized, so 0xB2C8000C can be excluded from fuzz testing. From the log On Shutdown emerged the massive presence of 0xB2c80018, so let’s fuzz it. Here the configuration for IOCTL Fuzzer:

    Code:
    <?xml version=”1.0″ encoding=”windows-1251″?>
    <cfg>
    <log_file>C:\ioctls.txt</log_file>
    <hex_dump>true</hex_dump>
    <log_requests>true</log_requests>
    <debug_log_requests>true</debug_log_requests>
    <fuze_requests>true</fuze_requests>
    <fuze_size>true</fuze_size>
    <allow>
    <drivers>
    <entry>aswMon2.SYS</entry>
    </drivers>
    <devices>
    <entry>\Device\aswMon</entry>
    </devices>
    <ioctls>
    <entry>0xb2c80018</entry>
    </ioctls>
    <processes>
    <entry>ashServ.exe</entry>
    </processes>
    </allow>
    <deny>
    <drivers>
    
    <entry>aswSP.SYS</entry>
    <entry>Aavmker4.SYS</entry>
    <entry>aswTDI.SYS</entry>
    </drivers>
    <ioctls>
    
    <entry>0xb2c8000c</entry>
    <entry>0xb2c80014</entry>
    <entry>0xb2c80020</entry>
    </ioctls>
    </deny>
    </cfg>
    The config script allows only 0xB2c80018 sent from aswMon, other drivers are locked. Obviously fuzzing need to follow the log unit that evidenced out IOCTL, so run fuzzer and stop all Avast services.

    Bang..a BSOD, discovered an Avast vulnerability into aswMon2.sys

    From crashdump:

    kd> !analyze -v

    UNEXPECTED_KERNEL_MODE_TRAP_M
    Arguments:
    Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
    Arg2: 80042000
    Arg3: 00000000
    Arg4: 00000000_KERNEL_MODE_TRAP_M (1000007f)
    STACK_TEXT:
    WARNING: Stack unwind information not available. Following frames may be wrong.
    f76f3234 8053d251 f76f3250 00000000 f76f32a4 nt+0Χ600fa
    f76f32a4 8052c712 badb0d00 20a0a0a1 f76f5658 nt+0Χ66251
    f76f3328 8052c793 41414141 00000000 f76f377c nt+0Χ55712
    f76f33a4 804fc700 f76f377c f76f3478 05050505 nt+0Χ55793
    f76f3760 8053d251 f76f377c 00000000 f76f37d0 nt+0Χ25700
    f76f37d0 8052c712 badb0d00 20a0a0a1 f76f5658 nt+0Χ66251
    f76f3854 8052c793 41414141 00000000 f76f3ca8 nt+0Χ55712
    f76f38d0 804fc700 f76f3ca8 f76f39a4 05050505 nt+0Χ55793
    f76f3c8c 8053d251 f76f3ca8 00000000 f76f3cfc nt+0Χ25700
    f76f3cfc 8052c712 badb0d00 20a0a0a1 f76f5658 nt+0Χ66251
    f76f3d80 8052c793 41414141 00000000 f76f41d4 nt+0Χ55712
    f76f3dfc 804fc700 f76f41d4 f76f3ed0 05050505 nt+0Χ55793
    f76f41b8 8053d251 f76f41d4 00000000 f76f4228 nt+0Χ25700
    f76f4228 8052c712 badb0d00 20a0a0a1
    ...
  2. On Analysis of Client-Server Software Applications

    Hi,

    Initially was a closed paper, now I rewritten it a bit. Here a little Abstract:

    The principal objective of this paper is to give a good detailed
    panoramic view of the Security aspects involved in Client-Server based
    Applications. The panoramics will be seen from the point of view of a
    Reverse Engineer that should be aware of the Security Problems that are
    directly releated to the Client-Server Software Structure.


    and here the link:

    http://evilcry.netsons.org/tuts/CSAnalysis.pdf

    Regards,
    Evilcry
    Categories
    TechLife , (In)Security
  3. CartellaUnicaTasse.exe Italian Malware RCE Analysis

    Hi,
    I've just released a paper into my website about the RCE Analysis of an italian Downloader

    Paper can be reached here:

    http://evilcry.altervista.org/tuts/Mw/CartellaUnicaTasse.pdf

    if this link does not works, just reach it from the home of my website.

    Regards,
    Evilcry
  4. Process Memory Dumper for Credentials Disclosure Vulns

    Hi,

    This last period was full of intersting findings, I've published two advisoryes on Bugtraq:

    http://www.securityfocus.com/bid/28420

    and

    http://www.securityfocus.com/archive/1/490265/30/0/threaded

    So I also coded a Process Memory Dumper, useful to improve these vulns.
    It can be downloaded here:
    http://evilcry.altervista.org/other/ProcessMemoryDumper.zip

    Enjoy!

    See you to the next post..
    Categories
    (In)Security
  5. aMSN Input Validation Error

    Risk: Low
    Tipology: Input Validation Error

    All aMSN versions, both on Windows and Linux platorms.

    As Microsoft MSN, aMSN have a nice feature for Exporting and Importing the list of
    contacts you have.

    This list is dumped into an XML file (file extension .ctt), with this structure

    ——————————————————————-
    <?xml version=”1.0″?>
    <messenger>
    <service name=”.NET Messenger Service”>
    <contactlist>
    <contact> your_contact@xxxx.yy</contact>
    </contactlist>
    </service>
    </messenger>
    ——————————————————————–


    aMSN does not Validate correctly the Contacts you insert, precisely does not parse
    the format of this file, and suddenly when you import a malformed Contact List it
    shutdown

    here an example of malformed input list

    ——————————————————————-
    <?xml version=”1.0″?>
    <messenger>
    <service name=”.NET Messenger Service”>
    <contactlist>
    <contact>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

    AAAAAAAAAAAAAAAAAAAAAAA@xxxx.yy</contact>
    </contactlist>
    </service>
    </messenger>
    ——————————————————————-


    Or another possibility

    ——————————————————————-
    <?xml version=”1.0″?>
    <messenger>
    <service name=”.NET Messenger Service”>
    <contactlist>
    <contact><contact><contact><contact>
    <contact></contact></contact><contact>
    </contact></contact></contact></contact>
    </contact>
    </contactlist>
    </service>
    </messenger>
    ——————————————————————-


    This will cause a freeze of aMSN..

    If you use the same “trick” with Ms Messenger, a MessageBox will advice you of the malformed
    file

    See you to the next post
    Categories
    (In)Security