Posts

  • No more popups!

    I hate these stupid popups! They’re ruining my life! Every time I think I’m doing alright, out of nowhere comes another popup. Then the user reports it to IT, one thing leads to another, and I’ve been detected. No, I don’t mean annoying advertisement popups. I mean when you compile an otherwise-good executable payload for post-exploitation, and it pops up (even briefly!) a CMD window for the users to see in all its glory, prompting thoughts of profound wonder (I wonder if I’m being hacked!?!).

  • Sloth: the slow, but adorable programming language

    This post is a literate program, which can be seen in source code format here on github.

    In this literate program, I will set out to create a small concatenative programming language. For lack of a better name, and frankly, it’s pretty hard to name languages, I’ll call it Sloth. This is a pedagogical interpreter; it’s not efficient, but the code should be easy to read. As of my first testing, it comes in about 6x slower than Ruby (which is saying something) in a completely unrealistic benchmark battle. Nevertheless, it’s a functioning language that could serve as the basis for experimentation.

  • Snarf Enhancement: Ignore Failed Logins

    SMB relay is a beautiful technique. Most SMB relay tools disrupt the client’s actions and deliver a single payload, which often means you give up perfectly good sessions that you could otherwise use for profit. In collaboration with Victor Mata, I had the pleasure of writing Snarf, whose key feature is that it relays a connection, and then retains it, allowing you to reuse an already-authenticated session many times. For more info, check out our presentation we did at Derbycon ‘14.

    I continue to get a lot of value out of Snarf in pentests. But sometimes it gets a little annoying in real environments when accounts that you’re relaying aren’t valid. If you have used Snarf and seen the following, then I think I have just fixed it:

    1006 20:44 :) josh ~ $ smbclient -U b%b //127.0.0.1/c$ -c ls
    Domain=[SNARFING_MITM] OS=[Snarf] Server=[Josh S. & Victor M.]
    tree connect failed: NT_STATUS_USER_SESSION_DELETED
    

    This happens when the session you’re relaying can’t login – maybe the password’s wrong, or the account doesn’t exist (anymore?), or the account is locked out. This is not unusual when you consider that lots of the stray SMB logins that result from LLMNR or NBNS poisoning relate to hosts or apps that have been decommissioned. Obviously, these sessions are of no value to the pentester, so Snarf shouldn’t keep them around.

    If you update Snarf, this is what you should see when any relayed connection fails to login (this is in the Snarf console output):

    20:50:21 Writing hash for WORKGROUP\test to snarf.pot
    20:50:21 [0] Server: SMB (35 bytes), CMD: SMB_COM_SESSION_SETUP_ANDX
    20:50:21 ERROR: client failed authentication!
    20:50:21 Setting UID to 2048
    20:50:21 Rewiring middler as dumb relay until it dies
    20:50:21 Activating middler
    20:50:21 Ready to start listening for hackers
    20:50:21 Listening for hacker clients on 445
    20:50:21 Keepalive for middler
    20:50:21 Destroying client socket!
    20:50:21 Server connection encountered an errorError: read ECONNRESET
    20:50:21 This could be because of a failure to route to the destination
    20:50:21 Encountered error from server
    20:50:21 Removing Middler #0
    

    Of note, you will see the message indicating that the relayed session failed to login (the session setup resulted in a non-zero status code), and the message showing that the middler has been rewired to function as a dumb relay. This way it won’t show up in your Snarf console. This should reduce the clutter quite a bit – test it out and let me know if you like the fix!

  • EvilVM: Building an Assembler

    This is part of my series on EvilVM, a project to create a tiny injectable VM with language support for EvilTM agent features for pen-testers like me. In other words, a programming language and agent framework specifically designed for post-exploitation. The goal is to allow ad-hoc, reliable adaptation of malicious agents to situational needs during a pen-test. And to build it from scratch for fun (of course). The index and overview for this project can be found here.

    Last time I added a few instructions to the VM so that I can start writing real code. As I manually created the machine code for a factorial() function, it became clear that I will need to write an assembler. This post is about my basic assembler – possibly getting into it a little deeper than the casual reader might want. Nevertheless, I’ve found that documenting this project in blog posts has really helped me tweak the design and find bugs, so here goes: let’s assemble!

  • EvilVM: Choosing Useful Instructions

    This is part of my series on EvilVM, a project to create a tiny injectable VM with language support for EvilTM agent features for pen-testers like me. In other words, a programming language and agent framework specifically designed for post-exploitation. The goal is to allow ad-hoc, reliable adaptation of malicious agents to situational needs during a pen-test. And to build it from scratch for fun (of course). The index and overview for this project can be found here.

    Last time I created the execution loop for the VM and defined a few fundamental instructions. This time I’ll expand the instruction set with the goal of writing some code that’s actually useful. I’ll have to make a few decisions about how to handle some things – I’m not sure if these decisions will stick or not. It’s clear at this point that I may encounter issues later that will make me question early decisions, so I’m trying to keep an open mind so far.

  • EvilVM: Executing Instructions

    This is part of my series on EvilVM, a project to create a tiny injectable VM with language support for EvilTM agent features for pen-testers like me. In other words, a programming language and agent framework specifically designed for post-exploitation. The goal is to allow ad-hoc, reliable adaptation of malicious agents to situational needs during a pen-test. And to build it from scratch for fun (of course). The index and overview for this project can be found here.

    Executing Instructions

    Last time I got my basic garbage collector up and running. In the future I’ll make some enhancements to it – I’ve been reading more about GC design, which is a topic that goes as deep as you want. But for now, I’d like to start getting some actual code running. Code running means my GC needs a bytecode virtual machine wrapped around it. I’ve looked over the design of a few other VMs – notably, the JVM, the Squeak Smalltalk VM, Lua, and a few toy VMs on github. I believe I’m doing this in a relatively normal way, though this is also a topic that goes as deep as you like.

  • EvilVM: Garbage Collector

    This is part of my series on EvilVM, a project to create a tiny injectable VM with language support for EvilTM agent features for pen-testers like me. In other words, a programming language and agent framework specifically designed for post-exploitation. The goal is to allow ad-hoc, reliable adaptation of malicious agents to situational needs during a pen-test. And to build it from scratch for fun (of course). The index and overview for this project can be found here.

    Garbage Collection: Shoulders of Babies

    I had slapped together a little Lisp interpreter some time ago, and it was pretty rough, but technically worked. I had implemented some data structures for representing data types and pairs (linked list nodes, basically), and had an S-expression parser and very simple interpreter. But then, after tons of work and some barely working code, I hit a serious issue. I hadn’t considered memory management at all, and I realized that garbage collection was in my future.

  • EvimVM Introduction

    I’m not using this blog space for much right now, so I thought I’d start a project and document it over time here. This will be the main post for the EvilVM project, and I’ll try to link subsequent posts into this article over time so it’ll become a sort of index page for it.

    1. EvilVM: Garbage Collector (2016-06-25)
    2. EvilVM: Executing Instructions (2016-07-08)
    3. EvilVM: Choosing Useful Instructions (2016-07-23)
    4. EvilVM: Building an Assembler (2016-07-31)
    5. EvilVM: Concatenative Language – coming soon

    Introduction & Motivation

    I’m a pen-tester for work, but in real life I’m a hacker. I don’t mean hacker like Johnny Lee Miller and Angelina Jolee. I’m also not a hacker like you see at Defcon. I mean I’m a hacker like what ESR talks about in the jargon file. Before I was infosec, I was a programmer, computer science student, and UNIX afficianado. My tech-heroes were the guys in the story of Mel and Steven Levy’s book about the MIT hacker subculture.

    A hacker, properly defined by ESR, is:

    A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users’ Glossary, usefully amplifies this as: A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.

    Probably my favorite piece of tech is programming languages. I’m a language hobbyist, picking up new ones all the time, hoping to make my toolbox bigger and broader so I can get stuff done quickly and powerfully when required. In the pen-testing world, I have to make some concessions in this area, because for some reason most infosec researchers stick with just a couple languages.

    But I end up writing code all the time. In the PCI world, penetration testing comes with a challenging “boss level” for every assessment. Once you work your way around a network and have an escalated position, your final stage is to compromise the cardholder data environment. If they did their job right, it’s pretty hard. And so I end up doing a lot of post-exploitation, trying to mount a reasonable attack on the segmentation boundary. This often means custom malicious agents that operate on end-user systems, and the specifics of their operation change with every environment and segmentation design.

    I’ve experimented with augmenting Meterpreter, building agents that embed other languages (like Lua, which really worked out pretty well, to be honest), and just embracing the pain and writing things in C (like my RSA-pwning keylogger I presented at DerbyCon last year). But none of these solutions has been ideal.

    Cue EvilVM

    I think it’s time to build a malicious programming language. There are unique programming challenges that you find in writing malicious agents, and no matter what existing environment you choose, you’re going to be making compromises and choose which part you’re OK with still being “hard”. You can use a fun, fuzzy language, but then low-level stuff is hard. You can use your favorite scripting language, but then you’re bundling a big interpreter and a bunch of files. You can use PowerShell, but then you’re fighting all the insane restrictions Microsoft seems to think should apply to a script but not the binaries. Etc.

    In this project, I’m going to build EvilVM – a runtime environment that implants a super-small bytecode VM on a target system. On top of this, I will build a companion language (or languages, why settle for one?) for compiling agent behavior for this VM, and the infrastructure needed to sustain persistent communication and interaction with the VM. Along the way, I have a few ideas about core language and runtime features that I think might make a good platform for remote-managed agents.

    A few basic thoughts about my initial requirements:

    • The EvilVM agent must be very small, 10s of kilobytes, max
      • Single file
      • EXE or injectable DLL
    • I/O streams should be heavily abstracted to allow even very strange communications strategies
    • I may borrow some Erlang concepts for multi-processing and reliability
    • Easy interoperability with the native environment
      • Use native DLLs
      • Call into C code
      • Manipulate native structures
    • Delivery of additional code at runtime
      • Compiled bytecode for the VM
      • Delivery of DLLs or C object code
    • High level, expressive language
      • First class functions
      • Dynamic typing
      • Metaprogramming
      • Very small core language
    • High availability
      • “Hypervisor” layer control of deployed VM
      • Reflection and discoverability
    • Native support for “malicious” actions
      • DLL injection
      • Manipulating security contexts / tokens
      • Monitoring for ‘target’ behavior
      • Keylogging

    There are also some anti-requirements – things that are definitely not the objective:

    • Performance – if it’s within 100x of C, I’m good
    • Large standard library
    • Graphics, databases, etc.

    So far, this has been a really fun project, and I hope to keep it up to completion. I’ve been a language nerd forever, but this’ll be the first full-spectrum language project I’ve done – from core language to compiler for a custom bytecode VM. Can’t wait!

  • Hunting VPNs

    Working in the PCI space makes for some really fun penetration testing challenges. With the PCI-DSS 3.1 language stiffening on what qualifies as acceptable segmentation, we get to see lots of different popular segmentation strategies. To be able to say that somethign is out of scope for PCI compliance, it has to be segmented from the cardholder data environment (CDE), “such that even if the out-of-scope system component was compromised it could not impact the security of the CDE”.

    One of the more popular designs is to create a separate network for the CDE and allow users to VPN into it to access or administrate CDE systems. There is a certain fundamental beauty about this design, especially when properly implemented with a good multifactor authentication. It can make for a difficult target for the penetration tester.

    In this type of environment, the problem to be solved by the pen-tester (after making the obligatory escalation to domain admin on the internal network) is finding the users who can VPN, and then exploiting any weaknesses in the VPN access method to get access to the CDE. So how do we find those people?

    My first approach hopes that they enable split tunneling – in this case, it’s really easy to find people who access the CDE because they tend to stay connected all day and not think twice about it. I’ll collect a netstat for all domain-attached systems and look through the results to find any active connections to the CDE network. Once I find some, it’s a straightforward matter of pivoting through those hosts into the CDE, and success criteria aren’t that far away.

    Split tunneling is always wrong, though, so lots of places do actually disable it. What options do we have now? And once I find someone who uses the VPN to access the CDE, how do I leverage that to get access for myself? This was the situation I was presented with in a recent pen-test.

    Finding VPN users was the first step.

  • OpenPasswordFilter Project

    I’ve been working on a project that’s motivated by a number of pen-test results over the past few years. Though it’s cool to find interesting vulnerabilities, it seems that most of my pen-tests at some point or another benefit from one of the dumbest vulnerabilities ever: guessable passwords. It seems to be an intractable security problem in most places, and this project is my little contribution to help make it better: OpenPasswordFilter.

    The point is that the security of any environment has less to do with the patch level of its systems than it does with the security decisions made by the users. It only takes one user to choose a classically bad password to doom the rest of the network to compromise. As domain user populations grow to thousands or tens-of-thousands, the probability approaches unity very quickly that someone has a password of Password1, Summer15, or Company123. Common 90-day password rotation policies are especially bad for this, because they basically train people to think of something that corresponds to that cycle and they end up on a SpringXX, SummerXX, etc., rotation forever.

    My primary recommendations in my reports are to implement stronger complexity requirements and conduct password audits. For various reasons, too many places are unwilling to do either – the former due to cost or lack of perceived options and the latter due to the fear of arming administrators with the tools to get user passwords. There’s an obvious critical logic flaw in the second (namely, that admins can do what they want and Google can teach them how to get the passwords out anyway), but the former can actually be addressed.

    Microsoft provides a mechanism supporting custom password filters, in which you implement a DLL that is loaded by LSASS on boot that can be called to evaluate passwords when users set them. It’s a very simple interface (all of four functions, and only one of them requires real code), but most organizations aren’t going to write their own. There are commercial options, but they typically fall into the “call for pricing” category.

    But it’s such a simple DLL… one function that returns a TRUE or FALSE. I worked up a proof of concept that is very much in the “alpha” stage, but it’s enough to share. The OpenPasswordFilter project exists to provide the following features:

    1. A custom password filter DLL
    2. A user-space service for decision making
    3. User defined dictionaries for forbidden passwords

    I definitely intend to add more functionality in the future, but this is a good stab at the basics. The software architecture should be robust enough to allow adding more mechanisms for denying passwords (beyond just a straight dictionary). My goal is to have something actually usable on the cheap to armor a domain against trivial password attacks. I would be thrilled to get feedback from anyone with ideas how to make it better or just to let me know if it works on someone else’s domain.

  • Duo MFA Vulnerability

    It’s been a fun week. About six months ago, a coworker and I found a session stealing race condition in Duo Security’s multifactor authentication product. Wednesday, they published the fix, so now I can talk about it openly. The vendor response was really great – as we worked with them on different ideas on how to fix it, I wasn’t sure how they’d end up deciding. The solution they chose is really taking the high road, and I’m excited about the strength of the Duo MFA design with this update.

    Some of the discussion we had, though, was very interesting. The vendor has a certain objective, and in their view this race condition is hard to exploit and they felt (and I think express pretty clearly in their post about it) that it’s really the fault of the customer in failing to adequately protect their end-user workstations. From my perspective, as a pen-tester, I don’t think this line of argument is completely sound. Hence this post – presenting my thoughts on why the Duo race condition is a genuine concern, and how it fits in the broad threat scenario landscape.

  • Starting Processes in the Desktop Session

    I really don’t consider myself to be a Win32 expert at all. My programming hobby lifestyle moved away from development on Windows to the UNIX world as soon as I could. But my job means hacking Windows, so I have been working on my knowledge in this area so that I can just get things done.

    I’m working on a keylogging framework to support a couple fun attacks I want to do on pen-tests, and one of the barriers I’ve encountered has to do with effective deployment and safe operation of a keylogging “botnet” on an internal network. OK, so that’s a little self-aggrandizing, but nevertheless… last week I overcame a hurdle and learned a couple neat things…

  • How pen-testers can save the world

    The penetration testing industry is in a definitional crisis. The “puppy mill” problem has been discussed before. The industry’s finest pundits talk about what penetration testing ought to be, but most of the pen- testing worker class just has to live with those ideas occupying dreamland, and gut through something that doesn’t always feel right. I am lucky enough to live in dreamland…

  • What you're doing is the opposite of help

    Sometimes even us pen-testers find some new vulnerabilities. I find it fascinating how hard many tech companies make it to establish meaningful dialog and work an appropriate disclosure process. This blog post may be more venting or ranting than anything else, but seriously – this is the 21st century.
    Not understanding vulnerability disclosure is inexcusable for tech vendors these days, right?

  • SQL Wildcard Quirks

    I found a neat vulnerability the other day, and I thought I’d write about it here. It’s actually an issue I’ve found before, and known about for at least 10 years, but for some reason I can’t find much discussion about it on the Internet. Since in my reports I want to provide references to additional resources so a customer can research and best understand the recommendations I make, I was disappointed not to find a good writeup of the issues you can encounter when you don’t filter all SQL wildcards.

  • Ethernet Parallel I/O

    This is a post in a series about my Ethernet Project

    In my last post, I talked a little about the Ethernet interface options in the hobby microcontroller world. Most of the time, these chips will use an SPI interface, which simplifies connectivity to the processor. SPI uses only a handful of lines to communicate serially, and can operate at pretty high speeds in many cases. In the Arduino world, SPI is usually limited to some fraction of the processor speed. It may also be further limited by the maximum specifications for the chip. So, for example, the ENC424J600, which I’ve selected, has an SPI mode that maxes out at 14MHz. This is a tad slow – some chips support more like 20-30MHz, but still, this is far slower than Ethernet line speed.

  • Ethernet Hardware Project

    Text

    I’ve had a little dream for many years about getting my hands on Ethernet at the lowest possible level. Alright, maybe not quite as low as some – I don’t need to hit the physical layer quite like project Daisho. But I want to have nothing between myself and the packets on the wire. In some ways, perhaps this is a foolish project, since we really can do what we want with packets using tools like Scapy, which I’ve used to effect in my DHCP-exhaustion and 802.1x projects in the past. But even so, here are a couple reasons for this project:

  • Ethernet Hardware Options

    This is a post in a series about my Ethernet Project

    So I want to play hands-on with Ethernet. I thought it would be worth pointing out some of the hardware choices I’ve made for this project, especially considering the other ways that people do small-scale ethernet. I’m targeting something that’s about Arduino complexity, so that ecosystem is a good place to start.

  • Create Domain Accounts Variously

    I find myself creating Active Directory accounts fairly often. But of course I’m never doing it as a genuine domain administrator. That means I might not have MMC available to me – or maybe not even an RDP session! This blog post is about summarizing a few ways I’ve found handy in various situations.

  • GCC toolchain for mbed on STM32F411RE Nucleo

    This blog post is what I wanted to find on the Internet when I bought my new Nucleo STM32F411RE microcontroller board. I am absolutely pumped about working with this board. I have done some experimentation with the ARM Cortex microcontrollers (primarily with a Teensy USB 3.1), but I have some projects that require me to step it up and enter this world a little more thoroughly.

  • The Shape of Network Traffic

    I am working on a (probably foolhardy) project to play with network traffic at a very low level. It’s hardware, and so I’m trying to estimate performance. Given a CPU with speed X and choosing parallel bus architecture Y on the MAC/PHY, how much time do I have to process a packet, etc., etc. Estimations are only worth the information you use for the basis, of course; so I collected a network capture from a pretty busy and large network so I could get some idea of what’s “normal”. I was quite interested in what showed up.

  • Lisp on an AVR?

    Raw Munger

    I’m working on a new version of my USB HID testing rig. This one is a little more robust – i.e., not consisting of a bundle of Arduino shields and a breadboard. I’ve also started playing with more USB-related things, like using a raw HID to transfer data faster. As I’ve been experimenting, I’ve started thinking about the ultimate in usability. I really want to be able to script the behavior of the device dynamically, without having to reprogram it with new features.

  • Mutating Dictionaries

    I was dinking around with mutating word lists to make password dictionaries this morning, and ran into a little hitch. Using John the Ripper, you can generate word lists using its mutation rules. It definitely works, as follows:

  • Snarf Presentation at NOLAcon

    tl;dr → Check out github and the NOLAcon 2014 presentation.

    My esteemed colleague, Victor Mata, and I had the privilege to present our long-time research project, Snarf, at NOLAcon this past weekend. It was great to get everything together to share with others. Coincident with this presentation is the Github release of our source code, so others can experiment with the tool as well.

  • HIDs and USB Blockers

    Occasionally, I will work with a client who uses a USB blocker to prevent users from uploading unauthorized software or exfiltrating data. This can be interesting from an attacker’s perspective – especially the rogue internal user – because one may wish to install hacking tools on an end-user workstation. There are lots of handy tools that help when you’re exploring a network, and these are rarely installed in a corporate environment.

  • Monotonically Increasing Application IDs

    This post is about something I’ve seen take several forms during application tests. It may affect application-level session IDs, or it could be some other token, or, as in this case, part of the web infrastructure that supports the application. While this isn’t a high risk vulnerability, per se, it is of interest in terms of secure application design. Rather than describe it, I thought I’d show you what it looks like.

subscribe via RSS