One of the things that has often confused me is how little good advice there is for reading large files efficiently when writing code.

Typically most people use whatever the canonical file read suggestion for their language is, until they need to read large files and it’s too slow. Then they google “efficiently reading large files in ” and are pointed to a buffered reader of some sort, and that’s that.

However, in Halvar’s recent QCon talk he had several slides talking about how most code is written based on the old assumptions of spinning disks. With non-SSD HD’s there’s usually a single read head and you can’t do much in parallel. This requires code to optimise for single reads, minimal seeks, and large redhead of data layed out on disk next to each other. But modern SSDs are much more comfortable with seeks and parallelism.

When I got a new MacBook with an M1 Pro chip, I was excited to see the performance benefits. The first thing I did was to fire up hashcat which gave an impressive benchmark speed for NT hashes (mode 1000) of around 9 GH/s, a solid doubling of the benchmark speed of my old Intel MacBook Pro. But, when it came to actually cracking things, the speed dropped off considerably. Instead of figuring out why, I decided to try my hand at writing my own NT hash cracker, because I’m kind of addicted to writing single use tooling in rust then taking time to perf optimise it.

If you’re only interested in the results, here it is, under a variety of scenarios against hashcat, and you’ll see it ranges from waaay faster to much faster than hashcat. You can get the code at https://github.com/sensepost/ntcrack/.

tl;dr
We reported a long standing PEAP bug in all Apple devices that would allow an attacker to force any Apple device (iOS, macOS or tvOS) to associate with a malicious access point, even if the authentication server (RADIUS) couldn’t prove knowledge of the password. To understand it fully, we go on a deep dive into EAP and MSCHAPv2.

I’ve started seeing WebAssemly (WASM) stuff popping up in a few places, most notably CloudFlare’s recent anti-container isolated v8 workload stuff and I wanted to understand it a little better, but from a hacker's perspective.

Docker For Mac (and Windows) has done some interesting tricks to bring Docker to non-Linux platforms. It took me a while to figure it all out, and even longer to work out how to make change to the kernel and rebuild the VM. This is a write-up of what I did and why. If you just want the results, you can grab them from https://github.com/singe/linuxkit-for-mac.

This was an epic week for password cracking, we had lots of new hashes and lots of competition to see who could crack the most the fastest.

BLUF: I put together a cracking technique, and tested it against other techniques, generating some insight into the best performing cracking techniques. Rockyou with hob064 rules won, but my technique came a close second, and had a faster crack speed. Get the script here.

You can use the technique with a list of common substrings from your own lists (sorry we can’t share ours). Or use the technique targetted specifically at a dump you’ve been going at to mine more cracks out of it.

I’ve long been interested in the physics of RF, but never had a chance to play with it until recently. This post covers my experiments with the propagation of 7MHz signals; the equipment, the setup, the code, the results and the science.

After seeing PaulG's tweet on bureaucracy it kicked off some quick thoughts.

The dangerous thing about letting your company become bureaucratic is that when the smart people leave, they won't tell you that’s why.

https://twitter.com/paulg/status/910519167949971456

Last weekend was the BSides Cape Town conference, currently ZA’s only hacker con. It’s a cool little con with big dreams that get a little closer each time. This year was a lot a fun and well put together, congrats to all of the speakers organisers and volunteers.

SP gave some talks; Charl spoke about where we’re headed in a talk entitled Love Triangles in CyberSpace; a tale about trust in 5 chapters. Chris discussed his DLL preloading work and released his toolset. Finally, Darryn & Thomas spoke about exploiting unauth’ed X sessions and released their tool XRDP, it was also their first con talk ever.

The other thing we did was run a CTF challenge off the back of the cool badge & CTF platform AndrewNoHawk and elasticninja built. This is a write up of that challenge.

In 2011 Glenn and Daniel released Snoopy, a set of tools for tracking and visualising wireless client activity. However, the Snoopy project is no longer maintained. This blog entry is about how I got Snoopy-like functionality built into Mana.

Last Saturday, at Defcon 24, we gave a talk entitled “Universal Serial aBUSe: Remote Physical Access Attacks” about some research we had performed into USB attacks. The talk was part of a research theme we’ve been pursuing related to hardware bypasses of software security. We decided to look into these sorts of attacks after noting their use in real world attacks. For example, you have “Apex predators” such as the NSA’s extensive use of sophisticated hardware implants, most notably for this work, the COTTONMOUTH devices. On the other end of the scale, we noticed real world criminals in the UK and ZA making use of unsophisticated hardware devices, such as hardware keyloggers, drive imagers and physical VPN devices and successfully making off with millions. This led us to hypothesise that there’s probably a large series of possible attacks in between these two extremes. We also noted that there’s not many decent defences against these sorts of attacks, it’s 2016, and the only decent defence against decent hardware keyloggers is still to “manually inspect all USB ports” (assuming this stuff is even visible).

And so, if we manipulate a wise man’s quote to say something we want it to say: “pentesters need to emulate real world attacks”. We’re hoping that with enough hackers equipped with these things, there will be enough “audit findings” to move the needle.

If you’re just here for the tl;dr:

• Code is at https://github.com/sensepost/USaBUSe
• Video demo is at https://www.youtube.com/watch?v=5gMvtUq30fA

With the recent buzz around the iMessage crypto bug from the John’s Hopkins team, several people pointed out that you would need a root CA to make it work. While getting access to the private key for a global root CA is probably hard, getting a device to trust a malicious root CA is sometimes phrased as difficult to do, but really isn’t. (There’s a brief technical note about this in the caveats section at the end.)

In our 2014 Defcon talk where we released the mana toolkit, we pointed out how stupidly easy it was to get a root CA installed on both iOS and Android devices with no hacking required. Two years later, not much has changed in the iOS world, except for a single extra unclear prompt.

There's a story that's been doing the rounds in the ZA press entitled; "Your private Facebook messages can be used in court against you even if you were hacked" It details a case "Harvey v Niland and Others" in the South African High Court, Eastern Cape Division where Facebook messages were deemed admissible in a case, despite having been obtained illegally.

This is pretty attention grabbing, and could have far reaching implications. Could someone hack my WhatsApp/Gmail/Facebook and use my private conversations to implicate me in a crime? What does this mean for my right to privacy over my communications, and does it change the status quo? Could out intelligence services hack citizens for mass dragnet surveillance ala the NSA? Does this have implications for the Cybercrimes bill?

At DerbyCon I made a point about IBM's security response procedures. It's a complex and subtle issue that won't carry well over Twitter. Here's my quick attempt at clarifying my personal view, hurriedly typed on a phone before I catch a flight.

DigiNinja wrote a set of patches for hostapd that allow it to operate in KARMA mode (i.e. respond to any probe in an attempt to fool wifi devices into joining it). His last set of patches were for v1.0. I spent some time porting them to v2.0 of hostapd.

The functionality is exactly the same (although the probe response is a little more aggressive), and you can grab either the patch or the full tarball here:

• hostapd-2.0-karma.patch (38K)
• hostapd-2.0-karma.tar.gz (1.4M)

If you want to clean them up, some context: the majority of the changes are based in src/ap/beacon.c and are due to the introduction of the new ssid_match() function. I initially had something fairly intelligent, but it got turfed as I debugged back to Robin's initial method. The big problem was that the probe response's SSID was being grabbed from the configured SSIDs instead of what was probed for. So I created a new _karma probe response method that took the SSID as a parameter.