Category: Uncategorized

Try as I might to contact Wells Fargo regarding an almighty issue of issues regarding their authentication logic.

Probably equally secure

So let’s say your password that you set purposely to “SuperDuperPassword” or better yet your actual password if you use Wells Fargo you can try this at home. Back to the monologue; so you want a secure password for your account? Who wouldn’t? So you add lower cases and upper case into the mix. Try to make your password all sexy and shit right?

Now imagine this, none of the complexity that you created means anything. Login to your account with all upper case, lower case or mixed case it doesn’t matter.

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.

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.

Well, I finally tackled the whole HTTPS SSL Certificate thing and boy did I mess up the first go around 😀

Accidentally purchased and generated a SSL certificate for the wrong domain name and didn’t even realize until I went to go assign it and it’s screaming at me about name mismatch.

Welp, moment of discovery… a while later… Finally got the other certificate revoked and removed, got the new cert in place and enabled some fancy browser side security headers (not a challenge to break please).

Anyways, I’ll be posting another post here in a minute announcing a new forum I’ve setup for folks.

This is a write up I did, after reading the white paper and investigating the workings of speculative execution. I was genuinely interested in how it all played out and how this seems like the year for exploits and vulns.

I’m legitimately wondering if this ever did get weaponized yet. I’ve often thought about trying to implement it with BEeF as a post module of sorts as a JavaScript payload.

Also take note, that I really didn’t have the energy to try to read through Spectre even though its probably the worst one.

A non-technical synopsis of the microprocessor and kernel flaws.
Meltdown (CVE-2017-5754)

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.

MeltdownStarting 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 FLAWSuppose 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.

IMPACTConsequences 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.

The purpose of this article is to provide a repeatable means to performing cross-site scripting attacks via a SVG file. SVG, otherwise known as “scalable vector graphics” in which a XML document used to build an image.

The above code generates the following image:

However, by introducing JavaScript or HTML within the SVG, it is possible to in effect store XSS payloads that execute whenever the SVG is loaded into the page’s dynamic content.

However, let’s tweak it to add in some JavaScript and officially “weaponized” the SVG.

Which after loading the SVG within a browser results in XSS.

By simply adding a pair of script tags, an attacker can include any JavaScript functions, actions or even in a worst-case scenario remotely include a JavaScript file whenever the SVG is loaded.

In our case, we are using BeEF (Browser Exploitation Framework) to attack users of an application by including the BeEF JavaScript file within the page allows attackers to carry out attacks and get Beef Shells all from this SVG.

Take for example the following code:

With all of this in mind, seriously consider limiting or blocking SVGs from being uploaded. More often than not, developers have overlooked SVG as a potential threat vector and allow profile picture upload of malicious SVG files.

Additionally, if you are familiar with XXE attacks, this can also be used for that attack vector in some circumstances. If you aren’t already scanning uploads regardless of their extension or mime type, it might be time to change that.

Long story short, if you can pop XSS within a SVG you can do pretty much anything up to and including store malicious JS, malicious XML or malicious HTML in-line.

Excited to see how this Spectre and Meltdown patch madness will pan out, $10 says an engineer somewhere finger flubs something, then the debugger doesn’t catch it and pushes to production distribution.

Meanwhile, still waiting on meaningful exploit code beyond telling me that I’m either vulnerable or not.

In other news, will be trying to post more here. Life is hard, but add in blog stuff on top of that, work and family and you probably have a better idea of my life than I do myself.

Expect more content, I have tons written up for consuming, but need to sort through all the garbage that is my internal monologue dictating narration in them.

That and the non-stop quest to not rehash or regurgitate others works. Once its been done, there is no other point to doing it.

Discovery and the unknown are my two favorite friends, meanwhile chaos and curiosity continue to be my low key friends. We’ll explore all the closets I’ve encountered (minus NDA ones), and hopefully provide something of value to the next person.

Unless you call yourself someone’s “right hand person”, you can stop right there…