Grey Panthers Savannah

The 14th post

Because 13 is not a nice number :), and because the submission deadline for the two contests has passed, I thought I share with you my solutions (they are not guaranteed to be complete over correct for that matter):

The Hitch-Hacker’s Guide to the Galaxy

  • How did Zay Zeutrino gather the desired data to switch users to the Vogon matter transference officer’s user account?

    When matter transfer officer viewed the spoofed message (which wasn’t filtered in a proper way by the Vogon system to eliminate such threats), the script part included in the message wrote an image tag in the browser the URI of which contained all the cookies for the current page. This link was automatically followed by the browser trying to display the image. For this to work as expected, the following conditions have to been met:

    the user interface to read e-mails have to been the same as the one used to control the matter transference system (more precisely the cookies have to been set such a way that there were common for both parts of the system – they have to been on the same domain and the path of the cookie have to be set up in such a way that it was a common prefix for the URLs of both systems).

    authentication data has to been contained in the cookies. This can either be username in password (don’t laugh, I’ve seen this used in real life 🙁 ) in plaintext or in some naivly encrypted format (like rot13 or base64 – which isn’t an encryption but some may use this way) or a session identifier.

    the session management was set up in such a way that the session wasn’t tied to a given IP

  • How did Zeutrino switch users?

    He inserted the stolen cookies (or at least the ones which identified the session) in his browser (I bet that he was using Firefox 2.0 with the Add N Edit cookie extension – https://addons.mozilla.org/firefox/573/) and thus when he made the requests to the server it believed that this transaction was part of the session which was established when the matter transference officer authenticated himself.

  • What might Pal Homeran have seen in his logs?

    He might have seen several things:

    From the access logs (which are turned on by default) he might have seen an access to the matter transference management system from an IP which was outside the expected IP range

    Also from the access logs he might have seen that someone accessed the system with a different user agent than the standard one (if the Vogons were using IE 5.5 because that was the “company standard” and Zeutrino did not know this or did not spoof his user agent with the User Agent Switcher https://addons.mozilla.org/firefox/59/)

    A third possibility would be that there was a separate log (an audit trail) in the system which logged the actions taken from the interface. This is however unlikely given the poor state of the security. If such a log existed, Pal could have observed a transfer for which there was no paperwork or again which came from an unusual IP range (if such a thing was logged)

  • What should Zeutrino do next?

    He should delete the cookies, remove Firefox and wipe his hard drive. This is of course not a 100% solution because might be remnants of a Firefox installation in many places: in the registry (the registry has its own “filesystem” which in turn contains “slack space” which can’t be wiped by a disk eraser utility), in the prefetch directory, in the hibernation file and so on. His best bet is if he used a Firefox from inside a virtual machine, because he can just wipe the space occupied by the virtual disk and you have all the traces erased.

    If he has a dynamic IP address, he should renew his IP address, because hopefully he gets a new one (on Windows this would be ipconfig /release, ipconfig /renew from the command line). To make things ever more hidden, he could change his MAC address by either physically swapping out the NIC (if it isn’t on-board) or from software forcing an other MAC. This way it’s more probable that he will get a new IP address from the DHCP server. The MAC address change should be performed while no IP is assigned. That is: ipconfig /relese, , ipconfig /renew. This way it would look like that the original terminal went off-line and a new one came online from the logs. If no MAC spoofing is performed from the logs of the DHCP server (if such a thing exists) Pal could find identify the computer even if it had a different IP address (based on the MAC address). The physical changing of the MAC address is really recommended because if it’s only spoofed in software it could raise suspicion if the system would to be examined closer and this fact would be discovered.

    If his IP is static, he should try to assign himself either an unoccupied IP from the given subnet, or if he wants to incriminate someone, swap the IP of his terminal with the one of somebody else’s terminal.

  • What should Pal Homeran do next?

    Based on the log he probably has the IP address of Zeutrinos computer. If Zeutrino isn’t quick in performing the above mentioned changes, he can track down Zeutrinos computer directly. If Zeutrino did implement the countermeasures he could at least narrow down the search to the segment which is served by the DHCP from which the IP originated. Then he could either inspect each computer manually or if Zeutrino didn’t change his MAC address, just his IP address, he could look in the DHCP log for the following type of entries:

    <Offending IP> was leased to MAC address <X>
<Offending IP> released the lease
<New IP> was leased to MAC address <X>

    and identify the IP he should be looking for.

    Assuming that all IP addresses are statically assigned, he can narrow it down to one subnet (assuming there is are no NATs or proxys in the internal network of the ship – which is probably the case). In this case Zeutrinos defense options are limited if he didn’t use a fake IP or a proxy during the attack, because the IP will directly lead Pal to his computer.

    If Zeutrino has changed has changed is statically assigned IP, Pal should look for traffic on the given subnet from IP addresses which should not be assigned (we can assume that Pal being a Vogon sysadmin keeps a strict record about which IP are taken and by what). Because may have Zeutrino instead swapped his IP address with an other terminal, he should first inspect the terminal which has currently the offending IP and if he finds no signs that the attack originated from here (such evidence is most readily found in the browser history or in the free space on the disk if it wasn’t wiped) he should proceed and look at every computer on the subnet. To confirm that he has the right terminal, he should look for signs that the given computer was used for the attack (most simple way is to search for the contents of the cookie in the raw image of the terminals disk) or that the harddrive of the given terminal was wiped. If he finds only one harddrive which was wiped in the whole subnet and finds the strings nowhere, he can be pretty sure that that terminal was the offending one.

  • Bonus question: The wordcount is 42, which according to the book is the answer to all the questions of the universe.
Malware analysis quiz VII

  1. Is this malware packed? If so, with which packer?

    It is packed with Themida, produced by Oreans (http://www.oreans.com/themida.php), which is a very hard to break protector. It includes optionally detection for virtual machines (VirtualPC and VMware), a feature which is activated in this executable. Because of this analysis is only possible with an other virtual machine (if you don’t want to sacrifice a real one :)), my personal choice being Qemu (http://fabrice.bellard.free.fr/qemu/).

    During the process of unpacking the executable dumps a driver in the system32drivers directory with the name oreans32.sys (size: 33952 bytes, MD5: aad837bf3b475092fd515cd0842334e9). Although this is detected by CAT-QuickHeal as Rootkit.Agent.ad, is not malicious file, but a part of the protector itself. Still, probably most people would like to remove this file too, which can be done by entering net stop oreans32 at the command prompt and then deleting the file itself. Given the way this file was packed, we can say for certain that it was first run by a program having the load driver privilege (usually this is attributed to members of the Administrators group only). On subsequent runs however it wasn’t necessary for it to have this privilege since the driver was already installed and running. This is an other reason to delete the driver./

  2. What is the purpose of this malware?

    It has a single purpose: to download and execute any file the master controller instructs it to.

  3. Does it connect to a remote server? With which purpose?

    It connects to uk.undernet.org and joins the channel #secretcow with the password werule which acts as a command and control center for it (the channel has been shut down). The nickname of the user who controls this bot is Daddy.

  4. Which channels does it connects to?

    #secretcow. It also sends status messages to the #yousawthatss channel (like :Downloading. and :Executing.)

  5. Can you get any passwords related to this malware? (Not the infected password) 🙂

    The channel password for #secretcow is / was werule

  6. Which capabilities does this malware have?

    To download and execute files from a given url. These files are downloaded to C:dl.exe and executed from there. This is an other indication for the fact that the malware was intended to run with high privileges (because low privileged users do not have write access to c:). To reconstruct the files which were downloaded and executed (if any), there are two possibilities: looking at the Internet Explorer cache on the infected machine. This works because the malware uses the URLDownloadToFile API, which is part of Internet Explorer and stores the downloaded files in the same cache as it. An other possibility would be to look at the proxy logs if the computer was behind one. Because the malware uses a function which is part of Internet Explorer, it uses the same proxy settings as IE.

  7. What is the hidden message? (if there is any…) 🙂

    no security without knowledge. No knowledge without research. Be a good guy! It is worthwhile.

    For analysis I ran the program in Qemu for a couple of seconds and then did a full memory dump of the malware using the small program shown in the appendix. I imported the relevant sections (dump_00400000.bin, dump_00401000.bin and dump_00404000.bin) in in IDA (when importing you must take care to mark the sections as 32 bit code). Unfortunately the protector obfuscates the IAT, so the analysis was done mostly by looking at the strings and the method calls to the library functions (it was written in Delphi and IDAs FLIRT signatures managed to identify a couple of library routines).

Appendix – Source code for the memory dumper. Use Turbo Delphi or FreePascal to compile.

program dump_mem;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  Windows;

var 
    hProcess: THandle;
    l: integer;
    buffer: pointer;
    numRead: Cardinal;
    memStart: pointer;
    memInfo: MEMORY_BASIC_INFORMATION;

procedure PutFile(FileName: String; FileDataPtr: Pointer; FileSize: Cardinal);
var
  hFile: THandle;
  Written: Cardinal;
begin
  hFile := CreateFile(PChar(FileName), GENERIC_WRITE, 0, nil, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, 0);
  if hFile=INVALID_HANDLE_VALUE then begin
    WriteLn('Failed to open output file!');
    exit;
  end;

  WriteFile(hFile, FileDataPtr^, FileSize, Written, nil);

  If Written <> FileSize then begin
    WriteLn('Failed to write output file!');
    exit;
  end;

  CloseHandle(hFile);
end;

var
  pid: Integer;
begin
  pid := StrToInt(ParamStr(1));

  hProcess := OpenProcess(PROCESS_ALL_ACCESS, false, pid);
  if hProcess <> 0 then begin
    memStart := nil;
    l := VirtualQueryEx(hProcess, memStart, memInfo, SizeOf(MEMORY_BASIC_INFORMATION));
    while l = SizeOf(MEMORY_BASIC_INFORMATION) do begin
      if meminfo.State = MEM_COMMIT then begin
        GetMem(buffer, memInfo.RegionSize);
        if ReadProcessMemory(hProcess, memInfo.BaseAddress, buffer, memInfo.RegionSize, numRead) then begin
          PutFile('dump_' + IntToHex(Integer(memInfo.BaseAddress), 8) + '.bin', buffer, memInfo.RegionSize);
        end;
        FreeMem(buffer);
      end;
      integer(memstart) := integer(meminfo.BaseAddress) + meminfo.regionsize;
      l := VirtualQueryEx(hProcess, memStart, memInfo, SizeOf(MEMORY_BASIC_INFORMATION));
    end;
  end;
  CloseHandle(hProcess);
end.

gpanther

Leave a Reply

Your email address will not be published. Required fields are marked *