Friday, November 9, 2018

DNS issues at ISP Scale... who doesn't love a little internal/DMZ IP & Metadata Leakage

I don't like to publicly disclose in this manner... but I'm frankly tired of banging my head against the wall with RCN.

I accidentally discovered a number of issues with RCN's DNS servers. After *multiple attempts* to alert their engineering team and security folks to this issue, I've been told it"s "by design", they have *no issue with public disclosure*, etc. I.E. "You don't know what you're talking about." el oh el.

So, here we are.

This is, more than anything, "day one' footprinting and DNS recon... essentially novice hacking/pentesting.

1.You can perform a zone transfer of through client equipment.
After running a few DNS tools inside of a network, I discovered due to a slight configuration error, that RCN allows you to Zone Transfer RCN.NET through their equipment. I have no idea if this works *outside* of their equpiment/services, but you can do so with ease. During this little expedition, I found a snippet of internal non-routables in the database that was transferred.
RCN says they're "limited" and nothing to worry about. Yes... being able to zone transfer their DNS Zone is "no big deal."

2. They did not setup split horizon DNS on the zone, allowing for farming of internal/DMZ non-routable IPs, discovery of services/metadata on structure and a whole lot of other information through PUBLIC DNS queries.

No, not a joke. You can look for yourself!

If you're a novice to DNS security, this is where it gets interesting.

Since the internal IP address range is leaking (10.x.x.x) through queries, you can essentially brute force a map of their entire DNS zone.. and in turn their internal network.

Ex. resolves to 10 dot 156 dot 1 dot 25 (You can dig/nslookup/resolve this yourself)

What does that mean? I've effectively determined where a network proxy is *internally*, so if you can compromise the network, you know one of the first things to aim at or avoid.

Even better, queries like jabber.corp will resolve to 10 dot 156 dot 11 dot 15. So now, I know they run a piece of possibly vulnerable software, I know where to find it, I know that I can spoof or otherwise use that as a pivot point.

If you're paying attention so far, you probably noticed that CORP zone in there as well. I'm *pretty sure* this is their corporate network as queries like this are resolving quite a few internal IP addresses.

There are a number of other "interesting" subdomains.. like NOC, CABLE, DEV, etc. You can easily farm them for more metadata and information.

Throw enough wordlists at it and you'll start noticing "themes" like greek/norse gods, spaceballs movie references, etc. Want to get the IP of their helpdesk? Try

Needless to say, this is a *HUGE* hole and metadata/recon mapping 101. I confirmed *multiple times* that RCN doesn't see this as an issue and they have no problem with public disclosure.

BONUS: The potential for this to seriously impact their client networks is there as well. Misconfigured internal DNS resolvers and servers will essentially "blackhole" traffic. Ex. If your DNS is appending/resolving queries (Say your internal HELPDESK server), and you forgot to fix that, your traffic is being shunted to a non-existent, non-routable.

tl;dr? It's a nice lesson in basic DNS security.

Friday, January 5, 2018

Extremely Evil Encryption - Tactics for advanced encryption protections.


One of the more advanced tactics for encryption, particularly when the subject wants to throw some complexity/difficulty into the mix is the use of multiple factor authentication/encryption.

Typical encryption systems use passwords and/or certificates for encryption. One of the weaknesses in this strategy is that these can be guessed or obtained in relatively simple ways.

Passwords are a relative novelty these days.. at least in the sense that a vast majority of people use them insecurely or fail to properly manage/use them correctly. Passwords (particularly cognitive ones) can be a pain to crack when properly used. Hash extraction and hybrid attacks can significantly reduce time in this area.

Passwords shouldn't be considered secure by themselves. Combining them with other methods significantly improve their viability and security.

Salting passwords is a good start. Significantly difficult salting increases time, but once again... passwords are merely a time/resources tradeoff. They're still crackable, it just takes more time.

There are a few strategies to sufficiently deter or otherwise protect that encrypted data. I'm going to go over two particularly nefarious ones.


Keyfiles are files that can be used to aid in encryption/decryption. Without a dissertation on this subject, just think of them as an additional "password." They're key materials that are "added" in to the encryption process as an additional control.

Keyfiles can be anything. Common ones are pictures, documents, etc. As securing your data requires storage of that file, this makes it an easier proposition for the attacker. If I can find it, I can try it. A general rule for password cracking/attacking is "the more complex it is, the higher likelihood that it's being stored insecurely and unencrypted, just in case."

Where do I get one?

Hiding in plain sight is a great tactic, particularly when you can virtually guarantee your file will be overlooked.

Forensic examiners are trained to look for anomalies. They're also trained to heavily filter things that appear irrelevant or unresponsive. System files are frequently discarded or filtered out because they clutter up your view.

Enter system files

System files, particularly ones that do not frequently change are a great candidate. You can virtually guarantee that some of these files will remain static over a long period of time. Additionally, the fact that the key file is on MANY computers and widely available in an emergency, they make a great alternative.

This is the difference between "lab" and "practical." In the lab, using a file like this is trivial. In the lab, you have unlimited time and materials. In practical terms, most examiners are over-worked. They miss things. "No one would ever do this." or "I have xxxx files to review.. key locked encryption is very difficult to crack and I wouldn't know where to start." The process of breaking this is tedious. They just don't have the time to invest.

For the person who wants to "stay secure", the management of this key is easy. Memorize the version number, what file you used and grab the matching distribution. It won't show up in most forensic suites and if you do it right, you can avoid the forensic footprints you leave behind.. or at least reduce them. Better yet, the keyfile is sitting out there in a jam.

Bad guys also filter out irrelevant files. If I'm inside a system, I'm on a clock. Throwing up a hail mary like this takes time.. plus you still need the original password. System files are nearly universally filtered out or discarded. Once again, doing it right.. you can make it look like a normal system file access. They need to stay quiet, not draw attention and exfiltrate the data for further attacks. If you're using a system file to encrypt, they may not figure it out. They're looking in the wrong place.

Granted, it's not perfect, but it significantly increases the time and resources needed. The process of cracking in this manner is extremely tedious and time consuming.

You can alter or play with things to make this a little more difficult as well. Using a hex editor or performing minor, manual file changes that you know about can also work as a good tactic. This will change the file hash and set off some alarms. The idea is to stay stealthy and not leave footprints.

Text Files

One of the interesting things about text files is that they don't contain file headers. One of the hiccups that you encounter is file hash analysis/comparison or obvious alterations/accesses of files. A text file is just raw text.

Applying this concept to keyfiles will drive an attacker crazy. It also leaves few traces and can sufficiently obfuscate or disguise your intent. Another interesting facet is that you can recreate this file anytime, anywhere and quickly. If you lose the original key materials, you just have to ensure it matches the original.

So, how do you go about it?

Glad you asked!

Password encrypt your data and use a text file as a key file.

Memorize the text you entered or the sourcing of it. (Doing this on your computer will leave obvious trails either in your file system, allocation table, journal or internet history. Be smart.)

For example, type out a long sentence or use innocuous looking text. A passage from a book, your grocery list, a bunch of code phrases.

Use this as your keyfile and immediately scrub it afterwards. If you need to look at your encrypted materials again, simply recreate from scratch. You've eliminated errors/alterations, scrubbed any evidence that you used it and gave the bad guy an entire filesystem (devoid of the actual keyfile) to crack.

Granted, in a "lab" or with sufficient resources, this is still crackable. In a practical sense, it's exceedingly difficult. You've given someone millions of files to try ALONG WITH A PASSWORD. This is effectively impossible to nearly every attacker (short of a nation-state or excellent cryptographer.)

There are a number of complications to this. If the file is small, on a windows system, it will end up being a resident file. It can end up in the journal, shadow volume or even in file slack. Making this file more than 1k can fix some of these issues. If you overwrite, make sure you're looking at all places it could potentially show up. I won't give up the forensics side of this and exactly how this can occur.

(This is not a posting on how to commit computer crime and hide your tracks.)

You can extend this out to include cloud based files or common pages. Internet archives, innocuous online content and other sources can provide this as well. HTML files work well, just make sure it's retrievable and static. Once again, remember that this can show up in your file system and history.

Making the file content appear innocuous or trivial is key if you can't remove all traces. Done the right way, it's nearly impossible. As always, practice good opsec.

Following these steps can really muck this process up for an attacker. There are a number of other novel ways to do this. I'll probably expound upon this in the future.