Analyse van DNS-tunnelingtechnieken. Daan Raman

Analyse van DNS-tunnelingtechnieken Daan Raman

Promotoren: prof. dr. ir. Bjorn De Sutter, prof. dr. ir. Koen De Bosschere Begeleiders: Bart Coppens, Stijn Volckaert, Pieter Danhieux en Erik Van Buggenhout (Ernst & Young) Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Elektronica en Informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2010-2011

VOORWOORD

iii

Voorwoord Eerst en vooral wil ik mijn promotoren Prof. Dr. Ir. Bjorn De Sutter en Prof. Dr. Ir. Koen De Bosschere bedanken voor hun erg nuttig advies en feedback tijdens het realiseren van mijn scriptie. Ook een woord van dank aan Bart Coppens en Stijn Volckaert voor hun hulp bij het voorbereiden van de presentaties en het geven van waardevolle tips en suggesties. Dank aan Stijn Volckaert voor zijn hulp bij het aanpassen van de ReflectiveLoader voor het gebruik in mijn implementatie. Graag wil ik ook Pieter Danhieux bedanken voor het aanreiken van dit erg boeiende thesisonderwerp. Zijn advies en expertise rond beveiliging en DNS-tunneling waren erg waardevol bij de aanvang van mijn scriptie. Verder wil ik Erik Van Buggenhout bedanken voor de begeleiding tijdens het tweede deel van mijn scriptie. Zijn ervaring bij de beveiliging van bedrijfsnetwerken hebben mij enkele belangrijke inzichten gegeven waarvoor dank. Verder wil ik ook graag volgende leden van de #metasploit en #skullsecurity kanalen bedanken voor hun hulp tijdens mijn verkenning van metasploit en hun erg nuttig advies tijdens de implementatie: hdm, egypt, jduck, iago-x86 en mtgarden. Ten slotte wil ik mijn ouders bedanken die mij de mogelijkheid hebben gegeven om verder te studeren.

Daan Raman, juni 2011

TOELATING TOT BRUIKLEEN

iv

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Daan Raman, juni 2011

Analyse van DNS-tunnelingtechnieken door Daan Raman Scriptie ingediend tot het behalen van de academische graad van Burgerlijk Ingenieur in de Computerwetenschappen: optie software engineering Academiejaar 2010–2011 Promotoren: Prof. Dr. Ir. Bjorn De Sutter en Prof. Dr. Ir. Koen De Bosschere Begeleiders: Lic. Bart Coppens, Ir. Stijn Volckaert, Pieter Danhieux (Ernst & Young) en Erik Van Buggenhout (Ernst & Young) Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Elektronica en Informatiesystemen Voorzitter: Prof. Dr. Ir. J. Van Campenhout

Samenvatting Bedrijfsnetwerken worden beveiligd door firewalls met als doel communicatiekanalen te blokkeren die door kwaadwillige gebruikers worden opgezet tijdens een gerichte aanval. De aanwezigheid van firewalls maakt het moeilijk voor een aanvaller om een communicatiekanaal te realiseren met een aangevallen computer binnen het beveiligde netwerk. In tegenstelling tot traditionele TCP-verbindingen wordt DNS-verkeer zonder beperkingen toegelaten binnen het bedrijfsnetwerk. DNS-tunneling maakt van deze observatie gebruik om een betrouwbaar communicatiekanaal te realiseren tussen twee computers door enkel en alleen gebruik te maken van geldig DNS-verkeer. Deze scriptie onderzoekt de mogelijkheden van DNS-tunneling bij het opzetten van een betrouwbaar communicatiekanaal tijdens een gerichte aanval tegen een computer binnen een bedrijfsnetwerk. Een belangrijk onderdeel van de scriptie is een werkende DNS-tunnelimplementatie in metasploit.

Trefwoorden DNS-tunneling, metasploit, netwerkbeveiliging

An analysis of DNS tunneling techniques Daan Raman Supervisor(s): Bjorn De Sutter, Bart Coppens, Stijn Volckaert, Pieter Danhieux (Ernst & Young), Erik Van Buggenhout (Ernst & Young) Abstract—Corporate networks are often hardened with firewalls to prevent malicious network activity and remote attacks. This poses a problem for potential attackers wishing to set up a post-exploitation communication channel with the attacked client in the corporate network since these channels are often blocked by firewalls. However, DNS traffic is typically allowed virtually free passage through firewalls, providing an effective potential attack vector. DNS tunneling uses this observation to establish a communication channel between two hosts by using only valid DNS traffic. This article discusses ways of using DNS tunneling to establish a two-way communication channel between a client in a corporate network and a remote attacker. The results include an implementation of DNS tunneling in metasploit. Keywords—DNS tunneling, network security, penetration testing, metasploit

I. I NTRODUCTION

T

RADITIONAL methods for post-exploitation communication with an attacked client often involve TCP connections. TCP connections are prone to firewalls scans, which often renders traditional communication channels useless during an attack. By hiding data in DNS queries and their responses it becomes possible to set up a communication channel between two hosts using DNS. This technique is called DNS tunneling. In order to successfully tunnel data using DNS several problems need to be addressed: firstly, a polling mechanism is required to support traffic from the DNS server to a client. Next, since DNS records only support textual data, we need methods of transforming binary data to text. Finally, we must add control data to the tunneled data to make the communication channel reliable since DNS uses the unreliable UDP protocol. In what follows we address these three problems. II. DNS TUNNELING DNS works in a client-server fashion. In a client-server model it is the client that takes initiative to communicate with the server. If one side of the DNS tunnel is the server and the other side is the client, then the server is unable to tunnel data back to the client since it is unable to contact the client without a prior query sent by that client. To solve this problem we can use polling. With polling a client sends a DNS query to a DNS server in a fixed interval - this way the server is given the opportunity to send back data to the client using the responses to the polling queries. To send binary data through the DNS tunnel we must find ways to transform binary data into text strings at one side of the tunnel, and apply the inverse operation at the other side of the tunnel to obtain the original data again. NetBIOS [1] and Base32 [2] are both suitable for this purpose since both encoding methods are case-insensitive as are DNS records. Converting binary data to a text format results in a space overhead since byte values are mapped onto a smaller character set. For NetBIOS every byte

of data is converted to two bytes of readable text in the range [‘A’-‘P’] resulting in a space overhead of 100%. Base32 maps binary data to twenty-six letters [‘A’-‘Z’] and six digits [2-7] resulting in a space overhead of approximately 60%. Another issue with using DNS for the purpose of a communication channel is reliability and ordering. Since DNS operates over UDP we must add control data to the application layer to make the communication channel reliable. This control data includes message counters to prevent packet loss and out-of-order delivery. To prevent caching in DNS servers operating on the path between the attacker and the victim a few bytes of random data are added to every tunneled DNS message. This highly increases the probability of the uniqueness of every message exchanged through the DNS tunnel. To further decrease this probability of caching a low TTL (Time To Live) is set for every DNS message. DNS supports a wide variety of record types. The most commonly used record types are A records and CNAME records. A and AAAA records are used to translate domain names to matching IP-addresses. CNAME records provide support for canonical names on the internet. A less frequently used record type is the TXT record. This record type allows administrators of DNS servers to add a textual description to domain names and is mainly used for e-mail address verification using the Sender Policy Framework (SPF) [3]. To successfully tunnel data using DNS it is crucial to use valid DNS records to encapsulate all data before transmission. Candidate record types are both CNAME and TXT records since both support textual data. Other records types such as the A and AAAA record are not suitable for tunneling since according to the DNS standard [4] these record types can only contain an IP-address as part of the DNS response. We take into account two important criteria when deciding on which record types to use for DNS tunneling: optimizing bandwidth by sending as much data as possible and reducing the probability of detection by using record types that are often observed in regular DNS traffic. After discussing solutions to the three aforementioned problems, we want to use DNS-tunneling as a reliable two-way communication channel during an attack against a corporate network. To achieve this goal, an implementation was realized in metasploit. III. I MPLEMENTATION Metasploit is a security framework used worldwide by security professionals to test the security of corporate networks. Several components were implemented in metasploit to support DNS tunneling during an attack: on the side of the attacker

a DNS server and DNS tunnel handler were developed. Both components were developed in ruby and rely on the MSF::Base library to interact with the framework. On the victims’ side both a DNS stager and DLL stager were implemented. These components were developed in assembly and C. Figure 1 gives an overview of all components and their interaction during the attack.

DNS traffic. This is illustrated in Figure 2 for CNAME records and in Figure 3 for TXT records.

DNS tunnel endpoints

Attacker

DNS tunnel handler

Victim

DNS server

DNS stager

Transition network

Session

MSF::Base

API calls Communication

DLL stager

Stage

kernel32 & winsock2

metasploit

Fig. 1. Overview of all implemented DNS tunneling components and their interaction in metasploit.

The DNS stager is based on DNS Cat by Ron Bowes [5] and was extended with NetBIOS support. The DLL stager makes use of reflective DLL injection [6]. Both the DNS server and DLL stager make use of a TCP abstraction layer to translate session data between the tunnel endpoints to valid DNS traffic. The session and stage components on Figure 1 are part of the metasploit framework and did not require any changes.

Fig. 2. Comparison of CNAME record length between traditional DNS traffic and tunneled DNS traffic generated by the own implementation. On the horizontal axis are the query length intervals (in bytes). The vertical axis represents the total percentage of all CNAME records for a specific length interval.

Blocking queries in a certain length interval representing a high percentage of all DNS traffic could successfully block DNS tunnels. For the analyzed data in Figures 2 and 3 this means blocking all CNAME records in the [40-50] and TXT records in the [200-210] length interval.

IV. S ECURITY Several options can be considered to block DNS tunneling attacks against a corporate network. A first technique blocks certain record types used by DNS tunneling implementations. Only record types that are not used for the correct resolving of domain names can be blocked in a realistic setup. This excludes A and CNAME record types since both are fundamental for the correct resolving of domain names to IP addresses. TXT records do not play a fundamental role in domain name resolving. Blocking TXT records disables features provided by the Sender Policy Framework in the fight against spam but does not interfere with the core functionality of DNS: translating domain names to IP addresses. Blocking certain types of records is not a very flexible solution since attackers can always respond by adding support for different record types such as NS records. Unlike TXT records, NS records are a fundamental part of the recursive nature of DNS and can not be blocked by system administrators. A second technique to protect against DNS tunneling is based on the analysis of the data in the DNS queries. Assuming an attacker takes full advantage of the available space in a single DNS query, tunneled DNS queries will tend to be much longer than regular DNS queries. This behavior is confirmed by comparing the record length between regular DNS traffic and traffic generated by the DNS tunneling implementation. Using this observation we can block queries based on the length of the requested domain name. Tests indicate that DNS traffic generated by the own implementation has different properties than regular

Fig. 3. Comparison of TXT record length between traditional DNS traffic and tunneled DNS traffic generated by the own implementation. On the horizontal axis are the query length intervals (in bytes). The vertical axis represents the total percentage of all TXT records for a specific length interval.

Blocking DNS tunnels based on the detection of used date encoding scheme such as NetBIOS and Base32 in the analyzed DNS traffic requires a lot of processing power and might not be feasible in a realistic corporate network. A last defensive strategy against DNS tunnels makes use of a DNS proxy. This proxy intercepts all DNS traffic between clients in the corporate network and the public internet. Whenever a client sends a DNS query it is the task of the proxy server to recursively resolve the requested domain until an A record is received. This A record is then forwarded to the client. Using a DNS proxy prevents exchange of possibly malicious record types such as CNAME and TXT records between the client and the DNS servers, while still offering domain resolving to the clients in the corporate network. Using this technique requires

no complex query analysis as was the case in the aforementioned techniques. The use of a DNS proxy provides a realistic countermeasure against DNS tunnel attacks in real time. V. R ESULTS We realized a working DNS tunneling implementation in the metasploit framework. This implementation was tested in a realistic setup using the Google DNS server and a free service used to gain authoritative rights of a subdomain [7]. We measured the throughput and achieved an average speed of 2.18 kB/s during the exchange of tunneled session data between attacker and victim. The implementation supports the metasploit shell stage, giving an attacker the option of tunneling a command line session over DNS. Other stages such as meterpreter and VNC require SSL support and higher bandwidth and are part of future work. VI. C ONCLUSION In this article we investigated the possibilities of using DNS to create a reliable communication channel between two computers. We discussed three techniques that make DNS suitable for this task: a polling mechanism to support two-way communication, data encoding schemes to transform binary data to readable text supported by DNS record types, and the addition of control data to make the communication channel reliable. We realized an implementation in metasploit, a security framework used by security specialists worldwide to test the security of corporate networks. The current implementation supports tunneling a command line session by solely using standard DNS traffic. This results in a communication channel difficult to prevent in the context of present-day corporate networks. R EFERENCES [1] Microsoft Corporation, ASCII and Hex Representation of NetBIOS Names, http://support.microsoft.com/kb/194203 [2] Network Working Group, The Base16, Base32, and Base64 Data Encodings, http://tools.ietf.org/html/rfc4648 [3] The SPF Council, ”Sender Policy Framework”, http://www.openspf.org/ [4] Network Working Group, ”Domain Names - Implementation and Specifications”, http://tools.ietf.org/html/rfc1035 [5] Ron Bowes, ”DNS Cat”, http://www.skullsecurity.org/wiki/index.php/Dnscat [6] Stephen Fewer, ”Reflective DLL Injection”, http://www.harmonysecurity.com/files/HSP005 ReflectiveDllInjection.pdf [7] Joshua Anderson, ”Free DNS Hosting, Dynamic DNS Hosting, Static DNS Hosting, subdomain and domain hosting.”, http://freedns.afraid.org

INHOUDSOPGAVE

ix

Inhoudsopgave Voorwoord

iii

Toelating tot bruikleen

iv

Overzicht

v

Extended abstract

vi

Gebruikte afkortingen

xii

1 Inleiding 1.1 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Structuur van de scriptie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Gerelateerd werk 2.1 Netwerktunneling . . . . . . . 2.2 DNS . . . . . . . . . . . . . . 2.2.1 Recordtypes . . . . . . 2.2.2 Structuur DNS-pakket 2.3 DNS-tunneling . . . . . . . . 2.4 DNS-tunneling software . . . 2.4.1 DNS Cat . . . . . . . . 2.4.2 tcp-over-dns . . . . . . 2.5 Metasploit . . . . . . . . . . . 2.5.1 Exploits . . . . . . . . 2.5.2 Payloads . . . . . . . . 2.5.3 Encoders . . . . . . . . 2.5.4 NOPs . . . . . . . . . 2.5.5 Aux . . . . . . . . . . 2.5.6 Interfaces . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

1 2 5 5 7 7 9 11 15 18 22 22 23 24 25 25 26 26 26 27

INHOUDSOPGAVE

x

2.5.7 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.8 Voorbeeld van een aanval in Metasploit . . . . . . . . . . . . . . . . 2.6 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Werking van de DNS-tunnel 3.1 Inleiding . . . . . . . . . . . . . . 3.2 Componenten . . . . . . . . . . . 3.3 Het communicatiekanaal . . . . . 3.3.1 Verkeer in twee richtingen 3.3.2 Betrouwbaarheid . . . . . 3.3.3 Binaire data . . . . . . . . 3.4 Besluit . . . . . . . . . . . . . . .

27 28 29

. . . . . . .

30 30 31 32 32 34 37 39

. . . . . . . . . . .

40 40 41 42 44 44 46 51 51 55 60 61

. . . . . . . .

62 62 62 64 64 65 66 67 68

6 Evaluatie 6.1 Testopstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Aanval binnen lokaal netwerk . . . . . . . . . . . . . . . . . . . . . 6.1.2 Aanval over het publieke internet . . . . . . . . . . . . . . . . . . .

69 70 70 70

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

4 Implementatie van de DNS-tunnel in metasploit 4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . 4.2 Overzicht van de aanval in metasploit . . . . . . . 4.3 Componenten . . . . . . . . . . . . . . . . . . . . 4.4 De aanvaller . . . . . . . . . . . . . . . . . . . . . 4.4.1 DNS-tunnel handler . . . . . . . . . . . . 4.4.2 DNS-server . . . . . . . . . . . . . . . . . 4.5 Het slachtoffer . . . . . . . . . . . . . . . . . . . . 4.5.1 DNS-stager . . . . . . . . . . . . . . . . . 4.5.2 DLL-stager . . . . . . . . . . . . . . . . . 4.5.3 Stage . . . . . . . . . . . . . . . . . . . . . 4.6 Besluit . . . . . . . . . . . . . . . . . . . . . . . . 5 Bescherming tegen DNS-tunneling 5.1 Inleiding . . . . . . . . . . . . . . . . . 5.2 Blokkeren van bepaalde recordtypes . . 5.3 Analyseren van DNS-queries . . . . . . 5.3.1 Datalengte . . . . . . . . . . . . 5.3.2 Codering . . . . . . . . . . . . . 5.3.3 Het gebruik van een DNS-proxy 5.3.4 Frequentie van aanvragen . . . 5.4 Conclusie . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . .

INHOUDSOPGAVE 6.2 6.3 6.4

xi

Bandbreedte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyse van getunneld DNS-verkeer . . . . . . . . . . . . . . . . . . . . . . Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 Conclusies en toekomstig werk 7.1 Mogelijke uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 Ondersteunen van encryptie . . . . . . . . . . . . . . . . . . 7.1.2 Ondersteunen van simultane sessies met eenzelfde computer 7.1.3 Ondersteunen van meerdere domeinnamen . . . . . . . . . . 7.1.4 Ondersteunen van meer recordtypes . . . . . . . . . . . . . . 7.1.5 Ondersteunen van meer stages . . . . . . . . . . . . . . . . . 7.2 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

70 73 75 76 77 77 78 78 78 79 79

Bibliografie

80

Lijst van figuren

83

Lijst van tabellen

85

GEBRUIKTE AFKORTINGEN

Gebruikte afkortingen DNS

Domain Name Service

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

IDPS

Intrusion Detection and Prevention System

FTP

File Transfer Protocol

HTTP Hypertext Transfer Protocol NOP

No Operation

VNC

Virtual Network Computing

xii

INLEIDING

1

Hoofdstuk 1 Inleiding Het beveiligen van computersystemen geniet sinds de opkomst van netwerken steeds meer aandacht. Zowel hardware- als softwaresystemen worden vandaag de dag ingezet om te voorkomen dat kwaadwillige gebruikers ongeoorloofd toegang krijgen tot een systeem. Deze kwaadwillige gebruikers maken vaak misbruik van fouten in software, om zo de controle over een computer over te nemen. Waar een aanvaller vroeger steeds een grote kennis nodig had van het doelwit om een aanval te laten slagen, is het de laatste jaren door de opmars van software zoals metasploit [5] steeds makkelijker geworden om op geautomatiseerde wijze computersystemen aan te vallen, zonder al te veel kennis van de computer in kwestie. Bij een goede beveiliging van een netwerk horen onder meer het up-to-date houden van gebruikte software om beveiligingslekken te voorkomen, en het opstellen van regels voor het toelaten of weigeren van connecties tussen computers binnen en buiten het bedrijfsnetwerk. Deze regels zijn vaak erg restrictief, waarbij enkel en alleen verbindingen die essentieel zijn voor de werking van het bedrijf toegelaten worden. Dit legt grote beperkingen op aan de aanvaller, die daarom creatief uit de hoek moet komen om in deze omgeving een werkend communicatiekanaal op te zetten met het slachtoffer [10]. Zo een communicatiekanaal is nodig indien de aanvaller interactief met het aangevallen systeem wil communiceren. In deze scriptie wordt DNS-tunneling onderzocht, een techniek die kan gebruikt worden om ook in een erg restrictieve omgeving zo een communicatiekanaal op te zetten. Daartoe werd een implementatie ontwikkeld van DNS-tunneling in metasploit.

1.1 Probleemstelling

1.1

2

Probleemstelling

Vooraleer we overgaan tot de bespreking van DNS-tunneling, kijken we in dit hoofdstuk naar bestaande mogelijkheden voor het opzetten van een communicatiekanaal tussen een aanvaller en een computer op afstand. Een bestaande techniek om dit te doen is het opzetten van een TCP-verbinding. Hierbij maken we onderscheid tussen bind en reverse verbindingen [12]. Bij bind verbindingen zal de aanvaller een verbinding maken met een luisterende TCP-socket op afstand, bij een reverse TCP-verbinding zal het slachtoffer een verbinding maken met een luisterende TCP-socket aan de kant van de aanvaller. Het is de taak van de netwerkbeheerder om deze ongewenste verbindingen te blokkeren en alle gewenste verbindingen die deel uitmaken van de normale werking van het bedrijfsnetwerk ongemoeid te laten. Er werden reeds vele oplossingen uitgewerkt om ongewenste verbindingen tussen een bedrijfsnetwerk en het internet te vermijden, waarvan firewalls de meest gekende zijn. Deze zijn in staat om aan de hand van regels te bepalen of een bepaald netwerkpakket mag worden doorgestuurd of niet. Firewalls kunnen zowel op pakket- als op applicatieniveau werken [6]. Deze laatste soort van firewalls zijn in staat om op basis van bepaalde protocollen (HTTP, DNS, FTP, . . . ) verkeer al dan niet toe te laten binnen het bedrijfsnetwerk. Na de firewalls vormen Intrusion Detection and Prevention Systems of IDPS [1] een belangrijk hulpmiddel voor de systeembeheerder om ongeautoriseerde toegang tot het netwerk te detecteren. Een IDPS wordt beheerd door een reeks regels die verdacht gedrag in een computersysteem beschrijven. Wanneer een sensor in het IDPS aan de hand van deze regels bepaalde acties als verdacht classificeert wordt deze verdachte actie afgebroken en zal de systeembeheerder hiervan op de hoogte worden gebracht. Figuur 1.1 geeft een overzicht van de verschillende componenten die typisch terug te vinden zijn in een bedrijfsnetwerk. Dit netwerk bestaat uit een reeks clients die beveiligd worden door een firewall. Op de figuur wordt een onderscheid gemaakt tussen het pad gevolgd door DNS-verkeer en niet-DNS verkeer. Wat meteen opvalt is de rol van de firewall die alle verkeer tussen de clients in het bedrijfsnetwerk en het publieke internet zal gaan controleren op ongewenst gedrag. Een voorbeeld van ongewenst gedrag is een computer buiten het bedrijfsnetwerk die een TCP-verbinding probeert op te zetten met een client binnen het bedrijfsnetwerk. Wanneer dit gebeurt zal de firewall het verzoek van de computer op afstand voor het aanmaken van een TCP-verbinding gaan onderscheppen, en zo de communicatie via deze weg onmogelijk maken.


3

client A F I R E W A L L

client B

Webserver Internet

DNS-server

client C

lokale DNS server

DNS verkeer Niet-DNS verkeer

Bedrijfsnetwerk

Figuur 1.1: Overzicht van de verschillende componenten in een typisch bedrijfsnetwerk.

Netwerkverbindingen die noodzakelijk zijn voor de correcte werking van het bedrijf mogen echter niet geblokkeerd worden door de firewall: hiertoe behoren ondermeer verbindingen met bepaalde webservers buiten het bedrijfsnetwerk, zoals weergegeven op Figuur 1.1. Om het onderscheid te maken tussen verbindingen die al dan niet moeten geblokkeerd worden zal in de praktijk vaak gebruik gemaakt worden van blacklists en whitelists. Een blacklist bevat een lijst van poortnummers waarlangs communicatie met computers op het publieke internet verboden is. Een whitelist werkt net omgekeerd en zal een lijst van poortnummers bevatten waarlangs communicatie met computers op het publieke internet mogelijk is. Om de eerder besproken netwerkverbindingen tussen clients in het bedrijfsnetwerk en computers op het publieke internet mogelijk te maken is er nood aan een protocol dat computers op afstand eenvoudig aanspreekbaar maakt. Dit is de taak van het Domain Name System (DNS). DNS is het protocol dat op het internet wordt gebruikt om namen van computers naar IP-adressen te vertalen en omgekeerd. DNS biedt gebruikers de mogelijkheid om computers aan te spreken door enkel hun naam te onthouden: DNS verzorgt vervolgens de omzetting van deze naam naar het bijhorend IP-adres. Zo zal een gebruiker enkel het adres van een website moeten onthouden (bijvoorbeeld www.google.be) en zal DNS het bijhorend IP-adres opzoeken: in dit geval 74.125.79.147. Deze omzetting van computernaam naar IP-adres noemen we in de context van DNS een lookup. Ook de omgekeerde actie, waarbij een IP-adres wordt omgezet naar een domeinnaam, wordt ondersteund door DNS. Dit is een reverse lookup.


4

Figuur 1.1 bevat twee componenten die van belang zijn voor de werking van DNS in het bedrijfsnetwerk: de lokale DNS-server die deel uitmaakt van het bedrijfsnetwerk en een DNS-server op het publieke internet. De lokale DNS-server zal door de clients binnen het bedrijfsnetwerk aangesproken worden voor het uitvoeren van lookups. Wanneer een lookup voor een domein buiten het bedrijfsnetwerk aankomt bij de lokale DNS-server zal deze communiceren met andere DNS-servers op het publieke internet om zo de client te kunnen voorzien van een antwoord. De communicatie tussen de lokale DNS-server en de DNS-servers in het publieke internet gebeurt op recursieve wijze. Dit mechanisme wordt uitgebreid besproken in hoofdstuk 2. Wat nu vooral van belang is voor deze scriptie is de observatie dat DNS-verkeer binnen het bedrijfsnetwerk veelal zonder restricties van de firewall het publieke netwerk kan bereiken. Dit wordt ge¨ıllustreerd door de stippellijnen op Figuur 1.1. Lookups worden door de clients rechtstreeks naar de lokale DNS-server van het bedrijfsnetwerk gestuurd, zonder de firewall te passeren. Ook de antwoorden op deze lookups worden door de lokale DNS-server rechtstreeks doorgestuurd naar de clients. De reden waarom het pad gevolgd door DNS-verkeer afwijkt van de rest van het netwerkverkeer is het feit dat DNS door zijn erg beperkte functionaliteit en heel specifieke taak (het vertalen van domeinnamen naar IP-adressen) doorgaans wordt vertrouwd binnen het bedrijfsnetwerk. In wat volgt plaatsen we ons in de positie van een potentiële aanvaller van het bedrijfsnetwerk. Deze aanvaller bevindt zich op het publieke internet. Mogelijke doelstellingen van een aanval zijn onder andere het stelen van vertrouwelijke data, het verstoren van de normale werking van het netwerk en het installeren van malafide software op de computer van het slachtoffer. Voor het slagen van zulke aanvallen is het cruciaal dat de aanvaller beschikt over een communicatiekanaal met het doelwit binnen het bedrijfsnetwerk. In een bedrijfsnetwerk waar verkeer wordt beveiligd door firewalls is dit echter vaak problematisch: indien een aanvaller bijvoorbeeld een rechtstreekse TCP-verbinding probeert op te zetten met een computer in het bedrijfsnetwerk zal deze onderschept worden door de firewall, waardoor de aanval faalt. Als oplossing voor dit probleem wordt in deze scriptie een techniek bestudeerd die als doel heeft het opzetten van een communicatiekanaal tussen een aanvaller en een computer binnen een sterk beveiligd bedrijfsnetwerk. Deze techniek heet DNS-tunneling en zal gebruik maken van de observatie dat DNS-verkeer in het bedrijfsnetwerk vrij kan verstuurd en ontvangen worden om zo firewalls te omzeilen en de slaagkansen van een aanval te vergroten. DNS-tunneling is een relatief recente techniek voor het opzetten van communicatiekanalen

1.2 Doelstelling

5

en zal in deze scriptie verder onderzocht worden.

1.2

Doelstelling

Het doel van deze scriptie is te onderzoeken welke mogelijkheden DNS-tunneling biedt voor het opzetten van een communicatiekanaal tijdens een aanval op een systeem in een bedrijfsnetwerk. Daartoe zullen we eerst experimenteel onderzoeken wat de fundamentele mogelijkheden en beperkingen van het DNS-protocol zijn. Dat zullen we doen aan de hand van een eerste experiment, waarbij een DNS-tunnel wordt opgezet tussen een lokale DNS-server en een computer op afstand. Hierbij zal ook bestudeerd worden welk type van DNS-verkeer geschikt is voor het doorsturen van binaire data, een taak waar het DNSprotocol oorspronkelijk niet voor ontwikkeld werd. Via enkele experimenten zal ook de haalbare communicatiesnelheid van DNS-tunneling bepaald worden. Een tweede vooropgesteld doel is om DNS-tunneling te bestuderen in het kader van een gerichte, realistische aanval tegen een bedrijfsnetwerk. Daartoe zullen we een eigen implementatie ontwikkelen in het metasploit framework, dat speciaal werd ontwikkeld voor het uitvoeren van beveiligingsaudits. Het realiseren van een implementatie die naadloos gebruikt kan worden in metasploit behoort tot één van de belangrijkste doelstellingen van deze scriptie. Door een aanval gebaseerd op DNS-tunneling met metasploit uit te voeren, waarvan de overige componenten realistische aanvalscomponenten implementeren, garanderen we immers dat de DNS-tunneling zelf in een realistische omgeving ingebed zit. Bovendien worden onze onderzoeksresultaten op die manier direct bruikbaar voor computerbeveiligingsspecialisten overal ter wereld. Tenslotte zullen we manieren onderzoeken om het bedrijfsnetwerk te beveiligingen tegen aanvallen die gebruik maken van DNS-tunneling. De focus van deze scriptie ligt echter op de offensieve kant van DNS-tunneling, bekeken vanuit het standpunt van een potentiële aanvaller van het bedrijfsnetwerk.

1.3

Structuur van de scriptie

Het vervolg van deze scriptie is als volgt gestructureerd:

1.3 Structuur van de scriptie

6

• Hoofdstuk 2 geeft een overzicht van het werk gerelateerd aan deze scriptie, samen met een inleiding tot netwerktunneling, DNS en DNS-tunneling. • Hoofdstuk 3 bespreekt de conceptuele werking van een DNS-tunnel. • Hoofdstuk 4 beschrijft de implementatie van de DNS-tunnel in metasploit. • Hoofdstuk 5 bespreekt mogelijke beveiligingstechnieken tegen DNS-tunnels. • Hoofdstuk 6 bespreekt aan de hand van enkele experimenten de prestaties van de eigen implementatie. • Hoofdstuk 7 vat de resultaten samen en geeft een suggesties voor mogelijke uitbreidingen op de besproken technieken.

GERELATEERD WERK

7

Hoofdstuk 2 Gerelateerd werk In dit hoofdstuk geven we een overzicht van gerelateerd werk. We beginnen met een bespreking van het concept tunneling. Vervolgens wordt DNS besproken, het netwerkprotocol dat de hoofdrol speelt in deze scriptie. De combinatie van tunneling en DNS leidt tot DNS-tunneling, dat we ook in dit hoofdstuk zullen introduceren. Tenslotte bespreken we reeds bestaande tools die DNS-tunneling ondersteunen, alsook het framework waarin in Hoofdstuk 4 de eigen implementatie werd gerealiseerd: metasploit.

2.1

Netwerktunneling

Een netwerktunnel is een speciaal type netwerkverbinding tussen twee computers die zich in twee verschillende netwerken bevinden. Het doel van netwerktunnels is het verbinden van twee computers op zo een manier dat het lijkt alsof beide computers zich in hetzelfde netwerk bevinden. De techniek die hiervoor wordt toegepast heet inkapseling. Bij inkapseling zullen we aan elk uitgaand netwerkpakket dat bedoeld is voor versturen via de tunnel extra informatie toevoegen. In de praktijk zal inkapseling inhouden dat aan een netwerkframe extra headerinformatie wordt toegevoegd, waardoor het verkeer bruikbaar wordt gemaakt voor getunnelde verzending over een medium zoals het publieke internet. Wat inkapseling zo interessant maakt is de mogelijkheid om netwerkpakketten die gebruik maken van een bepaald protocol door te sturen via een ander protocol. Het principe van inkapseling wordt ge¨ıllustreerd in Figuur 2.1. In dit voorbeeld willen we

2.1 Netwerktunneling

8 Tunnel eindpunten

Computer B

Computer A

Ontvangen data

Te versturen data Headerinformatie (inkapseling)

Transitnetwerk

Figuur 2.1: Het toepassen van inkapseling bij netwerktunneling.

data via de tunnel doorsturen van computer A naar computer B. Het is belangrijk om op te merken dat de te versturen data veel verschillende gedaantes kan hebben: zo is het mogelijk om data te tunnelen die we onmogelijk zouden kunnen doorsturen naar computer B zonder gebruik te maken van tunneling. Een voorbeeld hiervan is het versturen van AppleTalk-berichten. AppleTalk werd tot 2009 ondersteund door Apple, en omvat een reeks netwerkprotocollen die het mogelijk maken om printers en bestanden te delen tussen verschillende Macintosh-computers in een netwerk. Het versturen van AppleTalk-berichten tussen twee netwerken op afstand is echter problematisch: het maximaal aantal routers dat een AppleTalk kan bezoeken op het pad naar zijn bestemming is 15 zoals besproken in de ondersteuningspagina’s van Apple [27]. Indien echter het bericht tussen twee netwerken op grote afstand moet verzonden worden (bijvoorbeeld tussen twee netwerken die verbonden zijn via het publieke internet) kan dit ervoor zorgen dat berichten een hop count hebben die groter is dan 15, en zo hun bestemming nooit bereiken. Netwerktunneling kan hier een oplossing bieden: aan de hand van inkapseling wordt nieuwe headerinformatie toegevoegd aan het AppleTalk-bericht, zoals ge¨ıllustreerd op Figuur 2.1. Deze headerinformatie maakt het bericht klaar voor verzending over het publieke internet. Wanneer vervolgens het bericht na het versturen op zijn pad een router tegenkomt, zal enkel de hop count van de nieuw toegevoegde headerinformatie verhoogd worden: de hop count van het AppleTalk bericht zelf blijft ongewijzigd. Wanneer het bericht toekomt aan het eindpunt van de tunnel zal de headerinformatie die eerder werd toegevoegd bij inkapseling terug verwijderd worden. Hierdoor is de data ontvangen door een proces op computer B identiek aan de data die werd verstuurd door een proces op computer A: het

2.2 DNS

9

toevoegen van de headerinformatie aan één kant van de tunnel en het verwijderen van de headerinformatie aan de andere kant van de tunnel gebeurt volledig transparant voor de processen die de getunnelde data uitwisselen. Hierdoor lijkt het alsof de afstand tussen de twee eindpunten van de tunnel slechts één hop is, hoewel er in werkelijkheid, op het pad tussen verzender en ontvanger, een willekeurig aantal routers kunnen liggen. Op deze manier zal het voor de twee computers lijken alsof ze zich in hetzelfde netwerk bevinden, daar waar ze in werkelijkheid worden gescheiden door het publieke internet.

2.2

DNS

Eén van de protocollen die noodzakelijk zijn voor het correct werken van het internet is het Domain Name System (DNS). DNS is een protocol dat de koppeling tussen een domeinnaam en een IP-adres mogelijk maakt, en werd reeds kort voorgesteld in de probleemstelling. In dit deel zullen we de relevante delen van DNS voor deze scriptie meer in detail bespreken. DNS werkt in twee verschillende modi, recursief en iteratief. Figuur 2.2 toont een voorbeeld van een DNS-aanvraag naar www.google.be, en illustreert het gebruik van beide modi. In de eerste stap zal de client een recursieve aanvraag sturen naar de lokale DNS-server in zijn eigen netwerk. Eigen aan een recursieve aanvraag is dat er steeds een volledig antwoord moet teruggestuurd worden naar de client. Dit betekent dat het voor de lokale DNS-server niet toegelaten is om de client het IP-adres te sturen van een andere DNS-server, maar enkel het IP-adres van de computer waarnaar de client effectief op zoek is. Na stap één gebeurt er een omschakeling van de recursieve naar de iteratieve modus van DNS. Eigen aan een iteratieve aanvraag is dat de verzender van de aanvraag (in dit voorbeeld de lokale DNS-server) als antwoord enkel het correcte IP-adres van de domeinnaam in kwestie (in dit voorbeeld www.google.be) of het adres van een andere DNS-server aanvaardt. Stappen 2 tot en met 6 op Figuur 2.2 illustreren deze iteratieve aard van het DNS-protocol. Hierbij zal de lokale DNS-server opeenvolgend verschillende DNS-servers aanspreken, via een top-down werkwijze. Eerst wordt de DNS-server op het hoogste niveau aangesproken, de rootserver. Dit wordt ge¨ıllustreerd in stappen twee en drie. Deze rootserver bevat geen informatie rond specifieke domeinnamen (zoals het gevraagde IP-adres van www.google.be uit het voorbeeld) maar zal de lokale DNS-server wel op weg kunnen helpen om het correcte antwoord te vinden, in dit voorbeeld door het IP-adres van de DNS-server

2.2 DNS

10

voor het .be domein door te sturen in stap drie. Na stappen vier en vijf zal de lokale DNS-server het IP-adres bezitten van de DNS-server verantwoordelijk voor het google.be domein. Dit is de authoritative of bevoegde DNS-server voor het domein google.be. In stap zeven tenslotte wordt dan door deze authoritative DNS-server het correcte IP-adres van www.google.be doorgestuurd naar de lokale DNS-server, die op zijn beurt in de laatste stap dit adres doorstuurt naar de client. Na stap acht bezit de client het IP-adres van de opgezochte domeinnaam (www.google.be), waarna de DNS-aanvraag beëindigd wordt. 132.45.12.3 2

1 Client

DNS rootserver

64.23.54.1

3 Lokale DNS server

4

.be DNS-server

5 8 6 1

Wat is het IP-adres van www.google.be?

2


3

Probeer eens bij 64.23.54.1

4


5

Probeer eens bij 67.138.54.100

6


7

Het IP-adres van www.google.be is 74.125.79.147

8

Het IP-adres van www.google.be is 74.125.79.147

7

67.138.54.100

google.be DNSserver

Figuur 2.2: Een voorbeeld van de verschillende boodschappen uitgewisseld tijdens een DNS lookup.

Zoals we in het voorbeeld zagen zal de vertaling tussen domeinnamen en IP-adressen steeds starten met een vraag van een client aan de DNS-server. Het is voor de DNS-server niet mogelijk om het initiatief te nemen tot communiceren met een client: de DNS-server wacht op de ontvangst van lookup-verzoeken door de clients om vervolgens zoals in het besproken voorbeeld via iteratieve stappen het correcte antwoord aan de client te bezorgen. Deze observatie dat een client het initiatief zal nemen tot communiceren met de server is eigen aan het client-server model, maar zoals we later zullen zien heeft dit grote gevolgen voor het ontwerp van de DNS-tunnel. Dit wordt verder toegelicht in Hoofdstuk 3. In wat volgt bespreken we in detail de verschillende recordtypes die deel uitmaken van

2.2 DNS

11

DNS. Onze bespreking van DNS sluiten we tenslotte af met een overzicht van de structuur van een DNS-pakket.

2.2.1

Recordtypes

Elke DNS-server beschikt over een databank die alle relevante domeininformatie voor de server bijhoudt. Deze informatie wordt in de server onder de vorm van resource records bijgehouden in zone files. Een zone file is een tekstdocument dat voor een domeinnaam waarvoor de DNS-server verantwoordelijk is alle DNS-informatie zal bijhouden, zoals de mapping tussen domeinnamen en IP-adressen. In wezen is een zone file niets meer dan een opeenvolging van entries voor resource records. Het formaat van deze zone files werd vastgelegd in de standaarden [20, 18]. Elke resource record heeft een recordtype, dat het doel van de record in de zone file beschrijft: dit kan zoals bij het voorbeeld in Figuur 2.2 het opzoeken van een IP-adres zijn van een webserver, het opvragen van geografische informatie die bij een domeinnaam hoort, het opvragen van aliassen voor een bepaalde domeinnaam, enzovoort. Wat volgt is een voorbeeld van zo een zone file. Deze bevat een reeks resource records die het gedrag van de DNS-server vastleggen. Er bestaan verschillende types resource records, die in het voorbeeld worden aangeduid met SOA, NS, MX, A en CNAME. Helemaal bovenaan in het bestand wordt vastgelegd op welke domeinnaam ($ORIGIN) de zone file van toepassing is. $TTL 24H $ORIGIN example.com. @ 1D IN SOA ns1.example.com. hostmaster.example.com. ( 2002022401 3H 15 1w 3h ) IN NS ns1.example.com. IN NS ns2.otherdomain.com. IN MX 10 mail.anotherdomain.com.

2.2 DNS

12

; Server host definities ns1 IN A 192.168.0.1 www IN A 192.168.0.2 ftp IN CNAME www.example.com. ; Niet-server host definities daan IN A 192.168.0.3 karel IN A 192.168.0.4 Elke DNS-aanvraag die wordt verstuurd door de client zal informatie bevatten over het recordtype waarin de client ge¨ınteresseerd is. De DNS-server die het uiteindelijke antwoord naar de client doorstuurt (in voorbeeld 2.2 is dit de lokale DNS-server) moet zich hieraan houden, en mag enkel als antwoord een resource record doorsturen dat hetzelfde recordtype heeft als dat van de originele aanvraag van de client. Indien er voor de opgezochte domeinnaam geen passende resource record bestaat moet de DNS-server de client hiervan op de hoogte brengen. In wat volgt wordt een overzicht gegeven van de recordtypes die relevant zijn voor deze scriptie. A-record Het eerste recordtype dat we bespreken zijn de A-records. A-records vormen het hart van DNS. Het zijn de records die een domeinnaam omzetten naar het bijhorende IP-adres. Indien we kijken naar het eerder besproken voorbeeld op Figuur 2.2 dan zal de client in stap één een verzoek sturen voor een A-record naar de lokale DNS-server. Dit betekent dat de client in stap 8 maar twee mogelijke antwoorden van zijn lokale DNS-server zal aanvaarden: het correcte IP-adres van de opgezochte domeinnaam of de boodschap dat er voor het opgezochte domein geen bijhorende A-record bestaat. A-records zijn de reden waarom het voor gebruikers bij het communiceren met computers binnen een netwerk (bijvoorbeeld het bedrijfsnetwerk of het publieke internet) voldoende is om een domeinnaam te onthouden in plaats van het bijhorende IP-adres. CNAME-record CNAME staat voor Canonical Name. CNAME-records worden binnen DNS gebruikt voor het werken met aliassen. Een alias (of canonical name) is een secundaire naam die aan

2.2 DNS

13

een subdomein kan gegeven worden en die verschilt van de DNS-hostnaam. Om het nut hiervan te illustreren bespreken we een voorbeeld. Stel dat een DNS-server een zone file bezit voor het domein example.com. Een computer die deel uitmaakt van dit domein heeft IP-adres 192.168.10.10 en kan worden aangesproken met de naam icarus. De volgende regel zal dus deel uitmaken van de zone file: icarus A 192.168.10.10

Op icarus is een webserver ge¨ınstalleerd. Het is dus mogelijk om met een browser te surfen naar icarus.example.com. De beheerder van het netwerk zou gebruikers ook de mogelijkheid willen bieden om naar deze computer te surfen via het adres www.example.com. Dit kan door een CNAME-record toe te voegen aan de zone file. Na toevoeging van deze record ziet de zone file er als volgt uit: icarus A 192.168.10.10 www CNAME icarus.example.com

Wanneer een gebruiker vervolgens surft naar www.example.com zal hij op dezelfde computer belanden als wanneer hij surft naar icarus.example.com. De tweede regel in de zone file is dus in wezen niets meer dan een doorverwijzing naar de A-record op de eerste regel. CNAME-records moeten steeds doorverwijzen naar een bestaande A-record, en wanneer een host geassocieerd is met een CNAME-record (zoals www in het voorbeeld) dan mag deze host geen enkel ander recordtype bevatten in de zone file. Het is ook niet toegelaten om een CNAME-record te laten verwijzen naar een andere CNAME-record: er is met andere woorden maar één niveau van doorverwijzing toegelaten. MX-record MX staat voor Mail eXchange. MX-records worden gebruikt voor het resolven van de IP-adressen die het versturen van e-mail ondersteunen. Een zone file kan meerdere MXrecords bevatten met elk een geassocieerde prioriteit: deze prioriteit geeft informatie aan de clients over de volgorde waarin mailservers moeten aangesproken worden. Een voorbeeld van MX-records in de zone file kan er als volgt uitzien: IN IN

MX MX

20 10

mail2.example.com. mail.example.com.

2.2 DNS

mail mail2

14

IN IN

A A

192.168.10.2 192.168.10.3

Wat we opmerken voor de MX-records zijn de extra waarden 10 en 20 die niet aanwezig waren bij A-en CNAME-records. Ze stellen een prioriteit voor, en vertellen de client die de lookup doet welke mailserver eerst moet aangesproken worden. Een lager getal betekent een hogere prioriteit. Net zoals bij CNAME-records het geval was moeten ook MX-records steeds doorverwijzen naar een A-record, wat in het voorbeeld wordt ge¨ıllustreerd door de twee laatste regels van de zone file. TXT-record TXT-records laten clients toe om tekst op te vragen die geassocieerd is met een host. Een voorbeeld: icarus

IN

TXT

("De webserver van het bedrijf.")

TXT-records worden vooral gebruikt voor het opleggen van bepaalde regels voor het gebruik van mailservers in het netwerk. Deze regels worden in de context van DNS opgelegd aan de hand van het Sender Policy Framework (SPF) door The SPF Council [28]. SPF werd ge¨ıntegreerd in DNS om het spammers moeilijker te maken om e-mail te versturen met een vals verzendadres. Om te begrijpen hoe SPF werkt geven we een voorbeeld: example.com.

TXT

"v=spf1 mx a:jeroen.example.com -all"

De bovenstaande regel zal opleggen dat enkel de eigen mailservers (MX-records) en de host jeroen.example.com toelating hebben om mail te versturen met een verzendadres uit het example.com domein (bijvoorbeeld [email protected]). Alle andere computers hebben géén toestemming voor het versturen van e-mail via dit domein (-all). Wanneer een spammer vervolgens e-mail verstuurt in naam van dit domein (bijvoorbeeld door gebruik te maken van het e-mailadres [email protected]) dan zal de ontvanger van dit bericht de TXT-record uit bovenstaand voorbeeld kunnen opvragen bij de DNSserver van het example.com domein. Uit die regel zal de ontvanger van het spambericht

2.2 DNS

15

afleiden dat de verzender geen toelating heeft om e-mail te versturen via het e-mailadres [email protected], waardoor het automatisch als spam kan beschouwd worden. NS-records NS staat voor Name Server. NS-records in de zone file bevatten informatie over de nameservers voor domeinnamen waarvoor de DNS-server bevoegd is. Een voorbeeld: example.com. example.com. ns1.example.com. ns2.example.com.

IN IN

NS NS IN IN

ns1.example.com. ns2.example.com. A A

192.168.10.20 192.168.10.21

In dit voorbeeld worden twee nameservers gedefinieërd: ns1 en ns2. NS-records vertellen andere nameservers welke computers verantwoordelijk zijn voor een bepaald domein. Indien we terugkijken naar het eerder besproken voorbeeld op Figuur 2.2 zal in stappen drie en vijf een NS-record worden teruggestuurd naar de lokale DNS-server, waardoor deze laatste zijn iteratieve lookups kan verder zetten tot het antwoord in stap zeven wordt teruggestuurd naar de lokale DNS-server. NS-records vormen dus een belangrijke schakel voor de correcte werking van iteratieve lookups binnen DNS.

2.2.2

Structuur DNS-pakket

Figuur 2.3 toont de structuur van een DNS-pakket zoals vastgelegd in de standaard [20]. We onderscheiden een header en een datagedeelte. De header bestaat uit 15 velden, waarvan we de meest relevante voor deze scriptie bespreken. Header QR (Query/Response) Duidt aan of het gaat om een DNS-aanvraag (query) of een DNS-antwoord (response). RD (Recursion Desired) Bepaalt of de DNS-server op een recursieve manier te werk moet gaan bij het zoeken naar een antwoord op een query. Indien we terugkijken naar Figuur 2.2 eerder in het hoofdstuk, dan zal de client in stap één een recursieve query

2.2 DNS

16

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 Identification

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 QR

Opcode

AA

TC

RD

RA

Z

Total Questions

Total Answer RRs

Total Authority RRs

Total Additional RRs

AD

CD

Rcode Header

Questions Answer RRs

Data

Authority RRs Additional RRs

Figuur 2.3: De structuur van een DNS-pakket.

sturen naar de lokale DNS-server. Dit heeft tot gevolg dat de client zelf maar één enkele query zal sturen naar de lokale DNS-server, waarna de DNS-server iteratief in stappen 2 tot en met 7 queries zal sturen naar de verschillende DNS-servers op het publieke internet om zo een antwoord te bekomen op de vraag van de client. Het ondersteunen van recursie is niet verplicht voor DNS-servers: het al dan niet ondersteunen van recursie wordt door de DNS-server aangeduid door het RA-veld (Recursion Available). AA (Authoritative Answer) Geeft aan of de DNS-server die het antwoord verstuurt verantwoordelijk is voor de domeinnaam die wordt opgezocht. Op Figuur 2.2 zal enkel het antwoord uit stap 7 authoritative zijn, aangezien dat antwoord wordt verstuurd door de DNS-server die verantwoordelijk is voor het opgezochte domein google.be. Op basis van het begrip bevoegdheid kunnen we DNS-servers onderverdelen in twee categorieën: bevoegde (authoritative) en niet-bevoegde (non-authoritative) servers. Bevoegde DNS-servers zullen voor minstens één domein een authoritative antwoord terugsturen. Dit betekent dat deze DNS-servers A-records bevatten voor minstens één domein in hun zone file. Niet-bevoegde DNS-servers zullen enkel hun cache en andere DNS-servers gebruiken bij het uitvoeren van lookups en zullen dus nooit een authoritative antwoord naar de client sturen. RCode (Return Code) Geeft de status weer van het DNS-antwoord, teruggegeven door een DNS-server. Deze code wordt gebruikt om de client in te lichten rond eventuele problemen met de server (zoals een Server Failure code), of om de client te waarschuwen dat een query foutief is opgebouwd (Format Error ).

2.2 DNS

17

Data Questions Bevat één of meerdere DNS-aanvragen (queries). Elke query bevat een domeinnaam, een klasse (IN voor het publieke internet) en een recordtype (A,CNAME, . . . ). Figuur 2.4 toont de structuur van een query. Belangrijk is dat ook elk DNS-antwoord een kopie bevat van de DNS-aanvragen voor die query: zo weet de client bij ontvangst op welke vraag de DNS-server het antwoord terugstuurde. 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Name Type

Class

Figuur 2.4: De structuur van een query.

Answer RRs Bevat een lijst van antwoorden op de DNS-aanvragen onder de vorm van resource records. De structuur van een resource record wordt weergegeven in Figuur 2.5. 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Name Type

Class TTL

Rdata Length

Rdata

Figuur 2.5: De structuur van een Resource Record.

Authority RRs Bevat een lijst van resource records waarvoor de DNS-server verantwoordelijk is. Dit zal veelal een lijst van nameservers zijn, voorgesteld aan de hand van NS-records. Additional RRs Een lijst van resource records waarvan de DNS-server vermoedt dat ze nuttig kunnen zijn voor de client die de DNS-aanvraag stuurde. Meestal zal dit een lijst van A-records zijn die wijzen naar de nameservers, zoals de twee A-records uit het voorbeeld bij de bespreking van NS-records eerder in dit hoofdstuk.

2.3 DNS-tunneling

2.3

18

DNS-tunneling

Na het bespreken van netwerktunneling en DNS gaan we over tot het bespreken van de combinatie van beide: DNS-tunneling. In Hoofdstuk 1.1 werd het concept DNS-tunneling reeds ge¨ıntroduceerd: het doel van DNS-tunneling is om een werkend communicatiekanaal op te zetten tussen twee computers, door enkel en alleen gebruik te maken van geldig DNS-verkeer.


client B

A

Webserver Internet DNS-server example.com

B

client C

lokale DNS server


Bedrijfsnetwerk

Figuur 2.6: Het pad dat gevolgd wordt door verkeer verstuurd via een DNS-tunnel.

Figuur 2.6 toont de twee computers waartussen we een DNS-tunnel wensen op te zetten: een client in het bedrijfsnetwerk en de DNS-server van het example.com domein. Deze tunnel-eindpunten werden op de figuur aangeduid door A en B. We gaan er voor het vervolg van deze sectie vanuit dat we volledige controle hebben over de DNS-aanvragen die door A worden uitgevoerd. In Hoofdstuk 4 zullen we meer in detail bespreken hoe we dit tijdens een gerichte aanval kunnen realiseren. Om verkeer van punt A naar punt B te tunnelen via DNS is het voldoende voor punt A om lookups uit te voeren naar een domein waarvoor punt B authoritative (bevoegde) DNS-server is. Zoals eerder besproken in het voorbeeld bij Sectie 2.2 zal het steeds de bevoegde DNS-server van het opgezochte domein zijn die bepaalt welk antwoord naar de client wordt gestuurd: wanneer de client uit het voorbeeld op Figuur 2.6 een lookup verstuurt voor het example.com domein, zal het dus DNS-server B zijn die na eventuele

2.3 DNS-tunneling

19

iteratieve tussenstappen (besproken in 2.2) een antwoord zal terugsturen naar A, aangezien deze de bevoegde DNS-server is voor het example.com domein. Nu we aan de hand van lookups voor het example.com domein gegevens kunnen doorsturen van A naar B zoeken we naar de recordtypes die de meeste mogelijkheden bieden om binaire gegevens door te sturen, wat ons uiteindelijk doel van DNS-tunneling is. Hoewel we hier spreken over het doorsturen van binaire gegevens, zullen we in wezen zoeken naar de recordtypes die ons toelaten om strings door te sturen - dit komt doordat DNS is ontwikkeld met als doel het doorsturen van domeinnamen (die eigenlijk niets meer dan strings zijn) en niet voor het doorsturen van een binaire gegevensstroom. Hoe we juist binaire gegevens kunnen gaan omzetten naar strings wordt in detail besproken in Hoofdstuk 3. Hierbij zal de verzender (A) de binaire gegevens omzetten naar een string en zal de ontvanger (B) de string terug transformeren tot de oorspronkelijke binaire datastroom. De recordtypes die eerder werden besproken in Sectie 2.2.1 en die in aanmerking komen voor het doorsturen van strings zijn de TXT-record en de CNAME-record. Andere recordtypes zoals de A-record zullen niet in aanmerking komen voor gebruik bij tunneling aangezien enkel de aanvraag een string bevat (de domeinnaam die wordt opgezocht) – het antwoord zal steeds een IP-adres bevatten. In Figuur 2.7 wordt op twee verschillende manieren zes bytes data uitgewisseld tussen A en B. De datastroom van A naar B zal steeds verlopen aan de hand van DNS lookups. Het verkeer van B naar A zal steeds gebeuren via geldige antwoorden op deze lookups. De vereiste dat alle verkeer tussen A en B geldig DNS-verkeer moet zijn is eenvoudig te verklaren door de recursieve aard van DNS zoals besproken in Sectie 2.2. Aangezien elk DNS-pakket dat wordt verstuurd tussen A en B een onbekend aantal tussenliggende DNS-servers kan bezoeken zal DNS-verkeer dat niet voldoet aan de regels van het protocol eenvoudigweg geblokkeerd worden. Dit zou de correcte werking van de DNS-tunnel verstoren - elk pakket dat deel uitmaakt van het getunnelde verkeer moet dus de regels van het DNS-protocol respecteren. Dit impliceert ondermeer dat: • Het recordtype van een DNS-antwoord hetzelfde moet zijn als het recordtype van de bijhorende lookup. Het is met andere woorden de client die het formaat van de resource records zal bepalen, waarvoor vervolgens de DNS-server een antwoord zal moeten formuleren dat resource records bevat in datzelfde formaat. Wanneer bijvoorbeeld een client een lookup stuurt die resource records bevat met recordtype TXT zal ook het antwoord dat wordt teruggestuurd door de authoritative DNS-server

2.3 DNS-tunneling

20

A

B

1a

Type: TXT Rdata: AABBCC.example.com

2a

Type: TXT Rdata: 112233

A

B 1b

Type: CNAME Rdata: AABBCC.example.com

2b

Type: CNAME Rdata: 112233.example.com

Figuur 2.7: Het gebruik van TXT-en CNAME records voor het doorsturen van strings via DNS. In dit voorbeeld wisselen A en B allebei zes bytes uit.

van ditzelfde type moeten zijn. • Elk recordtype heeft een reeks van regels waaraan moet voldaan zijn bij het doorsturen van een DNS-pakket. Zo zal bijvoorbeeld het antwoord op een A-record een IP-adres moeten bevatten.

Figuur 2.7 illustreert de basiswerking van DNS-tunneling. In Figuur 2.6 zagen we dat we verkeer willen tunnelen tussen A en de bevoegde DNS-server voor het example.com domein (B). Indien A op Figuur 2.7 aan de hand van een lookup B wilt contacteren is het dus noodzakelijk dat A lookups uitvoert naar het example.com domein omdat dit verzekert dat de lookups door B zullen ontvangen worden, aangezien B de bevoegde DNS-server is voor dit domein. In stap 1a stuurt de client een DNS-aanvraag die één TXT-query bevat voor

2.3 DNS-tunneling

21

het subdomein AABBCC. Deze zes bytes stellen de gegevens voor die we via de DNS-tunnel van A naar B willen sturen. De query voor dit subdomein van example.com zal door B ontvangen worden. Indien B een traditionele DNS-server zou zijn, dan zou deze in de zone file op zoek gaan naar een regel van het volgende formaat: AABBCC

IN

TXT

("Een beschrijving van het AABBCC subdomein")

De werking van B zal echter anders zijn: de zes bytes die het subdomein voorstellen zullen worden opgeslagen (en zoals eerder vernoemd via een transformatie worden omgezet naar een binaire datastroom) en B zal als antwoord op de TXT-query een nieuwe string doorsturen die gegevens voorstelt die van B naar A door de tunnel moeten gestuurd worden. In het voorbeeld op Figuur 2.7 wordt dit ge¨ıllustreerd in stap 2a, waarbij de 6 bytes 112233 via een TXT-record worden teruggestuurd naar A. Op diezelfde figuur zullen in stappen 1b en 2b dezelfde 12 bytes worden doorgestuurd gebruikmakend van CNAME-records in plaats van TXT-records. In dit eenvoudige voorbeeld zijn we er in geslaagd om via geldig DNS-verkeer in totaal 12 bytes data uit te wisselen tussen A en B. Indien deze stappen herhaald worden met andere data (en door gebruik te maken van grotere boodschappen) wordt het mogelijk om een communicatiekanaal op te zetten tussen A en B. Hoewel we hier reeds de essentie van gegevensoverdracht bij DNS-tunneling hebben besproken zullen verschillende technische problemen moeten opgelost worden om dit kanaal ook effectief bruikbaar te maken voor betrouwbare gegevensoverdracht tussen twee computers: oplossingen voor problemen zoals out-of-order -aflevering en ongewenste caching door tussenliggende DNS-servers worden besproken in Hoofdstuk 3. We sluiten deze inleiding tot DNS-tunneling af met het herhalen van de belangrijkste vereiste voor het slagen van communicatie via dit kanaal: het bezitten van een bevoegde DNS-server voor een bepaald domein zoals example.com uit de besproken voorbeelden. Enkel door het gedrag van zo een bevoegde DNS-server te controleren wordt het mogelijk om queries verstuurd aan de client-zijde van de tunnel te gaan ontvangen aan de serverzijde van de tunnel (zoals in stap 1a op Figuur 2.7) en data bestemd voor de client te gaan versturen via een passend DNS-antwoord. In deze sectie hebben we kort besproken hoe DNS-tunneling werkt, en hoe we aan de hand van CNAME-en TXT-records data kunnen tunnelen via DNS. In Hoofdstuk 3 zullen we in detail bespreken hoe we DNS-tunneling kunnen gaan gebruiken voor het opzetten van

2.4 DNS-tunneling software

22

een betrouwbaar tweerichtingskanaal, maar eerst bespreken we bestaande DNS-tunneling software.

2.4 2.4.1

DNS-tunneling software DNS Cat

DNS Cat werd ontwikkeld door Ron Bowes [2] en bestaat uit een client-en serverapplicatie die communicatie tussen twee computers over internet mogelijk maakt. DNS Cat zal communicatie tussen een client en server ondersteunen door alle netwerkverkeer te tunnelen via een zelfgekozen DNS-server. Door enkel te communiceren via het DNS-protocol, zal DNS Cat in staat zijn veel publieke en lokale firewalls te omzeilen, aangezien DNS-verkeer in veel netwerken ongecontroleerd verloopt, en dus niet door de traditionele firewalls passeert, zoals reeds besproken in Hoofdstuk 1. DNS Cat server

1

DNS Cat client

De DNS Cat server applicatie wordt opgestart.

2

dnscat --listen

De DNS Cat client applicatie wordt opgestart. dnscat --domain example.com

3

Een lokaal proces wordt opgestart. cmd.exe

4

In-en uitvoer van het cmd.exe proces wordt getunneld via DNS. cmd.exe

Figuur 2.8: Communicatie tussen twee computers aan de hand van de DNS Cat server-en clientapplicaties.

Figuur 2.8 toont de DNS Cat server-en client, en de verschillende stappen die worden doorlopen om een DNS-tunnel op te zetten tussen beiden. In stap één wordt DNS Cat gestart aan de kant van de server: om DNS-tunneling te ondersteunen moet deze computer

2.4 DNS-tunneling software

23

bevoegd zijn voor een bepaald domein - deze vereiste werd besproken in Sectie 2.3. Onafhankelijk van stap één wordt in stap twee DNS Cat gestart aan de kant van de client, en wordt als argument het domein meegegeven waarvoor de DNS Cat server bevoegd is (--domain example.com). Hierdoor weet de client naar welk domein DNS lookups moeten verstuurd worden zodat ze met zekerheid toekomen bij de DNS Cat server. In stap drie zal de client een nieuw proces opstarten (bijvoorbeeld een shell via het commando cmd.exe) en de in-en uitvoer van dit proces gaan koppelen aan het DNS Cat client proces. Vervolgens wordt alle uitvoer van dit proces omgezet naar DNS-aanvragen en doorgestuurd naar de DNS Cat server op afstand. Dit gebeurt door gebruik te maken van TXT-en CNAME-records zoals besproken in Sectie 2.3. De DNS Cat server kan vervolgens via de standaard invoercommando’s terug doorsturen naar de DNS Cat client door gebruik te maken van dezelfde DNS-tunnel. Kan DNS Cat ingezet worden voor het opzetten van een DNS-tunnel bij een gerichte aanval tegen een bedrijfsnetwerk? Indien we er vanuit gaan dat de DNS Cat server beheerd wordt door de aanvaller zal het geen probleem zijn om in stap één de DNS Cat server-software op te starten, aangezien de aanvaller de volledige controle heeft over deze computer (en dus in staat is om server-software te starten). Stap twee uit Figuur 2.8 vormt echter een groot probleem: om deze stap uit te voeren heeft de aanvaller ook volledige controle nodig over de computer van het slachtoffer (die de rol van de DNS Cat client vervult) om zo de DNS Cat client software te kunnen opstarten. Bij een realistische aanval waarbij de aanvaller door het uitbuiten van een softwarefout slechts heel beperkte toegang krijgt tot de aangevallen computer zal het uitvoeren van de DNS Cat client veelal buiten de mogelijkheden van de aanvaller liggen. Niettegenstaande dat DNS Cat in zijn huidige gedaante niet inzetbaar is bij een aanval tegen een computer in een bedrijfsnetwerk, gaan we enkele concepten die door DNS Cat worden gebruikt voor het opzetten van de DNS-tunnel en het uitwisselen van informatie via DNS hergebruiken in de eigen implementatie die wordt besproken in Hoofdstuk 4.

2.4.2

tcp-over-dns

tcp-over-dns door AnalogBit [8] werkt gelijkaardig aan DNS Cat, gebruikmakend van twee aparte stukjes software: een client en een serverapplicatie. tcp-over-dns laat het toe om

2.5 Metasploit

24

een bepaalde TCP-verbinding te gaan tunnelen over DNS, zoals bijvoorbeeld een SSHverbinding. Het voordeel van deze techniek is dat tcp-over-dns kan gebruikt worden met om het even welke TCP-verbinding, wat het bijvoorbeeld mogelijk maakt om HTTP-verkeer te tunnelen over DNS. tcp-over-dns maakt gebruik van TXT-records en de laatste versie ondersteunt sinds kort ook CNAME-records. Ook deze methode is echter niet eenvoudig toe te passen in combinatie met een aanval om dezelfde reden die werd aangehaald bij de bespreking van DNS Cat in Sectie 2.4.1.

2.5

Metasploit

Metasploit is een open source framework speciaal ontwikkeld voor beveiligingsspecialisten. Het bevat een hele reeks tools en modules die het ontwikkelen en testen van exploits sterk vereenvoudigen. Metasploit-componenten worden geschreven in Ruby, C en ASM. Figuur 2.9 toont een overzicht van alle componenten aanwezig in metasploit [4]. De belangrijkste onderdelen van het metasploit-framework die ook verder in de scriptie aan bod zullen komen zijn de volgende:

Libraries

Tools

Interfaces

Console

Rex

CLI MSF Core Web

Plugins

MSF Base

GUI

Modules Payloads

Exploits

Encoders

NOPs

Aux

Figuur 2.9: Een overzicht van de metasploit-architectuur.

2.5 Metasploit

2.5.1

25

Exploits

Exploits zijn kleine programmaatjes die gebruik maken van een softwarefout om zo de controle over een computer over te nemen. Exploits komen in twee soorten voor: local en remote exploits. Remote exploits zijn exploits die kunnen gebruikt worden over een netwerk en waarbij geen eerdere toegang tot het aangevallen systeem nodig is. Voor local exploits is er wel eerst toegang tot het systeem nodig. Dit kan bijvoorbeeld door het openen van een ge¨ınfecteerde PDF op het doelsysteem of het misbruiken van een fout in de linux kernel waardoor een aanvaller de privileges van de systeembeheerder kan bemachtigen.

2.5.2

Payloads

Payloads zijn stukken code die we willen uitvoeren nadat we succesvol de controle over een proces hebben overgenomen na het slagen van een exploit. In metasploit komen payloads voor onder drie verschillende vormen: • Stagers hebben als doel een communicatiekanaal op te zetten tussen de aanvaller en het slachtoffer. Eenmaal het communicatiekanaal is opgezet, zal vervolgens via dit kanaal een nieuw stukje uitvoerbare code worden uitgewisseld tussen aanvaller en slachtoffer, een stage. Stagers leggen het communicatiekanaal vast waarlangs vervolgens stages worden uitgewisseld. • Stages zijn stukken code die samenwerken met stagers voor het slagen van een aanval. Stages zijn de stukken uitvoerbare code die het eigenlijke doel van de aanval vastleggen (zoals het starten van een bepaald proces aan de kant van het slachtoffer). Aangezien de uitvoerbare code vaak een shell start, wordt deze om historische redenen vaak shellcode [22] genoemd - ook in de gevallen waar de uitvoerbare code een andere functie vervult dan het opstarten van een shell. • Singles zijn stukken code die volledig onafhankelijk werken doordat ze geen andere payloads zoals stages nodig hebben om een aanval uit te voeren. Ze zijn vaak groter in omvang dan de andere soorten payloads en minder flexibel doordat ze bijvoorbeeld vaak niet kunnen gecombineerd worden met een communicatiekanaal naar keuze. Het gebruik van singles tijdens een realistische aanval is ook beperkt doordat ze vaak te groot zijn in omgang om in de heap van het aangevallen proces te passen. Dit probleem wordt verder toegelicht in Sectie 4.5.1.

2.5 Metasploit

2.5.3

26

Encoders

Encoders zijn scripts die een payload kunnen transformeren zonder de werking van de payload te gaan wijzigen - encoders genereren met andere woorden een polymorfe versie van een payload. Encoders worden gebruikt om antivirussoftware te omzeilen door een payload die anders als verdacht zou beschouwd worden te gaan transformeren waardoor deze minder gemakkelijk dedecteerbaar wordt door beveiligingssoftware. Een vaak gebruikte techniek om dit te realiseren is het encrypteren van de payload. Tijdens het uitvoeren zal vervolgens de payload on the fly worden gedecrypteerd door een functie die aan de payload werd toegevoegd door de encoder. Naast het omzeilen van antivirussoftware zullen encoders het mogelijk maken om een payload op een zodanige manier te transformeren dat bepaalde bytes niet meer voorkomen in de nieuwe bytestroom, zoals de null-byte \0. De reden om bepaalde bytes te gaan vermijden in een payload heeft te maken met het misbruiken van buffer overflow softwarefouten, en wordt uitvoerig besproken in Sectie 4.5.1 - hier is het enkel van belang dat encoders het vermijden van specifieke bytes ondersteunen.

2.5.4

NOPs

NOP staat voor No Operation. Een NOP-instructie is een machine-instructie die gedurende één processorcyclus niets doet. NOP-instructies worden vooral gebruikt voor synchronisatie door het besturingssysteem. Metasploit bevat een reeks NOP-generators die een willekeurig aantal bytes aan een payload kunnen toevoegen die de uitvoering van de payload niet gaan wijzigen. Net zoals een encoder zal een NOP-generator dus een polymorfe versie maken van een payload. Dit toevoegen van NOP-instructies aan een payload zal de slaagkansen van een payload die een buffer overflow softwarefout misbruikt sterk doen vergroten. Ook hier verwijzen we naar Sectie 4.5.1 voor meer details.

2.5.5

Aux

Auxiliary modules worden in metasploit gebruikt om een bepaalde taak uit te voeren die standaard niet wordt ondersteund door het framework. Voorbeelden hiervan zijn het uitvoeren van een poortscan of het lanceren van een Denial of Service aanval, waarbij een computer gedurende een bepaalde tijd wordt bestookt met nutteloze aanvragen, in de

2.5 Metasploit

27

hoop het onmogelijk te maken voor de aangevallen computer om legitieme aanvragen te behandelen. Het zal ook mogelijk zijn om aan de hand van een zelfgeschreven auxiliary module een valse server op te zetten, bijvoorbeeld een DNS-server. Deze piste werd gevolgd bij het uitvoeren van een eerste experiment, en wordt besproken in Hoofdstuk 4.

2.5.6

Interfaces

Metasploit gebruiken kan op vier verschillende manieren: • Console Deze interface biedt de gebruikers van metasploit een interactieve omgeving om via een console metasploit te gebruiken. Via de console is het ook mogelijk om met een aangevallen computer op afstand te interageren. Deze interface kan opgestart worden met het commando msfconsole. Het is deze interface die de meeste mogelijkheden biedt, en die doorheen deze scriptie het vaakst aan bod komt. • CLI Staat voor Command Line Interface. Via deze interface is het mogelijk om metasploit te gebruiken zonder interactie met de gebruiker. Dit kan handig zijn voor het gebruik van metasploit in scripts, die het gebruik van metasploit automatiseren. De CLI kan opgestart worden met het commando msfcli. • Web Metasploit kan ook vanuit een browser gebruikt worden. Hierbij kan de gebruiker in verschillende stappen een aanval voorbereiden, en ook de aanval vanuit de browser uitvoeren. De web-interface van metasploit maakt het mogelijk voor gebruikers die minder vertrouwd zijn met de console-interface om het framework te gebruiken, maar beschikt niet over alle mogelijkheden die in de console-interface aanwezig zijn. • GUI Tot slot beschikt metasploit over een grafische interface. De grafische interface kan gestart worden met het msfgui commando, en geeft de gebruiker de mogelijkheid om in een grafische omgeving exploits en payloads te combineren, aanvallen uit te voeren en de aangevallen computers op afstand te controleren via sessies.

2.5.7

Libraries

De bibliotheken (libraries) vormen het hart van het metasploit-framework, en bevatten alle functionaliteit die door het framework aan ontwikkelaars wordt aangeboden. Alle modules

2.5 Metasploit

28

in metasploit (payloads, exploits, encoders, NOPs en aux modules) maken gebruik van deze bibliotheken. De Rex-bibliotheek bevat alle socketfunctionaliteit en implementeert ook protocollen zoals HTTP en SSL. De MSF::Core bibliotheek bevat alle basisfunctionaliteit en vormt de kern van het framework. De MSF::Base bibliotheek stelt een vereenvoudigde versie voor van de Core-bibliotheek, en maakt het vooral eenvoudiger voor ontwikkelaars om met de Core functionaliteit te interageren. Tools en plugins zijn voor deze scriptie niet relevant en worden hier daarom niet besproken.

2.5.8

Voorbeeld van een aanval in Metasploit

Na het bespreken van de verschillende componenten die deel uitmaken van het metasploitframework illustreren we nu hoe deze componenten samenwerken bij het uitvoeren van een aanval. Figuur 2.10 illustreert de verschillende stappen die worden doorlopen bij het uitvoeren van een aanval tegen een computer op afstand. De aanvaller voert de volledige aanval uit via de metasploit-console (msfconsole). In stap één zal de aanvaller misbruik maken van een softwarefout op de computer van het slachtoffer, zoals een buffer overflow fout in de software van een webserver (verder besproken in Sectie 4.5.1). Gebruikmakend van één van de exploits die deze softwarefout misbruikt en die beschikbaar is in metasploit, zal de aanvaller in staat zijn om een eerste stuk uitvoerbare code uit te voeren op de computer van het slachtoffer: de stager. Dit gebeurt in stap twee. Wanneer deze stager wordt uitgevoerd in stap twee zal deze een boodschap terugsturen naar de metasploit-console van de aanvaller - hierdoor weet de aanvaller dat de exploit succesvol werd uitgevoerd op de computer van het slachtoffer en dat de stager klaar staat voor het ontvangen van het volgende stuk uitvoerbare code: de stage. Dit gebeurt in stappen vier en vijf. Het doorsturen van deze uitvoerbare code zal zoals besproken in Hoofdstuk 1 via verschillende kanalen kunnen verlopen, zoals bijvoorbeeld een TCP-verbinding of een DNStunnel (dit laatste gebruikmakend van de eigen implementatie besproken in Hoofdstuk 4). Net zoals het geval was bij de stager zal ook de stage in stap zes een boodschap sturen naar de aanvaller van zodra deze succesvol is gestart en klaarstaat om gegevens uit te wisselen met de aanvaller. In stap zeven zullen ten slotte tussen de aanvaller en het slachtoffer

2.6 Besluit

29

Aanvaller (msfconsole) 1

De aanvaller stuurt een exploit door naar het slachtoffer, die misbruik zal maken van een softwarefout aan de slachtofferkant om controle over het aangevallen proces over te nemen.

3

De stager signaliseert de aanvaller dat de controle over het systeem is overgenomen, en dat stukjes uitvoerbare code mogen doorgestuurd worden.

4

De aanvaller stuurt een stage door naar het slachtoffer. De stage is uitvoerbare code die een specifieke taak vervult, zoals het opzetten van een communicatiekanaal.

6

De stage signaliseert de aanvaller dat het communicatiekanaal is opgezet, en dat via dit kanaal data kan uitgewisseld worden tussen aanvaller en slachtoffer.

7

Data wordt uitgewisseld tussen aanvaller en slachtoffer via het opgezette communicatiekanaal.

Slachtoffer

2

5

Uitvoeren van de ontvangen exploit geeft controle aan een stager.

Uitvoeren van de ontvangen stage door de stager.

Figuur 2.10: Voorbeeld van de verschillende stappen tijdens een aanval opgezet via metasploit.

gegevens worden uitgewisseld via het communicatiekanaal dat eerder werd opgezet door de stage.

2.6

Besluit

In dit hoofdstuk werden de werking en concepten van netwerktunneling, DNS en DNStunneling toegelicht. Ook werd reeds-bestaande software besproken die DNS-tunneling mogelijk maakt. Echter, gezien de besproken beperkingen van deze tools, is het duidelijk dat het gebruik van DNS-tunneling bij het opzetten van een gerichte aanval nog steeds niet vanzelfsprekend is. Gezien de populariteit en flexibiliteit van het framework, werd gekozen voor een eigen implementatie in metasploit, die we in de volgende hoofdstukken bespreken.

WERKING VAN DE DNS-TUNNEL

30

Hoofdstuk 3 Werking van de DNS-tunnel 3.1

Inleiding

In dit hoofdstuk gaan we dieper in op de werking van een DNS-tunnel. De bevindingen uit dit hoofdstuk zullen erg belangrijk zijn voor de ontwikkeling van een werkende implementatie besproken in het volgende hoofdstuk. Om DNS-tunneling te kunnen realiseren, moeten we drie fundamentele problemen oplossen die een direct gevolg zijn van de werking van het DNS-protocol: • Het is bij DNS de client die het initiatief moet nemen tot communicatie door een DNS-aanvraag te sturen naar de DNS-server. We willen ook dat de DNS-server zelf contact kan opnemen met de client, om zo een communicatiekanaal in twee richtingen mogelijk te maken. • DNS werd ontwikkeld met als doel het doorsturen van domeinnamen en IP-adressen. Het doorsturen van binaire data wordt niet rechtstreeks ondersteund, wat we echter wel nodig hebben bij DNS-tunneling. • DNS maakt gebruik van het UDP-protocol als transportlaag. Aangezien UDP geen garantie biedt dat gegevens effectief toekomen moeten we zelf verificatiemethoden uitwerken om de DNS-tunnel betrouwbaar te maken.

Na een overzicht van de vereiste componenten om DNS-tunneling te realiseren trachten we een oplossing te bieden voor deze drie problemen.

3.2 Componenten

3.2

31

Componenten

Zoals reeds aangehaald in Hoofdstuk 1 is het bij DNS-tunneling de bedoeling om een communicatiekanaal op te zetten dat enkel en alleen gebruik maakt van het pad gevolgd door DNS-verkeer. Op 3.1 kunnen we zien dat dit pad start bij een client in het netwerk en zo via de lokale DNS-server van het bedrijf het lokale netwerk zal verlaten, waarna het via het publieke internet wordt gerouteerd tot bij de bevoegde (authoritative) DNS-server. Deze routering van DNS-verkeer op het publieke internet gebeurt op een iteratieve manier, waarbij de bevoegde DNS-server verantwoordelijk is voor het formuleren van een antwoord op de DNS-aanvraag. Dit werd uitgelegd in Hoofdstuk 2. Het bedrijfsnetwerk bestaat uit enkele clients die worden beveiligd via een firewall. De lokale DNS-server van het bedrijf is verantwoordelijk voor het routeren van het DNSverkeer bestemd voor het bedrijfsnetwerk.


client B

client C slachtoffer

lokale DNS server

Internet

Authoritative DNS-server aanvaller


Bedrijfsnetwerk

Figuur 3.1: Een standaard scenario voor het opzetten van een DNS-tunnel met een client beveiligd door een firewall

Indien een aanvaller buiten het bedrijfsnetwerk contact wil maken met een client binnen het netwerk door enkel gebruik te maken van DNS, dan moet de aanvaller een bevoegde DNS-server bezitten voor een bepaalde domeinnaam. Deze belangrijke vereiste werd eerder besproken in Sectie 2.3. In Hoofdstuk 4 wordt besproken hoe we een bevoegde DNS-server kunnen opzetten om aan deze vereiste te voldoen.

3.3 Het communicatiekanaal

32

In het vervolg van dit hoofdstuk gaan we er daarom verder van uit dat de DNS-aanvragen die door het slachtoffer binnen het bedrijfsnetwerk worden verstuurd steeds zullen ontvangen en beantwoord worden door de bevoegde DNS-server die wordt gecontroleerd door de aanvaller. Verder zullen we vanaf nu de slachtofferkant van de tunnel de client noemen, en de aanvallerskant de server.

3.3

Het communicatiekanaal

Zoals reeds aangehaald in de inleiding van dit hoofdstuk moeten we drie fundamentele problemen oplossen om DNS bruikbaar te maken als communicatiekanaal bij een aanval.

3.3.1

Verkeer in twee richtingen

Een fundamentele vereiste van elke tunnel is de mogelijkheid om op elk moment in beide richtingen verkeer te kunnen sturen. Dit betekent dat data afkomstig van de client en bestemd voor de server kan verstuurd worden gebruikmakend van de DNS-tunnel, en viceversa. Om te tonen dat dit een probleem is bij DNS, herinneren we de lezer eraan dat bij DNS-verkeer het initiatief tot communicatie steeds genomen wordt door de client. Dit betekent dat de server enkel data kan versturen onder de vorm van een DNS-antwoord op een DNS-aanvraag van de client. Gebruikmakend van deze observatie kunnen we via een systeem van polling verkeer in twee richtingen verwezenlijken. Bij polling stuurt de client periodiek DNS-aanvragen naar de server, waardoor de server de kans krijgt om deze DNS-aanvragen te beantwoorden, en om dus data naar de client door te sturen. Figuur 3.2 toont de basiswerking van polling. De DNS-client zal periodiek (aangeduid door polling timeout) een speciale DNS-aanvraag sturen naar de DNS-server. De DNS-server erkent deze aanvraag als een pollingsverzoek, en zal vervolgens controleren of er data beschikbaar is om naar de client-zijde van de DNS-tunnel te versturen. Indien dit het geval is, zal deze data onder de vorm van een DNS-antwoord op het pollingsverzoek teruggestuurd worden naar de client. Indien de DNS-server geen data beschikbaar heeft om door te sturen naar de client zal de client hiervan op de hoogte worden gebracht door de server, onder de vorm van een speciaal gevormd DNS-antwoord. De keuze van een correcte waarde voor de polling timeout is belangrijk: langs de ene kant willen we zo vaak mogelijk pollingsverzoeken doorsturen, om zo de DNS-server vaak genoeg


33

de mogelijkheid te bieden om data door te sturen naar de client. Langs de andere kant willen we de hoeveelheid pollingsverzoeken tot een minimum beperken, aangezien deze veel extra DNS-verkeer veroorzaken. Dit laatste is nadelig om twee redenen: ten eerste zullen extra pollingsverzoeken ervoor zorgen dat er minder bandbreedte beschikbaar is voor het doorsturen van andere data. Ten tweede zal een DNS-tunnel met een hoog aantal pollingsverzoeken sneller afwijken van het normale karakter van DNS-verkeer, waardoor deze ook sneller detecteerbaar zouden kunnen worden voor systeembeheerders van bedrijfsnetwerken. Vooral deze laatste bedenking is belangrijk indien we DNS-tunneling willen gebruiken bij een gerichte aanval, en detecteerbaarheid van het communicatiekanaal een invloed heeft op het slagen van deze aanval. DNS-client

DNS-server 1

DNS-aanvraag (polling aanvraag 1)

3

DNS-antwoord (polling antwoord 1)

4

DNS-aanvraag (polling aanvraag 2)

2

Controleer of er data klaar staat om naar de client te versturen.

5

Controleer of er data klaar staat om naar de client te versturen.

Polling timeout

6

DNS-antwoord (polling antwoord 2)

Figuur 3.2: Tijdsverloop van het DNS-verkeer bij polling.

In Hoofdstuk 4 wordt in detail besproken hoe polling bij DNS-tunneling werd ge¨ımplementeerd.


3.3.2

34

Betrouwbaarheid

Op de transportlaag verloopt DNS-verkeer standaard via het User Datagram Protocol (UDP ). In tegenstelling tot het Transmission Control Protocol (TCP ) levert UDP geen garantie dat gegevens werkelijk aankomen. Dit heeft als voordeel dat UDP een lagere overhead produceert (veroorzaakt door bijvoorbeeld handshaking bij TCP), maar met het nadeel dat UDP minder betrouwbaar is [11]. Bij traditioneel gebruik van DNS is betrouwbaarheid niet belangrijk. Indien een client na een bepaalde tijd (de timeout) geen antwoord ontvangt van de bevoegde DNS-server, zal de client de originele DNS-aanvraag gewoon opnieuw sturen. Dit verstoort de normale werking van DNS niet, aangezien de interactie tussen client en DNS-server beperkt blijft tot het sturen en ontvangen van één enkel antwoord op één enkele DNS-aanvraag. Er is bij DNS dus geen sprake van state waarbij er een geschiedenis van transacties tussen client en server wordt bijgehouden - elke DNS-aanvraag met bijhorend antwoord wordt onafhankelijk van ander DNS-verkeer behandeld. Deze redenering gaat echter niet meer op indien we DNS willen gebruiken voor het opzetten van een tunnel. De reden hiervoor is dat een DNS-tunnel wel een vorm van state moet bevatten, waarbij zowel DNS-client als DNS-server op de hoogte moeten zijn van wat correct werd ontvangen aan elk uiteinde van de tunnel. Figuur 3.3 illustreert twee mogelijke problemen waarbij een client 1000 bytes wil versturen naar de DNS-server. In dit voorbeeld gaan we ervan uit dat de client hiervoor twee DNS-aanvragen moet sturen naar de server, aangezien het beschikbare aantal bytes dat in één enkele DNS-aanvraag kan verstuurd worden beperkt is. In het eerste scenario op Figuur 3.3 gaat de eerste DNS-aanvraag op het pad tussen de client en de server verloren. De client kan echter op geen enkele manier controleren dat de data correct werd ontvangen door de server, en zal nietsvermoedend de tweede DNSaanvraag doorsturen. Hierdoor zal de DNS-server enkel de tweede helft van de 1000 bytes ontvangen. Het tweede scenario toont aan hoe out-of-order aflevering ervoor kan zorgen dat data in de foutieve volgorde wordt ontvangen door de DNS-server. Door het gebrek aan acknowledgement mechanismen is er geen garantie dat de volgorde van versturen aan de client-zijde ook dezelfde volgorde is van ontvangst aan de server-zijde. Zoals ge¨ıllustreerd op Figuur 3.3 kan dit ervoor zorgen dat de server de data in een verkeerde volgorde zal ontvangen. Zonder


35

de extra mechanismen die we hierna bespreken zou de DNS-tunnel dus niet betrouwbaar zijn. DNS-client 1000 bytes klaar om te versturen naar server.

DNS-server 1

DNS-aanvraag (bytes 1-500)

2


DNS-client 1000 bytes klaar om te versturen naar server.

DNS-server

1


2


Figuur 3.3: Twee mogelijke scenario’s die de onbetrouwbaarheid van DNS verduidelijken. Het bovenste scenario illustreert het verlies van data, het onderste scenario illustreert out-of-order aflevering.

Om de problemen van dataverlies en out-of-order aflevering op te lossen gebruiken we een methode die controledata toevoegt aan de resource records om zo de DNS-tunnel betrouwbaar te maken. Door aan deze resource records een nummer toe te voegen wordt het voor beide kanten van de tunnel mogelijk om out-of-order aflevering of verlies van data te detecteren. Dit concept wordt ondermeer toegepast in het eerder besproken DNS Cat uit Sectie 2.4.1 en wordt ge¨ıllustreerd op Figuur 3.4. Een domeinnaam kan opgesplitst worden in verschillende velden of labels. Elk label mag maximaal 63 karakters bevatten zoals opgelegd in de standaard [19]. In Figuur 3.4 wordt het eerste veld gebruikt voor het toevoegen van een sequentienummer. In dit voorbeeld gaat het eerste DNS-bericht afkomstig van de DNS-client onderweg naar de DNS-server verloren. Dit wordt ge¨ıllustreerd in stap één. Wanneer de client na een bepaalde tijd (de timeout) geen bevestiging van ontvangst heeft gekregen van de DNS-server, zal het bericht met hetzelfde sequentienummer opnieuw worden verzonden. Dit gebeurt in stap twee, waarop


36

DNS-client

DNS-server example.com

1

01.AABBCC.EU.example.com

2

01.AABBCC.DB.example.com

Timeout

4

02.DDEEFF.UO.example.com

5

03.GGHHII.MN.example.com

3

01.OK.ER.example.com

6

03.OK.PL.example.com

7

02.OK.XF.example.com

... Figuur 3.4: Het betrouwbaar maken van het kanaal door het toevoegen van eenvoudige controledata.

de DNS-client een bevestiging (OK) krijgt van de DNS-server in stap drie. Hierdoor weet de DNS-client met zekerheid dat de eerste zes bytes (AABBCC) correct werden ontvangen door de DNS-server, en kan de client overgaan tot het verzenden van een volgende reeks bytes in stap vier. Het gebruik van sequentienummers lost ook het probleem van out-of-order delivery op, wat wordt ge¨ıllustreerd in stappen vier tot en met zeven: aan de hand van het sequentienummer in het eerste label is de DNS-server in staat om boodschappen te herschikken in het geval deze in een andere volgorde zouden toekomen dan de volgorde waarmee ze de DNS-client verlaten. Het tweede label van elke domeinnaam bevat de getunnelde data en zal steeds verstuurd worden als een string (bijvoorbeeld DDEEFF in stap vier). Hoe dit mogelijk is wordt besproken in de volgende sectie waarin we onderzoeken hoe we binaire data kunnen versturen via de DNS-tunnel. Verder merken we op dat een derde label werd toegevoegd, bestaande uit twee karakters. Dit label wordt aan elke resource record toegevoegd en voorkomt ca-


37

ching in tussenliggende DNS-servers. Dit principe wordt reeds toegepast in bestaande DNS-tunneling software zoals DNS Cat en is noodzakelijk om ervoor te zorgen dat elke query die wordt verstuurd door de DNS-client ook effectief onze bevoegde DNS-server zal bereiken, en niet eerder zal worden beantwoord door een resultaat uit de cache van een tussenliggende DNS-server tijdens het iteratief resolven van een query (besproken in Sectie 2.2). Het toevoegen van deze willekeurige karakters aan de domeinnaam zal er met andere woorden voor zorgen dat er veel minder resource records in een query zullen gaan matchen met een eerder verstuurde query - het toevoegen van deze karakters zorgt er dus voor dat elke query uniek zal zijn en dus geen hits zal veroorzaken in de cache van een DNS-server die zich bevindt tussen de DNS-client en onze DNS-server. De laatste twee labels (example.com) bevatten het domein waarvoor we bevoegd zijn. Zoals eerder besproken in Sectie 2.3 zal dit ervoor zorgen dat lookups steeds door onze eigen DNS-server zullen beantwoord worden. Na het bespreken van manieren om het communicatiekanaal betrouwbaar te maken door het toevoegen van controledata zullen we vervolgens een eenvoudige techniek bespreken om het doorsturen van binaire data via DNS mogelijk te maken.

3.3.3

Binaire data

Zoals in Sectie 2.2 werd besproken is het hoofddoel van DNS de correcte vertaling van domeinnamen naar IP-adressen. De gegevens die via het DNS-protocol worden doorgestuurd zijn dus veelal van tekstuele aard, leesbaar door de mens. Dit geldt bijvoorbeeld voor de besproken CNAME -records (Canonical Name records), die aliassen voor één enkele domeinnaam definiëren. Een fundamentele vereiste van de DNS-tunnel is de mogelijkheid om binaire data door te sturen, wat een direct probleem vormt indien we hiervoor gebruik willen maken van de bestaande recordtypes aangeboden binnen DNS. Een mogelijke oplossing voor dit probleem is het toepassen van een transformatie op de binaire data die dient te worden verstuurd, zodat deze wel voldoet aan de specificaties van geldig DNS-verkeer. Ron Bowes gebruikt voor DNS Cat NetBIOS-encodering bij het omzetten van binaire data naar leesbare karakters [15, 2]. Aan de ontvangstzijde dient dan de inverse operatie uitgevoerd te worden om de originele binaire datastroom te bekomen. Dit kan door van elke twee opeenvolgende karakters de vaste waarde 0x41 af te trekken, en de resulterende waarden te gebruiken als eerste en tweede nibble bij het reconstrueren van de binaire data. Dit principe wordt toegepast bij NetBIOS-codering [15].


38

Ter illustratie van deze techniek geven we in tabel 3.1 een voorbeeld waarbij we de 10 bytes aan data willen doorsturen door enkel gebruik te maken van CNAME -records. Elke byte wordt opgesplitst in twee nibbles, waar bij elke nibble de vaste waarde 0x41 (‘A’) wordt opgeteld. Hierdoor wordt elke nibble getransformeerd naar een leesbaar karakter in de range [‘A’-‘P’]. Op het eerste zicht lijkt dit niet efficiënt, aangezien we de volledige ASCIIruimte zouden kunnen gebruiken [17]. Echter, de DNS-specificaties [20] leggen duidelijk vast dat domeinnamen binnen DNS niet hoofdlettergevoelig zijn. Deze restrictie negeren in een eigen implementatie is niet mogelijk aangezien software in tussenliggende DNS-servers tijdens iteratieve lookups vaak het DNS-verkeer zullen normaliseren door elke byte om te zetten naar kleine letters. Input

Transformatie 1e nibble

Transformatie 2e nibble

0xeb 0x1a 0x5e 0x31 0xc0 0x88 0x46 0x07 0x8d 0x1e

0xe 0x1 0x5 0x3 0xc 0x8 0x4 0x0 0x8 0x1

0xb 0xa 0xe 0x1 0x0 0x8 0x6 0x7 0xd 0xe

+ + + + + + + + + +

0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41

= = = = = = = = = =

0x4F 0x42 0x46 0x44 0x4D 0x49 0x45 0x41 0x49 0x42

("O") ("B") ("F") ("D") ("M") ("I") ("E") ("A") ("I") ("B")

+ + + + + + + + + +

0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41

= = = = = = = = = =

0x4C 0x4B 0x4F 0x42 0x41 0x49 0x47 0x48 0x4E 0x4F

("L") ("K") ("O") ("B") ("A") ("I") ("G") ("H") ("N") ("O")

NetBIOS resultaat "OL" "BK" "FO" "DB" "MA" "II" "EG" "AH" "IN" "BO"

Tabel 3.1: Voorbeeld van NetBIOS-codering voor het omzetten van 10 bytes binaire data naar leesbare tekst, klaar voor gebruik in DNS-verkeer.

Een andere mogelijkheid voor het transformeren van de datastroom is het gebruik van Base32 [21]. Base32 gebruikt de 26 hoofdletters van het alfabet, samen met de getallen 2 tot en met 9. Aangezien in Base32 geen speciale tekens worden gebruikt of onderscheid wordt gemaakt tussen grote en kleine letters, is deze methode ook geschikt voor het gebruik in DNS. Base64 [21], de opvolger van Base32, is echter niet geschikt aangezien hier een uitgebreidere karakterset wordt aangeboden die niet compatibel is met DNS. Het gebruik van technieken voor het omzetten van binaire data naar een leesbare reeks tekens (en omgekeerd) zorgt voor twee soorten overhead:

3.4 Besluit

39

• Computationeel Elke byte die wordt verstuurd en ontvangen moet eerst door de verzender worden getransformeerd, en na ontvangst terug worden omgezet naar zijn originele vorm gebruikmakend van de inverse transformatie. Dit zorgt voor een computationele meerkost. • Bandbreedte Door de transformatie van binaire data naar een kleiner domein (zoals bij het voorbeeld in tabel 3.1) zullen we per byte data meerdere bytes nodig hebben na transformatie. Dit zorgt voor extra nood aan bandbreedte, wat in het geval van NetBIOS zelf zal zorgen voor een overhead van 100 %.

3.4

Besluit

In dit hoofdstuk hebben we de mogelijkheden onderzocht om DNS te gebruiken als communicatiekanaal bij het opzetten van een tunnel. Hiervoor moesten drie fundamentele problemen opgelost worden: het tunnelen van verkeer in twee richtingen, het betrouwbaar maken van het kanaal en het mogelijk maken om binaire data door te sturen. Voor elk van deze problemen hebben we oplossingen besproken, die we in het volgende hoofdstuk zullen vertalen naar een werkende implementatie van DNS-tunneling in metasploit.

IMPLEMENTATIE VAN DE DNS-TUNNEL IN METASPLOIT

40

Hoofdstuk 4 Implementatie van de DNS-tunnel in metasploit 4.1

Inleiding

Zoals reeds aangehaald in de inleiding van deze scriptie willen we via DNS-tunneling een aanvaller een communicatiekanaal aanbieden met een computer in een beveiligd bedrijfsnetwerk. In dit hoofdstuk nemen we de plaats in van een potentiële aanvaller, en onderzoeken we de mogelijkheden en beperkingen van DNS-tunneling tijdens het realiseren van een eigen aanval. In Hoofdstuk 3 werd het concept van DNS-tunneling in detail toegelicht. In dit hoofdstuk wordt een eigen implementatie van DNS-tunneling in het metasploit-framework besproken. Er werd gekozen voor een implementatie voor het Windows besturingssysteem aangezien dit platform hedendaags het meeste aandacht geniet van aanvallers en beveiligingsspecialisten. We starten met een algemeen overzicht van de verschillende componenten en hun interactie tijdens het opzetten van de tunnel in het kader van een gerichte aanval. Vervolgens wordt besproken hoe het DNS-protocol in de praktijk gebruikt wordt om data te tunnelen. Tenslotte bespreken we meer in detail de verschillende componenten die werden ge¨ımplementeerd in metasploit ter ondersteuning van DNS-tunneling.

4.2 Overzicht van de aanval in metasploit

Aanvaller

1b

De DNStunnel handler start de DNSserver

41

Slachtoffer 1a

De aanvaller stuurt een exploit door naar het slachtoffer, die misbruik zal maken van een softwarefout aan de slachtofferkant om controle over het aangevallen proces over te nemen.

3

De DNS-stager signaliseert de DNS-server van de aanvaller dat de controle over het systeem is overgenomen, en dat stukjes uitvoerbare code mogen doorgestuurd worden.

4

De aanvaller stuurt de DLL-stager door naar het slachtoffer. Deze stager is uitvoerbare code die de DNS-tunnel zal opzetten tussen slachtoffer en aanvaller, en de stage zal downloaden.

6

De DNS-stager signaleert de DNS-server van de aanvaller dat de stage mag doorgestuurd worden.

7

De DNS-server stuurt de stage door naar de DLL-stager.

9

Sessiegegevens worden uitgewisseld tussen aanvaller en slachtoffer via de opgezette DNS-tunnel.

2

5

8

Uitvoeren van de ontvangen exploit geeft controle aan de DNS-stager.

Uitvoeren van de ontvangen DLL-stager.

De DLL-stager voert de stage uit in een aparte thread, en zal de input-en outputkanalen van de stage verbinden met één kant van de DNS-tunnel.

Figuur 4.1: Het tijdsverloop en de interactie tussen de aanvaller en het slachtoffer tijdens het uitvoeren van een gerichte aanval gebruikmakend van DNS-tunneling en metasploit.

4.2

Overzicht van de aanval in metasploit

We beginnen met een algemeen overzicht van de verschillende componenten van de aanval en hun interactie. Figuur 4.1 geeft een overzicht van de verschillende stappen die worden doorlopen bij het opzetten van een DNS-tunnel in metasploit. In stap 1a maakt de aanvaller misbruik van een fout die aanwezig is in een stuk software dat wordt gebruikt door het slachtoffer. Deze softwarefout kan door een aanvaller gebruikt worden om een arbitrair stuk code uit te voeren op de machine van het slachtoffer - dit klein stukje uitvoerbare code is de DNS-stager. Zoals we verder nog in detail zullen bespreken is de DNS-stager onderhevig aan verschillende beperkingen die ervoor zorgen dat de functionaliteit van deze component heel klein blijft. De taak van de DNS-stager bestaat erin

4.3 Componenten

42

om de aanvaller op afstand op de hoogte te brengen op het moment dat de controle over een systeem succesvol is overgenomen en er stukken code kunnen uitgevoerd worden op het systeem van het slachtoffer. Dit is ge¨ıllustreerd in stappen twee en drie van Figuur 4.1. De component die dit bericht - verzonden door de DNS-stager in stap drie - zal ontvangen, is de DNS-server. Deze server wordt in stap 1b opgestart zoals weergegeven op de figuur. In stap vier zal de aanvaller een tweede component (na de DNS-stager) doorsturen naar het slachtoffer: dit is de DLL-stager. Het is deze component die in stap vijf van Figuur 4.1 wordt uitgevoerd en de DNS-tunnel met de aanvaller gaat opzetten. Daar waar de DNSstager maar over heel weinig functionaliteit beschikt, zal de DLL-stager niet onderhevig zijn aan deze beperkingen. Dit verschil in beperkingen tussen de DNS-stager en de DLL-stager wordt verderop uitgebreid besproken in secties 4.5.1 en 4.5.2. Net zoals dat het geval was in stap drie zal ook de DLL-stager de aanvaller informeren van zodra de DNS-tunnel succesvol is opgezet. Nadat dit is gebeurd zal in stap zeven een laatste stuk uitvoerbare code door de aanvaller worden doorgestuurd: de stage. Zoals besproken in Sectie 2.5.2 zal de stage de stukken uitvoerbare code bevatten die het eigenlijke doel van de aanval vastleggen, zoals het starten van een bepaald proces of het uitvoeren van een bepaalde actie op het systeem van het slachtoffer. Nadat de stage in stap acht is ontvangen door de DLL-stager zal de stage worden opgestart in een nieuwe thread en zullen de input-en outputkanalen van dit proces worden beheerd door de DLL-stager. Hierdoor wordt het mogelijk om instructies doorgestuurd door de aanvaller te verbinden met het inputkanaal van de stage aan de slachtofferkant. In de omgekeerde richting zal alle data gegenereerd door de stage worden onderschept door de DLL-stager en via de DNS-tunnel worden doorgestuurd naar de aanvaller. Dit wordt ge¨ıllustreerd in stap negen. Na dit algemeen overzicht van de verschillende componenten en hun interactie zullen we in het vervolg van dit hoofdstuk elke component apart meer in detail bestuderen.

4.3

Componenten

Aangezien we een DNS-tunnelingimplementatie wensen te realiseren in metasploit, is het van groot belang dat alle componenten die hier deel van uitmaken ook op een correcte manier samenwerken met het metasploit-framework. Dit heeft een grote impact op het ontwerp van de verschillende onderdelen van de implementatie.

4.3 Componenten

43

De componenten kunnen ruwweg opgesplitst worden in twee verschillende categorieën: allereerst zijn er de componenten aan de kant van de aanvaller. Deze componenten starten de aanval en gaan na het succesvol opzetten van de DNS-tunnel als taak hebben om met de aanvaller te interageren via de metasploit-console. Deze eerste categorie bevat de DNSserver, de DNS-tunnel handler en alle code die nodig is om een geslaagde interactie met het metasploit-framework te verzekeren. Een tweede categorie van componenten bevat alle uitvoerbare code (vaak shellcode genoemd) die via de DNS-tunnel tot bij het slachtoffer wordt gestuurd. In tegenstelling tot de eerste categorie zal deze code niet worden uitgevoerd in het metasploit-framework maar worden ge¨ınjecteerd en uitgevoerd in de context van bestaande processen op de computer van het slachtoffer. Tot deze tweede categorie van componenten behoren de DNS-stager, de DLL-stager en de stage. Door het feit dat deze code moet kunnen uitgevoerd worden in het kader van een gerichte aanval, zullen we zien dat ook hier enkele ontwerpbeslissingen van groot belang zijn om de aanval te doen slagen voor een zo groot mogelijk aantal scenario’s. DNS-tunnel eindpunten

Aanvaller

DNS-tunnel handler

Slachtoffer

DNS-server

DNS-stager

Transitnetwerk

Sessie

MSF::Base

API-oproepen Communicatie

DLL-stager

Stage

kernel32 & winsock2

metasploit

Figuur 4.2: Overzicht van alle ge¨ımplementeerde componenten voor de realisatie van DNStunneling in metasploit.

Deze opsplitsing in twee categorieën is ook duidelijk zichtbaar op Figuur 4.2. Elk van de componenten uit deze figuur worden in de rest van dit hoofdstuk uitvoerig besproken.

4.4 De aanvaller

4.4

44

De aanvaller

We beginnen met een bespreking van alle ge¨ımplementeerde componenten die te vinden zijn aan de kant van de aanvaller.

4.4.1

DNS-tunnel handler

In metasploit heeft een handler de taak om van zodra een exploit naar het slachtoffer wordt gestuurd alle software op te starten om de aanvaller klaar te maken voor communicatie met het slachtoffer op afstand. De belangrijkste taak van de DNS-tunnel handler is het opstarten van de DNS-server van zodra de exploit naar het slachtoffer is gestuurd zoals weergegeven in stap één van Figuur 4.1. Indien dit niet zou gebeuren dan zou het bericht verzonden door de DNSstager in stap drie verloren gaan. Wanneer de aanvaller gebruik maakt van msfconsole zoals besproken in Sectie 2.5.6 zal hij voor het sturen van de exploit moeten aangeven welke handler moet gebruikt worden tijdens de aanval. Hierdoor weet het framework welke component verantwoordelijk is voor de communicatie met het slachtoffer op afstand van zodra de exploit succesvol is uitgevoerd - in onze eigen implementatie is dit dus de DNStunnel handler. Een tweede belangrijke vereiste van de DNS-tunnel handler is het ondersteunen van sessies. In metasploit gebeurt de interactie tussen de aanvaller en het framework aan de hand van deze sessies. Een sessie stelt een communicatiekanaal voor horend bij een succesvol uitgevoerde aanval die door de aanvaller kan gecontroleerd worden: zo zal het sturen van commando’s naar een aangevallen computer en het ontvangen van de uitvoer van deze commando’s via sessies verlopen die worden beheerd door de handler. Figuur 4.3 toont een gestarte sessie in de eigen implementatie die wordt beheerd door de DNS-tunnel handler en waarmee de aanvaller interactief commando’s kan uitwisselen. In het voorbeeld werd een stage gebruikt die een commandoregel opstart aan de kant van het slachtoffer. Metasploit bevat reeds een tiental handlers die elk een verschillend communicatiekanaal ondersteunen. Zo bestaan er ondermeer handlers voor het opzetten van een communicatiekanaal via een TCP-verbinding (bind tcp en reverse tcp) of het tunnelen van verkeer via HTTPS (reverse https). In metasploit vormen alle handlers een onderdeel van de Corebibliotheek (MSF::Core). Ook de zelf ge¨ımplementeerde DNS-tunnel handler wordt aan

4.4 De aanvaller

45

Figuur 4.3: Een sessie in de eigen implementatie die in dit voorbeeld een commandolijn tunnelt.

deze bibliotheek toegevoegd. Handlers worden net zoals alle andere metasploit-componenten geschreven in Ruby. De grootste uitdaging bij het schrijven van de DNS-tunnel handler was het begrijpen van de metasploit-architectuur op het niveau van de MSF::Core bibliotheek: er is geen documentatie beschikbaar voor ontwikkelaars om op dit niveau aanpassingen te maken aan het framework. Om de eigen implementatie te realiseren werd de broncode van reeds bestaande handlers bestudeerd zoals de PassiveX handler: deze handler ondersteunt communicatie over een HTTPS-tunnel [10]. Ge¨ınspireerd door PassiveX maakt ook de DNS-tunnel handler gebruik van de Rex::IO::StreamAbstraction module voor het aanmaken van een socketpaar lsock (local socket) en rsock (remote socket) voor de communicatie met de DNS-tunnel. lsock

1

DNS-server (aanvaller)

DLL-stager (slachtoffer)

create_session

2

3

4

rsock

Sessie 8

5 7

6

DNS-tunnel handler

Figuur 4.4: Interactie tussen de DNS-tunnel handler en de DNS-server bij het uitwisselen van sessiegegevens.

4.4 De aanvaller

46

De werking van de DNS-handler tijdens de interactie met sessies wordt in detail weergegeven in Figuur 4.4. In stap twee wordt een nieuwe sessie gestart op het moment dat de DNS-server een verzoek ontvangt van de DLL-stager voor het openen van zo een sessie. Dit gebeurt gelijktijdig met stap zes uit de eerder besproken Figuur 4.1. Wanneer de aanvaller via de msfconsole interface commando’s ingeeft in stap drie zullen deze door de lokale kant van het socketpaar worden ontvangen. Wanneer vervolgens een pollingsbericht toekomt zal de DNS-server gegevens uit lsock uitlezen en deze via de DNS-tunnel naar de DLL-stager sturen aan de kant van het slachtoffer. Dit gebeurt in stappen vier en vijf. Wanneer de DLL-stager in stap zes over gegevens beschikt bestemd voor de aanvaller zullen deze via de DNS-tunnel doorgestuurd worden naar de DNS-server van de aanvaller. Deze worden vervolgens in stap acht lokaal doorgestuurd naar rsock waarna ze in stap negen kunnen uitgelezen worden door de sessie en in de msfconsole interface beschikbaar worden gesteld voor de aanvaller. Zoals duidelijk blijkt uit Figuur 4.4 werkt de DNS-tunnel stager nauw samen met de DNSserver tijdens het uitwisselen van gegevens met het slachtoffer.

4.4.2

DNS-server

De DNS-server vormt de belangrijkste component langs de kant van de aanvaller. Zoals te zien is op Figuur 4.2 zal de DNS-server één eindpunt van de DNS-tunnel voorstellen. De DNS-server heeft als hoofdtaak het inkapselen en versturen van gegevens via de DNS-tunnel en het ontvangen van getunneld verkeer afkomstig van het slachtoffer. We geven een overzicht van alle functionaliteit die de DNS-server moet ondersteunen: • Versturen van de DLL-stager naar de DNS-stager. • Correct interpreteren en beantwoorden van payloadverzoeken afkomstig van de DNSstager. • Versturen van de stage naar de DLL-stager. • Ontvangen en interpreteren van getunneld verkeer afkomstig van de stage. • Correct interpreteren en beantwoorden van pollingsverzoeken afkomstig van de DLLstager. Tijdens een aanval zal de DNS-server in drie verschillende fasen werken.

4.4 De aanvaller 4.4.2.1

47

Fase ´ e´ en: uitwisselen van de DLL-stager met de DNS-stager

Zoals reeds werd aangehaald in de vorige sectie zal de DNS-server worden opgestart door de DNS-tunnel handler in stap één van Figuur 4.1. Na het opstarten van de DNS-server zal deze wachten op een verzoek van de DNS-stager om het eerste stuk van de DLL-stager door te sturen. Dit komt overeen met stap drie en markeert de start van de eerste fase. In deze eerste fase zal de DNS-server gebruikmakend van TXT-records de DLL-stager doorsturen naar de DNS-stager. Deze fase komt overeen met stap vier van Figuur 4.1. Het doorsturen van de DLL-stager naar de DNS-stager wordt ge¨ıllustreerd in Figuur 4.5. DNS-server

DNS-stager 1

2

Transformeer bytes 1-100 van de DLLstager naar een TXT-record

3

5

6

Transformeer bytes 101-200 van de DLLstager naar een TXT-record

7

Type: TXT Rdata: 00.example.com

Type: TXT Rdata: AABB...CCDD (200 bytes)

Type: TXT Rdata: 01.example.com

Opslaan van bytes 1-100 in het gereserveerd geheugen.

8


Type: TXT Rdata: EEFF...AABB (200 bytes)

... 9

4

Type: TXT Rdata: null (0 bytes)

Figuur 4.5: Het uitwisselen van de DLL-stager tussen de DNS-server en de DNS-stager in stukken van 100 bytes tijdens fase één van de DNS-server.

In stap één van Figuur 4.5 stuurt de DNS-stager een TXT DNS-query met de vraag om het eerste stuk van de DLL-stager door te sturen. Dit gebeurt door een controlelabel toe te voegen aan de query die het volgnummer aanduidt van het gewenste stuk payload: in de eerste stap is dit 00. Wanneer de DNS-server in stap twee dit bericht ontvangt zal deze de eerste 100 bytes van de DLL-stager omvormen tot een TXT-record door gebruik

4.4 De aanvaller

48

te maken van NetBIOS-codering 3.3.3. De hoeveelheid bytes van de payload die per TXTrecord worden doorgestuurd is een parameter van de DNS-server (STAGER_CHUNK_SIZE) en kan eenvoudig aangepast worden: de enige voorwaarde is dat het aantal payload bytes na codering moet passen in de DNS-record. In theorie mag de rdata sectie van een resource record tot 65535 bytes bevatten aangezien er plaats is voor 16 bits in de rdata length sectie. De aangewezen maximale grootte is echter beperkt tot 512 bytes aangezien veel software-implementaties in DNS-servers niet overweg kunnen met grotere resource records. Aangezien NetBIOS-codering na transformatie de grootte van de payload zal verdubbelen zoals uitgelegd in 3.3.3 zijn we dus beperkt tot het doorsturen van maximum 256 bytes per resource record. Nadat alle stukken van de DLL-stager zijn doorgestuurd zal een leeg antwoord worden teruggestuurd naar de DNS-handler. Hierdoor weet de DNS-handler dat de volledige DLLstager succesvol is ontvangen. Wanneer dit is gebeurd zal de DNS-stager de ontvangen DLL-stager uitvoeren – dit markeert het einde van fase één. 4.4.2.2

Fase twee: uitwisselen van de stage met de DLL-stager

In een tweede fase zal de DNS-server op analoge wijze als in fase één een payload doorsturen: in deze fase is het de stage die wordt doorgestuurd naar de DLL-stager. Het verschil met de techniek gebruikt in de eerste fase is dat we hier zullen gebruikmaken van CNAME-records in plaats van TXT-records voor het doorsturen van de payload. In wat volgt worden deze twee verschillende aanpakken besproken en verantwoord. Zoals we later zullen zien in Sectie 4.5.1 is het van groot belang om de DNS-stager zo klein mogelijk te houden. Het uitlezen van een resource record van het type TXT is eenvoudiger dan het verwerken van een CNAME resource record en zal dus ook minder code vereisen. Hierdoor zal de keuze voor TXT records tijdens de eerste fase een kleinere DNS-stager opleveren. Voor de keuze van een gepast recordtype voor het uitwisselen van gegevens tussen de DNSserver en de DLL-stager in de tweede fase werd onderzocht in welke mate de kandidaatrecordtypes voor DNS-tunneling (CNAME-en TXT-records) voorkomen in traditioneel DNS-verkeer. Hiervoor werden tien metingen uitgevoerd binnen het UGent-netwerk waarbij op tien verschillende tijdstippen 100 megabyte aan DNS-verkeer werd verzameld. De resultaten van deze metingen zijn terug te vinden in Tabel 4.1.

4.4 De aanvaller

Meting Meting 1 Meting 2 Meting 3 Meting 4 Meting 5 Gemiddeld

49

TXT-records

CNAME-records

A-records

Andere

1% 2% 1% 1% 1% 1%

20% 21% 29% 30% 26% 25%

46% 38% 42% 48% 45% 44%

33% 39% 28% 21% 28% 30%

Tabel 4.1: Resultaten van tien metingen uitgevoerd in het UGent netwerk.

In Hoofdstuk 2 werd ge¨ıllustreerd hoe TXT-records worden gebruikt voor het uitwisselen van sender policy informatie. Door de aard van deze queries zal traditioneel DNS-verkeer slechts voor een klein percentage uit TXT-records bestaan. Dit wordt bevestigd door de metingen in Tabel 4.1 waarop te zien is dat TXT-records slechts 1% van het totale verkeer voorstellen. Een andere observatie is het feit dat CNAME-records gemiddeld één vierde van het totale verkeer vertegenwoordigen. Bij het zoeken van een geschikte resource record voor het doorsturen van de stage is het zinvol om de resource record te kiezen die het meest voorkomt in traditioneel DNS-verkeer om zo detectie van de DNS-tunnel lastiger te maken. Indien we kiezen voor CNAME-records dan zal een groot volume aan records uitgewisseld in fase twee (en drie) minder snel beschouwd worden als verdacht verkeer door beveiligingssoftware in het bedrijfsnetwerk. Ten slotte merken we op dat de overige 30% DNS-verkeer uit Tabel 4.1 voor 25% wordt vertegenwoordigd door AAAA-records voor de ondersteuning van ondermeer Kerberos [35]. Minder vaak voorkomende recordtypes zoals NS-records zullen de laatste 5% van het verkeer uitmaken. In Figuur 4.6 wordt ge¨ıllustreerd hoe de stage van de DNS-server naar de DLL-stager wordt gestuurd. Zoals te zien op de figuur is dit bijna volledig analoog met fase één met de volgende verschillen: • In plaats van TXT-records te gebruiken zal gewerkt worden met CNAME-records voor het vermijden van detectie zoals toegelicht in de vorige paragraaf. • Het eerste label van de domeinnamen stelt het sessienummer voor. In 4.4.1 werd de werking van sessies toegelicht. Dit sessienummer laat de DNS-server toe om een

4.4 De aanvaller

50

DNS-server

DLL-stager 1

2

6

Transformeer bytes 1-64 van de stage naar een CNAMErecord

Transformeer bytes 65-128 van de stage naar een CNAME-record

3

Type: CNAME Rdata: 3.0.17.GETPAYLOAD.example.com

Type: CNAME Rdata: 3.0.23.AABBCC.example.com

5

Type: CNAME Rdata: 3.1.56.GETPAYLOAD.example.com

7

Type: CNAME Rdata: 3.1.87.DDEEFF.example.com

... 9

4


8


Type: CNAME Rdata: 3.<# delen>.44.EOF.example.com

Figuur 4.6: Het uitwisselen van de stage tussen de DNS-server en de DLL-stager in stukken van 64 bytes tijdens fase twee van de DNS-server.

onderscheid te maken tussen verschillende aangevallen computers in het geval de aanvaller met meerdere simultane sessies wenst te werken. • Het tweede label stelt het volgnummer voor van het stuk stage dat wordt doorgestuurd. • Het derde label stelt een willekeurig gegenereerd getal voor tussen 0 en 100 om het probleem van caching te vermijden zoals besproken in 3.3.2. Caching vormde geen probleem in fase twee aangezien elk stuk van de DLL-stager slechts eenmaal per aanval dient doorgestuurd te worden. • Label vier en volgende (behalve de laatste labels gebruikt voor het domein, example.com in het voorbeeld) worden gebruikt voor het doorsturen van de feitelijke data. Aangezien elk label maximaal 63 karakters kan bevatten zoals aangegeven in de standaard [19] is het mogelijk dat de data moet opgesplitst worden over verschillende labels. Dit wordt ondersteund door de implementatie.

4.5 Het slachtoffer

51

• Speciale controlesignalen worden gebruikt in stappen één en negen om het begin (GETPAYLOAD) en einde (EOF) van het doorsturen van de stage aan te duiden.

Nadat de stage is doorgestuurd zal deze in een nieuwe thread worden opgestart door de DLL-stager. Dit komt overeen met stap acht op Figuur 4.1. De interactie tussen de DLLstager en de stage wordt verder besproken in 4.5.2. Na het succesvol doorsturen van de stage zal de DNS-server overgaan tot fase drie. 4.4.2.3

Fase drie: uitwisselen van sessiegegevens met de stage

Fase drie komt overeen met stap negen op Figuur 4.1. In deze fase worden sessiegegevens uitgewisseld tussen de DNS-server en de DLL-stager, de twee eindpunten van de DNStunnel zoals weergegeven op Figuur 4.2. Het uitwisselen van sessiegegevens gebeurt om de zelfde redenen als in fase twee via CNAME-records. De structuur van de berichten die in deze fase worden uitgewisseld is bijna identiek aan die van fase twee met het enige verschil dat een extra label werd toegevoegd met de waarde DATA. Dit label wordt toegevoegd net vóór de labels die gebruikt worden voor het versturen van de domeinnaam. Op die manier wordt het mogelijk voor de DNS-server en de DLLstager om een onderscheid te maken tussen verkeer dat wordt uitgewisseld in fase twee en fase drie. Onderdeel van de sessiegegevens uitgewisseld tussen de DNS-server en de DLLstager zijn de pollingsverzoeken waarvan we de implementatie verderop in dit hoofdstuk bespreken.

4.5

Het slachtoffer

In wat volgt bespreken we alle componenten van de implementatie die aan de kant van het slachtoffer worden uitgevoerd.

4.5.1

DNS-stager

De DNS-stager is het eerste stuk uitvoerbare code dat wordt uitgevoerd aan de kant van het slachtoffer. Het is het stuk shellcode dat wordt meegestuurd met de exploit, en na succesvol uitvoeren van de exploitcode zal uitgevoerd worden in de context van het aangevallen

4.5 Het slachtoffer

52

proces. Om de werking van exploits en de DNS-stager te begrijpen is het concept van codeinjectie belangrijk. codeinjectie is een veelgebruikte techniek om de controle over een systeem over te nemen door stukken uitvoerbare code te injecteren in een lopend programma. Om als aanvaller van codeinjectie gebruik te kunnen maken is het noodzakelijk dat een softwarefout aanwezig is in een lopend programma. Een erg populaire techniek om codeinjectie te realiseren is door een buffer in het kwetsbare programma te overschrijven met uitvoerbare code die buiten de grenzen reikt van de voorziene grootte van de buffer. Dit soort aanvallen waarbij buffers worden overschreven met uitvoerbare code worden Buffer Overflow -aanvallen genoemd [22]. Door ook het terugkeeradres van een kwetsbare functie op de stack te gaan overschijven wordt het mogelijk om op deze manier het controleverloop van het programma te gaan wijzigen. Normale uitvoering

Gewijzigde uitvoering na buffer-overflow

Programma instructies


Data

Data 1

1

Heap Kwaadwillige code

Heap 2

Frame voor functie-oproep

2

Frame voor functie-oproep

Buffer

Buffer overflow

Terugkeeradres

Overschreven terugkeeradres

Figuur 4.7: Voorbeeld van een buffer-overflowaanval waarbij via codeinjectie kwaadwillige code wordt uitgevoerd.

Figuur 4.7 illustreert de werking van codeinjectie door het misbruiken van een bufferoverflowkwetsbaarheid in software. Het linkerdeel van de figuur toont de normale uitvoering van een functieoproep. Op het rechterdeel van de figuur is te zien hoe het overvloeien

4.5 Het slachtoffer

53

van een buffer het terugkeeradres overschrijft en kwaadwillige code toevoegt aan de heap van het programma. Door het terugkeeradres van de functieoproep met een nauwkeurig gekozen nieuw adres (dat wijst naar de start van de ge¨ınjecteerde kwaadwillige code) te overschrijven wordt het mogelijk om op een gecontroleerde manier het controleverloop van het programma te wijzigen. Het foutief overschrijven van het terugkeeradres zal onvermijdelijk leiden tot het crashen van het programma - om dit te voorkomen worden technieken als Heap Spraying [23] toegepast, waar hier niet verder op zal ingegaan worden. De DNS-stager is het stuk uitvoerbare code dat na codeinjectie zal worden uitgevoerd in de context van het aangevallen proces (vaak in de heap zoals weergegeven in Figuur 4.7). Om een stuk uitvoerbare code geschikt te maken voor uitvoering na codeinjectie moet voldaan zijn aan enkele belangrijke vereisten: • De maximale grootte van het stuk uitvoerbare code is beperkt, en hangt af van de softwarefout in het aangevallen programma. Dit is bijvoorbeeld problematisch bij buffer-overflowaanvallen met een erg kleine beschikbare buffer. Op het moment van schrijven maakt 68% van alle exploits aanwezig in metasploit gebruik van een bufferoverflowbug om de controle over het systeem over te nemen. Dit betekent dat de grootte van de shellcode van groot belang is indien we deze compatibel willen maken met zoveel mogelijk exploits. • Voor de meeste exploits (bijvoorbeeld bij deze die misbruik maken van een bufferoverflow) zal de aanwezigheid van een null-byte in de uitvoerbare code de correcte werking gaan verstoren. Dit komt doordat het correct kopiëren van de shellcode naar de overschreven buffer zal gestopt worden van zodra de eerste null-byte wordt gelezen (zoals bijvoorbeeld het geval bij de strcpy functie in C). Dit zorgt ervoor dat slechts alle bytes vóór deze null-byte zullen gekopieerd worden, wat de correcte werking van de shellcode onmogelijk maakt. Andere softwarebugs zullen dan weer andere beperkingen opleggen aan de karakterset die kan gebruikt worden door de shellcode. Zo zullen bijvoorbeeld bij het overvloeien van een gebruikersnaam-veld in een FTP-server de karakters @ en newline hoogstwaarschijnlijk moeten vermeden worden. • De uitvoerbare code moet na codeinjectie rechtstreeks uitvoerbaar zijn in de context van het aangevallen proces. Dit betekent dat het traditioneel niet mogelijk is om shellcode te schrijven in een taal als Java, die bytecode produceert en door een virtuele machine dient ge¨ınterpreteerd te worden. Voor het schrijven van shellcode wordt steeds gekozen voor machinecode.

4.5 Het slachtoffer

54

• We willen de shellcode zo platform-onafhankelijk mogelijk maken, om ze zonder aanpassingen bruikbaar te maken over verschillende versies van eenzelfde besturingssysteem heen. Om dit te realiseren is het concept van positie-onafhankelijke shellcode belangrijk. Hierbij zullen alle geheugenadressen van functies die doorheen de code worden gebruikt, op een dynamische manier worden berekend. Hard coderen van geheugenadressen moet dus te allen tijde vermeden worden.

Bij het implementeren van de DNS-stager moeten bovenstaande beperkingen gerespecteerd worden. Als basis werd de stager code gebruikt die ontwikkeld werd door Ron Bowes in het kader van DNS-cat [2]. Deze stager maakt gebruik van TXT-records 2.2.1 om een stuk uitvoerbare code te downloaden via DNS, en het vervolgens uit te voeren. De stager bestaat uit 168 lijnen positie-onafhankelijke shellcode, die gebruik maakt van de topstack methode voor het vinden van geheugenadressen van functies [24]. Deze stager werd ontwikkeld door Ron Bowes met als doel een shell te downloaden via DNS en uit te voeren op het systeem van het slachtoffer. Aangezien in de eigen implementatie de DNS-stager moet overweg kunnen met meer algemene payloads dan enkel een shell (voor gebruik in het kader van metasploit) moesten na het testen van de originele stagercode volgende aanpassingen gemaakt worden in de eigen implementatie: • Het doorsturen van de uitvoerbare code via DNS gebeurt in de originele versie van de stager zonder enige vorm van codering. Tijdens het testen van de code bleek echter dat hierdoor niet alle bytes van de uitvoerbare code correct werden afgeleverd aan de kant van het slachtoffer, doordat tussenliggende DNS-software niet steeds overweg kan met een binaire stroom van data als inhoud van TXT-records. Volgens de standaard [20] is het doel van TXT-records om een beschrijvende tekst toe te voegen bestaande uit leesbare tekst, wat de gemeten transmissiefouten voor binaire data mogelijk verklaart. Om verschillen tussen de doorgestuurde en ontvangen stroom data verder te vermijden wordt bij versturen door de DNS-server alle data via NetBIOS-codering omgezet naar een leesbare reeks tekens. Aan de ontvangstzijde (de DNS-stager) zal vervolgens de inverse operatie worden uitgevoerd om de originele stroom data te bekomen - dit mechanisme werd reeds eerder besproken in Sectie 3.3.3. Door deze aanpassing te implementeren in de DNS-stager kan op een correcte manier een arbitraire stroom van binaire gegevens via DNS worden doorgestuurd van de aanvaller naar het slachtoffer.

4.5 Het slachtoffer

55

• De originele code maakt het mogelijk om tot 100 verschillende TXT-records uit te wisselen tussen de DNS-server en de DNS-stager. Dit is aanvaardbaar voor het doorsturen van code die een shell opstart, maar bleek al snel onvoldoende te zijn voor het doorsturen van grotere payloads. De stager werd daarom aangepast om tot tien keer meer verschillende TXT-records te kunnen uitwisselen waardoor het mogelijk wordt om meer binaire data uit te wisselen tussen aanvaller en slachtoffer. • In de originele code worden slechts 1000 bytes gealloceerd. Dit gebeurt aan de hand van de functie VirtualAlloc() [25]. Dit gealloceerde geheugen wordt gebruikt voor het opslaan van de uitvoerbare code die via TXT-records wordt ontvangen. Dit bleek echter voor problemen te zorgen bij het uitwisselen van grotere payloads met de DNSstager, waardoor in de eigen implementatie werd gekozen voor het reserveren van een tienvoud van deze limiet.

Figuur 4.8 toont stapsgewijs de werking van de ge¨ımplementeerde DNS-stager. Stappen één en twee verlopen volledig analoog aan de stappen in het rechterdeel van Figuur 4.7. In stap drie zal via het overschreven terugkeeradres (als resultaat van het succesvol uitvoeren van een buffer-overflowaanval) gesprongen worden naar de start van de DNS-stager code. Deze code zal op zijn beurt in stappen drie en vier via TXT-records de volgende stager gaan downloaden (in dit geval de DLL-stager uit Sectie 4.5.2) zoals eerder toegelicht in Sectie 4.4.2.1 en deze gaan opslaan in het blok geheugen dat aan de start van de DNS-stager werd gereserveerd door VirtualAlloc(). Deze twee stappen worden herhaald zolang de DNS-server de DNS-stager niet informeert dat de volledige uitvoerbare code succesvol werd doorgestuurd. Van zodra de volledige uitvoerbare code via DNS (gebruikmakend van TXT-records) is gedownload door de DNS-stager, kan er gesprongen worden naar de start van het blok geheugen dat eerder werd gereserveerd door VirtualAlloc(), en dat in opeenvolgende geheugenlocaties de gedownloade uitvoerbare code bevat. Deze volgende component is de DLL-stager en zal in wat volgt uitvoerig worden besproken.

4.5.2

DLL-stager

Het tweede stuk uitvoerbare code dat uitgevoerd wordt aan de kant van het slachtoffer is de DLL-stager. Om de noodzaak voor een tweede stager te begrijpen herinneren we de lezer eraan dat de hoeveelheid uitvoerbare code die met een exploit kan meegestuurd worden

4.5 Het slachtoffer

56

Werking van de DNS-stager


Data Heap DNS-stager

1 5

DNS-server

VirtualAlloc()

3

\xeb\x1a\x5 \x31\xc0\x88

4

2

Frame voor functie-oproep Buffer overflow Overschreven terugkeeradres

Figuur 4.8: De stapsgewijze werking van de DNS-stager, hier ge¨ıllustreerd in het kader van een buffer-overflowaanval.

heel beperkt is, zoals besproken in Sectie 4.5.1. De DNS-stager werd daarom zo klein mogelijk gehouden. Dit heeft echter tot gevolg dat de DNS-stager slechts over een heel beperkte functionaliteit beschikt. Zijn taak bestaat enkel uit het downloaden en uitvoeren van een tweede stager die wél veel functionaliteit bevat: de DLL-stager. Net zoals in Sectie 4.5.1 beginnen we met een overzicht van alle vereisten waaraan een tweede stager moet voldoen: • Net zoals het geval was bij de eerste stager, zal ook de tweede stager moeten bestaan uit code die rechtstreeks uitvoerbaar is na codeinjectie. Waar bij de eerste component werd gekozen voor een oplossing in machinecode zal voor de tweede stager gekozen worden voor een reflective DLL [26]. Dit verklaart waarom de tweede stager de naam DLL-stager kreeg. De keuze voor een oplossing aan de hand van een reflective DLL

4.5 Het slachtoffer

57

wordt verder in deze sectie nog toegelicht. We gaan verder in dit hoofdstuk nog verder in op de werking van een reflective DLL. • Aangezien de DNS-stager zelf bepaalt hoeveel geheugen wordt gereserveerd om de gedownloade tweede stager op te slaan (aan de hand van het tweede argument doorgegeven aan de VirtualAlloc() functieoproep [25]), is de grootte van deze tweede stager van klein belang. Dit in tegenstelling tot de grootte van de DNS-stager, die wel zo klein mogelijk moet zijn ter ondersteuning van een zo groot mogelijk aantal exploits. Rekening houdend met bovenstaande beperkingen willen we een tweede stager implementeren die de volgende functionaliteit bevat: • De stager moet in staat zijn om een DNS-tunnel met de aanvaller op te zetten. Dit houdt in dat de stager in staat moet zijn om DNS-aanvragen naar de DNS-server van de aanvaller te versturen, en de ontvangen antwoorden hierop correct te interpreteren. • De stager moet, gebruikmakend van deze DNS-tunnel, een laatste stuk uitvoerbare code kunnen downloaden via DNS (de stage). Zoals reeds besproken in Sectie 2.5.2 zijn stages de stukken uitvoerbare code die het eigenlijke doel van de aanval uitvoeren (zoals het starten van een bepaald proces aan de kant van het slachtoffer). Het doorsturen van deze stage werd besproken in Sectie 4.4.2.2. • Na het succesvol downloaden van de stage zal deze worden uitgevoerd in een aparte thread binnen de DLL-stager zoals te zien in stap acht van Figuur 4.1. De standaardinvoer- en uitvoerkanalen van dit proces worden vervolgens verbonden met twee sockets: alle DNS-verkeer dat toekomt aan de kant van het slachtoffer zal doorgestuurd worden naar het standaardinvoerkanaal van de stage. Alle standaarduitvoer van de stage zal via de DNS-tunnel naar de aanvaller op afstand worden gestuurd. Op deze manier wordt het mogelijk voor een aanvaller op afstand om de stage te controleren. Zoals reeds eerder vermeld werd bij de implementatie van deze tweede stager gekozen voor een implementatie aan de hand van een reflective DLL [26]. Een reflective DLL zal net als shellcode rechtstreeks kunnen uitgevoerd worden in de context van een ander proces. Dit is mogelijk door gebruik te maken van reflective loading. Om een DLL te injecteren in een bestaand proces worden volgende stappen doorlopen:

4.5 Het slachtoffer

58

1. Een klein stukje shellcode geeft de controle aan de reflective loader. 2. Aangezien de DLL zich op een dynamisch gealloceerde plaats in het geheugen bevindt zal de reflective loader eerst en vooral het startadres van zichzelf berekenen. Dit is nodig om later de PE-headers [16] te kunnen uitlezen. 3. Gebruikmakend van de export-table van Kernel32.dll zal het adres van drie functies berekend worden die vereist zijn in latere stappen - LoadLibraryA, GetProcAddress en VirtualAlloc. 4. De reflective loader zal nu, gebruikmakend van VirtualAlloc, een stuk geheugen reserveren waarin het zichzelf zal laden. 5. De DLL wordt naar de nieuwe locatie gekopieerd. 6. De relocatietabel wordt verwerkt. 7. Nu de reflective loader op een nieuwe locatie is gekopieerd zal de eigen import-table worden verwerkt waardoor bibliotheken en hun functieadressen opgezocht worden. 8. Nadat alle vorige stappen succesvol zijn afgewerkt zal de reflective loader de startfunctie van de DLL oproepen: DllMain. 9. Wanneer de uitvoering van de DLL stopt zal de controle worden teruggegeven aan het stukje shellcode dat in stap één de controle aan de reflective loader gaf.

Deze negen stappen moesten niet zelf ge¨ımplementeerd worden maar zijn een onderdeel van publiek beschikbare broncode. Het gebruik van een reflective loader werd voor het eerst besproken door skape en Jarkko Turkulainen [29]. Figuur 4.9 geeft een overzicht van de verschillende onderdelen van de DLL-stager en de interne communicatie tussen de componenten. De DLL-stager maakt gebruik van een TCP-abstractielaag die de link vormt tussen de DNS-tunnel client en de stage. De keuze voor zo een abstractielaag tijdens de implementatie zorgt ervoor dat stage geen notie moet hebben van de DNS-tunnel en enkel met een lokaal socketpaar moet communiceren. Deze aanpak is analoog met het principe toegepast in Sectie 4.4.1 waarbij een socketpaar werd aangemaakt om sessiegegevens tussen de DNS-tunnel handler en de DNS-server uit te wisselen. Hierdoor wordt de DLL-stager compatibel met de stages in metasploit die gebruikmaken van een TCP-socket om te communiceren met de stager. Het invoerkanaal

4.5 Het slachtoffer

59 DNS-tunnel eindpunten

Aanvaller

DNS-tunnel handler

Slachtoffer

DNS-tunnel client

DNS-server

Transitnetwerk Sessie

TCP-abstractie server

TransmitToLocal

TransmitToRemote

Stage TCP-abstractie client

DLL-stager

Figuur 4.9: Detailweergaven van de verschillende onderdelen van de DLL-stager en hun onderlinge communicatie.

van de stage wordt verbonden met de TCP-abstractie client en het uitvoerkanaal met de TCP-abstractie server. Via de functies TransmitToLocal en TransmitToRemote zal vervolgens tussen client en server data uitgewisseld worden zoals weergegeven op Figuur 4.9. In Hoofdstuk 3 werd het concept van polling besproken om tweerichtingsverkeer door de DNS-tunnel mogelijk te maken. Dit concept wordt door de DLL-stager ge¨ımplementeerd op analoge wijze als besproken in Sectie 3.3.1. Periodiek (standaard om de seconde) zullen er pollingsverzoeken verstuurd worden naar de DNS-server om deze de kans te geven om gegevens terug te sturen naar de DLL-stager. Ook hier werd gekozen voor CNAME-records tijdens de implementatie waarvan één label de waarde GETPOLLING kreeg zodat de DNSserver pollingsverzoeken kan onderscheiden van ander verkeer. Indien de DNS-server geen data heeft om door te sturen zal deze een antwoord terugsturen met de boodschap NODATA. Indien de DNS-server wel beschikt over data bestemd voor het slachtoffer dan zal deze verstuurd worden zoals besproken in Sectie 4.4.2.3. De DNS-tunnel client tenslotte vormt het tunneleindpunt langs de kant van de aanvaller. Deze client communiceert met de DNS-server zoals besproken in Secties 4.4.2.2 en 4.4.2.3 voor het ontvangen van de stage en het uitwisselen van sessiegegevens. Tot slot merken we op dat de DLL-stager volledig werd ge¨ımplementeerd in C en gebruik maakt van de winsock2 bibliotheek zoals weergegeven op Figuur 4.2 om het werken met sockets mogelijk te maken. Een eerste versie van de DLL-stager werd geschreven in C++

4.5 Het slachtoffer

60

maar deze bleek na compileren erg groot in omvang, ook na het toepassen van allerhande optimalisaties. Dit zorgde niet voor technische problemen (de toegestane grootte van de DLL-stager is in theorie onbeperkt) maar verhoogt wel de kansen op detectie tijdens een realistische aanval, aangezien er meer TXT-records zullen moeten uitgewisseld worden in fase één van de DNS-server bij het doorsturen van een grotere DLL-stager. Na omzetting naar C heeft het binair bestand van de DLL-stager een aanvaardbare grootte van 61 kB.

4.5.3

Stage

De laatste component die we bespreken is de stage. In tegenstelling tot de andere componenten hoort de stage niet tot de eigen implementatie maar maakt deze reeds deel uit van het metasploit-framework. We herinneren de lezer eraan dat stages de stukken uitvoerbare code zijn die het eigenlijke doel van de aanval vastleggen zoals het starten van een bepaald proces aan de kant van het slachtoffer. Metasploit bevat op het moment van schrijven de volgende stages voor het Windows besturingssysteem: • dllinject Laat het toe om een willekeurige DLL te injecteren in een aangevallen proces. Deze stage maakt gebruik van reflective loading zoals besproken in Sectie 4.5.2. Deze stage wordt ondersteund door de eigen implementatie. • meterpreter Meterpreter is een zeer uitgebreide stage die functionaliteit implementeert zoals lezen of schrijven van files op het aangevallen systeem en het openen van een commandoregel [30]. Meterpreter zal in de laatste versie van metasploit standaard gebruikmaken van een SSL-beveiligd kanaal. Hierdoor is deze stage niet compatibel met de eigen implementatie aangezien SSL-ondersteuning niet werd ge¨ımplementeerd. Hierdoor wordt meterpreter in de eigen implementatie momenteel niet ondersteund. • shell Deze stage start een interactieve commandolijn (shell ) waarlangs de aanvaller de aangevallen computer op afstand kan controleren. Door de kracht van een commandolijn werd tijdens het ontwikkelen van de eigen implementatie speciale aandacht besteed aan de ondersteuning van deze stage. Figuur 4.3 toont een sessie waarlangs een commandolijn wordt getunneld via DNS in de eigen implementatie. • upexec Deze stage zal een uitvoerbaar bestand uploaden naar de aangevallen machine en het vervolgens uitvoeren. Deze stage wordt ondersteund door de eigen implementatie. De upexec stage zal geen sessie opzetten na het uitvoeren van het

4.6 Besluit

61

bestand. In de eigen implementatie is het wel mogelijk om te controleren of het bestand succesvol werd doorgestuurd naar de computer op afstand maar na uitvoeren is de aanvaller de controle kwijt. Dit is geen limitatie van de eigen implementatie maar is eigen aan de upexec stage. Om die reden wordt deze stage daarom minder vaak gebruikt dan bijvoorbeeld een interactieve shell. • vncinject vncinject zal een DLL injecteren die vervolgens een VNC-sessie zal opzetten waardoor het bureaublad van het slachtoffer wordt gedeeld met de aanvaller. Deze stage vereist een erg hoge bandbreedte wat in de huidige vorm van de eigen implementatie niet haalbaar is.

4.6

Besluit

In dit hoofdstuk werd in detail een eigen implementatie van DNS-tunneling besproken die naadloos samenwerkt met het metasploit-framework. Deze implementatie is compatibel met enkele bestaande metasploit stages waarvan de shell stage de belangrijkste is. Voor deze stage werd ook ondersteuning voor sessies toegevoegd waardoor een aanvaller op vertrouwde manier in het metasploit-framework kan communiceren met het slachtoffer op afstand. Tijdens het ontwerpen van de verschillende componenten moest rekening gehouden worden met de mogelijkheden en beperkingen van het metasploit-framework. Zo moesten alle componenten aan de kant van de aanvaller ge¨ımplementeerd worden in Ruby, een taal waar ik tot voor mijn scriptie geen ervaring mee had. In het volgende hoofdstuk plaatsen we ons in de positie van de systeembeheerder van een bedrijfsnetwerk. We bespreken mogelijke methoden om aanvallen via DNS-tunneling te gaan detecteren alvorens ze schade kunnen aanrichten. Zoals reeds vermeld in de inleiding zal het defensieve deel van deze scriptie beperkter zijn dan de offensieve kant. Daarom worden in het volgende hoofdstuk enkel beveiligingsconcepten besproken die niet verder worden omgezet naar een implementatie.

BESCHERMING TEGEN DNS-TUNNELING

62

Hoofdstuk 5 Bescherming tegen DNS-tunneling 5.1

Inleiding

In dit hoofdstuk gaan we op zoek naar methoden om DNS-tunnels binnen het bedrijfsnetwerk te detecteren. Aan het begin van deze scriptie werd ge¨ıllustreerd hoe DNS-verkeer net zoals ander netwerkverkeer via de firewall passeert, maar dat DNS-verkeer door de firewall veelal niet zal gecontroleerd worden op verdacht gedrag. Dit komt doordat DNS binnen het bedrijfsnetwerk wordt beschouwd als een vertrouwd protocol dat enkel wordt gebruikt voor het opzoeken van hostnamen binnen het eigen netwerk en op het publieke internet. In het vervolg van dit hoofdstuk zoeken we naar methoden om DNS-verkeer afkomstig van DNS-tunneling te blokkeren zonder het traditioneel DNS-verkeer te hinderen.

5.2

Blokkeren van bepaalde recordtypes

Een eerste mogelijkheid om DNS-tunnels onmogelijk te maken is het blokkeren van bepaalde recordtypes die worden gebruikt tijdens DNS-tunneling. We bespreken de impact van het blokkeren van elk recordtype afzonderlijk. We herinneren de lezer eraan dat enkel recordtypes die tekst of domeinnamen kunnen doorsturen in zowel de query als het antwoord in aanmerking komen voor DNS-tunneling. • CNAME Zoals blijkt uit Tabel 4.1 vormen CNAME-records een groot deel van het totale DNS-verkeer (gemiddeld 25% in de eigen metingen). Indien we in de DNSserver van het bedrijfsnetwerk CNAME-records volledig blokkeren wordt het werken

5.2 Blokkeren van bepaalde recordtypes

63

met aliassen zoals besproken in Sectie 2.2.1 onmogelijk. Uit de data die werd opgemeten voor de resultaten in Tabel 4.1 blijkt verder dat 85% van alle CNAME-records bestemd zijn voor hosts binnen het bedrijfsnetwerk. Indien enkel de CNAME-records bestemd voor het publieke internet worden geblokkeerd blijft de functionaliteit van aliassen binnen het bedrijfsnetwerk behouden. • TXT Uit Tabel 4.1 blijkt dat slechts 1% van alle gemeten DNS-verkeer uit TXTrecords bestaat. Na verder onderzoek van dit verkeer bleek dat al deze onderzochte TXT-records gebruikt worden voor het verifiëren van e-mail adressen zoals eerder werd toegelicht in Sectie 2.2.1. Het is dus aangeraden om TXT-records bestemd voor de mailserver toe te laten om zo het Sender Policy Framework (SPF) te blijven ondersteunen. TXT-records met andere bestemmingen dan de mailserver kunnen wel geblokkeerd worden. • NS Sommige DNS-tunnelimplementaties maken gebruik van NS-records voor het tunnelen van data. NS-records vormen een essentieel onderdeel bij het recursief opzoeken van domeinnamen. In Figuur 2.2 worden in stappen drie en vijf NS-records doorgestuurd. Door de fundamentele rol van NS-records op het internet is het blokkeren van deze records niet mogelijk.

Indien bepaalde recordtypes worden geblokkeerd moeten enkele componenten van de aanval aangepast worden. Zo zal ondermeer de DNS-stager moeten uitgebreid worden met ondersteuning voor nieuwe recordtypes zoals NS-records indien men binnen het bedrijfsnetwerk overgaat tot het blokkeren van TXT-records. De complexiteit van deze aanpassingen is relatief groot aangezien de DNS-stager rechtstreeks in machinecode wordt geschreven. Per recordtype dient nieuwe code ontwikkeld te worden om data uit de recordtypes te lezen alsook code die in staat is om zo een nieuw recordtype aan te maken en te versturen. Aanpassingen aan de DLL-stager en de DNS-server zijn eenvoudiger aangezien voor deze componenten gebruik werd gemaakt van bibliotheken die reeds het grootste deel van alle recordtypes uit de DNS-standaard ondersteunen. De DNS-tunnel handler en de stage moeten niet aangepast worden voor het ondersteunen van nieuwe recordtypes aangezien deze componenten enkel communiceren op het niveau van de TCP-abstractielaag. Het blokkeren van een bepaald recordtype is geen ideale oplossing tegen DNS-tunneling. Deze aanpak laat de aanvaller namelijk toe om steeds nieuwe recordtypes te gebruiken voor het opzetten van DNS-tunnels die niet worden geblokkeerd, zoals de NS-record die

5.3 Analyseren van DNS-queries

64

essentieel is voor een correcte werking van DNS. In het vervolg van dit hoofdstuk zoeken we naar alternatieve methoden voor het detecteren van DNS-tunnels.

5.3

Analyseren van DNS-queries

In deze sectie bestuderen we de mogelijkheden om een classificatie te doen op basis van de data aanwezig in resource records. Hierbij proberen we technieken te ontwikkelen die – onafhankelijk van de DNS-tunnelingsoftware gebruikt door de aanvaller – succesvol een communicatiekanaal over DNS kunnen detecteren. In wat volgt onderzoeken we eigenschappen die getunneld DNS-verkeer onderscheiden van traditioneel DNS-verkeer op basis van de inhoud van de DNS-pakketten.

5.3.1

Datalengte

Een eerste criterium dat getunneld verkeer onderscheidt van ander DNS-verkeer is de grootte van de resource records. Om dit criterium te gebruiken bij het detecteren van DNS-tunneling gaan we uit van de veronderstelling dat de aanvaller zal proberen om elk DNS-pakket zo efficiënt mogelijk te gebruiken tijdens het tunnelen. Dit betekent in de praktijk dat zoveel mogelijk data zal worden doorgestuurd per beschikbare resource record. Indien de aanvaller een interactieve sessie wenst te tunnelen via DNS (zoals ook het geval is in de eigen implementatie waarbij een sessie wordt opgezet die een commandolijn tunnelt) zal aan deze veronderstelling veelal worden voldaan. In Sectie 4.4.2 werd reeds vermeld dat de aangewezen maximale grootte van de datasectie van een resource record beperkt is tot 512 bytes. In de eigen implementatie worden resource records steeds maximaal gevuld indien er voldoende data aanwezig is om door te sturen. Andere implementaties zoals DNS Cat uit Sectie 2.4.1 zullen een gelijkaardig principe toepassen. Wanneer grote resource records voorkomen voor een beperkte set van domeinnamen kan dit een indicatie zijn dat deze records worden gebruikt voor het tunnelen van gegevens. In Hoofdstuk 6 analyseren we in welke mate de lengte van getunnelde resource records afwijkt van traditioneel DNS-verkeer.

5.3 Analyseren van DNS-queries 5.3.1.1

65

Complexiteit

Om deze strategie te kunnen implementeren moeten gegevens over het DNS-verkeer verzameld worden in ware tijd, die een verband tonen tussen bepaalde domeinnamen en de lengte van resource records. Door het berekenen van een maat van spreiding zoals de variantie voor de lengte van deze records kunnen domeinnamen gedetecteerd worden die verdacht gedrag vertonen. De complexiteit van deze aanpak ligt hoog indien de lengte van elke resource record moet geëvalueerd worden.

5.3.2

Codering

Een tweede eigenschap die we kunnen gebruiken is het toegepaste coderingsschema voor het versturen van binaire gegevens via DNS-pakketen. We geven een overzicht van de coderingsschema’s die in huidige DNS-tunnelimplementaties worden gebruikt. Daarbij onderzoeken we hoe we gecodeerde data kunnen gaan detecteren. • NetBIOS De werking van NetBIOS-codering [15] werd in Sectie 3.3.3 uitvoerig toegelicht. NetBIOS-codering is een onderdeel van het NetBIOS-protocol [31] dat werd ontwikkeld door IBM. Het laat applicaties op verschillende computers in een lokaal netwerk toe om met elkaar te communiceren. NetBIOS-pakketten volgen volledig de DNS-pakketstructuur. Het NetBIOS-protocol maakt zowel gebruik van TCP als UDP en opereert langs poort 137 [31]. NetBIOS-pakketten hebben wel dezelfde structuur als DNS-pakketten maar worden niet via het DNS-protocol verstuurd maar via de NetBIOS Name Service. Indien NetBIOS-gecodeerde data kan gedetecteerd worden in traditionele DNS-pakketten kan dit dus wijzen op verdacht verkeer. NetBIOSgecodeerd verkeer zal enkel karakters bevatten in het bereik A-P. Indien een resource record tekenreeksen bevat met enkel karakters in dit bereik kan dit een indicatie zijn dat NetBIOS-codering werd toegepast. • Base32 en Base64 Deze coderingsschema’s worden net als NetBIOS-codering gebruikt voor het omzetten van binaire gegevens naar leesbare strings. Als padding wordt het = karakter gebruikt. Base32 gebruikt karakters in het bereik [A-Z] en [0-9], base64 voegt daar [a-z] aan toe. Base64 kan enkel gebruikt worden voor recordtypes die hoofdlettergevoelig zijn zoals TXT-records. Het detecteren van resource records die base32 of base64 gecodeerde data bevatten is nog moeilijker dan het geval was bij NetBIOS-codering aangezien zo goed als de volledige karakterruimte


66

ondersteund door DNS kan voorkomen in de gecodeerde data. Dit maakt het moeilijk om op geautomatiseerde wijze verkeer te gaan detecteren dat gebruik maakt van base32 of base64 codering. Het detecteren van padding bytes kan hierbij een hulp bieden. 5.3.2.1

Complexiteit

Het detecteren van verdacht DNS-verkeer op basis van de gebruikte codering voor de datasectie van resource records is niet eenvoudig en kan voor de besproken coderingsschema’s niet eenduidig gebeuren. Deze aanpak brengt ook een grote computationele kost met zich mee aangezien elke resource record moet onderzocht en vergeleken worden met de verschillende coderingsschema’s.

5.3.3

Het gebruik van een DNS-proxy

In de huidige implementaties voor DNS-tunneling wordt verondersteld dat de aangevallen client in het bedrijfsnetwerk DNS-aanvragen kan sturen naar een server op het publieke internet die wordt beheerd door de aanvaller. Verder wordt ook verondersteld dat deze client rechtstreeks antwoorden van een DNS-server op het publieke internet kan ontvangen. Een mogelijke verdedigingsstrategie tegen DNS-tunneling is het gebruik van een DNS-proxy binnen het bedrijfsnetwerk, die gebruikt wordt voor het verwerken van DNS-aanvragen voor het publieke internet. De DNS-server van het bedrijf kan alle DNSaanvragen met een bestemming in het publieke netwerk doorsturen naar een DNS-proxy (die kan ge¨ımplementeerd zijn als onderdeel van de DNS-server zelf). Deze DNS-proxy zal vervolgens zelf recursief DNS-aanvragen verwerken en enkel A-records doorsturen naar de computer in het bedrijfsnetwerk die de oorspronkelijke DNS-aanvraag deed. Door enkel A-records door te sturen zullen clients nog steeds in staat zijn om domeinnamen op het publieke internet aan IP-adressen te koppelen (wat bijvoorbeeld noodzakelijk is voor het surfen naar websites) maar zullen andere recordtypes die mogelijk gebruikt kunnen worden voor DNS-tunneling geblokkeerd worden door de DNS-proxy. 5.3.3.1

Complexiteit

Deze strategie kan erg krachtig zijn aangezien op deze manier aanvallen via DNS kunnen voorkomen worden zonder te weten welke resource records of domeinnamen worden


67

gebruikt voor het tunnelen van gegevens. Om een DNS-proxy te gebruiken moet de DNSserver uitgerust worden met nieuwe regels die alle DNS-verkeer bestemd voor het publieke internet doorsturen naar de DNS-proxy. Om de complexiteit laag te houden is het mogelijk om de DNS-proxy rechtstreeks in de DNS-server van het bedrijf te implementeren.

5.3.4

Frequentie van aanvragen

Getunneld DNS-verkeer zal er voor zorgen dat één of meerdere domeinnamen gedurende de periode van de aanval waarschijnlijk vaker zullen voorkomen in DNS-aanvragen dan andere. Deze observatie kan gebruikt worden om domeinnamen te detecteren die gebruikt worden voor DNS-tunneling. Door tijdens intervallen van beperkte tijdsduur te gaan meten welke domeinnamen abnormaal vaak voorkomen in het DNS-verkeer, wordt het mogelijk om een lijst te maken van domeinnamen die verder onderzocht moeten worden op verdacht verkeer. De moeilijkheid bij het toepassen van deze techniek is het vinden van een goeie grenswaarde die het aantal valse positieven en valse negatieven beperkt. Het vinden van deze grenswaarde wordt waarschijnlijk nog bemoeilijkt door de observatie dat bepaalde domeinnamen in traditioneel DNS-verkeer veel vaker voorkomen dan andere. Dit is ook het geval voor het DNS-verkeer gebruikt voor de meetresultaten uit Tabel 4.1 waarin 5% van alle DNS-verkeer bestemd is voor het google.com domein. 5.3.4.1

Complexiteit

Het uitvoeren van een analyse van het DNS-verkeer over de tijd vraagt veel extra rekenkracht en is waarschijnlijk onrealistisch voor DNS-servers die veel verkeer moeten verwerken. Een alternatief voor het uitvoeren van analyses in ware tijd is het offline analyseren van een kopie van het DNS-verkeer. Deze aanpak heeft als voordeel dat de analyse kan uitgevoerd worden door een computer verschillend van de DNS-servers. Het nadeel van deze aanpak is dat op deze manier aanvallen pas zullen gedetecteerd worden nadat ze reeds hebben plaatsgevonden.

5.4 Conclusie

5.4

68

Conclusie

In dit hoofdstuk werden enkele mogelijke technieken besproken die kunnen gebruikt worden bij de beveiliging tegen DNS-tunnels. Naarmate nieuwe implementaties en technieken zullen gebruikt worden door aanvallers zullen ook passende beveiligingstechnieken moeten ontwikkeld worden. Hierbij moet een afweging gemaakt worden tussen de voordelen van het type beveiliging en de extra complexiteit die hiermee gepaard gaat. Deze complexiteit vertaalt zicht vooral in een extra computationele kost die nodig is voor het analyseren van DNS-verkeer. Het gebruik van een DNS-proxy lijkt op dit moment een realistische techniek voor het blokkeren van DNS-tunnels in ware tijd.

EVALUATIE

69

Hoofdstuk 6 Evaluatie In dit hoofdstuk evalueren we de prestaties van de eigen implementatie die eerder werd toegelicht in Hoofdstuk 4. Hierbij ligt de focus op twee verschillende aspecten: allereerste wensen we de bandbreedte van het communicatiekanaal te bepalen. Om dit te realiseren worden twee verschillende testopstellingen gebruikt: allereerst testen we de aanval waarbij aanvaller en slachtoffer zich in hetzelfde netwerk bevinden. Hierdoor kunnen we de maximaal haalbare bandbreedte van de implementatie meten zonder de invloed van vertragende elementen op het internet, zoals de keten van DNS-servers tussen de aanvaller en het slachtoffer. Vervolgens wordt de aanval getest in het kader van een tweede meer realistische testopstelling waarbij aanvaller en slachtoffer met elkaar verbonden zijn via het publieke internet. Door een vergelijking te maken tussen de meetresultaten uit de twee testopstellingen proberen we in te schatten wat de invloed is van de verschillende elementen op het pad tussen aanvaller en het slachtoffer op de bandbreedte van het communicatiekanaal. In een tweede reeks tests onderzoeken we de mate waarin het DNS-verkeer geproduceerd door de aanval afwijkt van traditioneel DNS-verkeer binnen het bedrijfsnetwerk. Deze observaties kunnen aansluitend op Hoofdstuk 5 inzicht verschaffen in mogelijke verdedigingstechnieken tegen DNS-tunnels.

6.1 Testopstellingen

6.1 6.1.1

70

Testopstellingen Aanval binnen lokaal netwerk

In de eerste testopstelling wordt een computer aangevallen die zich in het lokale netwerk van de aanvaller bevindt. Om dit te realiseren werd de aangevallen computer zo geconfigureerd dat alle DNS-verkeer rechtstreeks wordt doorgestuurd naar de aanvaller. Dit zorgt ervoor dat het getunnelde verkeer nooit het lokale netwerk verlaat en dus ook niet wordt vertraagd door versturing via het publieke internet.

6.1.2

Aanval over het publieke internet

In deze tweede testopstelling wordt een realistische aanval opgezet met een slachtoffer op het publieke internet, beveiligd door een firewall. Om deze tweede testopstelling te realiseren werden volgende stappen ondernomen: • Op de computer van het slachtoffer werd de DNS-server van Google (8.8.8.8) gebruikt als primaire DNS-server. Het gebruik van deze DNS-server is gratis en vereist geen authenticatie van de gebruiker, wat deze service interessant tijdens een geautomatiseerde aanval. Zoals besproken in Sectie 3.2 moet de aanvaller bevoegd zijn voor een bepaald domein om DNS-tunneling mogelijk te maken. Om dit te realiseren werd gebruik gemaakt van een gratis service [36] die het mogelijk maakt om de DNS-instellingen voor een subdomein te beheren. Door alle DNS-aanvragen voor dit domein om te leiden via de aanvaller krijgt deze controle over de antwoorden die worden teruggestuurd, wat DNS-tunneling mogelijk maakt.

6.2

Bandbreedte

In een eerste reeks tests werd de bandbreedte van het communicatiekanaal bepaald. Hiervoor werd voor beide testopstellingen een onderscheid gemaakt tussen drie fasen van de aanval: 1. Het uitwisselen van de DLL-stager met de DNS-stager. 2. Het uitwisselen van de stage met de DLL-stager.

6.2 Bandbreedte

71

3. Het uitwisselen van sessiegegevens tussen de aanvaller en de stage.

Aangezien alle drie deze fasen gebruikmaken van verschillende communicatietechnieken heeft het zin om deze opsplitsing te maken. In fase één wordt uitsluitend gebruik gemaakt van TXT-records. Fase twee en drie maken gebruik van CNAME-records. Fase drie ten slotte maakt als enige gebruik van polling. Het opsplitsen in verschillende fases maakt het mogelijk om de impact van deze ontwerpbeslissingen op de snelheid van het communicatiekanaal te achterhalen. Allereerst bespreken we de bandbreedte die werd behaald binnen de eerste testopstelling. Om een eerlijke vergelijking mogelijk te maken werd in de verschillende fasen de chunk size parameter ingesteld op 100 bytes. Dit betekent dat per resource record 100 bytes aan data wordt gecodeerd gebruik makende van het NetBIOS-coderingsschema zoals besproken in Sectie 3.3.3. Na codering zijn deze 100 bytes data omgezet naar een tekenreeks van 200 bytes. Na toevoeging van controledata en de domeinnaam bevat elke resource record ongeveer 230 bytes aan data. Dit komt sterk in de buurt van de toegelaten limiet van 255 bytes per resource record zoals gedefinieërd in de DNS standaard [20]. De resultaten van deze metingen zijn te vinden in Tabel 6.1.

Fase één (61kB data) Fase twee (0.23kB data) Fase drie (13.00kB data) 8.14

0.80

3.34

Tabel 6.1: Gemeten bandbreedte in kB/sec tijdens het uitvoeren van de aanval in het lokale netwerk voor een chunk size van 100 bytes (testopstelling één).

Uit Tabel 6.1 blijkt een duidelijk verschil in bandbreedte tussen de verschillende fasen. Allereerst merken we op dat de grootste bandbreedte werd behaald in fase één. Dit valt te verklaren door de observatie dat in fase één geen pollingmechanisme wordt gebruikt voor het tunnelen van gegevens zoals besproken in Sectie 4.5.1 en er dus geen extra overhead wordt veroorzaakt door deze pollingverzoeken. De lage bandbreedte in fase twee valt gedeeltelijk te verklaren door de kleine grootte van de stage die in deze fase wordt uitgewisseld: aangezien de DLL-stager bij het opvragen van de stage nog bezig is met het initialiseren van ondermeer de TCP-abstractielaag zal hier de vertraging veroorzaakt

6.2 Bandbreedte

72

worden door een trage dataverwerking van de DLL-stager tijdens de opstartfase. Het meten van de verwerkingstijd van de opstartende DLL-stager in fase twee bevestigt dat deze de vertragende factor vormt. Het verschil in snelheid tussen fase één en drie is vooral te verklaren door de overhead veroorzaakt door pollingverzoeken en het toevoegen van meer controledata tijdens fase drie om ondermeer caching te voorkomen. In Tabel 6.2 worden de resultaten samengevat van de metingen voor de tweede testopstelling waarbij een realistische aanval werd uitgevoerd via het publieke internet.

Fase één (61kB data) Fase twee (0.23kB data) Fase drie (39.92kB data) 0.68

0.68

2.18

Tabel 6.2: Gemeten bandbreedte in kB/sec tijdens het uitvoeren van de aanval via het publieke internet voor een chunk size van 100 bytes (testopstelling twee).

Uit de metingen blijkt meteen een groot verschil met de resultaten uit de eerste testopstelling. Fase één en twee beschikken over dezelfde bandbreedte van 0,68kB. Daar waar in de eerste testopstelling fase één beduidend beter presteerde dan fase drie observeren we een omgekeerd gedrag in de tweede testopstelling. Na observatie van het uitgewisselde DNS-verkeer tussen de aanvaller en de publieke DNS-servers blijkt dat het langer duurt om een TXT-record door te sturen dan een CNAME-record van dezelfde grootte. Een mogelijke verklaring voor deze observatie is het vermoeden dat de publieke DNS-servers voorrang geven aan de verwerking van recordtypes die gebruikt worden voor de vertaling van domeinnamen naar IP-adressen (zoals A-records en CNAME-records) om zo de voelbare vertraging voor de eindgebruikers te minimaliseren. Dit zou het verschil in bandbreedte tussen fase één en drie kunnen verklaren. De gedeelde lage bandbreedte voor fasen één en twee doet vermoeden dat het uitwisselen van TXT-records via het publieke internet minder efficiënt gebeurt dan het uitwisselen van CNAME-records in fase drie. Uit het verschil in de meetresultaten tussen testopstelling één en twee wordt het duidelijk dat de routering van getunneld verkeer via publieke DNS-servers een grote impact heeft op de beschikbare bandbreedte tijdens het uitvoeren van de aanval. Fase drie stelt het interactieve deel van de aanval voor waarbij de aanvaller sessiegegevens afkomstig van een commandolijn uitwisselt met het slachtoffer. De behaalde gemiddelde bandbreedte van

6.3 Analyse van getunneld DNS-verkeer

73

2.18kB per seconde is hiervoor voldoende maar zal echter wel zorgen voor een voelbare vertraging tijdens het werken met de interactieve sessie.

6.3

Analyse van getunneld DNS-verkeer

In dit deel bestuderen we het verschil tussen traditioneel DNS-verkeer en het verkeer gegenereerd door de eigen implementatie van DNS-tunneling. Aangezien dit verkeer analoog is voor beide testopstellingen maken we hier geen onderscheid tussen een aanval over het lokale netwerk en het publieke internet. Gebruikmakend van de testdata uit Secties 4.4.2.2 en 6.2 analyseren we het verschil in lengte van resource records tussen traditioneel DNS-verkeer en getunneld DNS-verkeer. De resultaten van deze metingen zijn weergegeven in Figuur 6.1 (CNAME-records) en Figuur 6.2 (TXT-records).

Figuur 6.1: Vergelijking van de CNAME-recordlengte tussen traditioneel DNS-verkeer en getunneld DNS-verkeer uit de eigen implementatie. Op de horizontale as vinden we de lengte-intervallen (in bytes). De verticale as stelt het totaal percentage van alle gemeten CNAME-records voor.

Wat meteen opvalt aan Figuur 6.1 is de piek bij getunneld DNS-verkeer voor het internval [40-50]. Daar waar het traditioneel DNS-verkeer veel meer verspreid is over de verschil-

6.3 Analyse van getunneld DNS-verkeer

74

lende intervallen zal 84% van alle getunnelde verkeer zich bevinden in één interval. Dit valt te verklaren door de observatie dat de DLL-stager per CNAME-record zo veel mogelijk bytes data zal proberen versturen naar de aanvaller. Ter illustratie werd voor het voorbeeld in Figuur 6.1 per resource record tot maximaal 64 bytes aan data verstuurd. De piek rond het interval [40-50] illustreert dat er voldoende vaak data werd uitgewisseld tussen aanvaller en slachtoffer waardoor deze maximale waarde van 64 bytes slechts in 2% van alle berichten werd bereikt (voorgesteld door het interval [70-80] op Figuur 6.1).

Figuur 6.2: Vergelijking van de TXT-recordlengte tussen traditioneel DNS-verkeer en getunneld DNS-verkeer uit de eigen implementatie. Op de horizontale as vinden we de lengteintervallen (in bytes). De verticale as stelt het totaal percentage van alle gemeten TXT-records voor.

Dit afwijkend gedrag voor getunneld DNS-verkeer is zelfs nog duidelijker zichtbaar voor TXT-records zoals weergegeven op Figuur 6.2. Voor traditioneel DNS-verkeer merken we een bijna uniforme spreiding over de verschillende intervallen. Voor getunneld DNS-verkeer zien we dat uitgewisselde TXT-records volledig in het interval [200-210] liggen. Door het gebruiken van een vaste chunk size van 100 bytes zal elke TXT-record in fasen één en twee een vaste lengte hebben van 200 bytes na transformatie via NetBIOS, wat het resultaat uit Figuur 6.2 verklaart.

6.4 Besluit

6.4

75

Besluit

In dit hoofdstuk werd aan de hand van twee testopstellingen de bandbreedte van de eigen implementatie gemeten. Uit de beduidend lagere waarden die werden opgemeten tijdens de aanval over het publieke internet hebben we geconcludeerd dat de routering via publieke DNS-servers een bottleneck vormt voor de maximaal haalbare snelheid tijdens het tunnelen van gegevens via DNS. De behaalde bandbreedte tijdens een realistische aanval via het publieke internet is echter wel nog groot genoeg om het tunnelen van een commandolijnsessie te realiseren. In het tweede deel van dit hoofdstuk werd onderzocht in welke mate getunneld DNS-verkeer afwijkt van traditioneel DNS-verkeer. Hiervoor werd de recordlengte vergeleken voor de twee recordtypes gebruikt in de eigen implementatie: CNAME- en TXT-records. Uit de resultaten blijkt dat het DNS-verkeer gegenereerd door de eigen implementatie sterk afwijkt van traditioneel DNS-verkeer. Deze observatie kan gebruikt worden voor de verdediging tegen DNS-tunnels zoals besproken in Hoofdstuk 5.

CONCLUSIES EN TOEKOMSTIG WERK

76

Hoofdstuk 7 Conclusies en toekomstig werk In deze scriptie werden de mogelijkheden onderzocht om DNS te gebruiken bij het opzetten van een communicatiekanaal tussen twee computers. In Hoofdstuk 3 werden drie oplossingen besproken die samen DNS geschikt maken voor het gebruik bij tunneling: NetBIOS-codering voor het versturen van binaire gegevens, een pollingsmechanisme om verkeer in twee richtingen mogelijk te maken en het toevoegen van controledata om het communicatiekanaal betrouwbaar te maken en om caching te voorkomen. Hoofdstuk 4 vormt de kern van deze scriptie waarin een eigen implementatie van DNStunneling werd besproken. Voor het realiseren van deze implementatie moesten verschillende ontwerpbeslissingen genomen worden waarvan de keuze voor een reflective DLL de belangrijkste was tijdens het ontwikkelen van de tweede stager. Het resultaat is een implementatie die DNS-tunneling mogelijk maakt in het metasploit-framework. Tests werden uitgevoerd die bevestigen dat de implementatie correct functioneert zowel binnen het lokale netwerk als over het publieke internet. Het aanbieden van DNS-tunneling in metasploit zorgt ervoor dat dit communicatiekanaal bruikbaar wordt voor beveiligingsexperts wereldwijd. De mogelijkheid om een exploit naar keuze te combineren met een communicatiekanaal dat enkel en alleen gebruik maakt van DNS, opent nieuwe mogelijkheden tijdens het uitvoeren van een gerichte aanval tegen een computer in een sterk beveiligd bedrijfsnetwerk. Dit betekent dat in de toekomst ook aandacht zal moeten besteed worden aan de beveiliging tegen deze vorm van aanvallen iets wat momenteel in de meeste firewalls en intrusiedetectiesystemen nog ontbreekt. In Hoofdstuk 5 werden reeds enkele mogelijke beveiligingsstrategieën tegen DNS-tunneling besproken maar hier zal nog verder onderzoek naar moeten verricht worden.

7.1 Mogelijke uitbreidingen

77

In Hoofdstuk 6 werd aan de hand van twee testopstellingen de beschikbare bandbreedte van het communicatiekanaal gemeten. Uit de metingen blijkt dat het uitwisselen van sessiegegevens tijdens een aanval via het publieke internet slechts mogelijk is aan de helft van de beschikbare bandbreedte dan tijdens een soortgelijke aanval binnen een lokaal netwerk. Een gemiddelde snelheid van 2kB per seconde is voldoende voor het tunnelen van een commandolijnsessie maar maakt het tunnelen van sommige complexere stages zoals VNC (besproken in Sectie 4.5.3) voorlopig onmogelijk.

7.1

Mogelijke uitbreidingen

De eigen implementatie kan nog op verschillende manieren uitgebreid worden. Door de beperkte die tijd tijdens deze scriptie aan de implementatie kon besteed worden kon niet alle gewenste functionaliteit ge¨ımplementeerd worden. In wat volgt wordt een overzicht gegeven van mogelijke uitbreidingen op de huidige implementatie in metasploit.

7.1.1

Ondersteunen van encryptie

In de huidige implementatie wordt getunnelde data gecodeerd maar niet geëncrypteerd. Het encrypteren van de doorgestuurde data kan volgende voordelen opleveren: • Het wordt moeilijker voor intrusiedetectiesystemen om regels te gebruiken die op basis van de inhoud van DNS-pakketten een beslissing nemen over de aard van het verkeer. Door het getunnelde verkeer te encrypteren zullen enkel de tunneleindpunten de inhoud van de berichten kunnen lezen. • Het encrypteren van getunnelde data voorkomt dat verkeer dat wordt afgeluisterd door een derde partij kan gelezen worden. Het encrypteren van verkeer brengt ook een extra computationele kost met zich mee aangezien het versleutelen en ontcijferen van gegevens extra rekenkracht vereist. Routines die encryptie implementeren zullen onvermijdelijk de hoeveelheid code gaan vergroten - dit kan problematisch zijn voor bijvoorbeeld een stager waarbij één van de vereisten is dat deze in de heap van het aangevallen proces past zoals besproken in 4.5.1. Om deze reden zal de DNS-stager geen encryptie gebruiken tijdens de communicatie met de DNS-server. Het gebruiken van encryptie voor communicatie tussen de DLL-stager en de DNS-server is wel een mogelijke uitbreiding.

7.1 Mogelijke uitbreidingen

7.1.2

78

Ondersteunen van simultane sessies met eenzelfde computer

In de huidige implementatie is het niet mogelijk om meerdere simultane sessies te starten met eenzelfde computer op afstand. Dit kan gewenst zijn indien in de toekomst nog andere stages buiten de commandolijn worden ondersteund. Voor het ondersteunen van meerdere simultane sessies met eenzelfde computer moeten aanpassingen gemaakt worden in de DLL-stager en de DNS-server.

7.1.3

Ondersteunen van meerdere domeinnamen

De huidige implementatie biedt momenteel ondersteuning voor één enkel domein waarvoor de aanvaller bevoegd is (example.com genoemd doorheen de scriptie). Door het ondersteunen van meerdere domeinnamen die kunnen gebruikt worden tijdens het tunnelen wordt de kans op detectie kleiner aangezien het getunnelde verkeer kan verdeeld worden over meerdere domeinen.

7.1.4

Ondersteunen van meer recordtypes

Momenteel worden enkel TXT-en CNAME-records gebruikt tijdens het tunnelen. De DNSserver gebruikt TXT-records om te communiceren met de DNS-stager en CNAME-records om te communiceren met de DLL-stager. Het gebruik van NS-records behoort tot de mogelijkheden alsook het gebruik van DNSSEC-records. DNSSEC [32] is een uitbreiding van DNS en maakt data-integriteit en authenticatie mogelijk in de context van DNS. Een onderdeel van DNSSEC vormt het uitwisselen van publieke sleutels - de recordstypes die hiervoor worden gebruikt vormen kandidaten voor het gebruik bij tunneling, aangezien deze voldoende data per resource record kunnen bevatten. De RRSIG resource record [33] is hiervan de belangrijkste. Een vereiste voor het gebruik van deze resource records is dat alle tussenliggende DNS-servers op het pad tussen de aanvaller en het slachtoffer DNSSEC ondersteunen. DNSSEC wordt ondersteund sinds versie 9 van BIND en versie 2.9.21 van PowerDNS, twee vaak gebruikte implementaties voor DNS-servers. Uit gepubliceerde statistieken [34] blijkt dat 99% van de top-500 domeinen op het moment van schrijven nog geen gebruik maken van DNSSEC. Indien toekomstige implementaties voor DNS-tunneling gebruik maken van DNSSEC-records is het niet ondenkbaar dat deze

7.2 Besluit

79

op eenvoudige manier zullen gedetecteerd worden aangezien ze momenteel nog maar zelden voorkomen in traditioneel DNS-verkeer. Dit kan in de toekomst veranderen aangezien ondersteuning voor DNSSEC in de lift zit en het waarschijnlijk is dat DNSSEC in de toekomst meer zal gaan gebruikt worden.

7.1.5

Ondersteunen van meer stages

Momenteel worden nog niet alle stages in metasploit ondersteund door de eigen implementatie. Zoals besproken in 4.5.3 is het nog niet mogelijk om een meterpretersessie te tunnelen over DNS aangezien deze stage gebruik maakt van SSL. Ondersteuning voor SSL en meterpretersessies behoort tot belangrijk toekomstig werk gezien de uitgebreide functionaliteit van deze stage.

7.2

Besluit

In deze scriptie werd onderzocht hoe DNS-tunneling kan gebruikt worden bij het opzetten van een communicatiekanaal tussen twee computers via het publieke internet. Eén van de belangrijkste doelstellingen was het ontwerpen van een DNS-tunnelingimplementatie voor het metasploit-framework dat wereldwijd wordt gebruikt door beveiligingsexperts voor het testen van de beveiliging van bedrijfsnetwerken. Deze doelstelling werd behaald met als resultaat een reeks metasploitcomponenten die het mogelijk maken om een commandolijnsessie op te zetten met een computer in een sterk beveiligd bedrijfsnetwerk, door enkel en alleen gebruik te maken van geldig DNS-verkeer. In Hoofdstuk 6 werd aangetoond dat een realistische aanval via het publieke internet met de eigen implementatie mogelijk is. Dit betekent dat beheerders van bedrijfsnetwerken maatregelen moeten nemen om het netwerk te beveiligen tegen aanvallen via DNS-tunnels. In Hoofdstuk 5 werden enkele mogelijke verdedigingstechnieken voorgesteld waarvan het gebruik van een DNS-proxy momenteel de beste oplossing lijkt. Ten slotte werden in Sectie 7.1 verschillende suggesties gegeven voor mogelijke uitbreidingen van de gerealiseerde implementatie.

BIBLIOGRAFIE

80

Bibliografie [1] Hamdan.O.Alanazi and Rafidah Md Noor and B.B Zaidan and A.A Zaidan. Intrusion Detection System: Overview. Journal of Computing, 2(2), 2010. [2] Ron Bowes. DNS Cat. http://www.skullsecurity.org/wiki/index.php/Dnscat. [3] Giovanni Giacobbi. Netcat. http://netcat.sourceforge.net/. [4] Offensive Security. Metasploit Unleashed. http://www.offensive-security. com/metasploit-unleashed/Metasploit_Unleashed_Information_Security_ Training. [5] Rapid7. Metasploit Framework. http://www.metasploit.com. [6] Kenneth Ingham and Stephanie Forrest. A History and Survey of Network Firewalls. http://www.cs.unm.edu/~treport/tr/02-12/firewall.pdf, 2002. [7] Karen Scarfone and Peter Mell. Guide to Intrusion Detection and Prevention Systems (IDPS). http://csrc.ncsl.nist.gov/publications/nistpubs/800-94/ SP800-94.pdf, 2007. [8] AnalogBit. tcp-over-dns software tool. tcp-over-dns.

http://analogbit.com/software/

[9] bindhsell.net. The Browser Exploitation Framework(BeEF). http://www.bindshell. net/tools/beef/. [10] skape. Post-Exploitation on Windows using ActiveX Controls. uninformed.org/?v=1&a=3&t=sumry.

http://www.

[11] James F. Kurose and Keith W. Ross. Computer Networking: A Top-Down Approach, 5/E. Addison-Wesley, 5 edition, 2010.

BIBLIOGRAFIE [12] Rapid7. Metasploit Pro ms-pro-user-guide.pdf.

81 User

Guide.

http://www.rapid7.com/docs/

[13] Network Sorcery. Dns, domain name system. http://www.networksorcery.com/ enp/protocol/dns.htm. [14] Network Working Group. Using the Domain Name System To Store Arbitrary String Attributes. http://tools.ietf.org/html/rfc1464. [15] Microsoft Corporation. ASCII and Hex Representation of NetBIOS Names. http: //support.microsoft.com/kb/194203. [16] Microsoft Corporation. Microsoft PE and COFF Specification. microsoft.com/nl-nl/windows/hardware/gg463125.

http://msdn.

[17] Network Working Group. ASCII format for Network Interchange. http://tools. ietf.org/html/rfc20. [18] Network Working Group. Domain Names - Concepts and facilities. http://tools. ietf.org/html/rfc1034. [19] Network Working Group. Domain Name System (DNS) Case Insensitivity Clarification. http://tools.ietf.org/html/rfc4343. [20] Network Working Group. Domain Names - Implementation and Specification. http: //www.ietf.org/rfc/rfc1035.txt. [21] Network Working Group. The Base16, Base32, and Base64 Data Encodings. http: //tools.ietf.org/html/rfc4648. [22] Aleph One. Smashing The Stack For Fun And Profit. Phrack 49, 7(49), 1996. http: //insecure.org/stf/smashstack.html. [23] Microsoft Corporation. Microsoft Internet Information Services Remote Buffer Overflow (SYSTEM Level Access), 2001. http://www.eeye.com/Resources/ Security-Center/Research/Security-Advisories/AD20010618. [24] Skape. Understanding Windows shellcode, 2003. skape/papers/win32-shellcode.pdf.

http://www.hick.org/code/

[25] Microsoft Corporation. VirtualAlloc Function, 2011. http://msdn.microsoft.com/ en-us/library/aa366887(v=vs.85).aspx.

BIBLIOGRAFIE

82

[26] Stephen Fewer. Reflective DLL Injection, 2008. http://www.harmonysecurity.com/ files/HS-P005_ReflectiveDllInjection.pdf. [27] Apple Computer, Inc. AppleTalk: Hop Count Limit, 2008. http://support.apple. com/kb/TA28399?viewlocale=en_US. [28] The SPF Council. Sender Policy Framework. http://www.openspf.org/. [29] skape and Jarkko Turkulainen. Remote Library Injection, 2004. nologin.org/Downloads/Papers/remote-library-injection.pdf. [30] skape. Metasploits Meterpreter, 2004. Papers/meterpreter.pdf.

http://www.

http://www.nologin.org/Downloads/

[31] Network Working Group. Protocol standars for A NetBIOS service on a TCP/UDP transport: detailed specifications, 1987. http://ubiqx.org/cifs/rfc-draft/ rfc1002.txt. [32] Network Working Group. Domain Name System Security Extensions, 1999. http: //tools.ietf.org/html/rfc2535. [33] Network Working Group. Resource Records for the DNS Security Extensions, 2005. http://www.ietf.org/rfc/rfc4034.txt. [34] Neustar Inc. Domain Statistics, 2011. http://www.ultratools.com/stat. [35] B. Clifford Neuman and Theodore Ts’o. Kerberos: An Authentication Service for Computer Networks. IEEE Communications Magazine, 32(9), 1994. [36] Joshua Anderson. Free DNS Hosting, Dynamic DNS Hosting, Static DNS Hosting, subdomain and domain hosting. http://freedns.afraid.org.

LIJST VAN FIGUREN

83

Lijst van figuren 1.1

Overzicht van de verschillende componenten in een typisch bedrijfsnetwerk.

3

2.1 2.2

Het toepassen van inkapseling bij netwerktunneling. . . . . . . . . . . . . . Een voorbeeld van de verschillende boodschappen uitgewisseld tijdens een DNS lookup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . De structuur van een DNS-pakket. . . . . . . . . . . . . . . . . . . . . . . De structuur van een query. . . . . . . . . . . . . . . . . . . . . . . . . . . De structuur van een Resource Record. . . . . . . . . . . . . . . . . . . . . Het pad dat gevolgd wordt door verkeer verstuurd via een DNS-tunnel. . . Het gebruik van TXT-en CNAME records voor het doorsturen van strings via DNS. In dit voorbeeld wisselen A en B allebei zes bytes uit. . . . . . . Communicatie tussen twee computers aan de hand van de DNS Cat server-en clientapplicaties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Een overzicht van de metasploit-architectuur. . . . . . . . . . . . . . . . . Voorbeeld van de verschillende stappen tijdens een aanval opgezet via metasploit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10

Een standaard scenario voor het opzetten van een DNS-tunnel met een client beveiligd door een firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Tijdsverloop van het DNS-verkeer bij polling. . . . . . . . . . . . . . . . . 3.3 Twee mogelijke scenario’s die de onbetrouwbaarheid van DNS verduidelijken. Het bovenste scenario illustreert het verlies van data, het onderste scenario illustreert out-of-order aflevering. . . . . . . . . . . . . . . . . . . 3.4 Het betrouwbaar maken van het kanaal door het toevoegen van eenvoudige controledata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 16 17 17 18 20 22 24 29

3.1

31 33

35 36

LIJST VAN FIGUREN 4.1

4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9

Het tijdsverloop en de interactie tussen de aanvaller en het slachtoffer tijdens het uitvoeren van een gerichte aanval gebruikmakend van DNS-tunneling en metasploit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overzicht van alle ge¨ımplementeerde componenten voor de realisatie van DNS-tunneling in metasploit. . . . . . . . . . . . . . . . . . . . . . . . . . Een sessie in de eigen implementatie die in dit voorbeeld een commandolijn tunnelt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interactie tussen de DNS-tunnel handler en de DNS-server bij het uitwisselen van sessiegegevens. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Het uitwisselen van de DLL-stager tussen de DNS-server en de DNS-stager in stukken van 100 bytes tijdens fase één van de DNS-server. . . . . . . . . Het uitwisselen van de stage tussen de DNS-server en de DLL-stager in stukken van 64 bytes tijdens fase twee van de DNS-server. . . . . . . . . . Voorbeeld van een buffer-overflowaanval waarbij via codeinjectie kwaadwillige code wordt uitgevoerd. . . . . . . . . . . . . . . . . . . . . . . . . . . . De stapsgewijze werking van de DNS-stager, hier ge¨ıllustreerd in het kader van een buffer-overflowaanval. . . . . . . . . . . . . . . . . . . . . . . . . . Detailweergaven van de verschillende onderdelen van de DLL-stager en hun onderlinge communicatie. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Vergelijking van de CNAME-recordlengte tussen traditioneel DNS-verkeer en getunneld DNS-verkeer uit de eigen implementatie. Op de horizontale as vinden we de lengte-intervallen (in bytes). De verticale as stelt het totaal percentage van alle gemeten CNAME-records voor. . . . . . . . . . . . . . 6.2 Vergelijking van de TXT-recordlengte tussen traditioneel DNS-verkeer en getunneld DNS-verkeer uit de eigen implementatie. Op de horizontale as vinden we de lengte-intervallen (in bytes). De verticale as stelt het totaal percentage van alle gemeten TXT-records voor. . . . . . . . . . . . . . . .

84

41 43 45 45 47 50 52 56 59

6.1

73

74

LIJST VAN TABELLEN

85

Lijst van tabellen 3.1

4.1

Voorbeeld van NetBIOS-codering voor het omzetten van 10 bytes binaire data naar leesbare tekst, klaar voor gebruik in DNS-verkeer. . . . . . . . .

38

Resultaten van tien metingen uitgevoerd in het UGent netwerk. . . . . . .

49

6.1

Gemeten bandbreedte in kB/sec tijdens het uitvoeren van de aanval in het lokale netwerk voor een chunk size van 100 bytes (testopstelling één). . . . 6.2 Gemeten bandbreedte in kB/sec tijdens het uitvoeren van de aanval via het publieke internet voor een chunk size van 100 bytes (testopstelling twee). .

71 72

Analyse van DNS-tunnelingtechnieken. Daan Raman

Recommend Documents