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.

Backstory:
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 RCN.net 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 RCN.net 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. proxy01.corp.rcn.net 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 helpdesk.rcn.net.

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.

Overview

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

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.


















Tuesday, December 19, 2017

CVE-2017-17759 Conarc iChannel - Unauthenticated Access/Default Webserver Misconfiguration allows for compromise of server

https://(affectedserver)/wc.dll?wwMaint~EditConfig

The customized webserver used by iChannel is based on an outdated and vulnerable version of WestWind Webserver. This page is available, unauthenticated, to a malicious attacker.

By visiting this link, the attacker can access the webserver configuration edit page. This page reveals sensitive information, allows for alteration of the webserver configuration, upload/modification of the server's configuration and can result in a Denial of Service attack by deleting the configuration.

This has been acknowledged by Conarc and they have been notified of the impact.

If your iChannel install is available publicly, this can result in complete compromise of the server, the web application and severe information leakage/DOS.

Resolution:

Conarc has been notified of this issue. Until this issue is patched, the affected installs should be removed from public access. In the case of private deployments, this page should have an ACL applied to prevent unauthenticated access to this page.


Friday, December 15, 2017

BrightSign - Multiple Vulnerablities - CVE-2017-17737, 17738, 17739

The BrightSign Digital Signage (4k242) device (Firmware 6.2.63 and below) suffers from multiple vulnerabilities.

The pages:

/network_diagnostics.html
/storage_info.html

Suffer from a Cross-Site Scripting vulnerability. The REF parameter for these pages do not sanitize user input, resulting in arbitrary execution, token theft and related attacks.



The RP parameter in STORAGE.HTML suffers from a directory traversal/information leakage weakness:
/storage.html?rp=%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2Fetc

Through parameter manipulation, the file system can be traversed, unauthenticated, allowing for leakage of information and compromise of the device.

This page also allows for unauthenticated upload of files.

/tools.html

Page allows for unauthenticated rename/manipulation of files.

When combined, these vulnerabilities allow for compromise of both end users and the device itself.

Ex. A malicious attacker can upload a malicious page of their choosing and steal credentials, host malicious content or distribute content through the device, which accepts large format SD cards.

Tuesday, October 17, 2017

Exploiting a VMWare File Lock Hole - LET'S GRAB THAT VMDK AND NTDS.DIT!

An interesting note on VMware file locks...




The VMDK file is locked by the ESX hypervisor when the host is active. Without access to the vCenter instance or SAN/NAS/Storage device directly, this is a problem.




This is a problem particularly when your target is privileged information... like the NTDS.DIT file for an Active Directory domain.




As you can probably guess, this was an issue I recently investigated and an attack that was devised from it.




VMware places a lock on the active VMDK file to prevent any sort of tampering/corruption/access issues with a live host. This is, by design, a safeguard against a number of attacks. When presented with hypervisor access (strictly on specific hosts), but the ability to administer parts of the system, this is a fairly easy issue to bypass.




In this case, I was after the NTDS.DIT file. This attack blended a number of operational security flaws and strategies to bypass active security controls.




First, with access to the hypervisor and disks, the issue is removing any restrictions by VMware to accessing the VMDK file which operates as the fixed disk for the host. Without a command line or vCenter, you aren't left with many options.



So what do you do?



Shoot the hostage.


Snapshot the host.




Snapshotting the host creates a new VMDK delta file. Essentially, for hypervisors, this becomes the "new hard disk", with the OLD, original VMDK file as the "reference disk." The new VMDK DELTA FILE is where the host goes to write/read any changes from the reference disk. The lock on the original disk is essentially "moved" to the new disk. The old disk exists as a reference and restore point.



From this point onward, you are able to clone/copy the original VMDK file as you see fit with NO restrictions from VMware.



Next, you take the original VMDK file and copy it to a new location. This allows you to spin up a NEW host with the old disk, enabling you to modify or play with the original machine. As Active Directory logs changes and syncs via DFS, you will have a copy of the schema as of whatever that period of update is set by the network administrator.



The problem now becomes "How do I get that NTDS.DIT file?"




I'm glad you asked.




This is an OLD SCHOOL trick from a LONG TIME ago.



You have the ability now to treat the DOMAIN CONTROLLER as if it's a physical host. In ye olden days, this was gold.



Spin up the newly cloned DC as an ISOLATED VM. DO NOT UNDER ANY CIRCUMSTANCES ALLOW IT TO CONNECT TO THE NETWORK OR YOU WILL DESTROY AD. Period. No questions asked. DON'T DO IT.



Spin up the new host and it will likely fail. This is good.



Load up an ISO (you can do this on another host, but windows security will be an issue for permissions.) that allows you to obtain file system access. (Hiren's is a nice choice.)



Boot the ISO on the new host with the ISO as your boot/live disk.

(Edit: Yes, I know that in certain environments, just loading up an ISO or live disk *cough*kali or a vanilla Linux*cough*  and copying the files out directly is much shorter and completely valid as an attack here. The issue at hand was an additional layer of security that made that type of attack here unfeasible and unnecessarily "loud".)





Navigate to the system drive: \windows\system32.



You will see two files of interest. CMD.EXE and UTILMAN.EXE.



UTILMAN is awesome. It's the accessibility option/menus for windows that HAPPENS to be accessible pre-login. (Windows + U or the icon in the lower left corner.)
Rename UTILMAN.EXE to something else. DON'T DELETE IT.



Make a copy of CMD.EXE (or whatever executable you want) and rename it UTILMAN.EXE.

Reboot the target into windows. You may want to try DIRECTORY SERVICES RESTORE MODE and it may only boot to that. Without network connections, the DC will likely take 30 minutes to boot, if at all.



Directory services restore mode is fantastic. Typically, you can't login to a DC as a local admin as windows keeps you from doing so, to prevent this exact type of attack.



DSR allows you to do so.



Eventually, you will boot into windows in DSR. Hotkey WINDOWS KEY + U or click the icon in the bottom left corner... VOILA! You are presented, prelogin with a command line running in the context of NT AUTHORITY / SYSTEM. This is a non-interactive, super user account.



Change the local password through this command line to one of your choosing.




Next, login locally to the AD domain controller with this and you are now the administrator of the machine.



From this point, extraction of the SYSTEM hive and NTDS.DIT is fairly simple. Copy/paste the files to a different location, reset the security descriptors and exfiltrate the data. Since you DON'T WANT TO HOOK IT UP TO THE NETWORK, an alternate drive/vmdk to copy to works... or you can simply add the VMDK as a hard drive on another host you do control.



That's it. A nice way to obtain privileged, secured system data from a host with only hypervisor access.




Enjoy.





Saturday, September 9, 2017

OpenVAS & Kali 2017 - Job for openvas-scanner.service failed because a timeout was exceeded

You probably found this through the same google searching I did. No real good answers.












"Job for openvas-scanner.service failed because a timeout was exceeded"




pico /etc/init.d/openvas-scanner
pico /etc/init.d/openvas-manager


Change the DODTIME=(integer)


Double the values.


Try again. Works for me.



Monday, October 3, 2016

Script Kiddie Network Mapper/Profiler

Here's a simple python script to quickly port scan a network (All TCP, default UDP via NMAP) and then Nikto scan common webserver ports (80, 443)

Written as a quick/rough tool for automation of simple "script kiddie" tasks.

Just the basics for now. System for scanning is passed as an argument. Can be individual or in CIDR notation.

Run this with correct arguments, grab a cup of coffee and come back in a few minutes.

#
#
#
#
#
# CODE STARTS HERE
import sys, os, platform
from netaddr import *

ip = IPNetwork(sys.argv[1])

# Quick Network Mapping Tool
#This will scan the target host without a ping, full TCP scan, all ports
def nmapfull(host):

    # NMAP Command
    nmap_str = "-sV -O -p 1-65535 -Pn"
    # NMAP
    return os.system("nmap" + " " + nmap_str + " " + str(ip))

#This will scan the target, with a ping, quick UDP scan
def nmapudp(host):


    # NMAP Command
    nmap_str = "-sU -O"

    # NMAP
    return os.system("nmap" + " " + nmap_str + " " + str(ip))

#This will nikto the host on port 80 (default http)
def nikto(host):

    # NIKTO Command
    nikto_str = "-h " + str(ip) + " -p" + " 80"

    # RUN NIKTO
    return os.system("nikto" + " " + nikto_str + " " + str(ip))

#This will nikto the host on port 443 (default https)
def niktossl(host):

    # NIKTO Command
    nikto_str = "-h " + str(ip) + " -p" + " 443"

    # RUN NIKTO
    return os.system("nikto" + " " + nikto_str + " " + str(ip))


for ip in IPSet([ip]):
      print(ip)
      print ("IP "  + str(ip) + " Results for FULL nmap")
      nmapfull(ip)
      print ("IP "  + str(ip) + " Results for UDP nmap")
      nmapudp(ip)
      print ("IP "  + str(ip) + " Results for port 80 nikto")
      nikto(ip)
      print ("IP " + str(ip) + " has been nikto scanned.")
      print ("IP " + str(ip) + " Results for port 443 nikto")
      niktossl(ip)
      print ("IP " + str(ip) + " has been nikto SSL scanned.")