• Digimode Playground Transceiver

    I’ve harmonized some of my thinking around the various experiments I’ve done recently, and decided I was ready to bring a bunch of ideas together in a big experiment. This post details my adventure trying to use the full 10x10cm of a JLC PCB order… or… how I made a double conversion superhet SDR transceiver and learned a whole lot!

  • IQ Phase Detection

    Continuing from my last post, where I built a digital IQ modulator for generating a carrier at any amplitude and phase… this post is about some investigation of phase detection and demodulation. I carried out three separate experiments, which make me hopeful that I could actually build a non-coherent demodulator for low baud-rate amateur radio digital modes.

  • Digital IQ Modulation

    I was greatly inspired by this video from W2AEW, where Alan shows the use of an IQ modulator to generate amplitude and phase modulated signals. I’ve enjoyed playing with simple FSK modes, using an Si5351 and changing its frequency to modulate data (played with Hellschreiber, WSPR, and RTTY, for example). But the idea of trivially generating PSK and QAM signals with a couple of mixers was intriguing.

    This blog post is about my initial adventure, building an IQ modulator, playing with it, and making some enhancements…

  • Trusting the NanoVNA?

    While working through some questions around impedance matching amplifiers, one of my mentors asked how confident I am in the measurements I get from the NanoVNA. I haven’t really run into a situation where it severely mislead me, but I had never really done anything to test its reliability. He suggested I measure a few values of resistors and capacitors and just check to make sure what we were seeing on the amplifier might be measurement error. That’s what this post is about!

  • DIY Load Pull Analysis

    This blog post is about the first step in what feels like a big project for me – but one that I hope will resolve a lot of outstanding questions I have about impedance matching and power amplifiers. This is my journey to create an in-home DIY load-pull analysis lab for characterizing and understanding transistors.

  • Impedance Matching the IRF614 with the NanoVNA

    I have been experimenting with the IRF614, which is off the beaten path for amateur radio power amplifiers. I was interested in some of the different specs from the IRF510, which is quite popular. Tonight I wanted to play with impedance matching, and see what difference a matched input would make. This blog post documents my experiment and my findings.

  • My First Transceiver

    This post documents my first homebrew transceiver, from the ground up. By this point, I’ve built enough prototypes for different types of block elements that I might use, and it’s time to put it all together to make a real thing! I think I’d underestimated all of what goes into such a project, and I learned a whole lot from this adventure!

  • Testing the BGA2866 MMIC amplifier

    I’ve had a very hectic summer, thus far, with some vacations, house renovations, and other excitement. So it’s been awhile since I wrote up a blog post. Actually, it’s been awhile since I built anything, ugh! But today I put together a small test board to exercise the BGA2866 MMIC amplifier, and the details are what’s in today’s post.

  • An HF Power Amplifier with Real RF Transistors

    As I near construction of a full-suite transceiver, I’m prototyping each of the major components to make sure they’re likely to work. This post is about a simple class-C power amplifier; different from my other ones I’ve blogged about, this is a pretty straightforward design, but with one important twist. I’m actually using transistors that are designed for RF power amplifier applications. I know, I know… sounds crazy, but it came out really well!

  • A 60dB Attenuator

    This is just a short little post, but I had to share. I suppose when one adds a binocular microscope to the home lab for building projects, one needs to find things to do with it. But this little project came out pretty well! I realized while testing my RF board in my last post that I just can’t make signals quiet enough to test receiver sensitivity. So I needed a big attenuator – here’s the result: a 60dB attenuator, in a svelte little package:

  • Another Receiver Board

    I’ve now built a couple of Tayloe detector-based receivers, and thought I should try my hand at one that’s a little more traditional. This post describes an analog double sideband direct conversion receiver, and documents my results. It’s not ultimately a very good receiver, but going through this process taught me some things, and I’ve come away from it with thoughts on where I’ll go next.

  • RF Receiver Board

    Moving on from amplifier experiments, I’ve gone and built a little RF receiver. It’s a direct conversion design, intended to produce output at line input voltage levels for use with a sound card or microcontroller ADC. This is another important step toward my goal of making a complete homebrew digital mode transceiver.

  • Coax to stereo audio connector

    OK, this is a little thing, but I couldn’t believe I can’t find this kind of connector inexpensively on Amazon. So tonight, I whipped up this little PCB and soldered on some connectors. So, now with my RF receiver experiments, where I’m putting out I and Q signals into stereo headphone jacks, I can easily see them on the oscilloscope!

  • Acclimating JS8 to Raspberry Pi

    Operating in ham radio, my favorite thing so far is the rag chew. Longer conversations, where you get to meet someone, learn about them. Really, the biggest reason I got into ham radio was to connect with a community of nerds. So of course, JS8 is one of the most wonderful digital modes, allowing conversational communications even with sketchy propagation and bad conditions.

    One frustration I’ve had, though, is that I run my transceiver with a raspberry pi at a lower resolution over VNC. With the default look and feel, the JS8Call software is not ideal. The spacing is wasteful, and the colors are not particularly pleasant. This past week, I spent some time customizing JS8Call, and I think I’ve got some pretty good enhancements to the U/X going on. I thought I’d share what I’m playing with in this post.

  • Some simple audio DSP for CW RX

    I recently picked up an FT-818 amateur radio transceiver. It’s a wonderful little thing, with lots of features. But it’s an older design, and doesn’t have a lot of filtering for audio enjoyment. Worse, I’m a cheapskate and don’t want to spring for an expensive add-on filter.

    Today I played around with one of my Teensy 4.0 microcontrollers, which can be used for some pretty powerful audio digital signal processing (DSP). This post is about some real improvements I was able to achieve, with parts I have on hand around the house.

  • IQ Sampling and Phasing Receivers

    IQ sampling is a technique used all over the place, from hobby software defined radio (SDR) systems to cell phones. Even though I’ve been an SDR enthusiast for a number of years, the underlying principles that make IQ sampling work have been a mystery to me. Recently, I’ve turned my attention to RF receiver design, and some thought experiments have really opened it up to me.

    This blog post presents what I think is the best intuitive, math-lite explanation of IQ mixing, why it’s significant, and how it works in phasing receivers (and lots of real-world devices).

  • Tweaks for push pull gate driver amplifier

    Continuing from my successful attack on thermal issues, I did some more measurements of the amplifier. I’ve now tweaked a few things that improved some more issues. The result is a little more power, a little better efficiency, and some improved (and safer) operation.

  • Amplifier - solving thermal issues

    Last time, my amplifier worked great. I did some testing on the air, got 8 watts of power out, etc. But one issue popped up – transmitting for a little while heated something up and produced some odd changes in power output and current consumption. With some gracious and patient help from some smart people, I’ve figured out what caused it, fixed it, and come out way ahead of where I thought I was!

  • Push-Pull Gate Driver Amplifier

    Building on the gate-driver based power amplifier, I have built a more powerful version that uses two gate drivers into a 180-degree combiner. This push pull arrangement yields increased power, but also raises interesting new questions that I hope to answer as I learn more.

  • Creating a Usable Hellschreiber Font

    After my previous success transmitting Hellschreiber with my gate driver-based amplifier, I thought I’d flesh things out in more detail. One thing I needed to figure out was how I am going to store the font for transmitting arbitrary text using Hellschreiber.

  • Gate driven Hellschreiber beacon

    Today I did some more experimenting with the gate-driver based amplifier I built this week, and whipped up a fairly performant little transmitter today. This post describes the layout, some new performance data on the amplifier, and an explanation of Hellschreiber transmission. I tested it as a “beacon” of sorts (really just a PoC!).

  • Gate Driver RF Amplifier

    My last experiment was an attempt to create a driver amplifier that could get sufficient power into an IRF510 power transistor to make a few watts, and it was successful. But it was not ideal for my longer term goals – it was a class AB design that illustrated some issues with a push-pull driver arrangement, and is needlessly wasteful because I don’t need a linear amplifier for the transceiver I want to build.

  • Building and measuring my first few-watt RF amplifier

    I have a medium term project in mind involving a portable HF digital mode transceiver. To get there, I need to build a lot of individual components that will come together in the final system. The most challenging so far has been developing an acceptable output power amplifier.

    For a little bit of background, this type of hardware will enable me to communicate using digital communications modes like RTTY, PSK31, or (my favorite) Hellschreiber. One important key is to get enough power out that the recipient can actually hear the transmission, and that requires an RF power amplifier.

    There are lots of published designs, but my goal is ultimately self educational here. So I don’t want to just use a kit amplifier, or simply replicate a circuit from a project book. I want to slog through the process of design, understanding each piece that goes into it, so that I know I’ve learned these things. My tentative benchmark is that my 6 year-old should be able to point to any part, and I should be able to explain what it is and why it’s there!

  • Windows Compression API

    From time to time, security software (read: hacking tool) needs to send blobs of data around. It’s nice to keep those blobs as small as possible, so compression is useful. While building infrastructure in EvilVM, I want to live off the Win32 land as much as I can, but compression has been a difficult problem. I don’t want to write my own routines (compression algorithms aren’t the most fun to write and debug), and the code would be costly in terms of size.

    Lots of hacking tools just include zlib and call it good, but there’s no C-based foundation in EvilVM. It’s made from x86_64 whole cloth, as it were, so it needs a lighter solution. This blog post is about how I can make use of the Win32 Compression API, which has been around since Windows 8 or so. I had to solve several interesting problems along the way, so I hope you enjoy the read.

  • Decoding Win32 Constants

    Whether writing shellcode, using some language’s FFI, or working on my EvilVM malicious compiler project, sometimes I need to know the value of a constant for calling some Win32 function. Sometimes, you can find the values in the MSDN documentation. But other times, it’s not so easy. Check this one out, from the MS documentation for opening process handles:

    Missing Constants

    What’s interesting on this one is that the actual value, from the header files, does not equal the value you’d get if you took all the other ones and OR’d them together. Maybe it doesn’t matter, but it’s nice to know what the right value is.

    In other cases, constants are members of an enum, and MS doesn’t give you the value in the docs, or maybe they just left it out to be mean. This post is about how I find the values, since I run into it quite a bit when I’m writing hacking tools in something other than C.

  • Hacking Quest For Glory III

    My kids and I are playing through the Quest For Glory games. I’m pretty sure QFG qualifies as my third parent – I spent a lot of time playing these games when I was a kid! I remember all the nooks and crannies well enough, my kids come up and ask random questions and I can rattle off the answers. My hope is that they grow up just like I did (because I turned out mostly alright, didn’t I?).

    I always like to max out my stats before moving on to the next game. You can get up to n * 100 in each skill for game n. I’m not perfect at it – some skills are harder to max out than others (I’m looking at you luck!). But while grinding in QFG3, the boys and I started talking about hacking it, and one thing lead to another…

  • 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 //$ -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.

  • EvilVM 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


    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