Setuid Script Wrapper Example

The problem? I have a Node.js script that needs to run as root and Linux doesn’t like me to shoot myself in the foot.

I have a bunch of sysadmin utilities that I like to use to do various clean up tasks on my projects. I call them “agents” and they are just short Node.js scripts that run forever using PM2 (PM2 is one of my favorite utilities ever because it lets you wrap up all your microservices into one frontend, no matter what language you wrote them in – also you’re allowed to say microservices and not sound like a complete tool).

One of these agents was ping-agent.js, a Node script that uses net-ping and node-schedule to periodically send ping packets to a list of hosts and write the results back to a Redis cache. The problem is that doing a ping requires privileged access to the OS and using sudo put it in an entirely different PM2 daemon so it wasn’t appearing with my normal pm2 list results. Sad!

Most of the time this would be a job for setuid, but setuid doesn’t work for interpreted scripts for security reasons. One solution is to code up a quick-and-dirty wrapper in C. This is usually a Bad Idea™ since it’s a perfect way to do privilege escalation on a compromised system. My version of this is to make it as narrowly defined as possible and useable for only a specific case, while still being kind of portable when I need to re-deploy code in a different situation.

Here’s my solution:

The C preprocessor here requires that you explicitly give a path to the script to run but the Makefile figures that out for you so you don’t need to hardcode something.

make
pm2 start wrapper --name ping-agent
[PM2] Spawning PM2 daemon with pm2_home=/home/austin/.pm2
[PM2] PM2 Successfully daemonized
[PM2] Starting /home/austin/projects/ping-agent/wrapper in fork_mode (1 instance)
[PM2] Done.
┌────────────┬────┬──────┬───────┬────────┬─────────┬────────┬─────┬───────────┬──────────┐
│ App name   │ id │ mode │ pid   │ status │ restart │ uptime │ cpu │ mem       │ watching │
├────────────┼────┼──────┼───────┼────────┼─────────┼────────┼─────┼───────────┼──────────┤
│ ping-agent │ 0  │ fork │ 14568 │ online │ 0       │ 0s     │ 3%  │ 24.0 MB   │ disabled │
└────────────┴────┴──────┴───────┴────────┴─────────┴────────┴─────┴───────────┴──────────┘
 Use `pm2 show <id|name>` to get more details about an app

Woo! Now I can run my Node.js stuff in PM2 without needing a spearate PM2 daemon for root-ish activity. One big caveat is that you need to have a shebang line on your Node.js script (e.g. #!/usr/bin/env node).

Final warning: setuid is still pretty nasty. It’s probably not a good idea to use it for anything that gets input from the outside world.

Security BSides NoVA 2017 Retrospective

I must be doing something right because they keep sending me to security conferences.

After going to ShmooCon last month, I got the opportunity to attend the inaugural Security BSides Northern Virginia conference on February 25. As a 1 day event, it was pleasantly brief and packed a lot of talks without requiring me to commit a full weekend. Also, it took place in Herndon, which is pretty easy to get to and didn’t require a trip on the DC metro.

Like with ShmooCon, I made a list of things that stood out to me at the conference.

• The first thing I noticed when walking in is this conference attracted a lot of big sponsors. ShmooCon actively limited the sponsorship spots and tried to showcase smaller companies, but this one had all the big names: SANS, ISC², Symantec, and pretty much ever contractor from the DC metro area.
  
  I don’t have strong feelings about this, but I was surprised since I sort of assumed that BSides was informal and driven by community individuals (I mean, the main website is a PBworks wiki running with an educational license, so I really didn’t expect to see Fortune 500 companies setting up booths). I guess it’s cool that the BSides NoVA organizers were able to get big names for the first conference.

• Initial keynote was by Tennable co-founder Ron Gula (@rongula) under the title Cyber Security 2017: Trends and Start Ups which rolled three talks into one on the topics of 1.) the cyber security market, 2.) new rules for business and 3.) how to pitch a cyber security startup to a VC.
  
  It was oddly refreshing to have someone talk about the intersections of startup culture and hacker culture. They both have a lot of common ground but tend to get mired by ideology.
  
  My favorite part of his talk was his take on the traditional 5 slide pitch deck (they spend too much time on posturing and not enough on describing the problem being solved).

• The talk 0 to 31337 Real Quick: Lessons Learned by Reversing the Flare-On Challenge was a retrospective on last year’s FLAREOn Challenge presented by two Endgame developers Josh Wang (@rh0gue) and Blaine Stancil (@MalwareMechanic).
  
  These challenges were what really got me into doing reverse engineering, so I was excited to meet someone who actually completed all of them. They didn’t reveal any of the answers, but instead provided a rundown of all the techniques they saw.
  
  This slide was the central point of the talk since it provided a table with the challenges and which reverse engineering techniques were used to solve each one:

• Another interesting talk was Doomsday Preppers: Fortifying Your Red Team Infrastructure by Steve Borosh (@424f424f) and Jeff Dimmock (@bluscreenofjeff). It focused on how a red team can setup a successful pen test by building out simple, redundant, and redeployable networks to keep the attack alive, even if the blue team takes active steps toward blocking it.
  
  I kind of assumed that red teams weren’t very organized and just grasped for footholds until they got the results they needed, but this really changed how I look at red team/blue team exercises.

• The final keynote was by Georgia Weidman (@georgiaweidman) whom I went to college with at James Madison University. She’s been much more successful than me since then. The organizers unfortunately put her keynote in the foyer of the building instead of an auditorium and that was a terrible idea; the sound system was awful and it was happening alongside the happy hour so it was hard to hear anything over the noise. My biggest complaint about the conference is that they messed this up so badly.

• But hey, there was free alcohol and food.

• In addition to talks, I dropped into a few workshops. There was a Malware Analysis 101 workshop in the schedule, but there must have been some confusion when printing the schedule because it was actually an OWSAP workshop on identifying attack patterns from network packet captures.
  
  The other workshop I did was a Forensics 101 course that was very well put together and instructed by Marcelle Lee (@marcelle_fsg), Brian Moran (@brianjmoran) and Courtney Lancaster (@allth3things).
  
  The wifi at the conference was pretty bad; probably because it wasn’t designed to hold a ton of people all at once. I made the mistake of not downloading the workshop materials in advance. A lot of people did the same thing. To remedy this, they began passing around a thumb drive with all the materials. At a security conference. During a session on malware. Let this sink in.
  
  

• The badges are awesome. They are an electronics reference board so they are actually pretty useful after the con.

• I saw Bruce Potter (@gdead) wandering around. It’s kind of cool to recognize people from other conferences.

Overall it was a fun conference. Most of the talks were aimed at a broader audience so it was highly accessible for all levels of experience. I definitely plan on returning.

ShmooCon 2017 Retrospective

I went to ShmooCon!

I’ve always wanted to attend but tickets are limited and incredibly hard to get. I was finally able to secure 2 barcodes this year so I passed one off to my friend, Ed, and we hopped on the metro to Dupont Circle.

The easiest way to get kicked out of the conference is take photos without permission. There’s a two strike policy on this; unfortunately that means I don’t have any photos of the conference. There were some interesting people and displays but I was going to respect the privacy of the attendees.

The vibe I got was that this was a gathering of good natured people and there wasn’t going to be much cover for illegal or blatantly malicious activities (I still wasn’t going to use the ATM in the lobby, however).

After 3 days of talks and shenanigans, I made a few retrospective notes.

• How did I get a barcode? No gimmicks. I just went to the website and hit F5 as the site went live. My Internet connection at home is reasonably good and I think this helped.
• Want to blend in? Wear a black tshirt and jeans. Want to make it easy for your friends to find you? Wear anything else.

I lost my friend at #ShmooCon and began looking for the guy in a black tshirt. Then I realized that's 90% of attendees.

— Austin Keeley (@austinkeeley) January 13, 2017

• There were two talks that really stuck out to me. The first was Anti-Ransomware: Turning the Tables by Gal Shpantzer and G. Mark Hardy. The presenters discussed why ransomware is such a big deal now (hint: money) and how it’s getting more sophisticated (e.g. being able to detect if VPN software is present and waiting for a connection for better exposure). The other talk was Goodnight Moon & the House of Horrors: A look at the current IoT ecosystem and the regulations trying to control it by Whitney Merrill and Aaron Alva. IoT is still a garbage fire from a security perspective and this talk discussed possible regulations to try to contain it.
• I mostly attended talks. I regret not visiting some of the side rooms and participating in the lockpick village. Next time I plan on dedicating at least half a day to visiting these. A co-worker spent most of his time doing Hack Fortress and his team wound up winning the championship. My TF2 skills are a little too rusty to join a team, but I might consider doing that next year.
• The Metro sucks. If you are coming from out of town, you might not know about the delays, shutdowns, and fires. I highly recommend giving yourself extra time if you plan on using it. This is especially true if you plan on using the disability access elevators since these are notorious for being out of order.
• A VPN is highly recommended, even for the WPA secured Wifi networks. Cell service was pretty bad. Probably because of all the devices.
• The food situation was wasn’t ideal. There was an impromptu bar set up in the lounge area where food was being sold, but it wasn’t great. Dupont Circle has some good restaurants within walking distance, however.
• The Friday night fire talks were fun and probably the best part of the day (also the lightest attended).
• Get a Twitter account. Set up alerts from @shmoocon. You’ll get buzzed when stuff happens. Also you can set up a list of all the speakers you saw so you can follow up with them later.
• I kept sitting behind Ed Skoudis (@edskoudis) at various talks but I didn’t realize it was him until some of his tweets later.

At #ShmooCon working hard on #SANSHolidayHack 2017. Just saying. You'll love it. :)

— edskoudis (@edskoudis) January 15, 2017

Overall, it was pretty awesome. If I can get a barcode for next year, I’m definitely going back. There are a few other hacker cons being scheduled that I might attend in the meantime, including BSides DC and, of course, DEF CON.

Image credits: Dupont Circle Station, Wikimedia Commons

New Project: Hacknowledge.io

I’ve been quietly working on a new project that just recently went into a closed beta release.

Back in college, I was studying a lot of information security. I was even on my university’s cyber defense team where we competed at a regional competition to defend a computer network against a nasty group of professional penetration testers.

I’m in the lower right with those sweet sideburns.

After college, I kind of moved away from doing infosec and I began to settle into a comfortable web application development career. I still tried to keep up on the world of infosec by reading blogs and following news articles, but it’s pretty tough unless you’re actively involved in the community.

Around 2013, I found some co-workers who also wanted to play around with infosec stuff and they let me hop on their private lab to solve challenges, learn some new stuff, and just have some fun. I was hooked back in and I instantly knew I wanted to host my own lab environment to do the same thing. I also wanted to apply some of my software engineer and dev ops skills to try to automate a lot of the boring stuff so I could spend more time exploring security concepts and less time doing admin work.

So that’s why I started hacknowledge.io. It is a private network that I’m hosting and also a set of tools for administering and monitoring the network.

Here’s how it works: I have a server in my basement running VMWare ESXi and with a few really vulnerable virtual machines. All of these VMs are on a private network that can only be accessed by going through a VPN. I’ve been calling this private network the Threat Net even though, at the moment, none of the hosts are dangerous on their own.

For each vulnerable host, there are a few challenge questions. Answering these gets you points and let you move up the leaderboard. The questions are designed to help push you in the right direction of fully exploiting the machine. They start off relatively easy (e.g. Find the port that a web server is running on) and eventually ramp up (e.g. What is the root password?).

Currently there are only 3 hosts. Eventually I’m going to have 5 for the initial closed beta round. The first three are relatively easy to exploit. Spoiler alert: the first host is vulnerable to Shellshock, which is about as obvious as they come. Anyone who knows how to install and run a Nessus scan can figure it out. I’m hoping that I can eventually build out some more difficult challenges in the future, but the closed beta is mostly just a proof-of-concept.

In addition to vulnerable hosts, the threat net also has some bots running around doing housekeeping chores like reverting the VMs to a known state every half hour (so you can trash a machine and it will be back to normal so someone else can have a chance). There’s also a bot that just checks to make sure the machines are online and available.

Outside of the Threat Net is a set of hosts that provide a web interface for users to answer challenge questions.

In the process of designing and writing all of this, I learned a bunch of stuff. I have a ton of blog entries planned on how I built this thing.

The Ways I've Changed as a Programmer

I’ve been doing professional software development for nearly eight years. That’s not an exceptionally long time, but it’s twice as long as the time I spent in college as an undergrad and it seems like a good place to stop and do some reflection.

I recently noticed at work that I’m now on the top of the heap with more junior developers working alongside of me than ever before. My input is weighed more heavily, my contributions are valued more highly, and I think I’m even getting small glimpses of this new feeling called “respect”. It’s an exciting time.

With all this new clout, I’ve compiled a short list of the ways that I’ve grown as a software developer.

I’ve learned to not be a control freak

Early in my career, I worked on really small teams on small, tight projects. I could know every detail of the baseline and know exactly how all the pieces fit together. I saw the projects as direct extensions of my worth and I found myself really nervous if I heard someone was trying to make some big changes. What if they don’t get my elegant designs and just kludge the whole thing up? What if they don’t have my same skills as me and turn the whole thing into an unmaintainable mess for me to deal with?

I had two options: I could constantly be checking the work of these outsiders and spend hours trying to “clean up” their messy less-than-perfect code. Or, I could just let go of my control freak nature and let them contribute like a professional. This has been incredibly difficult for me to do, but I’m finally getting around to it. If I tried to monitor every single code check-in and every change being made, I wouldn’t have any time to get real work done. On top of that, I’d look like a jerk who can’t play nice with others.

In the end, I really have to remind myself a few things:

• The success or failure of a project doesn’t depend solely on me.
• I was once a wide-eyed junior programmer who couldn’t wait to start contributing, no matter how little I knew of the code. I turned out okay.
• You gotta let things go sometimes. Walking away isn’t a sign of defeat or apathy.

I’m less concerned with style

Spaces versus tabs. Semicolons versus semicolon-free. Single quotes versus double quotes. So many battles rage on within software development teams. I have strong opinions of what good clean, readable code should look like, but these days, I’m much less apt to try to enforce it on others. We have a style guide at work for our code and I only like about half of the style choices, but I’m not about to spend the effort to try to change people’s minds on really petty stuff.

I have a theory on this: in college, I was used to doing work and getting a grade on it. It felt good to get validation. In the real world, I might go weeks before getting feedback from someone on my work, and even then, it might just be superficial. For a while, I really craved the kind of validation that I got from jshint and pylint and whatnot. To me, it was a way to write code and have someone tell me that it’s “good”.

I’ve discovered that even well-styled code can still be pretty lousy and I think I’ve outgrown the need for the praise.

My unit testing is way better

Unit testing is a skill that, unfortunately, doesn’t seem to be taught in college and most developers aren’t actively seeking out tutorials or books on how to write good unit tests. Most new developers write really, really awful unit tests, myself included. I could probably write a whole blog post on how you should go about learning how to write a good test suite (I probably will at some point).

In short, your unit tests need to meet some basic criteria:

• Independent, no external requirements, –that includes databases, network connections, filesystems, etc.
• Repeatable, you should get the same result each time you run the tests no matter what order you run them.
• Concise, you should be testing one thing in each test case.

One obstacle for me was learning how to mock out objects and modules for your unit tests. Most unit testing frameworks don’t present this up front and it’s incredibly difficult to write good unit tests without a good mocking framework in your toolbelt.

The Zen of Python is everywhere

The Zen of Python is a short mantra that describes the ethos of the Python community. It’s intended for Pythonistas, but honestly, it works for every language.

When combined with some of the things I’ve gained from functional programming, I’ve found that my code feels much more elegant and even fun to write.

I’m no longer afraid of exceptions

Somewhere back in college, a lot of programmers make the connection that exceptions crash your programs. Therefore, exceptions must be bad and you should do everything you can to remove them from your code.

But exceptions are a very powerful construct! In C code, you have to return positive or negative return codes and the calling function has to interpret them and react. I don’t want to go back to that.

A lot of rookie programmers will eat exceptions and this is universally considered bad form. Another anti-pattern I often see is avoiding situations where explicitly throwing an exception would be appropriate. Usually they will return a null value and let the calling function do a null check to figure that out.

If you’re a junior programmer and want to impress your seniors, learn some of the exception handling idioms of your language and find places where they help your code.

Frameworks are cool, but not a substitute for fundamentals

Frameworks are designed, in part, to reduce boilerplate code and the amount of cruft that you might otherwise write. I used to think that knowing a framework was a fast track for writing better code, e.g. Angular.js has modules and dependency injection so it’s halfway there to making you a JS ninja.

Well, not quite. It turns out, you’ll bend the framework to your bad habits. I’ve seen it so many times that I’m starting to understand the no-framework camp of developers.

For this, I think it’s just a lack of solid hands-on time with a language. I see developers mature in the language over time as they write code and find themselves maintaining it.

I’m going to set a reminder for myself to revisit this in 5 years and see what else I’ve learned. I could have a new job by then, a new favorite language, or a new database that I love. I don’t expect to stay the same, and that’s a good thing.