Development Geek Tue, 31 May 2016 23:45:47 +0000 en-US hourly 1 Apps Script Tue, 31 May 2016 23:45:47 +0000

Continue Reading]]> GoogleAppsScriptI’ve been using Google’s Apps Script to work on a side project of mine, during my free time at home (which has slowly diminished quite a bit lately).

It’s actually pretty cool. I started with the Quickstart Guide for Android and after a lot of trial-and-error and visits to StackOverflow, I have a pretty workable bit of code.

It’s a very niche application, but I liked getting more exposure with Android development. I had only done some very basic Hello World type apps on there before, so it was a good experience. That being said… I remembered just how much I have been spoiled by the .NET framework. I’m sure there are some nuances to it that I would quickly get used to if I worked in it more, but as it was… well… I’m glad it’s over for a bit ;)

Similarly, there were some aspects to Apps Script that I really didn’t like. One example of that was when I had accidentally removed the OAuth credentials needed for the web-based development client. I could run the script through my Android app, but I wasn’t able to use the web interface to execute or debug the script. Super annoying. Would’ve been great if there was some child-proofing in place to make it very difficult to remove those credentials. Or at least make it clear what happened and how to fix it. I ended up just having to blow away my original project and make a new one. Pointed my app at the new script id and was good-to-go, but it was a very frustrating hour or two — largely due to a general “something is wrong” error message.

Anyhow, once I’m done with it, I’ll post some screenshots and sample code.

]]> 0
Click It or Ticket — For The Web Sun, 01 May 2016 02:42:01 +0000

Continue Reading]]> buckle_upBy now, everyone is probably familiar with the “Click it or ticket” campaign, by the National Highway Traffic Safety Administration, with slogans like “Buckle up. It’s the law.”

We need something like that for the web…

It’s crazy how often I run across rather large sites not using HTTPS to protect sensitive data. Most recently, I was on the website of a rather popular vision care company, who is famous for the… crafting of lenses… if you know what I mean… The credentials were served by a page over HTTP and then passed to HTTPS for the actual account management portion. Not good…

Even though the actual account interactions are all happening within their HTTP-based web app, the initial login/registration was on an HTTP page. A simple man-in-the-middle attack would let you inject whatever extra content you want into that main page. At that point, harvesting the login credentials for yourself is quite simple. Though the site is fairly basic and (annoyingly, to me as a customer) doesn’t even offer basic features like checking the status of pending orders, there is still enough there for it to — at the very least — fall under the umbrella of HIPAA.

Thankfully, I won’t need to include screenshots demonstrating how this can be abused… The company in question (and its also-popular sister company) has now moved the website to full HTTPS. That’s good. But there are still countless sites out there that — for whatever reason — still don’t seem to see the need in making the switch to HTTPS. I don’t get it.

At this point, there’s almost no reason not to switch. Thanks to efforts like Let’s Encrypt, it’s now super-easy and free to get a certificate for your site. It’s a no-brainer, really. I just wish there was a better way of getting sites on board without having to resort to HTTP-shaming…

]]> 0
Sheet’s Getting Real Fri, 01 Apr 2016 00:20:33 +0000

Continue Reading]]> excelFor the past few years, all of my finances have been managed through spreadsheets. Before I spend even one cent of my paycheck, I have every last bit alloted into various categories. As I spend, I update the budget. I know it sounds like a lot of work, but it pretty much manages itself, really.

As some of you might know already, I like to automate, well, just about everything. Anything that can be offloaded to a scheduled job or whatever will free up extra resources for me to devote to other — more enjoyable — tasks.

My latest goal is to do some integration with Google Sheets, a bit of coding, and a cheap wifi-enabled digital picture frame.

The idea is to display an image of the spreadsheet, for quick and easy reference, in the picture frame. And then I would also include a “Last Modified” date and maybe a color-coded visual indicator to show when I am overdue on updating my budget.

If I am able to get that working, I would then get super-ambitious and try to also integrate with my bank, since I utilize my current balance in my budgets to always ensure I haven’t missed any transactions.

I know this project has limited appeal to most folks, but… Who cares? It should be fun.

]]> 0
Barcodes Are Input, Too… Mon, 14 Mar 2016 22:17:56 +0000

Continue Reading]]> barcodeLately I’ve been collecting barcodes. Not the ones off of cereal boxes, soda bottles, or that sort of thing… I’m not a weirdo! ;) But I have been collecting the store-generated barcodes from grocery stores, gas stations, etc. It’s interesting to see how what does or doesn’t get encoded and trying to think of ways to abuse it.

At one location — a grocery store — I noticed their barcodes encode a somewhat generic department/category identifier, followed by a price, and then a Luhn check-digit. Very simple. So, of course, I began wondering how easy it would be to take advantage of this. Barcode swapping is obviously nothing new. I just think it’s kind of neat that with just a tiny change to a few lines of the barcode, something can go from $8.79 to $3.79…

Since I obviously don’t want to go to jail for defrauding a store, though, I probably wouldn’t ever try such a thing. Or, if I did, it would be more along the lines of changing the price from $3.79 to $3.80, just to serve as a proof of concept. Does it still count as fraud if I pay them more…? ( #NotALawyer )

Think of how much trust is put into, say, membership IDs, identity bracelets at hospitals, etc. If it scans, it must be legitimate, right? And are they just checking for a valid-looking barcode and logging it somewhere or is it actually doing look-ups in a database?

There real fun, though is with sending unexpected input. After all, barcodes are typically just a quick and fast replacement for hand-keying values on a keyboard… So what happens if my coupon, membership card, etc. gets scanned and instead of a numeric-only barcode, I’ve encoded the message “KevinWasHere”? Or maybe encode some SQL-Injection commands in there? What if the encoded price is changed from 3.79 to -3.79…?

I would assume that most POS systems have safeguards in place to limit access to the system via traditional means. Maybe it’s all just a touch-screen and no physical keyboard. That might help stop a cashier from using the register to check Facebook, for example, but who needs a keyboard when you’ve got a barcode scanner…? What happens if the barcode scanner is tricked into sending the Escape key? Even if the barcode scanner is programmed in a way that would generally make abusing it difficult, it’s very common for the barcode scanners themselves to be programmed and reprogrammed purely by scanning certain barcoded commands in a certain order. If someone gets access to your company’s “price checker” kiosk, what damage could be done?

None of this stuff is worth jail time, of course. People should only consider messing around with this sort of thing if you have legitimate access to a system and want to ensure proper input validation is being enforced for barcode scans.

That being said, there’s nothing stopping you from using apps on your phone or whatever to scan barcodes given to you on receipts, confirmations, etc. and getting a better idea for what makes them tick. Does it have your account number, DOB, or other potentially sensitive information encoded? How else would you know unless you check?

]]> 0
Client Side Validation Mon, 29 Feb 2016 23:55:22 +0000

Continue Reading]]> Trust No OneIt cracks me up when I stumble upon an application that trusts anything coming from the user. Especially when that user is me :)

If given the opportunity, my browser will happily send your application whatever I tell it to. It’s up to you to actually make sure I’m not lying…

If I’m making calls to a webservice that only admins would be calling from you app, make sure I’m an admin before performing the action… Or instead of relying on client-side javascript to calculate the order’s total, for example, maybe do that on the backend instead…

Remember devs…. Trust No One.

]]> 0
The Way of the Developer Sun, 31 Jan 2016 04:15:09 +0000

Continue Reading]]> samurai

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.

]]> 0
2016 Goals Fri, 01 Jan 2016 01:46:03 +0000

Continue Reading]]> 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.

]]> 0
Reinventing The Wheel Thu, 19 Nov 2015 03:20:10 +0000

Continue Reading]]> 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?

]]> 0
Catch And Release: Barracuda WSA Tue, 29 Sep 2015 22:30:58 +0000

Continue Reading]]> fish*** EXECUTIVE SUMMARY ***

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. [UPDATE: As of 03/16/2016, details are now included.]

The premise was simple — get around WSA.

There weren’t any obvious results on Google, exploit-db, etc. for known flaws, so I was on my own.

Interacting with the system tray icon for WSA didn’t reveal a whole lot. I noticed that some actions (like Sync or Ping Service Hosts) seemed to briefly turn WSA off and then back on. It was only for a few seconds at most, though. I needed more.

I found the installation location for WSA, hoping it might have some really obvious weaknesses, but nothing really jumped out at me. There was a configuration tool. I decided to start with that.

Some of the applications, including the configuration tool were .NET assemblies. That meant I would be able to utilize ILSpy to see what’s going on behind the scenes, assuming the code hadn’t been obfuscated. Amazingly enough, it wasn’t. The decompiled code was nice and readable.

Immediately, I spotted something. The configuration tool was comparing the password entered by the user matched the value from its settings. Score! If the application was reading the password, that meant I could too.

Loading up the configuration tool and then Visual Studio, both with elevated rights, I was able to attach to the configuration tool’s process. This way, when I tried submitting a password to the tool, I was able to see the password it was being compared against. I then re-ran the configuration tool, entered the password I had just found, and was in. I now had the ability to view and change settings.

It was a start… but requiring admin rights isn’t exactly a ‘bypass’. I wanted to see just how far I could take it.

Thus, the first vulnerability was discovered…

WSA service has decryptable config that is readable by local users (BNSEC-6054)

Using ILSpy, I was able to find the encrypted .INI file that WSA kept all of the settings in. I took a brief look at the library it used, pwe.dll, to figure out how it was encrypting/decrypting the file’s contents. It wasn’t a .NET assembly, so my progress with that didn’t get very far. Thankfully, I realized there was an even easier way…I could just call pwe.dll directly, the same way the WSA executables did.

As a first attempt, I read the file directly through some proof-of-concept code in C#, called the library, and got back a string with all of the settings. Awesome.

Of primary interest, of course, was the configuration password. Given how often users/organizations reuse their passwords, knowing the WSA password could potentially give an attacker leverage against other systems or applications.

Having a list of whitelisted applications was also handy. That provided my first way around WSA. If ‘example.exe’ was whitelisted, I could simply rename my browser, malicious code, or whatever to match that name and WSA wouldn’t try to filter or monitor it. Knowing the IP ranges and domains excluded from filtering could be advantageous, too.

Now that I had a way around WSA if I wanted, I decided to make it harder on myself… Rather than just skirting around the filter, I wanted to see if I could actually mess with it.

That led to my second vulnerability finding….

WSA service allows for arbitrary local reconfiguration at net.tcp:// (BNSEC-6053, later absorbed into BNSEC-6147)

ILSpy made things incredibly easy. The service had a listener on and there didn’t seem to be any authentication required. The WSAMonitor app, which runs in the system tray, provided all of the information I needed to take advantage of the listener.

I wrote a bit more code and called net.tcp:// The service stopped. Or I guess I should say that the filtering stopped. The windows service was still running. I ultimately had to verify that the stop occurred by looking at log entries in the WSA.log file. I also was able to verify it through a website provided by Barracuda that shows whether or not WSA is filtering traffic. The agent’s icon in the system tray remained unchanged, though, as if it was still connected. This meant WSA could be disabled without the user or an admin noticing.

I also eventually wrote calls to GetSettings and SetSettings, allowing me to more easily read and alter the local WSA settings. Any changes would be reset by the next policy sync, but it gave enough of a window to make the changes I wanted. Changing the password was fun, but I also realized that changing how often service hosts get evaluated helped alleviate some of the issues I had with the program. Setting the interval to -1 disabled the automatic pinging of the hosts, which normally was happening every five minutes.

As much fun as I had trying to find ways around WSA, I knew that if I could find these methods, the ‘bad guys’ could, too.

Though Barracuda has a pretty nice bug bounty program, through BugCrowd, apparently WSA isn’t within its scope. Ultimately, I ended up submitting the issue to CERT’s CVE system and also sent the details via encrypted emails to the Barracuda security team.

A few days after my submission, I took one last look at the WSA code, looking for anything I might have missed.

That’s when I discovered the third vulnerability…

WSA local EoP to SYSTEM via net.tcp:// (BNSEC-6147)

This one was really straight-forward. I think I had glossed by it initially because I was simply focused on evading WSA, rather than exploiting it.

The danger of this routine is that it was too trusting. It accepted a filename and arguments and would execute the process as the service (which runs as SYSTEM). Not good.

As soon as I found it, I reported it the same way as the others. Barracuda was quick to acknowledge the issue and provided a reasonable timeline that it would get fixed.

The fix for this was simple enough. Just remove all of the parameters, so calling Update can only do one thing — run the update.


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.

]]> 0
DLL Hijacking Sun, 27 Sep 2015 19:54:21 +0000

Continue Reading]]> Procmon_BGInfo

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.

]]> 0