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.