The Attacker Waits for a Number Of Milliseconds > 자유게시판

• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

We analyze the prandom pseudo random quantity generator (PRNG) in use within the Linux kernel (which is the kernel of the Linux working system, in addition to of Android) and display that this PRNG is weak. The prandom PRNG is in use by many "consumers" in the Linux kernel. We targeted on three shoppers on the community level - the UDP source port technology algorithm, the IPv6 movement label era algorithm and the IPv4 ID era algorithm. The flawed prandom PRNG is shared by all these customers, iTagPro locator which permits us to mount "cross layer attacks" against the Linux kernel. In these assaults, ItagPro we infer the internal state of the prandom PRNG from one OSI layer, and use it to both predict the values of the PRNG employed by the other OSI layer, or to correlate it to an inner state of the PRNG inferred from the opposite protocol. Using this strategy we can mount a really efficient DNS cache poisoning attack in opposition to Linux.

We collect TCP/IPv6 move label values, or UDP supply ports, or TCP/IPv4 IP ID values, reconstruct the inner PRNG state, then predict an outbound DNS question UDP source port, which accelerates the attack by an element of x3000 to x6000. This attack works remotely, but can also be mounted regionally, throughout Linux customers and throughout containers, and (depending on the stub resolver) can poison the cache with an arbitrary DNS report. Additionally, we will identify and observe Linux and Android devices - we collect TCP/IPv6 move label values and/or UDP supply port values and/or TCP/IPv4 ID fields, reconstruct the PRNG inside state and correlate this new state to previously extracted PRNG states to identify the identical device. IPv4/IPv6 network address. This process is named DNS resolution. To be able to resolve a reputation into an tackle, the application makes use of a standard operating system API e.g. getaddrinfo(), which delegates the query to a system-wide service known as stub resolver.

This native (on-machine) service in turn delegates the query to one of many name servers within the working system’s community configuration, e.g. an ISP/campus/enterprise identify server, or a public identify server corresponding to Google’s 8.8.8.8. This recursive resolver does the precise DNS decision in opposition to the authoritative DNS servers which can be responsible for sub-bushes of the hierarchical DNS world database. Both the stub resolver and the recursive resolver might cache the DNS answer for ItagPro better efficiency in subsequent resolution requests for a similar host identify. DNS is fundamental to the operation of the Internet/net. For example, every non-numeric URL requires the browser to resolve the host name earlier than a TCP/IP connection to the vacation spot host will be initiated. Likewise, SMTP relies on DNS to find the community handle of mail servers to which emails ought to be despatched. Therefore, attacks that modify the decision course of, and specifically assaults that change present DNS records within the cache of a stub/recursive resolver or introduce pretend DNS information to the cache, can result in a extreme compromise of the user’s integrity and privacy.

Our focus is on poisoning the cache of the Linux stub resolver. The DNS protocol is applied on top of UDP, which is a stateless protocol. With a purpose to spoof a DNS reply, the attacker must know/guess all of the UDP parameters within the UDP header of the real DNS reply, namely the supply and vacation spot community addresses, and the supply and destination ports. We assume the attacker is aware of the vacation spot network tackle, which is the tackle of the stub resolver, and the supply community tackle, which is the deal with of the recursive name server utilized by the stub resolver. The attacker also is aware of the UDP source port for the DNS answer, which is fifty three (the usual DNS port), and thus the one unknown is the vacation spot port (nominally sixteen bits, virtually about 15 bits of entropy), which is randomly generated by the stub resolver’s system. At the DNS stage, the attacker must know/guess the transaction ID DNS header field (16 bits, abbreviated "TXID"), which is randomly generated by the DNS stub resolver, and the DNS query itself, which the attacker can infer or influence.

Thus, the attacker needs to foretell/guess 31 bits (the UDP vacation spot port, and the DNS TXID) with a purpose to poison the cache of the stub resolver. DNS answers is almost impractical to perform over today’s Internet within an affordable timeframe, and due to this fact improvements to DNS cache poisoning techniques that could make them more sensible are a topic of ongoing analysis. Browser-based mostly monitoring is a standard method in which advertisers and surveillance brokers determine users and observe them across a number of shopping classes and web sites. As such, it is widespread in today’s Internet/internet. Web-based monitoring could be performed instantly by web sites, or by advertisements placed in websites. We analyze the prandom PRNG, which is basically a combination of 4 linear feedback shift registers, and present the way to extract its inside state given a few PRNG readouts. For DNS cache poisoning, we obtain partial PRNG readouts by establishing a number of TCP/IPv6 connections to the target gadget, itagpro locator and observing the movement labels on the TCP packets sent by the gadget (on current kernels, we can alternatively set up TCP/IPv4 connections and observe the IP ID values).