During the last few months information about one of North Koreas operating systems was leaked. It is a Linux based OS that tries to simulate the look and feel of a Mac. Some of it’s features have already been discussed on various blog posts and news articles. We thought we would take a short look at the OS. This blog post contains some of the results.
As you can imagine, most interesting for us was to investigate features that impact the privacy of the users. There are some publications concerning the security of the OS, this is an aspect that we will not cover in this post. We will stick to a privacy issue that we identified in this post. As ERNW has a long history of “Making the World a Safer Place”, we consider this topic an important one. The privacy of potential users (especially from North Korea) may be impacted and therefore we think that the results must be made available for the public. So, here we go …
When analyzing the OS the first thing that came to our attention is that they have built an own kernel module named rtscan. There is a binary running that is named opprc and a few more binaries, one that seems to simulate/pretend to be some kind of “virus scanner” (scnprc) and seems to share some code base with opprc. We will concentrate on opprc in this blog post, as it is one of the most interesting binaries at first glance.
The first thing that came to our attention when looking at the functions in the binary was this: gpsWatermarkingInformation. And there are even more functions like this that sound interesting. You can see a short extract in the picture below.
So it seems that there is some watermarking functionality included. If we look at the available functions there seems to be additional AES crypto involved. From the available functions we can also see that there is watermarking available for documents, images and even audio. By looking at the binary we were able to see that classic word documents are in the list of documents to be fingerprinted. So we thought we will give it a shot and created a simple DOCX file that we copied on a USB drive and attached the drive to the RedStar OS. Guess what: The MD5sum of the file changed. We did not open the file with the included “Sogwang Office” or touch it in any way, it just changed simply making it available to the OS. Now a DOCX file is basically a ZIP with multiple files included. If you look at a DOCX in a hex editor you will see that there are larger areas that are filled with null bytes at the beginning of the file. By looking at the same area again in a file that has once been transfered to RedStar we see some garbage inserted into the file.
The next picture shows a hexdiff with the file before it was transfered to RedStar and after it was transfered. We can see the following: The upper part is the beginning of the original file and the lower part is the beginning of the file that was transfered to RedStar OS. The tainted file has the watermark added at offset 80 and the watermark is 32 byte long. The watermark ends with the string “EOF”.
We still need to figure out what the contents of the watermark are but it seems to come from data extracted from the host’s hardware such as disk serial numbers. Keep in mind that this does not only apply for classic Word files but also for files from the South Korean Hangul word processor and all kinds of media files like audio and pictures. Watermarks for audio files seem to be created by applying a custom filter. The OS even seems capable of keeping track of which files have been opened on the system. This makes it easy to track on which system a file has been created and on which it has been opened. Concerning privacy this is a big deal.
To sum that up: Creating and using media files and documents on RedStar OS can get you into trouble if you are living in North Korea. Do not assume that the files can be kept private and cannot be traced back to the creator!
We would like to thank Iltaek for helping us out and translating some of the stuff from Korean to English. That helped a lot. 😉
Cheers,
Florian
One more thing about reproducibility: The RedStar does not seem to recognize all DOCX documents equally. In my tests Openoffice DOCX files did not receive a watermark whereas documents created with Microsoft Word did receive the watermark. The watermark seems to be independent from the document content (it is the same for multiple different documents).
I can now confirm that for JPGs the same watermark is also applied and is simply appended to the end of the file.
Cheers,
Florian
Can the kernel module be unloaded or otherwise disabled?
We will figure out a way to disable this functionality. At the moment it is a mixture of the user space binary, the kernel module and selinux. It is not trivial for users to deactivate the stuff.
WTH? They use a totally transparent and obvious form of watermarking, even naming the function as “watermark”?? This seems hard to believe. Easy to detect and easy to bypass.
A bypass for a normal user is not that trivial. We don’t know for whom this OS is designed. If it is just for ordinary people running office applications there is no way to figure out how the systems works. Remember, you don’t have unlimited access to information in North Korea.
How it is made, that it doesn’t corrupt the file? And EOF don’t stops reading the file?
The EOF is just a string. It does not necessarily signal the application that it is really the end of the file. It depends on the application. In this case Word or Open Office simply ignore that fact that the string is there.
After some experimentation, I can assume that at least the user-space daemon and the kernel module are indeed very closely linked. At first, I simply tried disabling /usr/bin/opprc by turning off the relevant init file (/etc/init/ctguard.conf). However, the system would not boot. Then, I accessed the system partition from a “normal” Linux distro and restored the init file, but removed the rtscan kernel module from /lib/modules. Surprisingly, the system started without any problems, and I found that /usr/bin/opprc did not start either.
Without rtscan.ko present in /lib/modules, manually running /usr/bin/opprc results in the following message being printed :
process first running
FATAL: Could not open ‘/lib/modules/2.6.38.8-24.rs3.0.i686/kernel/fs/rtscan.ko’: No such file or directory
/dev/res error!
opprcmain error
So it seems like the opprc daemon is responsible for actually injecting rtscan.ko. Knowing Korean code, I wouldn’t be surprised if this is done via system(“insmod /lib/modules/…”) call, or equivalent. In fact, after running strings on the daemon binary, “modprobe rtscan” appears in the list. There are also some (though not a lot of) debug prints, stuff that looks like a list of file extensions, as well as a “get disk serial number” string. So it’s probable that watermarking uses the HDD S/N for identification purposes.
The binary is 768KB large, and so would probably be a large pain to disassemble. The kernel module is much smaller at just 19KB, and disassembling it would be much easier for somebody who has relevant kernel knowledge.
I couldn’t tell whether SELinux played any part in this play. I disabled it by setting SELINUX=disabled in /etc/selinux/config and adding selinux=0 to the kernel command line. The system boots up and seems to work properly with it being disabled.
I guess the next step would be running the opprc binary (and its forks, as it seems it does create some) under strace, or at least redirecting its std{out,err} to a file.
That is exactly what we examined so far. Kernel module and opprc are basically taking care of each other and selinux definitely plays a role, too. In addition there are checksums kept of some files so exchanging them will not work under some circumstances.