Author: Gh0st

Testing against the ClickShare devices identified that the SSID is hidden. This can be overcome by de-authenticating a specific MAC address as the access point. This is accomplished by sending a broadcast over the air, mimicking the AP requesting the client disconnect. After this happens, it takes a few seconds for the client to re-authenticate to the AP with a beacon frame that includes the SSID of the AP then commences the 4-way handshake for association. During this it was possible to obtain the WPA handshake for cracking offline, however this is not needed in this case.

After identifying the hidden SSID as “CLICKSHARE-LX-102” and performing research into default credentials for authentication it was found that the WPA2 Personal PSK is default to “clickshare”. After connecting to the affected device, it appears that outbound access is not enabled, however a DHCP server leases an IP address for each device (base station, wireless dongle, and clients directly connected). Using this it was possible to identify the base station at 192.168.2.1. This host was serving multiple avenues of access, including (but not limited to) HTTP, RTSP, SSH, HTTP Proxy, SMB, LDAP.

After opening a web browser session to http://192.168.2.1 the web application requests authentication via BASIC AUTH. It was possible to authenticate as the web admin for the application with the default credentials of “admin:admin”. This allowed the attacker to download the configuration file parsed in XML and attempts to recover the root password for SSH access were performed.

Attempts to attack the client attached to the dongle were ultimately unsuccessful due to the USB dongle acting as a pass-through with no direct OS/Device communication directly to the AP. This effectively isolates machines from the unsecured LAN. In one case it was possible to perform an availability attack by sending a raw RTSP PLAY command via port 49153 using telnet. This caused the base station to believe that something is broadcasting, however even after closing the terminal it still believes a session is in place and is unable to display anything until either the session is terminated, or the device is rebooted.

ClickShare Vulnerability
References:
http://seclists.org/bugtraq/2016/Nov/49
https://www.barco.com/en/support/clickshare%20csm-1/knowledge-base/KB1514

 

Now take into consideration that the minimum password length is 6 and max is 14, certain special characters disallowed, and not case sensitive… honestly without any sort of lockout you could easily brute force probably a quarter of their customer’s accounts.

TLDR; Wells Fargo login does not check case sensitivity for passwords. If you care to read on for more technical information and theory behind some of these assertions and assumptions you’ll find that below.

***Interest Rising***

All of this begs a pretty interesting question regarding how these credentials are handled on the backend…

Suppose I set my password to SuperDuperSecurePassword (Thats hoping they didn’t set to all lower or uppercase at first set). Now picture your password being stored on the backend in a super secure manner, generally you’d want to hash and salt to store it so users can login. Hashes are exact matches of a certain string or value, there are ways to force a collision in some instances but that is in a attacker scenario, not a banking app.

Alright back onto it; the following are hashed values of various formats of this super secure password we made based on our original password.

***Case Sensitivity Test***

SuperDuperPassword – Our original password
ED1170E378F9D2204CB0EE0678E6EAFA – MD5
F67B8C584323A9C12DD0469E3CA0E1C18A24944E – SHA1
E0B9072ACCFA63F4D754CDD0D2753F8BA8B387ECECE625AEAD1E6D9873DED463 – SHA256

superduperpassword – all lower case
3F0F04576E1BC3ACF916BFE3E63C075F – MD5
50B0FF56A91F64D21C8A7FFD2E3FF7A8B2C184AE – SHA1
2EF0ECE59A893120840BCCE18264C9A88EF4F6F80695FC9D472A389770FB2FF4 – SHA256

SUPERDUPERPASSWORD – all upper case
F8FC15E5771FEEA832BF5614388F8201 – MD5
F0204A6BE2D28B317818F7655127A58334D3C31A – SHA1
1A79FD55DACEEB24AE7B11E946B8174C40E83634D7DF11F5CBB25D6BD300EE5D – SHA256

Note: All these password strings in this scenario would be accepted by the application without question.

Now given that the web application allows passwords to be case insensitive we can establish that there is no way the password being sent is being matched by hash (which says all sorts of scary things about the backend) and is instead being looked up possibly by plain text.

Another theory of mine is that all passwords are set as either all upper or lowercase. After which the hash is generated by that string in a controlled environment and is then stored. Then at each login regardless of case, all passwords are made either all upper or lowercase and then the hash is generated and then queried in the database.

Realistically the above is more assumption based on observations and assertions, however the fact remains that somewhere in the logic between the database and the web app passwords are not case sensitive in any manner.

 

You might be hearing about these things in the news, or social media, or even your tech savvy friends. Meltdown this, Spectre that, meanwhile the scale of this flaw appears to be affecting nearly every device manufactured within the past decade. What’s more is the level of confusion upon first disclosure, seemingly it was only Intel affected by the flaws within it’s processors microcode, however throughout the day and the days that followed Spectre was introduced which pulled AMD, ARM, and Qualcomm microprocessors into the fray.

Fast forward the clock to today; as the world watches and waits hoping that this nightmare can be patched. Rumors and working code and theory continue to swirl about regarding mitigations, performance drops, and exploitability. Reviewing all the documentation surrounding the issue, it seems there is one clear answer in sight…  Patches are coming, and in a hurry.

As developers of applications, operating systems and microprocessor microcode set to the monumental task of patching, we can appreciate this massive cause for alarm.

Meltdown
Starting with Meltdown, this was the first in the series of flaws within Intel’s (Possibly AMD, ARM, Qualcomm) processor microcode in which an instruction within the processor known as “out-of-order” execution. This flaw resides entirely on the out-of-order execution to essentially break-out of the “userland” process’s mapped memory to reading kernel memory. This method previous to the incoming patches, could bypass all protections of the host machine, include ASLR, anti-virus, kernel protections, as well as the CPU “privileged check bit”. The privileged check bit is what effectively set kernel memory access.

At a high-level Meltdown’s flaw can be summarized as the ability for userland applications to read all mappable memory contents, including kernel protected addressed memory, however I still suggest giving the technical papers a review. When performing “out-of-order” execution the CPU will attempt to predict and execute, but not commit to actual memory or registers. This in effect allows rapid processing of data due to the processor attempting to prefetch and execute the dependency free instructions without actually performing a commit to memory. While parallel computing performance were increased, it added the fatal flaw…

Meltdown – THE FLAW
Suppose I developed an application or binary that’s sole purpose was to be executed. I don’t care about what level of OS permission I have, nor do I care about what software protections are in place. At execution the application will force an exception within its execution sequence (Idk… divide by zero, doesn’t matter just hit the OS exception handler).

The instructions that follow on are still problematically executed in advance and its resulting data is stored within the microprocessor’s cache, as well as the memory registers, but never commit. This exception is trapped by the exception handler that locks the kernel down and terminates the application. The issue from this is that follow-on code without any dependencies, normally cannot access memory beyond it’s applications bounds, however and more interestingly is that all prefetched executions are performed as if the “CPU Privileged Check Bit” was set to true, effectively executing the instructions and reading kernel addressed memory then transmitting via side-channel attacks such as “Flush+Reload” in time-based attacks.

IMPACT
Consequences from this are limited to what is contained within memory, however this goes beyond your typical workstation. Meltdown can also cross the hyper visor isolation and read into the physical memory. Most impacted are data centers, virtualization servers, and share web hosting. All it would take is one malicious actor to dump the entire server’s physical memory, which more likely than not secrets from other shared virtual servers.

Full memory disclosures are possible with this flaw.

Potential performance impacts from removing the out-of-order execution are speculative from anywhere at no impact, to upwards of up to 30% degradation of performance.

########
Situation
########

We all understand that WAFs are in place to identify and block malicious requests before the reach the application, so in effect I need to figure out exactly what makes it tick or how to make it tick for us. To that regard the development of this came after exhaustive research into UrlScan and trying to see if anyone had run across this in the professional or unethical realm. Well, guess you can figure out how well that went.

Anyways… I’ve identified the IIS module “UrlScan” running on a IIS6 machine (Note this can be IIS 7.5, 6, 5, etc.), I’ve identified that the application is filtering certain characters, but I’m stuck because whatever malicious requests I send get dropped or filtered by UrlScan anyways.

########
Eureka!
########
So after perusing developer forums, Microsoft technical documentation, and various SQLmap documentation and tamper methods I had learned that appending %00 (Null Byte) can be performed by the tamper script “appendnullbyte”. This however refused to work, and the UrlScan module picked it up right away. So what was I supposed to do? Well apparently UrlScan doesn’t know how to handle or what to do when the prefix is the nullbyte, and as far as I’m aware there are no SQLmap tamper scripts that would perform this bypass.

So after formatting the sqlmap command with the real value of a parameter I know that this page exists and has dynamic content depending on the “users” integer value

Original Unmodified
http://somesite.com/blog?users=3389

I quickly learn that the appendnullbyte tamper script only modifys the payload like this (note this is just generic payload)

http://somesite.com/blog?users=3389%00′ WAITFOR DELAY ‘0:0:10′–

So after analyzing the responses from the application it seemed like it wouldn’t take it at all… However, not all is lost and after performing more research into the matter the solution became apparent after some random dev was complaining about UrlScan filter rule of basically crashing their application. So what I can extrapolate from that is that is a null value (obvious), but more so than that I can deduce that is not only not interpreted by UrlScan, but its completely overlooked because of the null value where it expects something.

Imagine if you will, you are an application looking for a value of anything greater than 0, but then you encounter 0. Would you simply stop interpreting it because to you there is nothing there? Well if you said yes, your in the same boat as UrlScan’s logic apparently.

########
The Attack
########

So I’ve come to the conclusion that UrlScan expects some value to interpret or inspect whether it be in the Url, Url parameter, or POST body. I’ve also come to understand that if the value is %00 or Null. UrlScan simply ignores it on the basis that there is nothing to inspect, thus giving us the path towards carnage.

So here I am, at the end of the road… Will it work or not?

http://somesite.com/blog?users=3389%00’ WAITFOR DELAY ‘0:0:10′–

IT WORKS! This little null value gave me the ability to perform SQL injection where SQL had failed time and time before.

This also allowed XSS to any arbitrary parameter I wanted…

http://somesite.com/blog?foobar=foo%00’><script>alert(“XSS”)</script>

REMEMBER NULL should be PERCENT ZERO ZERO after the valid data, but before the actual payload.

########
Conclusion
########

In the end I’ve learned the following…

1. UrlScan’s logic is flawed in the manner of interpreting null values – Expects 1, but gets 0 and does not continue inspection
2. allows us to bypass UrlScan’s logic to perform XSS and SQL injection where it would normally fail
3. filtering within UrlScan breaks applications for whatever reason
4. SQLmap does not have a tamper script with which to bypass UrlScan, only has the ability to append to end of payload where instead requires it be prepended to the payload