We'll wait while you get the joke, it's funny...no? Ok.
A lot of what we do is centered around exploiting 'exotic' targets that you don't normally see during the course of an average operation. Red Star OS 3 (RSOS3) is one such intriguing target that presented itself in the digital field, so we decided to recreate our assessment in our lab and post some of our findings.
While previous analysis of RSOS3 has been published, it's always seemed a bit incomplete to us. There was no look at the actual attack surface from the perspective of a real-world digital operation. This left a few details to be discovered and really pursued by others.
This time, we had the actual Operating System to interact with directly, rather than encounter it at first unknowingly until we were able to compromise the host. This allowed us to really dive into the target (as well as make these pretty screenshots for you).
Environment Setup
Within a dedicated localized environment, we proceeded to install Red Star OS 3 as a virtual machine.
Now that the virtual machine is setup, we can proceed to walk-through the RSOS setup.
Upon boot, you're greeted with the above screen in Korean. If you don't know Korean, it's easy enough to guess next steps.
Go with the default option here.
Select the virtual volume to install RSOS to - this is wha was allocated during the VM setup.
Time to create our user account we'll be using to login to RSOS.
We want to make sure our image gets an IP Address to connect to the network, select DHCP.
Once we're done setup will continue and write the files to the virtual disk.
Time to initialize RSOS and boot into it.
The welcome screen
Time to log-in - soon we'll be able to change from Korean to English to make things a bit easier for us.
Default desktop view
Analysis of RSOS3
While reported by other sources that RSOS3 is built on top of Fedora, in actuality, RSOS3 is built on top of Red Hat 4.4.0-4 (keep in mind that RHEL is based on Fedora which is where this confusion might lend itself). This dates the core operating system back to August 2006 - quite old really, with it being EOL March 31, 2017.
RSOS3 comes with SELinux installed which was only a slight surprise to us to be honest. SELinux was originally developed and released by the NSA in 2000, so why the DPRK would be using it is slightly head scratching.
After the initial setup of Red Star, we decided to listen to the wire to determine what if anything RSOS3 was attempting to broadcast out. After reviewing the pcap for traffic it was apparent that the DPRK has setup to route all network traffic through a proxy server with the destination IP Address of 10.76.1.11.
Monitoring network traffic, name queries over NBNS occurred every few seconds to query for WORKGROUPs. Running an exhaustive port scan against RSOS3 we determined that there were only two (2) open ports. These were 139/tcp and 445/tcp, belonging to the SMB service.
Knowing how vulnerable Samba (SMB) is, we decided to take a pass with nmap's NSE scripts; more specifically smb-discover and then smb-brute. Having setup RSOS3 with the username 'redteams' with the password of 'password', it was no surprise when smb-brute came back with a successfully cracked password for the redteams user account.
Client Applications
Upon starting the Naenara web browser (v3.5b4), the client perform a TCP SYN to 10.76.1.11 - with being on a local network (not within DPRK to boot) there were no replies as the local IP Address does not exist obviously.
Since the Naenara Web Browser is a bastardized version of Mozilla Firefox, we can jump into the settings using 'config:about' where we can learn a few more details.
The general.useragent.vendor is set to Fedora with the general.useragent.vendorsub is 1.9.1-2.5.rs3.0
Interesting settings are truncated below:
app.update.url https://10.76.1.11/naenarabrowser/update/3/%PRODUCT%/%VERSION%
app.update.url.details http://10.76.1.11/naenarabrowser/%LOCALE%/releases/
app.update.url.manual http://10.76.1.11/naenarabrowser/%LOCALE%/
extensions.blocklist.detailsURL https://10.76.1.11/naenarabrowser/%LOCALE%/blacklist
Some choice security settings in the browser are set to the following by default:
security.warn_submit_insecure false
This tells us that the DPRK doesn't want their users to be alerted when they are submitting data over forms which may be 'insecure' (sic being man-in-the-middled).
Java is enabled by default, as well as SSL3 and TLS (SSL2 is disabled)
Looks like they forgot to configure the Crash Reporting service in /Applications/Naenara.app/Contents/lib as it still points to ServerURL=https://crash-reports.mozilla.com/submit. Now whether crash reports actually make it to Mozilla is another story with the breakpad report server directed to http://10.76.1.11/naenarabrowser/crash-stats.mozilla.com/report/index/...sneaky.
Reviewing the installed Naerna Browser about:config settings reveal that crash reports using the breakpad report server are directed to:
http://10.76.1.11/naenarabrowser/crash-stats.mozilla.com/report/index/
It also appears that Drop Box may be installed for all users by default, even the root account has /Public/Drop Box/ associated with the home folder.
Exploitation
While RSOS3 is locked down fairly well, thanks to their custom services and SELinux enforcement, it's still fairly trivial to get root. Yes you read that correctly.
It is possible to get root access on RSOS3 within 2 minutes.
When exploiting Linux it's important to search for world writable files as out of date and sloppy configurations can usually give you privilege escalation without too much of an issue. For this particular operating system build, this is done through exploiting the writable file 85-hplj10xx.rules. This file is the HP Laserjet printer rules file that udev (Linux device manager) uses to configure/change device names in userspace and is executed as root. Unfortunately, since it is writable, we can pass it commands to execute on our behalf in order to elevate to root.
To open the terminal; go to 'File Browser' > RedStar > 3rd option down > 4th option down > Utilities > Terminal.
Use the following command to find all files with other writable attributes and pipe it looking for the Linux device manager (udev) service:
find / -perm -o+w | grep /udev/
You should be able to see the 85-hplj10xx.rules file in the listed results; it's the one that does not say permission denied next to it.
Now that we have our target file to use to escalate privileges with, we need to determine which shells are in use on the system:
chsh --list-shells (#you can also cat /etc/shells)
The following will copy the udev rules to a temporary file in case we accidentally botch the working file. Once we have a working copy we create a reference to a new temporary shell script (getroot.sh) that will be used for the elevation by chaining the commands to be executed by the udev rule and create a new entry in /etc/sudoers to allow root elevation. Lastly, the temporary exploit script is set to execute in order to be executed upon reboot.
The code:
cp /etc/udev/rules.d/85-hplj10xx.rules /tmp/udev85.bak echo 'RUN+="/bin/bash /tmp/getroot.sh"' > /etc/udev/rules.d/85-hplj10xx.rules cat <<EOF >/tmp/getroot.sh echo -e "ALL\tALL=(ALL)\tNOPASSWD: ALL" >> /etc/sudoers mv /tmp/udev85.bak /etc/udev/rules.d/85-hplj10xx.rules chown 0:0 /etc/udev/rules.d/85-hplj10xx.rules rm /tmp/getroot.sh EOF chmod +x /tmp/getroot.sh
What the above code does is copy the current rules file to a backup file in the temp directory. It then creates a new temporary file getroot.sh and adds the ability to gain root access via the sudo command. Once the getroot.sh file is made executable through chmod, you reboot RSOS3 and log back in with your account. Once logged in, open the terminal window and type 'sudo su' to gain root access.
Below you will see how to allow root access by modifying /sbin/nologin to /bin/bash - thus allowing you to easily drop to root.
EASY!
Once you have admin, you can do two things to increase functionality/usability; 1) flush iptables and reboot in order to access the Internet, and 2) change the default language from Korean to English if desired.
To clear the default iptables, run the follow command:
rm /etc/sysconfig/iptables
To change from Korean to English, use the following commands:
sed -i 's/ko_KP/en_US/g' /etc/sysconfig/i18n sed -i 's/ko_KP/en_US/g' /usr/share/config/kdeglobals
Once you've performed the above commands, reboot the sytem for changes to take affect. Now that you have RSOS3 setup in English and have iptables flushed, you can now proceed to use the system and browser the Internet much easier.
Web Browsing to a website with Wireshark running, we can see that RSOS3 broadcasts itself by leaking the user-agent as Naenara Browser and Fedora /1.9.1-2.5.rs3.0 (Red Star 3.0). Remember why I mentioned the confusion around Red Hat and Fedora - now you can see why.
With all of the above said, we've taken you through some discovery of Red Star OS 3; to include discovery and enumeration of its attack surface, along with some exploitation methods in order to own the system. We hope this post was interesting to read and would welcome feedback on this or anything else, including any specific topics around digital exploitation you would like to see.
DW out
UPDATE: Now that WannaCry (and SambaCry) has made the rounds, I've decided to post this (draft dated March 15, 2016) since these exploits have run their course through the media and their vulnerabilities have patches issued. Some deeper information from this post has been redacted based on operational developments over the past year.