• Table of contents

Basics of Exploitation

Why exploitation

• Helps us in false positive reduction& elimination
• Acts as a proof that a certain vulnerability exists which can be leveraged in a given way
• Showing that a vulnerability is indeed a risk

Risks of exploitation

• Crashing of services and systems
• Data exposure
• Getting out of scope

Miscellaneous

• We should always target systems which represent a large portion of the user base
• It shouldn't be like they're upgrading some systems before a test takes place because in that case, the system will not represent normal behaviour
• Ideally, it's the computer of an employee which was recently terminated

Types of exploitation techniques

Most of the exploits fall under Service side exploit, client side exploit and local privilege escalation.

<aside> 👉 Service Side Exploit

</aside>

A vulnerable service listening across the network is exploited by an attacker by sending some maliciously crafted packets with the capability to exploit it

<aside> 👉 Client-side exploits

</aside>

• It involves waiting for a client application to access a malicious file by tricking them or something and then delivering the exploit as part of the response via an attacker controlled server. Example: browsers, media players, runtime environments etc.
• Make sure when sending the malicious attachment, not to send it to a whole lot of people otherwise they'll forward it to someone else and there's a possibility to go out of scope. What we should do instead is split the project into two:
  • Sending malicious links and checking the number of clicks we get but don't exploit it at all (gives us safety)
  • With a collaborator on the other side clicking on our link, exploiting (determine what's possible based on phase 1 clicks)

Physical access attacks

Basics

• By far the easiest way to get access to a system
• If we're able to physically compromise a machine, it's game over for the enterprise which we can do easily by purchasing stolen hardware of the enterprise.

Kon-boot

• The best and the easiest way to go.
• When our system boots, it goes through different types of memory protection techniques
• In older versions of Microsoft Windows, it used to have Real Mode Memory, which the memory of an application could access other applications' memory directly and there was no segmentation at all.
• In the later versions, Microsoft introduced Protected Mode Memory, which created segmentation between processes, and if any process would try to transcend that wall, a segmentation fault would occur and crash that program.
• But even today, our systems while being in the initial stages of booting up, is still in the Real Mode Memory, and Kon-Boot exploits exactly that, and it modifies the libraries by which we can log in with any password to the system successfully, do our stuff and turn off, next time, it'd log in with the original password only.

Lanturtle + Responder

We plug the Lanturtle to the system even when it's not logged in (hibernation state), and it opens up a new Ethernet interface and starts grabbing all the beacon packets with LLMNR to grab that authentication and can trick the system in authenticating to the Lanturtle and we can use Responder to capture those credentials.

LAN Turtle

Inception

• Useful for attacking systems with some hard drive encryption, but not used for bypassing the encryption, we just use an arbitrary password for logging in. All we need to do is to plug in our connector in a PC in locked or Hibernated state and Inception will unlock the PC for us.
• It works by attacking Direct Memory Access (DMA)
• According to the RFCs, the DMA controller, and any of these devices connected to our computer, have unrestricted access to the lower 4-gigs of the memory. So we can go in to that area of the memory, and modify the stuff that deals with passwords so that we're able to log in w/o any issue.

https://github.com/carmaa/inception

Rubber Ducky / Bash Bunny

• They are Human Interface Devices (HIDS), look like a USB drive, but they’re not, after being plugged in, they register as a keyboard.
• This automated keyboard types very quickly
• We can program that keyboard to do a wide variety of different things on the target computer system.
• We can use services like DuckToolKit to generate payload in a relatively easy manner.

Duck ToolKit

Defence

• Using full disk encryption (can reduce the threat surface)
• Training users to completely power down systems when not using them, not hibernating them.
• Restricting access to USB ports
• Disabling USB booting and password protecting the BIOS (Protection against Kon-boot)
• Disabling LLMNR (protection against Lanturtle+Responder)

BGP hijacking

What is it?

• This attack is possible when we have compromised an ISP level entity or can inject routes so that we can broadcast malicious routes and reroute traffic through out network viz. poisoning the routing tables all around the world
• These attacks are very hard to detect because they simply look like router misconfiguration issues.

Mitigation

• Having an idea of how the normal traceroute looks like
• Subscribing to online services which notify us if there are any changes in the ASN
• User awareness such as browser errors, dropped connections.

Attacks against DNS

DNS Spoofing

<aside> 👉 Triggered Cache Poisoning (Eugene Kashpureff)

</aside>

• It was made possible because DNS servers were accepting arbitrary information from the additional section of the DNS response.
• This attack is all about poisoning the cache of the resolver provided by the ISP
• The attacker would make an A record DNS request for a different domain (www.alternic.net) which is different from internic.net. The authoritative NS of which is running modified code, that instead of sending a standard response (that is the A record for the alternic.net), it would also send out the A record of internic.net in the additional section of the DNS response to the ISP recursive resolver, which would store all this information in the cache (including the bogus record), making the cache poisoned

The mitigation for this attack was resolvers now started looking at the DNS response to check for information that had nothing to do with the query that was made, and such information was ignored.

<aside> 👉 Message ID guessing and query prediction (Amit Klein)

</aside>

• In the DNS header, there is a message ID field which acts as a unique identifier (16-bits), and the request and response are supposed to have the same message ID.

<aside> 👉 Kaminsky NS Poisoning (Dan Kaminsky)

</aside>

• Researchers found a way to spoof DNS server caches even if the messageID was truly random

<aside> 👉 MITM

</aside>

• Since the DNS works over plaintext by default, the traffic could be sniffed and altered easily.