#!/zitstif.no-ip.org/

If you have a Meraki setup that has Umbrella tied into it, and you can’t communicate properly with your *.local domain controller over the Meraki VPN, I have a potential fix for you. In my scenario, VPN clients could see the domain controllers and DC IP addresses were specified as DNS servers which would properly assigned to VPN clients. VPN clients could query DCs for external DNS names without any issues but any *.local communications or gpupdate related commands would fail. I troubleshooted it to the nth degree and discovered this fix:

Go to Security & SD-WAN, then to configure, and then to threat protection. Scroll down to the Umbrella protection section and specify your local domain name (mydomain.local) as an exception from being routed to Umbrella. Save your changes and hopefully this resolves your issue.

If you continue to have issues, double check that your VPN clients and see what DNS servers are getting assigned. Some individuals had to change the metric (hint lower the number, route print to find metrics of adapters).

There’s a saying amongst a few fellow computer security enthusiasts that I know of, that goes a little something like this, “If the attacker has physical access to the machine, the game is over.” (Or something to that extent)

This couldn’t be any further from the truth. If I were to do a permitted pentest upon a company which included physical access as part of the scope, then I would definitely test the local workstations and use one of them as a pivot point to gain further access/information.

To mitigate this attack, the administrator should ideally change the boot sequence to have the hard drive as the first device the computer boots from in the BIOS and also set the BIOS password, and have the computer case locked down, so one couldn’t clear the CMOS (it’s usually jumper 1 on the motherboard).

However, in most large facilities, administrators usually don’t take the time to do this and are usually more concerned with other types of attacks, in my opinion.

Now I will give a hypothetical scenario for a pentester that will permit him/her to do a pentest that will include physical access to this factitious facility.

Upon gaining physical access to a workstation, the pentester has a few tools with him/her. In his/her arsenal he/she has as follows:

BackTrack 4 on a USB flash drive
PLoP ( http://www.plop.at/en/bootmanager.html )
Konboot ( http://www.piotrbania.com/all/kon-boot/ )
cmospwd ( http://www.cgsecurity.org/wiki/CmosPwd )

As the pentester reboots the computer and tries to enter the BIOS, he/she is stopped by a password prompt. In the password prompt, he/she tries a few combinations including backdoor passwords that are sometimes set by manufacturers. ( http://www.uktsupport.co.uk/reference/biosp.htm )

Realizing that none of these worked, the pentester needs to then assess whether or not the administrator has locked down the boot sequence.

Out comes the flash drive and into the USB port it goes! The pentester is aware of how some motherboards will default to the USB drive as the first boot device when plugged in. (I’ve personally experienced this on a motherboard I own). However, still no luck!

With the pentester’s lock picking skills not at their best, he/she is detoured by the workstation’s case lock. It is time to him/her to revert to PLop.

PLop is one beautiful tool. It is a boot manager that you can even use on old motherboards that don’t support booting off of flash drives.

The pentester was in luck! The workstation checked the CD-ROM drive first in its boot sequence! Now the pentester can direct the victim workstation to boot off his USB drive (with Backtrack 4) via PLop.

Upon getting the prompt from Backtrack 4, the pentester is now curious about what the password was set to on the workstation.

To find this info, he/she uses cmospwd. By retrieving this password, the pentester can use this as leverage towards other devices in the network.

I’ve had luck with some motherboards using cmospwd for retrieving the password from the dump it can produce. Consequently, it’s not perfect, but it can get the job done.

I know I mentioned konboot as part of the arsenal but didn’t have the pentester use it, but I thought I’d mention it due to the fact it’s such a wonderful tool to have.

I’ll have more to come as usual and I have two programs in mind that I’m working on..

Just a quicky:

If you’re in a local area network and you’re trying to do some passive information gathering using a sniffer, here is a great way to find .local host names:

tcpdump -i wlan0 -vv 2&>1 | egrep '*.local'

What’s beautiful about this method is you can usually find people’s full names, especially if they’re using Apple devices. Along with that, you’re not probing or alerting the targets.

Also, if you’re not in range of a wifi access point and can barely see the AP, you can use this method while trying to connect (it makes this method a little less passive..), but I’ve discovered Iphone device names via this method.

And now…. back to the books. 🙂

PS: I’m going to set aside time this week to put more effort into ettersploit.