Throughout this book we have examined the various aspects involved in modeling APT scenarios by discussing attacks against live targets in various sectors. In this last chapter, we're going to do something a little different. Rather than outline an attack on a legitimate target, we're going to look at a hypothetical intelligence gathering on a nation state. I've chosen North Korea as the target for several reasons but mostly that the massive secrecy that surrounds that hermit state, the various IT tech, and the considerable (indeed unprecedented) censorship that its citizens deal with on a daily basis make it an intriguing example and allows me to demonstrate how much information can be inferred from what is publicly available.
That, however, is not the only reason. Unlike any other nation state, North Korea can more easily be described in terms similar to a closed corporation both in a geopolitical and technological sense rather than just another country (at least from a macroscopic perspective)—granted it's not a company I would want to work for but secrecy is anathema to a good security consultant and it is therefore impossible not to be intrigued by its inner workings.
Against this backdrop, I can introduce some other approaches to advanced penetration testing that you should be familiar with, whether they are revived old school techniques—tried and tested—or newer, more emerging ideas. Therefore, examining North Korea as a closed nation state but within the analogous context of a corporate penetration test allows us to treat the analysis as a total process.
We'll look at the technologies that North Korea deploys such as:
While the Democratic People's Republic of Korea (DPRK) uses various imported tech (Kim Jong-Un is a big fan of Apple), the general populace is not so lucky. Very few members of society enjoy unrestricted Internet access (though that is changing with the import of black market mobile phones from China). Most people who have access to computer technology are forced to use approved operating systems and devices and are restricted to a freely accessible Intranet called Kwangmyong (), meaning “light” or “bright” in English. This is a walled garden and completely separate from the public Internet as we know it. Needless to say, you won't find anything critical about Kim or his regime here. This Intranet is accessible in various places—universities and cultural institutions—and is allegedly available via a dialup connection with North Korea as well. DPRK has its own allocation of a /22
(1,024 hosts) range of public IP addresses, although these are barely populated. Despite this, the IPs are allocated very conservatively; for example the Pyongyang University of Science and Technology has only one allocated address.
DPRK sells an “official” North Korean operating system called Red Star (at version 3.0 at time of writing). Red Star comes in two flavors—desktop and server—and are both based on Fedora Linux with Korea localizations. They are both designed to be highly restrictive from the ground up (albeit in slightly different ways, but we'll get to that). I will make both versions available via torrents from my website should you want to play with them.
First of all, let's examine Red Star Desktop, including its eccentricities and how to exploit it. Figure 9.1 shows what the OS looks like when booted; it's running here in VMWare.
Readers may be forgiven for noting its resemblance to Apple's OS X, which to be fair, has actually been quite nicely achieved. I, for one, find my Korean to be a little rusty, so our first order of business will be to get the thing in English so as to not be constantly referring to Google Translate. To do so, we first need to get a shell, as shown in Figures 9.2 and 9.3.
Type the following, shown in Figure 9.4.
Then a quick reboot and you'll see something like Figure 9.5.
Much more like it!
The assumption that the developers made with regard to the security and integrity of the OS is that it is not possible for users to achieve root permissions and therefore would be unable to deal with the Discretionary Access Control (DAC) provided by SE Linux, as various unpleasant other services running with an eye to monitoring the users and their activity. This assumption is false, as I will demonstrate (note that this security model is completely different than Red Star Server 3.0, where root permissions are granted by default and SE Linux is hardened to prevent it from being disabled. First things first, though).
To grant yourself root credentials, run the program rootsetting, as shown in Figure 9.6.
This will prompt you for a su
password. Confirm it, as shown in Figure 9.7.
At this point, you can elevate your privs
to root using su
, as shown in Figure 9.8.
First, we need to disable SE Linux to disable the DAC, as shown in Figure 9.9.
There are other services running that will reboot the system if you attempt to modify certain systems. They are also designed to watermark files so that the North Korean government can track their origin. You'll want to kill those too (see Figure 9.10).
At this point we can look around a little. Launch the default browser, which is called or naenara (“my country” in English). This is just a rebadged version of Firefox, but what is interesting here is that its homepage is 10.76.1.11, which is obviously a non-routable IP address. The reason for this is that Red Star is intended to be run within the walled garden and this is the IP address for the Intranet's home page, which sadly we can't see from here. The default search engine for the browser is Google Korea.
Now, we can add a local repository and install all the optional packages (should we want to do so).
While sharing the same codebase, the server variant of the operating system has a completely different security model. You are granted root privileges out of the box; however, the root user cannot disable SE Linux in the same way that it can in the Desktop version. See Figure 9.11.
You then get to choose a desktop manager, as shown in Figure 9.12.
The desktop server is a little more minimal than the desktop. Figure 9.13 shows it rendered in English.
There are several ways to disable SE Linux, but you won't be able to modify bootloader options or the SE Linux config files. The best approach is to mount the VMDK files as an OS volume and modify them from there or, if you've installed on bare metal, boot with another OS and do the same thing. To disable SE Linux permanently, you need to do the following to the /etc/selinux/config
file:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
At this point, you can install whatever you want, as with the desktop version.
While playing with the Red Star OS is an educational insight into the sort of totalitarianism that the people there live with every day, it doesn't give us a great deal of insight into the layout of the networking technology. I'd considered travelling to North Korea as a tourist and figuring out a way to access their Intranet so I could map it properly, but thirty years breaking rocks is not my idea of a good time. So if anyone reading this would like to volunteer for that particular mission, you can contact me through the publisher.
The next step is to look at their publicly facing Internet addresses.
DPRK IP space is administered by the Star Joint Venture Co LTD in Ryugyong-dong Potong-gang District and is upstreamed to the CNCGroup backbone in China.
North Korea has been allocated a /22
IP space, that is to say:
175.45.176.0/22 or 175.45.176.0-175.45.179.256
It has the potential for approximately 1,000 IP addresses. Needless to say, there are nowhere near that many in use. Using Masscan
, we can knock up a quick-and-dirty port scan in about an hour that will give us a snapshot in time of what's up and running:
Host: 175.45.178.154 () Ports: 5800/open/tcp////
Host: 175.45.178.154 () Ports: 6002/open/tcp////
Host: 175.45.178.154 () Ports: 5801/open/tcp////
Host: 175.45.178.131 () Ports: 36697/open/tcp////
Host: 175.45.178.133 () Ports: 2105/open/tcp////
Host: 175.45.178.154 () Ports: 6004/open/tcp////
Host: 175.45.178.131 () Ports: 80/open/tcp////
Host: 175.45.178.154 () Ports: 5900/open/tcp////
Host: 175.45.178.154 () Ports: 5804/open/tcp////
Host: 175.45.178.154 () Ports: 111/open/tcp////
Host: 175.45.178.133 () Ports: 53272/open/tcp////
Host: 175.45.178.154 () Ports: 5903/open/tcp////
Host: 175.45.178.129 () Ports: 22/open/tcp////
Host: 175.45.178.154 () Ports: 5802/open/tcp////
Host: 175.45.178.133 () Ports: 2103/open/tcp////
Host: 175.45.178.154 () Ports: 10000/open/tcp////
Host: 175.45.178.133 () Ports: 1801/open/tcp////
Host: 175.45.176.16 () Ports: 53/open/tcp////
Host: 175.45.176.9 () Ports: 53/open/tcp////
Host: 175.45.178.55 () Ports: 25/open/tcp////
Host: 175.45.178.154 () Ports: 22/open/tcp////
Host: 175.45.176.72 () Ports: 80/open/tcp////
Host: 175.45.178.154 () Ports: 5902/open/tcp////
Host: 175.45.178.154 () Ports: 5904/open/tcp////
Host: 175.45.178.154 () Ports: 3128/open/tcp////
Host: 175.45.178.154 () Ports: 39908/open/tcp////
Host: 175.45.178.133 () Ports: 2107/open/tcp////
Host: 175.45.178.154 () Ports: 6003/open/tcp////
Host: 175.45.178.154 () Ports: 5901/open/tcp////
Host: 175.45.178.154 () Ports: 5803/open/tcp////
Host: 175.45.176.15 () Ports: 53/open/tcp////
Host: 175.45.176.8 () Ports: 53/open/tcp////
Host: 175.45.178.154 () Ports: 3306/open/tcp////
Host: 175.45.178.154 () Ports: 6001/open/tcp////
Host: 175.45.176.73 () Ports: 80/open/tcp////
Host: 175.45.178.129 () Ports: 23/open/tcp////
# Masscan done at Tue Sep 27 12:20:31 2016
Getting reliable scans of this range is a pain given that the quality of the link into DPRK is anything but reliable. For example, we know that the web server for The Kim Il Sung University (http://www.ryongnamsan.edu.kp/univ
) is at 175.45.176.79
, but it doesn't show in this scan despite being up at the time. Nonetheless, it's informative as to what isn't filtered from the Internet.
There's an old VNC server vulnerable to various attacks at 175.45.178.154
:
root@wil:~# telnet 175.45.178.154 5900
Trying 175.45.178.154…
Connected to 175.45.178.154.
Escape character is '^]'.
RFB 003.008
A MySQL server at 175.45.178.154
.
A Telnet port for a Cisco router at 175.45.178.129
.
root@wil:~# telnet 175.45.178.129
Trying 175.45.178.129…
Connected to 175.45.178.129.
Escape character is '^]'.
User Access Verification
Username:
An insecure version of squid proxy at 175.45.178.154 (Figure 9.14):
There are open RPC ports and assorted SSH daemons using password authentication. There's even a webmin
server, as shown in Figure 9.15.
DoSing the DNS server at 175.45.176.16 would prevent all name resolutions for the .KP top-level domain.
All in all, I would expect this range to be a hell of a lot more locked down than it is, as there are various avenues of attack here (should one be so inclined). However, North Korea or not, we shall err on the side of international law and not let temptation get the better of us.
Dialing into North Korea is tricky at best. Most phone numbers are not reachable directly and require you to go through the operator at +850 2 18111 (850 is the country code for DPRK and 2 is Pyongyang). This works both ways, with most lines unable to directly call out to the rest of the world.
Phone numbers in DPRK that can receive international calls (and conversely, call out of the country without restriction) always begin with the number 381, directly following the area code. For example, the British Embassy in Pyongyang has the phone number +850 2 381 7982. Numbers that can dial internationally cannot dial locally; therefore, it is usual for such organizations to have two phone numbers with the 381 prefix substituted for 382.
According to Mr. Ri Jung Won, Director, Department of International Relations, the Ministry of Posts and Telecommunications, the current numbering format of North Korea looks like this:
LIST OF ALLOCATIONS IN 2011
Area Code | Length of Customer Number | City Name | Province Name |
2 11 | Pyongyang | Pyongyang | |
2 12 | Pyongyang | Pyongyang | |
2 18 | 3 digits | Pyongyang | Pyongyang |
2 381 | 4 digits | Pyongyang | Pyongyang |
2 771 | 4 digits | Pyongyang | Pyongyang |
2 772 | 4 digits | Pyongyang | Pyongyang |
2 880 | 13 digits | Pyongyang | Pyongyang |
2 881 | 13 digits | Pyongyang | Pyongyang |
2 882 | 13 digits | Pyongyang | Pyongyang |
2 883 | 13 digits | Pyongyang | Pyongyang |
2 885 | 13 digits | Pyongyang | Pyongyang |
195 | 7 digits | Pyongyang | Pyongyang |
31 | 6 digits | Pyongsong | South Phyongan |
39 | 6 digits | Nampo | Nampo |
41 | 6 digits | Sariwon | North Hwanghae |
43 | Songnim | ||
45 | 6 digits | Haeju | South Hwanghae |
49 | 6 digits | Kaesong | North Hwanghae |
53 | 6 digits | Hamhung | South Hamgyong |
57 | 6 digits | Wonsan | Kangwon |
61 | 6 digits | Sinuiju | North Phyongan |
67 | 6 digits | Kanggye | Jagang |
73 | 6 digits | Chongjin | North Hamgyong |
79 | 6 digits | Hyesan | Ryanggang |
82 | Rajin | Kwanbuk | |
85 29 | 4 digits | Rason | Rason |
86 | Sonbong |
There are three mobile network prefixes:
Additionally, the Rason Economic Special Zone has a prefix of 3 and many more lines are directly reachable given the international businesses operating there (mostly Russian, Chinese, and South Korean).
A number of cell phones also permit receiving international calls, although this is something that has to be requested by the subscriber and is not permitted to private individuals. The cell phone infrastructure was built and operated by the Egyptian firm Orascom as Koryolink; however, it has been reported that the North Korean government denied permission for Orascom to repatriate profits from the project and in November 2015 they claimed to have effectively lost control of the infrastructure and are owed millions of dollars—a cautionary tale for any budding tech investors thinking of expanding into the hermit kingdom.
So this is all very interesting, but what does it bring to the table? Back in the days before the massive uptake of the Internet, a lot of computer servers were attached to the telephone network, and the only way to access them was via dialup modems. Hunting for modems to attack was called war dialing and involved using a computer program to automatically dial huge swaths of numbers and recording what was found at the other end of the line, whether it be a voice, voice mail, fax machine, modem, PBX, or other tone. This was most popular in the United States, where local calls were free. In the UK, the free phone exchanges were usually targeted. The software mainly used to achieve this was called Toneloc (see Figure 9.16) and it would produce awesome maps of up to 10,000 numbers. It still works fine today.
What would be fun is if we could do the same thing and call every inbound number in Pyongyang to find modems. Who knows what we might find? Of course, there is a slight problem with this approach in that calling Pyongyang is expensive and calling there 10,000 times would be prohibitively so.
What we can do is use a VoIP calling solution to defray our costs somewhat—it's still expensive and the cheapest solution is 0.2 U.S. cents a minute (and therefore per call, as that's the minimal calling unit), but it's the best we can do. This still sounds expensive and potentially it could be, but remember that you'll only be billed for the numbers that pick up.
The only problem is that we can't carry data calls over VoIP given issues with compression (among other things), so the problem has to be approached in a slightly different way. Rather than using a modem and recording connections, the software we will use takes an audio sample of the response and performs a Fast Fourier Transform on it so the tones can be analyzed. Any tones that fall within a certain frequency we log as modems. Modem responses will contain the following tone DTMFs:
2250hz + 1625hz, 1850hz, 2000hz…
Luckily, a chap named HD Moore did all the hard work for us by creating a software suite called WarVOX. All we need to do is give WarVOX our VoIP account details and the number ranges we want to dial. Then we sit back and wait. You can get it at https://github.com/rapid7/warvox
.
WarVOX uses a web interface and the first thing you'll need to do is add your VoIP service to the provider screen, as shown in Figure 9.17.
You're ready to start a new job (see Figure 9.18).
The output is stored in PostgreSQL, so we can process it any way we like. Rather than dump out 10,000 lines, let's have a look at some choice nuggets. While a lot of fax machines were detected, very few carriers (fewer than 50) were noted.
Carrier 1: An unpassworded Cisco router
Carrier 2: An unpassworded PPPD stream
……
yyui343wfyyui343wfyyui343wfyyui343wfyyui343wfyyui343wfyyui343wfyyui343 wfyyui343wfyyui343wfyyui343wfyyui343wfyyui343wfyyui343wf
Carrier 3: An unknown BBS with bad ASCII art (see Figure 9.19).
As tempting as it is to probe these devices further, we shall once again resist. Yes, it's North Korea and I'm not likely to be extradited any time soon, but the law is the law and this is not a manual on how to break it. Where I live, war dialing and port scanning are not illegal.
There is only one smartphone and one tablet that are approved for use in North Korea—both can be used to access the Kwangmyong walled-garden Intranet. It is, of course, claimed that these were developed locally under the guidance of the Dear Leader and accompanied by the inevitable pictures of him inspecting the “factories” where they are made. In actuality, both devices are manufactured in China and rebadged locally with the nauseating patriotic imagery you should now be familiar with.
The Arirang () (named after the semi-official national anthem of North Korea) is the only smartphone approved for use within DPRK. Despite claims that it is pure North Korean technology, it is a rebranded Chinese Uniscope U1201 running version 4.2.1 (at time of writing) of the Android operating system that has been modified to be as oppressive as the Red Star operating system. Needless to say, there is no Internet access.
There is also an “official” tablet device called the Samjiyon (), which is also an Android device. It is equipped for 3G and can access the walled garden, but the manufacturer claims that it does not have a WiFi adapter. This, it turns out, is erroneous. WiFi hardware is present but has been disabled and anyone with a little Android savvy can enable it. The Samjiyon is also, according to local media, a North Korean invention and given the vast amount of cheap Chinese tablets available, it proved a little trickier to pinpoint exactly what the hardware was. However, a little analysis of the device's Android system files give it away, as shown in Figure 9.20.
It's a Yecon 75 tablet made by Alps in Hong Kong, heavily customized for the North Korean consumer.
Comparatively little is known about the North Korean Intranet. It's an IP-based network that links various sites together within the country, such as universities and governmental organizations. Access is free to North Korean citizens (assuming they can afford the equipment to access it), for whom it intends to provide all the news and information they need (or rather to restrict them to what the government wants them to see, depending on your perspective). Based on the information available, the intranet conforms to internal IP addressing, albeit inconsistently. Several different IP formats are in use, as can be seen in this list of hosts known to exist:
I would imagine the routing tables are a complete mess.
As I said, I would love to get inside this thing and map it out properly. I was hoping to find at least one carrier in the externally accessible phone range that would elicit some kind of access to it, but that was wishful thinking. There is no Internet access available from the Kwangmyong, which would make the nature of it somewhat moot.
It should be noted at this point that the North Korean people are not stupid and, despite the endless stream of propaganda nonsense they are subjected to, more and more of them have access to the Internet through black-market phones sourced from China. This is a technical not a political essay, but it is unlikely that such a regime will survive for long once Internet access becomes more and more saturated.
This final section is not in-depth enough to be classified as payload deployment or C2 management in its own right, but as we've talked a little about Android devices in this chapter, I wanted to include it. As an avenue of attack, it's nascent and will only become more relevant. Assuming that a C2 agent has been successfully deployed to a target endpoint, capturing audio and video is trivial and can be achieved through a number of native or third-party APIs. However, when attacking mobile devices or tablets, this can be more troublesome. It is certainly possible to create apps that, when installed and given certain permissions, can be remotely triggered through push notifications and the microphone and camera turned on and their contents streamed.
However, whether developing for iOS or Android, apps have to go through a review process before being allowed in either the App Store or Google Play and the use of certain APIs in apps that manifestly don't need them will likely be rejected during this process. For example, within the iOS operating there is an API called PushKit that contains two forms of such notifications—one that is standard and one for VoIP applications. The latter is needed to remotely enable call setup without having to maintain a permanent connection to the VoIP server, which will drain the battery fast. This particular API would be perfect for our needs, but using its functionality in an application that is manifestly not for VoIP will certainly be rejected during the review process.
However, with HTML5, we have access to a number of interesting API calls that can be used to access both the microphone and the camera. The benefits of this approach are that the malware code can simply be inserted into a web page and is cross-platform. The attack will work as well on an Android Phone as within a Firefox browser running on Windows. The downside is that as HTML5 is still an emerging standard, not all API calls are supported across all browsers. This of course will improve and HTML5 will likely provide interesting future avenues of attack.
The following code is the simplest possible way to demonstrate the use of HTML5 in media streaming:
navigator.getUserMedia = navigator.getUserMedia ||
navigator.webkitGetUserMedia ||
navigator.mozGetUserMedia ||
navigator.msGetUserMedia;
var video = document.querySelector('video');
if (navigator.getUserMedia) {
navigator.getUserMedia({audio: true, video: true}, function(stream) {
video.src = window.URL.createObjectURL(stream);
}, errorCallback);
} else {
video.src = 'somevideo.webm'; // fallback.
}
This code is suggestive and illustrative and will require some forethought on your part as to how to integrate this into your C2 solution.
Most browsers calling the getUserMedia
API will trigger a warning to the user. However, if you deliver the web page over SSL, this will only happen once and in future permission will be assumed. There is little coherence and agreement over security in the HTML5 standard as it currently stands.
The trick of course is getting the user to visit your web page, which takes us back into the realm of social engineering. There are two avenues of attack. One approach (and this is the preferable one) is a waterhole attack. That is to say that we embed our malicious code into an invisible iFrame of a site that we have previously compromised and that is trusted by the target. The benefits of this approach are two-fold. The first is trust: the target is much more likely to accept any security related messages. The second is persistence: this attack only works as long as the browser is not closed. A trusted website will likely be left open even if it is in the background and the target is no longer actively engaged with it.
An invisible iFrame can be injected as follows:
<iframe width="700" scrolling="no" height="400" frameborder="0" src="hostile_code.html" seamless="seamless">
Note that the seamless tag is another HTML5 oddity. I use it here because it's supported under Chrome/Android.
Another approach is almost the reverse of this. You register a domain name that is similar to the target, load the original website in, and create an iFrame alongside the hostile code.
There are other ways to grab audio/video from the target. Adobe Flash is one such possibility, but it's a technology that's going the way of the Dodo, so I wouldn't recommend it.
There is a certain bitter irony here; the various Linux operating systems were intended to promote openness and collaboration in software development. To see Linux turned into a tool of state control is quite unpleasant.
This final chapter was intended to be something a little different from the format I have otherwise used throughout this book, not just because I wanted to illustrate some open source intelligence gathering techniques, but also because I wanted to finish on a different note, at a different pace. There are several conclusions you can take away from this chapter, perhaps the most obvious being that if you're reading this, then you are likely a free person living in a free society and you probably take that for granted. If there's one lesson that can be learned from this book as a whole, it's that technology is a two-edged sword with very different implications for society, depending on who's wielding it.
.
From this list, consider other means of potential attack against mobile devices, whether it be remote compromise, intelligence gathering, or Denial of Service attacks.18.118.189.251