INCIDENT REPLAY · 2014-03-29
Turk Telekom hijack of public DNS resolver addresses
After Turkish users switched to foreign DNS resolvers to evade a Twitter block, Turk Telekom installed /32 routes for the resolver addresses and answered the queries from its own servers, returning falsified results. The interception ran from 29 March until about 7 April 2014 and affected users inside Turk Telekom's network.
A reconstruction, not the operator's network. Hammerhead's authors rebuilt the change from the public record as a small network of their own. No configuration here is the operator's. What follows is what the tool reported on that reconstruction; it is not a claim that the tool would have prevented the outage.
What happened
Who: Turk Telekom (AS9121); targets Google Public DNS 8.8.8.8, OpenDNS, Level 3 4.2.2.2
The summary at the top is paraphrased from the sources below. Hammerhead's catalog rates its confidence in this account high.
Sources
- https://security.googleblog.com/2014/03/googles-public-dns-intercepted-in-turkey.html
- https://www.bgpmon.net/turkey-hijacking-ip-addresses-for-popular-global-dns-providers/
- https://www.bortzmeyer.org/dns-routing-hijack-turkey.html
- https://www.computerworld.com/article/1513144/google-level-3-dns-services-hijacked-in-turkey.html
- https://www.internetsociety.org/blog/2014/04/turkish-hijacking-of-dns-providers-shows-clear-need-for-deploying-bgp-and-dns-security/
What the public record says
- After Turkish users switched to foreign DNS resolvers to evade a Twitter block, Turk Telekom installed /32 routes for the resolver addresses and answered the queries from its own servers, returning falsified results. The interception ran from 29 March until about 7 April 2014 and affected users inside Turk Telekom's network.
- Who: Turk Telekom (AS9121); targets Google Public DNS 8.8.8.8, OpenDNS, Level 3 4.2.2.2
What the reconstruction assumed
Decided by Hammerhead's authors to build a network that runs. None of it describes the operator's network.
Everything below is ours.
- The family template (
tools/replays/gen_family_audit.py): DOWNSTREAM-1 (AS 64500, a downstream Turkish ISP) has a session to TURKTELEKOM-1 (AS 9121, Turk Telekom, announcing /32s for public resolvers) with a prefix-list that permits any prefix of any length, a prefix limit, an inbound AS-path filter, and a second session with every safeguard, so that each finding is one row. - Intentional on the announcing side. Downstream ISPs accepting /32s for foreign space from their provider is the finding: the provider session's filter permits any length.
- No change is replayed: the announcing network's change is not ours to gate. The audit runs on the accepting router's healthy configuration.
- Cisco IOS syntax and stand-in address space throughout. A reconstruction, not any operator's configuration.
What Hammerhead said
Each run below is pinned by Hammerhead's replay tests at commit 0ee9732: the verdict and the quoted text are checked against the tool's output, and a run that disagrees fails the test. Reason lines are copied verbatim; a pinned line can be part of a longer reason. Every preflight run uses --max-blast-radius 100, so a change is never counted as caught merely because it touched many devices of a small network.
DOWNSTREAM-1's own router, no change: the inbound filter accepts prefixes longer than /24
now: fail (finding)An audit of one snapshot, no change: hammerhead nqe-library --mode run, check nqe.bgp.prefix_list_max_length. Pinned status: fail, a finding whose evidence contains the text below.
Evidence pinned (the evidence contains each line)
- 1 row(s)
- DOWNSTREAM-1
- 9121
First run, before the fixes this batch prompted
first: skipped-stub (the check was a stub)Need per-peer prefix-list length introspection.
Pinned in tests/gauntlet/replays-audit.yaml.
What changed in Hammerhead because of it
From the “What was fixed” table in Hammerhead's replay notes, where each fix landed after a failing test. “Found by” is copied as written; a family name means the batch this incident belongs to.
Inbound max prefix length and AS-path filter on BgpSession
prefix_list_max_length and a new ebgp_inbound_as_path_filter audit stop being stubs: a /32 for somebody else's address wins by longest match wherever it is accepted; a prefix filter generated from a forged registry object says nothing about whose path.
Found by: Accepting-network family
Limits
- The configurations are a reconstruction. Where the record is silent, the assumptions above fill the gap; if one is wrong, the replay is wrong in that respect.
- A verdict describes the reconstructed network's converged state. Timing, traffic load, and anything a device does that no configuration states, such as software reacting to a health check or a firmware bug, are outside it.
- A pass is reported as a pass. A fail says a gate fired on the reconstruction, nothing more.
- Why the catalog counts this outage as partly in scope: Intentional, so the gate would be overridden, but downstream Turkish ISPs accepting /32s for foreign space from their provider is an auditable missing filter.
Imported from docs/replays/turk-telekom-2014/FACTS.md and the replay manifests in the Hammerhead repository at commit 0ee9732.