Abuse of DNS, ARP & application protocols

10. Abuse of DNS, ARP & application protocols

Objectives

• To consider how supplementary protocols dealing with name/ address resolution can be attacked
• Application layer - To consider insecurities in selected protocols of the application layer
  • Remote logins, Email

Address resolution

• DNS -higher level one, turning human readable domain names to IP addresses, IP address needed for routing packets. Logical addressing scheme of the machines.
• ARP – But we need a further lower level resolution protocol which turns IP addresses into physical machine addresses MAC addresses that identify specific network interfaces of hardware
• Spoofing is possible for both of these protocols – how that works and in case of DNS how we attempt to solve this
  • Fooling the DNS software to giving attacker certain address instead of the legit one for a given domain name
  • ARP – spoofing arp layer into giving attacker a selected fake MAC address for a given IP address.

Attacking DNS

• Cache poisoning – direct attack
  • E.g. is the google domain of DRC Congo in December 2011, and cache poisoning affected that resolution process. It’d be redirected to this page.
• Hijacking site’s DNS records via the registrar for that domain name
  • indirect way
    • E.g. Brazilian bank – criminal online banking sending email for 5 hours – because the attacker targeted DNS record for that bank. During that attack, the visitors going to what they thought it was the bank, was redirected to a fake one and it harvested credentials of people and installed malware
    • Three state against attack against domain name registrar that has been attacked.

DNS Cache poisoning

• The idea is that you wanna be the first one to respond to a DNS query – rather than the real response, you wanna get in there.
• But its challenging coz there’s a 16-bit transaction ID. Bc it is a random number; you only have small chance of getting that correct. And then you have to wait coz if you guess the ID wrong you are locked out
  • Reason for delay is the result will be cached – once the successful query is received, it is cached for like a minute. you need 22 days to get 50% chance to beating the DNS server
• Sounds like it’s hard, but the attacker can fire off multiple replies with diff IDs – not constrained to one guess. If they responded 100 times before the real name, there’s a high chance
• And they can make requests for multiple related domains – 1.foo.com, 2.foo.com
• Basic idea is you can improve ur chances by correctly guessing the transaction ID
  • Once uve done that, uve poisoned the DNS cache of the machine you are targeting. Now when they visit the website expecting the DNS to take you to the right website, in fact you are taken to diff IP address that the attacker controls.
• Cryptographic techniques come into rescue– fix is to securely authenticate, instead of transaction ID which is guessable.
• DNSsec – uses digital signature to authenticate DNS queries. The idea is response issued by the server will be signed and the client can check the signature to see if it’s a legit response DNS slow.
• Another approach is ‘DNS on top of HTTPs –additional issues on how the queries are encrypted, but issue is that it makes everything secret and you can’t see the DNS request, and can’t guess if its legit or not

ARP cache Poisoning

• ARP resolves IP to a MAC address – same idea of hijacking that resolution process
• How it works, is the attack has to be on the local network – they could do that by finding a vulnerable machine in the connection. – now in the right place to be interfering with the process
• What uve got is network, user, connected to the internet through a switch/hub. you are spoofing the gateway from the perspective of the user, and user from the perspective of the gateway – 2 ARP cache poisonings.
  • One to do with traffic from the user out to the internet, and other to do with stuff coming in. this is the problem of switch network that you won’t see the traffic of different machine.
• U position the ARP cache, which allows you to act as a man in the middle, as a victim and gateway to the internet and see all the traffic going back and forth.

• Limitation – you need to be on the local network

• 

Remote Access: The Bad Old Days

• Moving up to the Application layer – like http, email protocols, and protocol for remote login
• We used to use telnet or rlogin for remote login
• If you wanted to copy files from/to remote machine– rcp, rsh to execute single commands and so on
• Problem w all of this is traffic is unencrypted
• Telnet, in addition to it being unencrypted, it required the use to always supply the username and password which travel in the air without protection– if someone intercepts the traffic using two methods above, it can see the credentials and everything else that was being typed
• R tools – will recognize trusted hosts – can spoof the hosts tho although it avoids the need for
  • Only thing it does to check if it’s trusted is to lookup the DNS host and see if it’s in the trusted host file

An Aside: ‘Banner Grabbing’

• Classic use of telnet was to log into diff ports of the machine – there are certain ports representing diff services, and well-known services will be known.
• Same thing with telnet. It also has to specify the diff ports – if you do this you won’t be connecting to a telnet server which support login but it’s rather like connecting a client to the wrong server
  • E.g. telnet connected to port 22
  • SSH-1.99-OpenSSH_3.6.1p1+CAN-2004-0175
  • Look at the response that come back – telnet can connect to SSH – so will get connection mismatch. But before you do that, we get banners – tells us what service is running. Can use this to query what’s happening on the other end. information disclosure threat
• Q: What is the Security issue with the highlighted bit
  • A: you see the version numbers – then you can look at what vulnerabilities are reported for that version, and someone can try to attack that system
  • Banners are for debugging purposes!

Sniffing a telnet Session

• Client talking to a server – what we see is not the telnet running, but is a result of dsniff running, which is a packet sniffing tool. There’re limitations on whether you see traffic, so you have to be on the gateway machine to sniff the ARP traffic. But we assume it’s the case.
• Dnsniff to spy the traffic passed to the client
• Q: What do we see in that traffic? Username and pw!! Matthew and leedsutd

Fixing it: Secure Shell (SSH)

• If telnet and rlogin aren’t good, how can we protect our traffic? We typically use SSH – secure shell.
• Idea is it gives us a way to add cryptography to remote login and other r tools. For every one of the r tools there’s a secure version of it.
  • Slogin, ssh, scp protected by encryption
• Way it works is it uses public key cryptography and symmetric cipher is both used – there’s an authentication aspect of it, using public key cryptography and to exchange the symmetric key of the session.
• SSH1 & SSH2– 2 versions of protocol
  • RSA is the commonality of the two
  • SSH2 uses DSA – similar pub key algo but focuses on digital signature so is more about authentication.

How does it work?

• We need to authenticate ourselves using key pair.
• When the client connects, server provides public key and client can check it against a local db, or go to the verified certificate issuer itself.
• That pub key can be used to encrypt authentication data sent to server
• Client authentication
  1. User can login by providing a valid pw, that is encrypted using the provided server pub key
  2. Or to create ur own SSH key pair – and you can put the pub public key of that to the remote machine. And SSH will allow login if there’s a corresponding private key.
     • It’s like Gitlab!! Setting SSH, then ur allowed to login to that. Machine to that SSH if you have corresponding private key. The passphrase you need to provide Is cached so you don’t have to provide it repeatedly.

SSH Problems

• Things can go wrong in the implementation like TLS
• SSH1 had design flaws – deprecated.
• SSH2 – superior but also had its own issue – CBC vulnerability in 2008.
  • It allowed an attacker to recover plain text from the cipher text, but not very much of it. They could recover 14 bits with probability of 2 ^-14
  • When it translates into practice, it is quite a big chunk that is translated. If you got a lot of traffic, it can recover small chunk of it which can be serious enough to cause a problem

‘Man In The Middle’ Attacks

• Another issue with SSH is MITM.
• Attacker could steal credentials if they could impersonate the SSH server – and you may not notice if they forwarded everything to the real server. Might notice a slowdown tho.
• We maintain a local store of trusted pub key from previously accessed server.
  • When it first connects, ‘do you trust this server?’ – then its stored. And from that point on ur okay
• But it provides a small ‘window of opportunity’ – coz when it first asks you need to be sure that its safe
• If you use SSH to connect – you will see ‘are you sure you want to continue connecting?’ and it adds to trusted host.

Sending Email: SMTP

• One of the things we use a lot is email – in email, we got diff protocols to support sending and receiving
  • For a simple response – uses port 25
• There is no authentication!! easy spoofing of sender
• All traffic is sent as ASCII text – so you can just use telnet to just command it.
  • It doesn’t check the sender and recipient!! – Boris Johnson but it doesn’t care
• Banner leaks information – name, vendor, version
• EXPN and VRFY commands – to leak username and address

Receiving Email: POP3& IMAP

• Pop3 – sends username and pw as a plaintext – although there’s an extension to use shared secret and MD5, but extension isn’t always used.
• IMPAP – also weak in terms of authentication, and mail itself is unprotected
• No good from security standpoint

Securing Email protocols

• Use SSH! It allows us to tunnel insecure protocols over an encrypted channel.
• No good anymore - now protocols been extended to support security.

Tunnelling

• U set up ur mail client on local machine, and pop3 on mail host and it communicates with unencrypted channel. But if you encrypt it using SSH on both ends, you have an encrypted channel
• We reconfigure the mail client to talk to port 5678 0 manually configure the email client where the SSH process is listed. On the other end, goes to SSH, port 22, and it connects to port 110 of the server.
• ssh -f -N -L 5678:localhost:110 mailhost – all I need to set up a tunnel.
• But we don’t need to do this bc there are better approaches.

Better approaches

• There’s a secure version of all of this – secure version of these email protocols have S on the front and they have their own alternative ports.
• Is basically those standard email protocols that runs on top of TLS.
• But then again, we don’t do this – bc there’s ‘Opportunistic TLS’
  • Allows us to use standard port- coz above pollutes the space of port number with secure and insecure version. But instead, it allows you to switch from insecure to encrypted using “STARTTLS”- standard version to encrypted version
  • When you execute, then it triggers a TLS handshake and upgrade to secure version
• But it could go wrong!!good eg is a STRIPTLS attack.

STRIPTLS Attack

• It attacked two major ISPs in Thailand in 2014. It ran for few weeks
• There’s a transparent proxy intercepting the connection, SMTP connections, and silently removing START TLS command – it will fall back on authenticating over an unencrypted channel.
• Problem is user never sees this!! Encryption is stripped away, and id and pw can be captured by the proxy.
• Sometimes it’s done deliberately – some cisco file will strip the TLS so they can examine emails.
• That’s why if ur communicating anything sensitive, end to end encrypt, you need to encrypt the data urself!!

Trade-offs

• Whilst it’s desirable to use encrypted channel for email, but email is a common vector for malware – and ur encrypting the email you are losing the ability to examine the content and recognize that malware.

Summary

• Seen that DNS and ARP are vulnerable to spoofing
• Noted that traditional Unix tools for remote login, remote command execution and file transfer are very insecure, and that SSH provides secure drop-in replacements
• Observed that email protocols also fail to adequately protect user credentials or message content
• Learned that email can be protected in transit via SSH tunnelling, full TLS or opportunistic TLS