SlideShare ist ein Scribd-Unternehmen logo

Bo2004

1 von 44
Downloaden Sie, um offline zu lesen
Black Ops 2004
@ LayerOne
Dan Kaminsky
Introduction
Who am I?
 Senior Security Consultant, Avaya
Enterprise Security Practice
 Author of “Paketto Keiretsu”, a collection of
advanced TCP/IP manipulation tools
 Speaker at Black Hat Briefings
 Black Ops of TCP/IP series
 Gateway Cryptography w/ OpenSSH
 Protocol Geek
What’s On The Plate for
Today?
/* char descrip[256] = “You’ll see”; */
What is DNS
DNS: Domain Name System
 Mechanism for translating human-readable names
into machine routable addresses
“Like 411 for the Internet”
 As 411 usually but not always yields simple phone
numbers, DNS usually but not always yields IP
addresses
 A: Given name, find IP
 MX: Given name, find Mail
 PTR: Given IP, find name
 TXT: Given name, find “stuff”
“Useful” Traits of DNS
(Very Very Abridged)
Hierarchical
 .com says where to find addresses in .doxpara.com, and
.doxpara.com says where to find addresses in
foo.doxpara.com
Recursive vs. Iterative Lookups
 Iterative Lookup: Ask a server a question, it tells you where
to go to find out the answer
 Recursive Lookup: Ask a server, it goes out and finds out
the answer for you, and tells you
 It queries the hierarchy…which you may control
Caching
 Responses contain a TTL – Time To Live – within which
future requests don’t require another message to be sent
Primary Research Areas
for DNS
Exploitation
 1999-2000 were filled with exploits against
BIND, the most common DNS server
 Not terribly vulnerable now
DNS Spoofing
 Returning false addresses = hijack
people’s outgoing net connections
DNS Tunneling

Recomendados

Dns protocol design attacks and security
Dns protocol design attacks and securityDns protocol design attacks and security
Dns protocol design attacks and securityMichael Earls
 
CNIT 40: 2: DNS Protocol and Architecture
CNIT 40: 2: DNS Protocol and ArchitectureCNIT 40: 2: DNS Protocol and Architecture
CNIT 40: 2: DNS Protocol and ArchitectureSam Bowne
 
DNS-SD
DNS-SDDNS-SD
DNS-SDnetvis
 
Class Project Showcase: DNS Spoofing
Class Project Showcase: DNS SpoofingClass Project Showcase: DNS Spoofing
Class Project Showcase: DNS SpoofingBeibei Yang
 

Más contenido relacionado

Was ist angesagt?

OARC 31: NSEC Caching Revisited
OARC 31: NSEC Caching RevisitedOARC 31: NSEC Caching Revisited
OARC 31: NSEC Caching RevisitedAPNIC
 
CNIT 40: 4: Monitoring and detecting security breaches
CNIT 40: 4: Monitoring and detecting security breachesCNIT 40: 4: Monitoring and detecting security breaches
CNIT 40: 4: Monitoring and detecting security breachesSam Bowne
 
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruptionCNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruptionSam Bowne
 
CNIT 40: 1: The Importance of DNS Security
CNIT 40: 1: The Importance of DNS SecurityCNIT 40: 1: The Importance of DNS Security
CNIT 40: 1: The Importance of DNS SecuritySam Bowne
 
CNIT 40: 3: DNS vulnerabilities
CNIT 40: 3: DNS vulnerabilitiesCNIT 40: 3: DNS vulnerabilities
CNIT 40: 3: DNS vulnerabilitiesSam Bowne
 
DNS spoofing/poisoning Attack
DNS spoofing/poisoning AttackDNS spoofing/poisoning Attack
DNS spoofing/poisoning AttackFatima Qayyum
 
DNS spoofing/poisoning Attack Report (Word Document)
DNS spoofing/poisoning Attack Report (Word Document)DNS spoofing/poisoning Attack Report (Word Document)
DNS spoofing/poisoning Attack Report (Word Document)Fatima Qayyum
 
CNIT 40: 4: Monitoring and detecting security breaches
CNIT 40: 4: Monitoring and detecting security breachesCNIT 40: 4: Monitoring and detecting security breaches
CNIT 40: 4: Monitoring and detecting security breachesSam Bowne
 
CNIT 40: 6: DNSSEC and beyond
CNIT 40: 6: DNSSEC and beyondCNIT 40: 6: DNSSEC and beyond
CNIT 40: 6: DNSSEC and beyondSam Bowne
 
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruptionCNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruptionSam Bowne
 
GopherFest 2017 - Adding Context to NATS
GopherFest 2017 -  Adding Context to NATSGopherFest 2017 -  Adding Context to NATS
GopherFest 2017 - Adding Context to NATSwallyqs
 
5.Dns Rpc Nfs 2
5.Dns Rpc Nfs 25.Dns Rpc Nfs 2
5.Dns Rpc Nfs 2phanleson
 
5.Dns Rpc Nfs
5.Dns Rpc Nfs5.Dns Rpc Nfs
5.Dns Rpc Nfsphanleson
 
Covert timing channels using HTTP cache headers
Covert timing channels using HTTP cache headersCovert timing channels using HTTP cache headers
Covert timing channels using HTTP cache headersyalegko
 
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS AttacksDNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS AttacksFindWhitePapers
 

Was ist angesagt? (20)

OARC 31: NSEC Caching Revisited
OARC 31: NSEC Caching RevisitedOARC 31: NSEC Caching Revisited
OARC 31: NSEC Caching Revisited
 
CNIT 40: 4: Monitoring and detecting security breaches
CNIT 40: 4: Monitoring and detecting security breachesCNIT 40: 4: Monitoring and detecting security breaches
CNIT 40: 4: Monitoring and detecting security breaches
 
Backtrack Manual Part3
Backtrack Manual Part3Backtrack Manual Part3
Backtrack Manual Part3
 
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruptionCNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
 
CNIT 40: 1: The Importance of DNS Security
CNIT 40: 1: The Importance of DNS SecurityCNIT 40: 1: The Importance of DNS Security
CNIT 40: 1: The Importance of DNS Security
 
CNIT 40: 3: DNS vulnerabilities
CNIT 40: 3: DNS vulnerabilitiesCNIT 40: 3: DNS vulnerabilities
CNIT 40: 3: DNS vulnerabilities
 
Anatomy of file read in hadoop
Anatomy of file read in hadoopAnatomy of file read in hadoop
Anatomy of file read in hadoop
 
DNS spoofing/poisoning Attack
DNS spoofing/poisoning AttackDNS spoofing/poisoning Attack
DNS spoofing/poisoning Attack
 
DNS spoofing/poisoning Attack Report (Word Document)
DNS spoofing/poisoning Attack Report (Word Document)DNS spoofing/poisoning Attack Report (Word Document)
DNS spoofing/poisoning Attack Report (Word Document)
 
CNIT 40: 4: Monitoring and detecting security breaches
CNIT 40: 4: Monitoring and detecting security breachesCNIT 40: 4: Monitoring and detecting security breaches
CNIT 40: 4: Monitoring and detecting security breaches
 
CNIT 40: 6: DNSSEC and beyond
CNIT 40: 6: DNSSEC and beyondCNIT 40: 6: DNSSEC and beyond
CNIT 40: 6: DNSSEC and beyond
 
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruptionCNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
CNIT 40: 5: Prevention, protection, and mitigation of DNS service disruption
 
GopherFest 2017 - Adding Context to NATS
GopherFest 2017 -  Adding Context to NATSGopherFest 2017 -  Adding Context to NATS
GopherFest 2017 - Adding Context to NATS
 
5.Dns Rpc Nfs 2
5.Dns Rpc Nfs 25.Dns Rpc Nfs 2
5.Dns Rpc Nfs 2
 
5.Dns Rpc Nfs
5.Dns Rpc Nfs5.Dns Rpc Nfs
5.Dns Rpc Nfs
 
2 technical-dns-workshop-day1
2 technical-dns-workshop-day12 technical-dns-workshop-day1
2 technical-dns-workshop-day1
 
Covert timing channels using HTTP cache headers
Covert timing channels using HTTP cache headersCovert timing channels using HTTP cache headers
Covert timing channels using HTTP cache headers
 
6 technical-dns-workshop-day3
6 technical-dns-workshop-day36 technical-dns-workshop-day3
6 technical-dns-workshop-day3
 
Introduction to DNS
Introduction to DNSIntroduction to DNS
Introduction to DNS
 
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS AttacksDNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks
DNSSEC: The Antidote to DNS Cache Poisoning and Other DNS Attacks
 

Destacado

Amigo De Verdad Gardfield
Amigo De Verdad GardfieldAmigo De Verdad Gardfield
Amigo De Verdad Gardfieldhuehue 1
 
TVSMILES - NOAH13 London
TVSMILES - NOAH13 LondonTVSMILES - NOAH13 London
TVSMILES - NOAH13 LondonNOAH Advisors
 
WilliamBlumeTheBusinessProject
WilliamBlumeTheBusinessProjectWilliamBlumeTheBusinessProject
WilliamBlumeTheBusinessProjectWill Blume
 
Antigo Fórum de Teresina - Arquitetura Eclética
Antigo Fórum de Teresina - Arquitetura EcléticaAntigo Fórum de Teresina - Arquitetura Eclética
Antigo Fórum de Teresina - Arquitetura EcléticaThiago Lopes
 
EDC_2131006_BipolarJunctionTransistor
EDC_2131006_BipolarJunctionTransistorEDC_2131006_BipolarJunctionTransistor
EDC_2131006_BipolarJunctionTransistorJitin Pillai
 
Walking on Troubled Water
Walking on Troubled WaterWalking on Troubled Water
Walking on Troubled WaterRay Pack
 
Repowering American Innovation
Repowering American InnovationRepowering American Innovation
Repowering American Innovationguest3d6941
 
Presentatie handson hsmai congres juni 13
Presentatie handson hsmai congres juni 13Presentatie handson hsmai congres juni 13
Presentatie handson hsmai congres juni 13Hands-On Advies
 
Fashion Trends On Campus
Fashion Trends On CampusFashion Trends On Campus
Fashion Trends On Campusjsr15
 
системы создания и публикации презентаций
системы создания и публикации презентацийсистемы создания и публикации презентаций
системы создания и публикации презентацийkatrindakatrin
 
Секретное руководство по созданию товаров и услуг, за которыми выстроится кил...
Секретное руководство по созданию товаров и услуг, за которыми выстроится кил...Секретное руководство по созданию товаров и услуг, за которыми выстроится кил...
Секретное руководство по созданию товаров и услуг, за которыми выстроится кил...internet27
 
Secondary and special good practice - innovating safely
Secondary and special good practice - innovating safelySecondary and special good practice - innovating safely
Secondary and special good practice - innovating safelyDan Bowen
 

Destacado (15)

Amigo De Verdad Gardfield
Amigo De Verdad GardfieldAmigo De Verdad Gardfield
Amigo De Verdad Gardfield
 
TVSMILES - NOAH13 London
TVSMILES - NOAH13 LondonTVSMILES - NOAH13 London
TVSMILES - NOAH13 London
 
WilliamBlumeTheBusinessProject
WilliamBlumeTheBusinessProjectWilliamBlumeTheBusinessProject
WilliamBlumeTheBusinessProject
 
Jornadas cao 2016
Jornadas cao 2016Jornadas cao 2016
Jornadas cao 2016
 
Furqan_Saqi (2)
Furqan_Saqi (2)Furqan_Saqi (2)
Furqan_Saqi (2)
 
Antigo Fórum de Teresina - Arquitetura Eclética
Antigo Fórum de Teresina - Arquitetura EcléticaAntigo Fórum de Teresina - Arquitetura Eclética
Antigo Fórum de Teresina - Arquitetura Eclética
 
EDC_2131006_BipolarJunctionTransistor
EDC_2131006_BipolarJunctionTransistorEDC_2131006_BipolarJunctionTransistor
EDC_2131006_BipolarJunctionTransistor
 
Walking on Troubled Water
Walking on Troubled WaterWalking on Troubled Water
Walking on Troubled Water
 
Repowering American Innovation
Repowering American InnovationRepowering American Innovation
Repowering American Innovation
 
Presentatie handson hsmai congres juni 13
Presentatie handson hsmai congres juni 13Presentatie handson hsmai congres juni 13
Presentatie handson hsmai congres juni 13
 
Fashion Trends On Campus
Fashion Trends On CampusFashion Trends On Campus
Fashion Trends On Campus
 
системы создания и публикации презентаций
системы создания и публикации презентацийсистемы создания и публикации презентаций
системы создания и публикации презентаций
 
Секретное руководство по созданию товаров и услуг, за которыми выстроится кил...
Секретное руководство по созданию товаров и услуг, за которыми выстроится кил...Секретное руководство по созданию товаров и услуг, за которыми выстроится кил...
Секретное руководство по созданию товаров и услуг, за которыми выстроится кил...
 
день 4 й
день 4 йдень 4 й
день 4 й
 
Secondary and special good practice - innovating safely
Secondary and special good practice - innovating safelySecondary and special good practice - innovating safely
Secondary and special good practice - innovating safely
 

Ähnlich wie Bo2004

DNS for Developers - NDC Oslo 2016
DNS for Developers - NDC Oslo 2016DNS for Developers - NDC Oslo 2016
DNS for Developers - NDC Oslo 2016Maarten Balliauw
 
DNS for Developers - ConFoo Montreal
DNS for Developers - ConFoo MontrealDNS for Developers - ConFoo Montreal
DNS for Developers - ConFoo MontrealMaarten Balliauw
 
DNS Over HTTPS by Michael Casadevall
DNS Over HTTPS by Michael CasadevallDNS Over HTTPS by Michael Casadevall
DNS Over HTTPS by Michael CasadevallGlenn McKnight
 
DNS Exfiltration and Out-of-bound attacks
DNS Exfiltration and Out-of-bound attacksDNS Exfiltration and Out-of-bound attacks
DNS Exfiltration and Out-of-bound attacksNitesh Shilpkar
 
06 coms 525 tcpip - dhcp and dns
06   coms 525 tcpip - dhcp and dns06   coms 525 tcpip - dhcp and dns
06 coms 525 tcpip - dhcp and dnsPalanivel Kuppusamy
 
Computer Networks Module 1 - part 2.pdf
Computer Networks Module 1 - part 2.pdfComputer Networks Module 1 - part 2.pdf
Computer Networks Module 1 - part 2.pdfShanthalaKV
 
Minieri CS6262 Project Poster
Minieri CS6262 Project PosterMinieri CS6262 Project Poster
Minieri CS6262 Project PosterJoe Minieri
 
NZNOG 2020: DOH
NZNOG 2020: DOHNZNOG 2020: DOH
NZNOG 2020: DOHAPNIC
 
DEF CON 27 - GERALD DOUSSOT AND ROGER MEYER - state of dns rebinding attack ...
DEF CON 27 - GERALD DOUSSOT  AND ROGER MEYER - state of dns rebinding attack ...DEF CON 27 - GERALD DOUSSOT  AND ROGER MEYER - state of dns rebinding attack ...
DEF CON 27 - GERALD DOUSSOT AND ROGER MEYER - state of dns rebinding attack ...Felipe Prado
 
Domain Name System (DNS) Fundamentals
Domain Name System (DNS) FundamentalsDomain Name System (DNS) Fundamentals
Domain Name System (DNS) FundamentalsWebSniffer
 
Passive DNS Collection -- the 'dnstap' approach, by Paul Vixie [APNIC 38 / AP...
Passive DNS Collection -- the 'dnstap' approach, by Paul Vixie [APNIC 38 / AP...Passive DNS Collection -- the 'dnstap' approach, by Paul Vixie [APNIC 38 / AP...
Passive DNS Collection -- the 'dnstap' approach, by Paul Vixie [APNIC 38 / AP...APNIC
 

Ähnlich wie Bo2004 (20)

DNS for Developers - NDC Oslo 2016
DNS for Developers - NDC Oslo 2016DNS for Developers - NDC Oslo 2016
DNS for Developers - NDC Oslo 2016
 
DNS for Developers - ConFoo Montreal
DNS for Developers - ConFoo MontrealDNS for Developers - ConFoo Montreal
DNS for Developers - ConFoo Montreal
 
DNS Over HTTPS by Michael Casadevall
DNS Over HTTPS by Michael CasadevallDNS Over HTTPS by Michael Casadevall
DNS Over HTTPS by Michael Casadevall
 
ION Bucharest - Deploying DNSSEC
ION Bucharest - Deploying DNSSECION Bucharest - Deploying DNSSEC
ION Bucharest - Deploying DNSSEC
 
Introduction
IntroductionIntroduction
Introduction
 
DNS Exfiltration and Out-of-bound attacks
DNS Exfiltration and Out-of-bound attacksDNS Exfiltration and Out-of-bound attacks
DNS Exfiltration and Out-of-bound attacks
 
06 coms 525 tcpip - dhcp and dns
06   coms 525 tcpip - dhcp and dns06   coms 525 tcpip - dhcp and dns
06 coms 525 tcpip - dhcp and dns
 
DHCP
DHCPDHCP
DHCP
 
Computer Networks Module 1 - part 2.pdf
Computer Networks Module 1 - part 2.pdfComputer Networks Module 1 - part 2.pdf
Computer Networks Module 1 - part 2.pdf
 
2_Chapter 2_DNS.pptx
2_Chapter 2_DNS.pptx2_Chapter 2_DNS.pptx
2_Chapter 2_DNS.pptx
 
DNS - MCSE 2019
DNS - MCSE 2019DNS - MCSE 2019
DNS - MCSE 2019
 
Minieri CS6262 Project Poster
Minieri CS6262 Project PosterMinieri CS6262 Project Poster
Minieri CS6262 Project Poster
 
NZNOG 2020: DOH
NZNOG 2020: DOHNZNOG 2020: DOH
NZNOG 2020: DOH
 
DEF CON 27 - GERALD DOUSSOT AND ROGER MEYER - state of dns rebinding attack ...
DEF CON 27 - GERALD DOUSSOT  AND ROGER MEYER - state of dns rebinding attack ...DEF CON 27 - GERALD DOUSSOT  AND ROGER MEYER - state of dns rebinding attack ...
DEF CON 27 - GERALD DOUSSOT AND ROGER MEYER - state of dns rebinding attack ...
 
Domain Name System (DNS) Fundamentals
Domain Name System (DNS) FundamentalsDomain Name System (DNS) Fundamentals
Domain Name System (DNS) Fundamentals
 
Domain Name System(ppt)
Domain Name System(ppt)Domain Name System(ppt)
Domain Name System(ppt)
 
Networking
NetworkingNetworking
Networking
 
6 networking
6 networking6 networking
6 networking
 
Session_2.ppt
Session_2.pptSession_2.ppt
Session_2.ppt
 
Passive DNS Collection -- the 'dnstap' approach, by Paul Vixie [APNIC 38 / AP...
Passive DNS Collection -- the 'dnstap' approach, by Paul Vixie [APNIC 38 / AP...Passive DNS Collection -- the 'dnstap' approach, by Paul Vixie [APNIC 38 / AP...
Passive DNS Collection -- the 'dnstap' approach, by Paul Vixie [APNIC 38 / AP...
 

Mehr von Dan Kaminsky

Bugs Aren't Random
Bugs Aren't RandomBugs Aren't Random
Bugs Aren't RandomDan Kaminsky
 
Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Dan Kaminsky
 
Move Fast and Fix Things
Move Fast and Fix ThingsMove Fast and Fix Things
Move Fast and Fix ThingsDan Kaminsky
 
A Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryA Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryDan Kaminsky
 
I Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetI Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetDan Kaminsky
 
Yet Another Dan Kaminsky Talk (Black Ops 2014)
Yet Another Dan Kaminsky Talk (Black Ops 2014)Yet Another Dan Kaminsky Talk (Black Ops 2014)
Yet Another Dan Kaminsky Talk (Black Ops 2014)Dan Kaminsky
 
Chicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenChicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenDan Kaminsky
 
Some Thoughts On Bitcoin
Some Thoughts On BitcoinSome Thoughts On Bitcoin
Some Thoughts On BitcoinDan Kaminsky
 
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Dan Kaminsky
 
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingShowing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingDan Kaminsky
 
Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Dan Kaminsky
 
232 md5-considered-harmful-slides
232 md5-considered-harmful-slides232 md5-considered-harmful-slides
232 md5-considered-harmful-slidesDan Kaminsky
 
Dmk sb2010 web_defense
Dmk sb2010 web_defenseDmk sb2010 web_defense
Dmk sb2010 web_defenseDan Kaminsky
 
Bh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsBh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsDan Kaminsky
 

Mehr von Dan Kaminsky (20)

Bugs Aren't Random
Bugs Aren't RandomBugs Aren't Random
Bugs Aren't Random
 
Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017Wo defensive trickery_13mar2017
Wo defensive trickery_13mar2017
 
Move Fast and Fix Things
Move Fast and Fix ThingsMove Fast and Fix Things
Move Fast and Fix Things
 
A Technical Dive into Defensive Trickery
A Technical Dive into Defensive TrickeryA Technical Dive into Defensive Trickery
A Technical Dive into Defensive Trickery
 
Chicken
ChickenChicken
Chicken
 
I Want These * Bugs Off My * Internet
I Want These * Bugs Off My * InternetI Want These * Bugs Off My * Internet
I Want These * Bugs Off My * Internet
 
Yet Another Dan Kaminsky Talk (Black Ops 2014)
Yet Another Dan Kaminsky Talk (Black Ops 2014)Yet Another Dan Kaminsky Talk (Black Ops 2014)
Yet Another Dan Kaminsky Talk (Black Ops 2014)
 
Chicken Chicken Chicken Chicken
Chicken Chicken Chicken ChickenChicken Chicken Chicken Chicken
Chicken Chicken Chicken Chicken
 
Black ops 2012
Black ops 2012Black ops 2012
Black ops 2012
 
Some Thoughts On Bitcoin
Some Thoughts On BitcoinSome Thoughts On Bitcoin
Some Thoughts On Bitcoin
 
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)Black Ops of TCP/IP 2011 (Black Hat USA 2011)
Black Ops of TCP/IP 2011 (Black Hat USA 2011)
 
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of TryingShowing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
Showing How Security Has (And Hasn't) Improved, After Ten Years Of Trying
 
Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)Domain Key Infrastructure (From Black Hat USA)
Domain Key Infrastructure (From Black Hat USA)
 
Interpolique
InterpoliqueInterpolique
Interpolique
 
232 md5-considered-harmful-slides
232 md5-considered-harmful-slides232 md5-considered-harmful-slides
232 md5-considered-harmful-slides
 
Confidence web
Confidence webConfidence web
Confidence web
 
Dmk sb2010 web_defense
Dmk sb2010 web_defenseDmk sb2010 web_defense
Dmk sb2010 web_defense
 
Interpolique
InterpoliqueInterpolique
Interpolique
 
Black opspki 2
Black opspki 2Black opspki 2
Black opspki 2
 
Bh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackopsBh us-02-kaminsky-blackops
Bh us-02-kaminsky-blackops
 

Bo2004

  • 1. Black Ops 2004 @ LayerOne Dan Kaminsky
  • 2. Introduction Who am I?  Senior Security Consultant, Avaya Enterprise Security Practice  Author of “Paketto Keiretsu”, a collection of advanced TCP/IP manipulation tools  Speaker at Black Hat Briefings  Black Ops of TCP/IP series  Gateway Cryptography w/ OpenSSH  Protocol Geek
  • 3. What’s On The Plate for Today? /* char descrip[256] = “You’ll see”; */
  • 4. What is DNS DNS: Domain Name System  Mechanism for translating human-readable names into machine routable addresses “Like 411 for the Internet”  As 411 usually but not always yields simple phone numbers, DNS usually but not always yields IP addresses  A: Given name, find IP  MX: Given name, find Mail  PTR: Given IP, find name  TXT: Given name, find “stuff”
  • 5. “Useful” Traits of DNS (Very Very Abridged) Hierarchical  .com says where to find addresses in .doxpara.com, and .doxpara.com says where to find addresses in foo.doxpara.com Recursive vs. Iterative Lookups  Iterative Lookup: Ask a server a question, it tells you where to go to find out the answer  Recursive Lookup: Ask a server, it goes out and finds out the answer for you, and tells you  It queries the hierarchy…which you may control Caching  Responses contain a TTL – Time To Live – within which future requests don’t require another message to be sent
  • 6. Primary Research Areas for DNS Exploitation  1999-2000 were filled with exploits against BIND, the most common DNS server  Not terribly vulnerable now DNS Spoofing  Returning false addresses = hijack people’s outgoing net connections DNS Tunneling
  • 7. DNS Tunneling [1] How  Client -> Server  What’s the information for BATCH-OF-ENCODED- DATA.doxpara.com?  Server -> Client  The information? Why, it’s “HERES-THAT-DATA-YOU- WERE-LOOKING-FOR” Why?  DNS is extremely permeable – it will route through architectures where often nothing else will  Captive portals for Wireless Internet  “More” ;-)
  • 8. Starting Simple: DNS Tunneling [0] Who?  NSTX most popular  Creates a “virtual network device” that routes IP (actually, Ethernet frames) over DNS  Linux Only  Rumors of various botnets / malware using DNS as a covert channel
  • 9. DNS Tunneling[2]: Entering Userspace Starting “Simple”  NSTX requires kernel cooperation to get at IP  Lets make something that doesn’t require the kernel, but still allows remote networking  Remote Networking: “I’m on this network, but all my traffic is routed through that network over there – preferably securely”  Normally done with VPNs (also kernel level)  SSH Dynamic Forwarding allows secure remote networking over a single TCP port (Poor Man’s VPN)  So lets start with SSH over DNS
  • 10. DNS Tunneling[3]: Problems DNS is not TCP  TCP moves bytestreams, DNS moves records  Blocks of data  TCP lets either side speak first, while in DNS, the server can only talk if the client asks something  TCP is 8 bit clean, while DNS can only move a limited set of characters in each direction (Base64)  This seems so familiar…
  • 11. DNS Tunneling[4]: Mini-HTTP The semantics of DNS are surprisingly similar to those of HTTP Many tools have been written with the “lets tunnel everything over HTTP” methodology because it gets through firewalls easier (see first point) Those tools that support small message sizes (like GNU httptunnel) can be quickly modified to use DNS as an alternate transport  Must use separate streams for upstream vs. downstream, since downstream reflects all data from upstream (similar to HTTP, but on a per packet basis) But DNS has a feature HTTP servers don’t…
  • 12. DNS Tunneling[5]: Recursive Redux Recursive lookup: Ask another host to iterate through the hierarchy to find your answer  Why, it’s as if every web server was also a web proxy...  Simple Trick: Bounce your traffic off any DNS server (like, for instance, a captive portal’s DNS for free WiFi)  But there’s better…
  • 13. DNS Tunneling[6]: Set em up… Some DNS servers are dual hosted  External interface is sending names out  Internal interface is bringing names in  Two interfaces because one is behind the firewall and one is in front Subdomain Delegation  It is possible to claim that “foo.doxpara.com” is hosted at an arbitrary name server with an arbitrary IP address  …even if you yourself can’t route to that address…  …someone else can…
  • 14. DNS Tunneling[7]: …and knock em down Incoming SSH to Protected Networks via Recursive DNS  1. Wrap SSHD in dns-ized httptunnel  2. Request that remote DNS daemon look up a subdomain of a domain you control. Tell that DNS it’ll find the answer it seeks at the internal server with the SSHD-DNS.  3. SSHD-DNS receives forwarded request, responds to it. Remote DNS daemon forwards that response back to you.  4. Continue with normal SSH over DNS semantics. Note: This is actually a bad thing
  • 15. Changing the Gameplan Most tricks require a DNS server under the requester’s control  The client and the final server conspire against the recursive server in the middle But what if there is no DNS server under the client’s control?  What can a client do with queries alone?  Can two clients communicate with eachother through a DNS server?
  • 16. DNS Cache Modulation[0] DNS stores the results of queries, along with a TTL (Time To Live)  Well known Information Leakage: If someone else looked up a site first, the TTL is different.  Example:  root@bsd:~# dig @129.210.8.1 mail.layerone.info; sleep 100; dig @129.210.8.1 mail.layerone.info  First Reply: mail.layerone.info. 4H IN A 66.33.213.202  Second Reply: mail.layerone.info. 3h58m19s IN A 66.33.213.202  Destructive – If nobody else made a particular query, then the probe becomes the standard bearer for max seconds.  Not well known: Two hosts can communicate with eachother through the state change introduced by a particular query  Possibly the lowest bandwidth channel available, at 1 bit per query
  • 17. DNS Cache Modulation[1] Temporal Bit Mapping  The sender requests a low traffic, preferably low TTL name from the server.  The receiver requests the same name, and sees it at some decremented TTL value. It thus knows at approximately what time the cache entry will expire.  Within some “sender window” after expiration, the sender either does (1) or does not (0) issue another request for the same name  Within some “receiver window”, the receiver checks the name after the window expiration. IF the TTL is max, then the bit was 0. IF the TTL is not max, then the bit was 1.  Capacity = 1 bit per Max TTL period (slowwww)
  • 18. DNS Cache Modulation[2] “Spatial Bit Mapping”  Spread the load across multiple names, probably each retrieved off a wildcard server  Wildcard – 00000001.doxpara.com still resolves  Bits are “set” within a setting window  Bits are destructively read within a reading window, using an identical TTL strategy.  Next series of bits may be sent when TTL of last sent request by the sender expires.  Capacity = 1 bit per name per Max TTL period (slow)
  • 19. DNS Cache Modulation[3] Bidirectionality  Simply use two separate channels, or timeshare one channel  It’s just a shared medium Adaptability  Anything that can be changed by one and seen by another can be used to send data  Web Counters  IP ID counters in IP Stacks  Whether a car was washed  “Did it increment or not? Were there sharp spikes between 6:01 and 6:02?”  “You can always send a bit” – can we send more?
  • 20. History of DNS Storage Long history of storing data in DNS  Means  TXT records  AXFR Zone Transfer (can be arbitrarily large, but doesn’t work from almost any restricted network since it’s TCP)  Downsides  Very inefficient – packet size (w/o AXFR) is locked below 512 bytes, and you only get a little more than half of the packet filled with a payload  DNS can get really slow, especially under load  Upsides  Everyone has a DNS server, and it caches
  • 21. KDNS[0] What do we have?  A Very Dynamic DNS server  A Desire to Send More Than A Bit  Fine, I’ll go host a name on a server  A challenge to send something new What do we get?
  • 22. KDNS[1] Voice over DNS – TXT w/ Streaming Audio Speex codec supports Voice compression at ~2kbps (best public codec)  Ends up (with headers) being about 356 bytes/second  We can traffic 356 bytes per second through even extremely slow DNS servers Power to the Caching People  Use a TTL of WINDOW seconds (~20s)  All listeners behind the same DNS server will split the same “stream”
  • 23. KDNS[2] Server HOWTO  <timestamp>.server.com  TTL=WINDOW  TXT (or MX) = 1.0s or 0.5s of audio  latest.server.com  CNAME to <window>.<timestamp>.server.com  TTL=0  This may be broken by resolvers with minimum TTL requirements (implemented to fight Dynamic DNS server loads)
  • 24. KDNS[3] Client HOWTO  Retrieve latest.server.com, learn <window>.<timestamp>.server.com  Retrieve audio samples from <timestamp- window>.server.com up through <timestamp>.server.com  Prefer to start playing at a packet that has spent some time decrementing in the cache – binary search for oldest sample within the window  Add random jitter for the start sample – this way, everyone’s at a different point in the stream, and if the “lead looker” drops, someone else will be next up to be first in line
  • 25. KDNS[4] Alternate Implementation: Proxy-Friendly HTTP Streaming  Abandon DNS entirely; simply distribute 3-10s chunks of audio over HTTP and let proxy servers share them out  Requires client cooperation, and greatly increases latency, but solves the (bandwidth) problem that proxies don’t cache streams  Proxies don’t support TTLs, though – a server side script would need to monitor that  HTTP of course supports much higher bandwidth!
  • 26. Crossroads Everything we’ve done with DNS is slow and low bandwidth?  DNS servers store little data, and may return it relatively slowly Can’t we go any faster? Is there no DNS “solution” with capacity?  Many hands make light work  There are many many many DNS servers  And almost all of them cache.
  • 27. DomainCast[0] The basic concept  Normal DNS operation: Talk to your own server; it retrieves data on demand from the official server upstream  Domaincast DNS operation: Talk to servers with different blocks preloaded into their cache; each of those blocks refers to the location of other cached blocks. Upstream server has actually preloaded data (through directed queries) into all of the servers.  This is possible. This is not necessarily a good idea. Don’t try this at home.
  • 28. DomainCast[1] Sidestepping Limited Resources  Capacity  20K/server = ~80 records @ 256bytes  700MB = Knoppix, a full Linux distribution  700MB / 20K = 35,000 servers required  Number of DNS servers detected in a single class A: +140,000 (More on this later)  Speed  1Kb/s * 35,000 = 35MB/s  Would require upload of ~3.5MB/s  ~50% packet / formatting overhead = 17MB/s  Not going to achieve peak bandwidth (it’d shred reliability) – but not going to get 1k/s either
  • 29. DomainCast[2] Packet Formats  Request: <offset>.<filename>.server.com  Reply – Either TXT or MX  TXT – Base64 Representation of Fixed Size Struct (describing file size, byte offset, data, and other servers)  MX – Can also represent data as mail server addresses  Requires dots every 64 characters  Responses are reordered randomly – must sort by “precedence”  Some headaches with extra information being “volunteered”  MX may stress BIND servers more (triggers search tree)
  • 30. DomainCast[3] Basic Mode – All packets retrieved from master server, provide linked list pointers to same host  0.file.server.com = first block, here for second  256.file.server.com = second block, here for third  Etc.
  • 31. Domaincast[4]: Population via Brute Force Simplest Approach:  Find enough servers that recurse  DNS servers don’t move rapidly -> Scan amortizes well across many populations  Plan out who’s going to store which blocks  Populate servers with data, references to planned other servers  Easy to validate caching, though not easy to fix a broken reference  Can populate out of order – 64 populating, verifying streams
  • 32. Domaincast[5][0]: Reverse Serial Propagation The problem: To populate the first server, you need the address of the second server. But to populate the second, you need the addr of the third. What to do? Answer: Populate backwards. The last server points nowhere. The second to last points to the last. The third to last points to the second to last.  Multi-server – last server can equal “last server group”.  Server groups may be larger than packet capacity to list servers – just include a random set
  • 33. Domaincast[5][1]: Reverse Serial Propagation Can be quickly and statelessly deployed  Scan networks with generic recursive probe  For each incoming request seeking to service the probe, return whatever(TTL=0) and probe with an actual block request  If a block request comes back from the recurser, populate the server  If the population packet drops, the upstream should retransmit  Move back through the file after each server group fills up  Can be much slower to populate!
  • 34. Large Scale DNS Scanning[0] Modding the scanrand codebase…  Basic scanrand concept: One half spews traffic, the other sees what comes back. Little to no communication between the two halves = fast!  Scanrand manages TCP; statelessness is a bit of a novelty to it. DNS is built on UDP, raw packet manipulation isn’t even necessary (it was useful, though).  Reflection: Stateless operation depends on sending packets out and forgetting, only to have the necessary data returned back in the response packet  TCP barely reflects back 48 bits worth of data  DNS reflects back whatever was in the query = thousands of bits if you want ‘em!  Crypto signatures can be embedded in the reflection
  • 35. Large Scale DNS Scanning[1] Floodable DNS Queries implemented by miname  Is anyone there, recursive or not?  Many hosts that don’t support recursion will at least provide a “NXDOMAIN”, but not all will  We need a generic query that appears to almost always work  1.0.0.127.in-addr.arpa PTR -> 127.0.0.1 = localhost  Everyone is localhost   Will you recurse back to me?  BIG_COOKIE.server.com
  • 36. Large Scale DNS Scanning[2] Returned Results  Direct: You requested, they responded.  Forward Lookup: You requested, they requested back to you, you responded.  Often not the server that you asked that asks you  Reverse Lookup: You requested…and someone wondered who you were asking such questions
  • 37. Large Scale DNS Scanning[3] More on Reverse Auditing  Not being too secretive  root@bsd:~# host 64.81.64.164  164.64.81.64.IN-ADDR.ARPA domain name pointer mail.dan.at.doxpara.com  L0pht’s Antisniff project – locate sniffers and IDS’s by watching reverse DNS traffic on the LAN  Miname w/ Co-opted Servers: Watch sniffers and IDS’s across the entire internet  TTL=0 on PTR replies means they continually look you up when you pass by them  Hard, but not impossible, to associate reverse lookup with node scanned to attract  Temporally associated w/ scan  Multiple scans, out of order, should provide required correlation  Traceroutes may help too – we know who’s looking us up
  • 38. Rendering The Flood How much data could it be?  [root@fire root]# ls -l dns.log -rw-r--r-- 1 root root 360215644 May 28 12:42 dns.log How are we going to visualize this?  3D space – could use the tools we used to visualize the complexity of arbitrary data
  • 40. 3D Viz[0] 3D Space provides a potentially valuable perspective on extremely complex datasets Volume tools have gotten more mature  Volsuite: Free, Open Source, Full Color, Cross Platform, Fast  Video games = New Absurdly High Speed Graphics Chipsets
  • 41. 3D Viz[1] “Volumetric” – Texture Based  Stacks of transparent photos  Arbitrary complexity data – it all gets blurred in  Limits positional accuracy  Totally static – you can’t animate the population “Particle” – Vertex Based  Dots! Dots everywhere!  Arbitrary positional accuracy – floating point coordinates can be zoomed into  Limits number of particles  Very easy to make dynamic  Dynamic particles can express higher dimensional data
  • 42. 3D Viz[2] Dimensions  Static: XYZ, Color  Dynamic  Shape  Direction  Color Shift  Trajectory Shift  Brightness / “Flare”  Surprising aspect of dynamics: Motion away from source point appears to bolster memory / perception of that point
  • 43. 3D Viz[3] Under Development – As yet unnamed Generic 3D Plotter  Coordinates are streamed in, perhaps with information about how to render each particle  A more generic version of the “Spinning Cube of Potential Doom”  Parallel development 