Skip to content

Latest commit

 

History

History
34 lines (23 loc) · 4.41 KB

README.md

File metadata and controls

34 lines (23 loc) · 4.41 KB
Raw

babukV3

Improved, refactored, and new version of the previously leaked source code of the Babuk ransomware by VXUG.

Analysis of Source Code (with help of ChatGPT), in finding issues:

entry.cpp

  1. In the find_files_network function:

    • The netRes parameter is expected to be a valid pointer to NETRESOURCEW, but there is no validation for a null pointer.
    • The condition if (netRes = (LPNETRESOURCEW)_halloc(cbBuffer)) contains an assignment (=) instead of a comparison (==), which may lead to unintended behavior.
    • There is a potential buffer overflow issue when allocating memory for netRes using _halloc. The size of cbBuffer (16KB) is used, but there is no guarantee that the allocated memory can hold that amount of data.

  2. In the enum_shares function:

    • The addr parameter is expected to be a valid pointer to a null-terminated wide string, but there is no validation for a null pointer.
    • The NetShareEnum function is called with a cast to (LPWSTR), which assumes that the addr parameter is modifiable, but this may not always be the case.
    • The lstrlenW function is used to determine the length of the p->shi1_netname string, but there is no validation for a null pointer or uninitialized p pointer.

  3. In the _processDrive function:

    • The driveLetter parameter is assumed to be a valid drive letter, but there is no validation for incorrect or unsupported values.
    • There is a potential buffer overflow issue when allocating memory for driveBuffer using _halloc. The buffer size should be 6 characters ("\\\\?\\X:"), but it is allocated with 7 characters, which may lead to unintended behavior.
    • The condition if (driveType != DRIVE_REMOTE) suggests that only local drives are processed, but there is no check for other drive types like network drives or removable drives.

  4. In both find_files_recursive and find_paths_recursive, a fixed-size buffer localDir of 32768 WCHAR elements is used for constructing file and directory paths. If the path length exceeds the buffer size, it can lead to a buffer overflow. Proper bounds checking should be implemented to ensure the buffer is not overflowed.

  5. Unchecked Heap Allocation: The functions _halloc and _hfree are used for memory allocation and deallocation. However, there is no explicit check for successful memory allocation. If the allocation fails and returns NULL, the code does not handle this situation. This can lead to undefined behavior if subsequent operations assume the memory is valid. It's important to check the return value of _halloc and handle allocation failures appropriately.

  6. Incorrect String Length Calculation: In find_files_recursive, the WriteFile function is called with the length of the ransom_note string calculated using lstrlenA. However, lstrlenA returns the length in bytes, not the number of characters for wide strings. This can lead to incorrect file writing if the string contains non-ASCII characters. The appropriate function to use for wide strings is lstrlenW or wcslen.

  7. Misuse of lstrcmpiW: In several places, the function lstrcmpiW is used for case-insensitive string comparison. However, it is used incorrectly. The comparison is made between fd.cFileName + i and the extension strings, but it should be comparing the extension string with the result of lstrcmpiW. The correct usage would be lstrcmpiW(fd.cFileName + i, L".exe") == 0, lstrcmpiW(fd.cFileName + i, L".dll") == 0, etc.

  8. Potential Infinite Loop: In the lilBabuk function, when popping items from the que_p queue, the loop condition while (TRUE) is used without an explicit termination condition. This can result in an infinite loop if there is an error or if the queue does not reach a state where no more items are available.

  9. Unclear Error Handling: Some error conditions are handled by outputting debug information, but the impact on program flow is not clear. For example, in find_files_recursive and find_paths_recursive, when FindFirstFileW fails, debug information is printed, but the behavior afterward is not specified. It is important to handle errors consistently and provide appropriate feedback or terminate execution if necessary.

  10. Lack of Error Checking: Several API calls, such as CreateFileW, WriteFile, FindFirstFileW, etc., are not checked for errors. It is crucial to verify the return values of these functions and handle any potential errors that may occur.