Sunday, 31 January 2016

The Way of the Developer


Recently, I’ve been reading Musashi: An Epic Novel of Samurai Era. I actually found it quite inspiring.

Though largely self-taught in his use of swordsmanship and fighting, the main character strives to constantly hone his craft and to follow what he sees as the Way of the Warrior. He learns by watching other warriors, nature, and by following teachings of Sun Tzu and later from Buddhism.

Maybe it’s because I’m also largely self-taught and learn mostly through interacting with other developers and from the code I work with every day, but this story resonated with me. As a developer, I feel like it’s important to cultivate one’s own Way of the Developer.

Thursday, 31 December 2015

2016 Goals

goals-signThis past year has been full of unexpected twists and turns but overall it’s been pretty fun.

On the professional side of things, I’ve enjoyed participating in lots of interesting private bug-bounty programs and getting more involved in learning new development languages.

By working on other software projects, though, it’s really reinforced how important it is to keep up with the latest design trends. Especially with some of the commercial code I’ve been able to work with, it seems much more heavily abstracted than I’m used to.

In the upcoming year, I’m hoping to get more hands-on experience with more the more advanced OOP styles.

Wednesday, 18 November 2015

Reinventing The Wheel

WheelIn business, it generally doesn’t make sense to reinvent the wheel. Why spend time and resources developing something that already exists commercially?

For personal development projects, though, it’s a great way to appreciate the amount of work that went into the existing solutions. Plus, it can obviously be customized to behavior however you’d like.

Lately, I’ve been working on a tool to take a domain name, suggest similar names, and then check to see if those sites are active.

The primary use will be in discovering and reporting domains being used for typosquatting or fraud. There are existing tools, like dnstwist, but I figured it might be fun to attempt something similar on my own.

My tool will allow me to define which domains I’m interested in monitoring out of the automatically-suggested list (since some are just super unlikely) and perform periodic checks against them. It’ll also grab a thumbnail image of the site (if a website for the domain exists) and maybe some meta-data… and allow me to add my own notes.

This will let me identify active domains with similar names to the ones I’m interested, but can also exclude sites I’ve identified as being legitimate. By periodically evaluating the registration data, I can also flag domains as needing reviewed. This way, if I identified as legitimate, but then a year later it changes hands, I wouldn’t want to treat it the same as the original that I originally reviewed.

I’m doing it all in my free time. Since I don’t have a whole lot of that these days, things are progressing quite slowly. Still, though… it’s fun. That’s what’s important, right?

Tuesday, 29 September 2015

Catch And Release: Barracuda WSA


While reviewing Barracuda Network’s Web Security Agent, I identified three security vulnerabilities.

Exploitation of these vulnerabilities allow the disclosure and alteration of local WSA settings, shutting down of the WSA service, and local elevation of privilege allowing execution as SYSTEM.

These issues were initially discovered within of WSA. They were responsibly disclosed in early June 2015 and were fully resolved at the end of September, as part of their 4.4.1 release.


I’m purposely leaving this details out of this section for now. Developers interested in evaluating the security posture of their applications will hopefully get something out of it, but there’s no reason to rush with the details until users have had a chance to update away from the vulnerable versions.


Throughout the entire process, I couldn’t have asked for a better contact at Barracuda than Justin Kelly. He and the rest of the BNSEC team did a great job keeping me in the loop. Justin provided the perfect blend of professionalism and casualness. It was clear that they were taking things seriously on their end, but I never got the feeling that they were going to go Oracle-style with it with legal threats for picking apart their product a bit. I’m looking forward to working with them more in the future.

Sunday, 27 September 2015

DLL Hijacking


I’ve been having a lot of fun recently with DLL Hijacking. It’s been around for quite a few years now and the ‘best practices’ recommended by Microsoft are to fully-qualify the DLL paths.

Quite a lot of applications that don’t do this, however…

Thankfully, the Windows OS has gotten quite a bit smarter over the years when it comes to this sort of thing. They’ve altered the priority of paths being searched, which significantly cut down on the impact to most applications. Additionally, some of their core DLL files are set up in such a way that even if an explicit path is given, it will ignore it in favor of where it knows the ‘good’ copy is.

The MSDN documentation provides some pretty useful information on the way searching happens.

  1. If a DLL with the same module name is already loaded in memory, the system checks only for redirection and a manifest before resolving to the loaded DLL, no matter which directory it is in. The system does not search for the DLL.
  2. If the DLL is on the list of known DLLs for the version of Windows on which the application is running, the system uses its copy of the known DLL (and the known DLL’s dependent DLLs, if any) instead of searching for the DLL. For a list of known DLLs on the current system, see the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.
  3. If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

The first and last items were interesting to me.

But, really, it’s even more simple if the application you’re looking to hijack is installed outside of the usual “Program Files” or “Program Files (x86)” directories. At least when an application is installed in one of those folders, local admin rights are needed to write to them. But if the program is installed to its own folder, plenty of fun can be had…

One such example I’ve had success with in my home environment is BGInfo utility, from Sysinternals. It’s a popular utility with system administrators and generally seems to get installed in C:\bginfo\ (which doesn’t have any built-in protections, by default). It looks like I wasn’t the only one who found it to be a worthwhile target

This allows a custom DLL to be added to the directory (by a tech-savy user, malware, an attacker, etc.) without any special rights being needed.

Using procmon, also by Sysinternals, I was able to see that one of the libraries BGInfo uses is version.dll

I found the legitimate file, made my own DLL with the same name and public methods. All requests made to it get sent over to the appropriate routine in the legitimate version.dll file (so the program continues to work as expected). I also added my own custom payload into the DLL’s initial execution. That payload gets run under the context of the account executing BGInfo.exe

As a proof-of-concept, I simply added a message box. If this had been a real exploit, however, there’s a lot more potential for abuse…

At most organizations, BGInfo gets executed upon login by all users… which includes local administrators and potentially domain administrators. Just let that sink in for a bit… Here’s code provided by a non-admin, malware, etc. and it’s getting automatically executed by an admin. Ouch!

Granted, it’s a bit of a waiting game… but it can allow for some rather easy elevation of privileges… Especially if logins by local administrators happen pretty frequently.

What about if domain admins don’t do local logins? No problem. Use the initial DLL hijacking to execute code for a local admin. From there, additional hijacking for programs commonly used by domain admins (via Run As…) can be done without a whole lot of additional effort.

This can also lead to pass-the-hash attacks, spreading similar attacks to other machines on the network, etc.

All in all… it’s bad news for an enterprise.

Even if no admins (local or otherwise) execute the DLL-hijacked application, it’s still going to have persistent code that launches whenever the program does (which is login, in the case of BGInfo). Probably not ideal.

If there isn’t an obviously-exploitable program in an unprotected directory, though… what then? I’ve had a surprisingly amount of success dropping hijacked DLLs into the current user’s AppData temp directory. Using my same tainted version.dll from earlier, I was able to trigger my ‘rogue code’ during a Notepad++ update. Pretty handy.

The moral of the story is… fully qualify your DLL paths. And even if you do, be aware of potential DLL hijacking through the dependencies of the DLLs you are fully-qualifying. If it can be abused… it probably will be.

Next on my list of techniques to get more familiar with is DLL Injection. Seems like it’ll be a lot of fun, too.