0xdabbad00

Developing Solutions

Sun, 31 May 2015 22:00:00 -0600

For the past decade I've been a "software developer". But what I really do is develop solutions, which often happen to involve writing some code, but sometimes it doesn't. This post is about advice I used to give to new hires that were fresh out of college or were summer interns.

Code Romance

I decided to write about this after reading "Why Don't We Learn from History?" by B. H. Liddel Hart (a great book), when I read the following passage (emphasis mine) about the Duke of Wellington, who had defeated Napolean:

"It was because he saw the value of peace that he became so unbeatable in war. For he kept the end in view, instead of falling in love with the means. Unlike Napolean, he was not infected by the romance of war, which generates illusions and self-deceptions. That was how Napolean had failed and Wellington prevailed."

We've all heard the phrase "If all you have is a hammer, everything looks like a nail." But carpenters don't romanticize about hammering. Software developers do romanticize about writing code though. We think writing lines of code shows that we did something. We've somewhat moved beyond counting lines of code as a way to measure productivity, but you shouldn't think in terms of code at all.

Software developers ultimately create solutions. That can mean fixing a bug, adding a feature, improving scalability, or many other things, but ultimately you are solving a problem. The merit of your solution has nothing to do with how hard it was for you to do. Usually it's the speed that you fixed it, the ability to maintain it, and other characteristics, which usually are the result of doing something in the simplest way possible, and the simplest solution may mean not writing code.

Password Authentication for Go Web Servers

Thu, 23 Apr 2015 14:00:00 -0600

The stackoverflow question "How are people managing authentication in Go?" has had a few thousand views. Go's framework's (beego, goji, revel, martini, negroni, gin) do not have anything you should use built-in. Other languages have a common capability for a "classic" password authentication scheme.

A "classic" scheme requires a username (could be email address) and password, that is stored in a database (with the password hashed). A cookie is stored in the user's browser to identify them, so they don't need to retype their credentials, and that cookie information is verified on the server. This post will look at what is available in Go (golang).

This will not get into the debate about not using passwords at all (such as using password reset emails only, using client certificates, or using things like OAuth). It's mostly just to help those auditing existing systems.

Go code auditing

Sat, 18 Apr 2015 14:00:00 -0600

In the book "The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities" from 2007, the authors Mark Dowd, John McDonald, and Justin Schuh, discuss where to look for common trouble spots that affect all web platforms. They discuss CGI (when a web server used to directly call an executable), Perl, PHP, Java, ASP, and ASP.NET. They focus on a couple of fairly common application features, where when things go wrong, they usually go horribly wrong, so you should look for these techniques specifically. This post hopes apply that same methodology to Go (golang). This post builds on my previous post Looking for security trouble spots in Go code which was focused on looking for problems that would be specific to Go.

Application White-Listing Expectations

Thu, 16 Apr 2015 14:00:00 -0600

Summary: Lower your expectations.

In infosec, one definition of an exploit is something that takes advantage of a flaw. To be a "flaw", it must be unexpected behavior, and to "take advantage", it must result in greater privileges.

Many discussions of exploits, bypasses, or attacks on white-listing systems show what they would claim is unexpected behavior because I believe many people's expectations of application white-listing are too high. For example, there are many posts about using powershell to bypass white-listing solutions. How did they get the powershell script there in the first place and give it execution? Many of these posts can be summarized as "Given arbitrary code execution, I was able to get arbitrary code execution." If you obtained no new privileges, is this an exploit? Was any of this unexpected? Perhaps you gained an easier persistence mechaninism, so that's a new privilege, but after the point where you have arbitrary code execution, you've probably passed the point where application white-listing should be considered useful.

Looking for security trouble spots in Go code

Sun, 12 Apr 2015 14:00:00 -0600

Different languages have certain areas where mistakes are commonly made, and which code auditors focus on. With C, you might grep for strcpy and memcpy. With ruby, you might look for regex that use ^ and $ instead of \A and \z. The use of those functions or idioms are not always vulnerabilities, but are good places to check first. I decided to look for such trouble spots for Go (golang). I did not find any.

Go has a lot going for it in terms of security, such as no pointer arithmetic, no manual memory management, a standard library that seems fairly well thought out and purposefully excludes things that are misused (ex. no ECB mode for AES), and put together by a team of seasoned veterans. However, one must also consider that part of the reason it does not have known trouble spots is perhaps due to it being such a young language that it has not had time for a lot of mistakes to pile up, or for it to be misused in unexpected ways.

With that, let's look at some issues that have been found.

Choosing Libraries for Go Web Servers

Fri, 03 Apr 2015 14:00:00 -0600

One of the hardest things about coming to a new language is figuring out which libraries you should use, especially for young languages like Go, where there are a bunch of competing options with no clear winners. As an example, for Node, there was an issue opened for it's npm package manager because there were 127 different bcrypt libraries.

This post will show some of the different choices I made in the libraries I use for the back-end to my end-point protection product at Summit Route. As quick summary, I use the goji web framework, some middleware, and the database library gorp (with Postgres for my database).

Go Everyday

Sat, 27 Dec 2014 13:00:00 -0700

I've been coding in Go everyday for the past 3 months, for Summit Route. This post describes how I use Go and what works for me, some of which differs from what I've seen in a lot of other tutorials. Tutorials give you the quick solution that might not be the best when you use it every day. This might help some others and the experts might give me some better ideas.

Tip 1: Use the Go Package Manager for Revision Locking
Tip 2: Use direnv for per project GOPATHs
Tip 3: Use the Atom editor with the go-plus plugin
Tip 4: Use the latest Go
Tip 5: Debug with gdb

Summit Route

Mon, 20 Oct 2014 00:00:00 -0600

For those that have followed this blog, I want to direct you to my new blog at https://SummitRoute.com/blog/. I founded the company Summit Route over a month ago for a couple of reasons, but one of which was to build an application white-listing solution, which I've complained about wanting on this blog before. No one else makes what I think is needed, and with every retail company being slaughtered by hackers lately, I decided I was sick of replacing my credit cards and I'd fix these problems myself. :)

My new blog includes a weekly summary of the important cyber news that has happened during the week in posts I title "Downclimb". It also will include some original technical pieces, such as my latest post "Modifying code-signed files".

Please add my new blog to your RSS feeds.

Endpoint Threat Detection Standards

Wed, 28 May 2014 00:00:00 -0600

The most vocal player in the endpoint threat detection standards game is Mitre. Unfortunately, they are also the least useful as they don't provide any tools that use the formats they create. For a long time this meant no one used their formats, but it seems recently the US government (who paid Mitre to make these formats) has started forcing companies to supply data in these formats. The docs on these formats are lengthy and never give a simple explanation, so this is my simplification.

Terms

Stateful properties: These are the currently running processes, files that exist, registry keys that exist, etc. These can be acquired by running periodic scans on a system, or running one scan after an incident. Think of this as data you obtain from a memory image or hard-drive image.
Events: These are acquired by monitoring a system. These are generated as processes are created or terminated, files are created, written to, read from, or deleted, etc. Think of this as procmon data from the Sysinternals tools.

Formats

OpenIOC

OpenIOC = stateful properties + a threat name. It is a Mandiant format that is useful for incident response.

CybOX

CybOX = stateful properties + event data. It's not really meant to be used by itself, but rather should be used as part of one of Mitre's other formats. There are 88 object types possible that range from common things like files and processes, down to oddly specific things like "PDF File" and "Windows hook". Although mostly focused on Windows, some objects are Unix specific.

MAEC

MAEC = CybOX + a threat name. It is used with some Advanced Threat Protection products, such Cuckoo Sandbox.

STIX

STIX = MAEC + whatever you want. The STIX samples on Mitre's site look like MAEC data plus lot's of meta-data including long html descriptions of pieces of the content.

TAXII

This is just how you should send STIX data. It is a publish/subscribe model built on HTTP/S. Luckily, Mitre actually made an example implementation of this.

The Future of Endpoint Threat Detection and Response

Tue, 27 May 2014 00:00:00 -0600

The current direction of the infosec industry, with regards to malware prevention and detection, is using two very similar technologies (with horrible acronyms). These are:

Advanced Threat Protection (ATP) which includes products like FireEye, Palo Alto's Wild Fire, LastLine, and Cuckoo Sandbox. These "detonate" samples in "sandboxes" (virtual machines).
Endpoint Threat Detection & Response (ETDR), which was coined by Gartner's Anton Chuvakin (here), and includes Mandiant's MIR, CarbonBlack, CounterTack's Sentinel, CrowdStrike's Falcon, and Immunity's El Jefe. These can be further categorized:
- Tools that do scans, such as Mandiant's MIR. This tells you what exists at the time of the scan, which are "stateful properties".
- Tools that do real-time monitoring, such as CarbonBlack, CounterTack, and El Jefe. These tell you what is happening as it happens (with perhaps a few minutes of delay. These are referred to as "events". These are the newer products.