Format string attacks remain difficult in both software and hackademic exercises as the techniques have not improved since their discovery. This session demonstrates advanced format string attack techniques designed to automate the process from creation to compromise as well as incorporate those techniques into the Metasploit framework. The audience is encouraged to bring a basic understanding of format string attacks in order to leave the presentation with the tools necessary to never write one again.
I’ve been thinking about honeytokens a lot lately. While I’ve always been fascinated by honeypots, honeytokens are a little different spin on the same idea. A honeypot usually functions as a machine or device just begging to get hacked. It usually emulates a machine that is missing a few patches and is very poorly configured. It can even be packed with services and data to make it look like a goldmine of sensitive information. The only catch is: none of it is real. All the information is fake, and the machine is usually very well segmented from any other critical devices. The whole idea is to attract a hacker to the honeypot, then keep them there long enough to alert the security team / trigger the IDS / call the police / blacklist them.
Whats different about honeytokens is that instead of emulating machines or devices, they emulate sensitive data. Their primary function is to identify the misuse of data or the failing of internal policies. In that sense, honeytokens are much easier to setup and monitor than its pot-derived brother. A good example of a honeytoken is as follows:
Steve works for Big Bank. While he is generally happy with his job, he feels underpaid and had always been curious about what his peers make. While doing some troubleshooting on one of the database servers, he notices a database named companySalaries. He checks over his shoulder, selects the database and tries to view its contents. It throws out a generic error, he shrugs it off and continues his work.
The database record named companySalaries doesn’t contain any real data at all. Its sole purpose is to alert a group of people when it is accessed. In normal operations, Steve has never been authorized to access this database – so triggering the alerts means something fishy is going on. In this case, Steve’s curiosity got the best of him, and most likely violated all sorts of internal privacy policies.
Their use doesn’t stop at salary information. They can be used in emails, databases, Intranet pages, customer records, medical patient information, financial details, core applications, and anything else you can think of. They can emulate the presence of all sorts of data, from Social Security numbers to credit card numbers, and from sensitive office documents to insider corporate information. They are very flexible, and can be integrated into any situation that has you worried about its confidentiality.
The legal ramifications around implementing something like this can be a little muddy. Do yourself a favor and chat up some legal assistance and make sure your Acceptable Use Policy is airtight before rolling out your domain-wide honeytoken install. Much like a honeypot, honeytokens are no replacement for proactive network security. Be sure you have the fundamentals of network security in place before you start stashing these honey-soaked easter eggs all around your network.