During the DEF CON 26 DC101 Panel, someone (probably highwiz) asked one of the n00bs they brought on-stage, "What makes you a hacker?" In the past, it has been used by bad actors as an aggressive question. Thoughtful types and artists have used it as a prompt. But here it was dripping with curiosity. "Why do you go to DEF CON?"
I'm more than a year out from a move that took me far from my hometown of Las Vegas to an adventure into the Pacific Northwest. Budgets, family and time being what they are, I too had to ask myself, "What makes you a hacker? Why should you go to DEF CON, again?" Obviously, moving two states makes it harder to go. Plane tickets are cheap enough in cattle-class, and I'm lucky to have family and friends in town upon which I can rely for lodging. But family illness and obligation are also considerations, and this feeling in the pit of my stomach topped it all off: the idea that I no longer belonged.
Ironically, this security-focused community is affected by deep insecurities. Concerns of legitimacy, competence, and belonging haunt us collectively, as do public examples of snake oil, burnout, and depression. Discussions of Impostor's Syndrome are almost cliche in their frequency. As is the mouth-agape disbelief following one of our rock stars admitting they second-guess themselves. This loose band of social misfits and punks emerged from in our cocoon of BBSes and IRC to be famously dysfunctional. We have had to exorcise #MeToodemons, and our unhealthy relationship with alcohol keeps many away for fear of their own safety. As a late-comer to DEF CON, I have not been personally affected by loss of friends in the community, but there's a reason Amber Baldet gave a talk on Suicide Interventions at DC21. Hackers in my cohort are maturing as well. Some of us are on their third career since the demoscene, and it has veered wildly away from any Information Security role. There has to be something that keeps us coming back to the desert in August. It sure ain't the unmistakable fragrance of Sunday morning talks.
It is a bit of a balancing act to maintain a conference that keeps drawing more and more people. As of this writing, DC28 is scheduled to use almost 400,000 sq. ft. of conference space in a brand new facility. Almost 30 villages with both broad and niche topics have formed, and each is a mini-con in and of itself. Along with this widening scope, there were public and repeated attempts by The Dark Tangent to reestablish DEF CON as a Hacker event and set it apart from the Information Security industry where so many of its attendees find employment. In the past, DT has publicly disinvited the Feds, and the run-up to DC27 saw another public clarification that while individual villages arrange their own sponsorship, DEF CON maintains no corporate sponsors. You can see the push and pull of "What makes you a hacker?" at the highest levels.
And so we approach a new year and a new DEF CON. Since DC19, I've grown with the conference. I started managing Toxic BBQ with the help of friends and this will be our fifth consecutive kick-off barbecue. People just show up to create an inviting space from scratch for anyone that can find it. I won a Black Badge with my son at DC 26 by solving crypto puzzles and have tried to contribute in equal measure since then. And yet there's this nagging feeling...
Ultimately, I've decided the gate-keeping question is not an important one to answer. What I give to and get from DEF CON keeps me going. I'm comes down to a desire to think things I have never thought before. I may not be able to show off like some, but I can gawk with the best of them at the Hacker Carnival. DC28's theme, Discovery!, is right out of my high school years when the internet promised the sum-total of human knowledge at our fingertips and all that we could do once those barriers dropped. Maybe we can celebrate by shedding our insecurities. Just for the weekend.
Three years ago in July, I completed Dan Boneh's online cryptography course with distinction through Coursera's Cryptography 1. Since then, I've had the opportunity to use and test cryptographic systems at work and for hobbies. Here are a few lessons learned when testing encryption.
I have found my fair share of bugs in the crypto we chose to use at work. I've gotten into a routine when testing encryption used for message authentication:
Test the same plaintext multiple times. Does it need to be different each time? How much of the MAC is different each time? It might help to explore the data your hashing function spits out as it can tell you how your hash function does what it does.
Replay it. How can a user abuse identical MAC'd data if they replay it at a later date? For a different user? Can you add items to the plaintext that will allow you to validate not only the data but the source or timeframe as well?
Ensure your hashes are detecting changes. Is your MAC rejected if you change the data at various places within the message?
Rotate the key. Do you need a hash to survive a key change? Usually you can just regenerate the data and re-MAC it, so figure out if you really need to use MACs over long lifetimes. They're easy to compute.
Generate a bunch at once. Is performance an issue with the service? Most hashes are built for speed, but is yours?
For each of these failure modes, I'm looking mostly for hints of weakness. I'm expecting pseudo-random noise, but how does my brain distinguish that from almost random noise?
There are many times when you need to generate a unique but random value but don't have the space to use a GUID. To evaluate if a solution will be "unique enough", check out the Birthday problem wikipedia page, and this table of probabilities in particular. Find out how many possible values exist (9 numeric digits = 10^9 ~= 2^30). Compare on the table with that value as the hash space size versus the number of times you'll be setting this value. This will tell you if the algorithm you want to use is sufficient. If you are making long-term IDs that can only be created once, you obviously want the probability of collision to be extremely low. If you can recover from a collision by creating a new transaction fairly readily, you might not need as much assurance. Ive used this to help drive a decision to increase unique token size from 13 to 40 characters, guide switching from SQL auto-numbers to random digits to hide transaction volumes, and ensure internal transaction IDs are unique enough to guide troubleshooting and reporting.
Time and again, the past three years have taught me that cryptography must be easy for it to be used widely. I've stayed with Signal for text messaging because it just works. I can invite friends and not be embarrassed at its user interface. It doesn't tick all the boxes (anonymity is an issue being a centralized solution), but it has enough features to be useful and few shortcomings. This is the key to widespread adoption of encryption for securing communications. Since Snowden revealed the extent of the NSA's data collection capability, sites everywhere have switched on HTTPS through Let's Encrypt. Learning more about each implementation of SSH and TLS in the course was both informative and daunting. I was anxious to get HTTPS enabled without rehosting the site on my own. Early 2018, Blogger added the ability to do just that through Let's Encrypt. It requires zero configuration once I toggle it on. I can't sing its praises enough. The content of this blog isn't exactly revolutionary, but this little move toward a private and authentic web helps us all.
Dan Boneh's Cryptography course continues to inform my testing. The core lesson still applies: "Never roll your own cryptography." And the second is how fragile these constructs are. Randomness is only random enough given the time constraints. Secure is only secure enough for this defined application. Every proof in the course is only as good as our understanding of the math, and every implementation is vulnerable at the hardware, software, and user layers. In spite of this, it continues to work because we test it and prove it hasn't broken yet. I'm looking forward to another three years of picking it apart.
A friend returned from San Diego Comic Con 2018 with an RFID bracelet used to track users in the Amazon Fire TV experience (on Twitter, #FireTVSDCC). This is a teardown of the bracelet after the event. At this time, I was unable to read from the bracelet.
The bracelet is fairly simple with a cloth band and plastic/paper tab threaded through. The closure is plastic and one-way. It bites into and mangles the cloth band if you attempt to remove, but you could probably shim it with tools and practice. Might be a fun thing for the Tamper Evident Village if it turned out events were trying to use this for access control like plastic self-destructing wristbands.
The back contains a serial number. I would like to see if this serial number would match the data read off the tag.
Separating the badge by prying them apart, I spot the prize: an adhesive RFID tag placed between the glossy plastic covers. It appears to have a model number of "CXJ-040" in the center of the tag. It uses a circular antenna. CXJ is the initials of Shenzen manufacturer Chuangxinjia. Their product pages show manysimilarwristbands in a few different frequencies.
The tag didn't respond to my Android phone, so it is not a Mifare or similar. Hopefully I can find a reader at the local Hackerspace or DEF CON 26.
It turns out that using the convenience function ENCRYPT$ENCRYPT_ONE_RECORD on OpenVMS for AES CBC does something squirrelly. It will not let you pass in an IV. Instead, ENCRYPT$INIT sets the IV to 16 bytes of \0. In order to ensure your identical plaintext first blocks aren't identical after encryption, your first 16 byte block needs to be your true IV. This will get XORd with the null byte encrypted IV and sufficiently scrambled so your second block can be uniquely encrypted. OR just do it right and avoid the convenience method. Use ENCRYPT$INIT properly.
"For AES, the optional P1 argument for the AES IV initialization vector is a reference to a 16-byte (2 quadword) value.
If you omit this argument, the initialization vector used is the residue of the previous use of the specified context block. ENCRYPT$INIT initializes the context block with an initialization vector of zero."
Above is Dan Kaminsky's keynote at the inaugural DEF CON China. It was nominally about Spectre and Meltdown, and I thought it was immediately applicable to testing at all levels. Here are some moments that jumped out at me:
On Context:
"There's a problem where we talk about hacking in terms of only software...What does hacking look like when it has nothing to do with software." 1:55
"But let's keep digging." Throughout, but especially 5:40
"Actual physics encourages 60 frames per second. I did not expect to find anything close to this when I started digging into the number 60...This might be correct, this might not be. And that is a part of hacking too." 6:10
"Stay intellectually honest as go through these deep dives. Understand really you are operating from ignorance. That's actually your strong point. You don't know why the thing is doing what it is doing...Have some humility as you explore, but also explore." 7:40
"We really really do not like having microprocessor flaws...and so we make sure where the right bits come in, the right bits come out. Time has not been part of the equation...Security [re: Specter/Meltdown] has been made to depend on an undefined element. Context matters." 15:00
"Are two computers doing the same thing?...There is not a right answer to that. There is no one context. A huge amount of what we do in hacking...is we play contexts of one another." 17:50
[Re: Spectre and Meltdown] "These attackers changed time which in this context is not defined to exist...Fast and slow...means nothing to the chip but it means everything to the users, to the administrators, to the security models..." 21:00
"Look for things people think don't matter. Look for the flawed assumptions...between how people think the system works and how it actually does." 35:00
"People think bug finding is purely a technical task. It is not because you are playing with people's assumptions...Understand the source and you'll find the destination." 37:05
"Our hardest problems in Security require alignment between how we build systems, and how we verify them. And our best solutions in technology require understanding the past, how we got here." 59:50
On Faulty Assumptions:
"[Example of clocks running slow because power was not 60Hz] You could get cheap, and just use whatever is coming out of the wall, and assume it will never change. Just because you can doesn't mean you should...We'll just get it from the upstream." 4:15
"[Re: Spectre and Meltdown] We turned a stability boundary into a security boundary and hoped it would work. Spoiler alert: it did not work." 18:40
"We hope the design of our interesting architectures mean when we switch from one context to another, nothing is left over...[but] if you want two security domains, get two computers. You can do that. Computers are small now. [Extensive geeking out about tiny computers]" 23:10
"[RIM] made a really compelling argument that the iPhone was totally impossible, and their argument was incredibly compelling until the moment that Steve Jobs dropped an iPhone on the table..." 25:50
"If you don't care if your work affects the [other people working on the system], you're going to crash." 37:30
"What happens when you define your constraints incorrectly?... Vulnerabilities. ...At best, you get the wrong answer. Most commonly, you get undefined behavior which in the presence of hacking becomes redefinable behavior." 41:35
"It's important to realize that we are loosening the assumption that the developer knows what the system is supposed to do...Everyone who touches the computer is a little bit ignorant." 45:20
On Heuristics
"When you say the same thing, but you say it in a different time, sometimes you're not saying the same thing." 9:10
"Hackers are actually pretty well-behaved. When hackers crash code...it does really controlled things...changing smaller things from the computer's perspective that are bigger things from a human's perspective." 20:25
"Bugs aren't random because their sources aren't random." 35:25
"Hackers aren't modeling code...hackers are modeling the developers and thinking, 'What did [they] screw up?' [I would ask a team to] tell me how you think your system works...I would listen to what they didn't talk about. That was always where my first bugs came from." 35:45
On Bug Advocacy
"In twenty years...I have never seen stupid moralization fix anything...We're engineers. Sometimes things are going to fail." 10:30
"We have patched everything in case there's a security boundary. That doesn't actually mean there's a security boundary." 28:10
"Build your boundaries to what the actual security model is...Security that doesn't care about the rest of IT, is security that grows increasingly irrelevant." 33:20
"We're not, as hackers, able to break things. We're able to redefine them so they can't be broken in the first place." 59:25
On Automation
"The theorem provers didn't fail when they showed no leakage of information between contexts because the right bits went to the right places They just weren't being asked to prove these particular elements." 18:25
"All of our tools are incomplete. All of our tools are blind" 46:20
"Having kind of a fakey root environment seems weird, but it's kind of what we're doing with VMs, it's what we're doing with containers." 53:20
On Testing in the SDLC
"We do have cultural elements that block the integration of forward and reverse [engineering], and the primary thing we seem to do wrong is that we have aggressively separated development and testing, and it's biting us." 38:20
"[Re Penetration Testing]: Testing is the important part of that phrase. We are a specific branch of testers that gets on cooler stages...Testing shouldn't be split off, but it kinda has been." 38:50
Ctd. "Testing shouldn't be split off, but it kinda has to have been because people, when they write code, tend to see that code for what it's supposed to be. And as a tester, you're trying to see it for what it really is. These are two different things." 39:05
"[D]evelopers, who already have a problem psychologically of only seeing what their code is supposed do, are also isolated from all the software that would tell them [otherwise]. Anything that's too testy goes to the test people." 39:30
"[Re: PyAnnotate by @Dropbox] 'This is the thing you don't do. Only the developer is allowed to touch the code.' That is an unnecessary constraint." 43:25
"If I'm using an open source platform, why can't I see the source every time something crashes? ...show me the source code that's crashing...It's lovely." 47:20
"We should not be separating Development and Testing... Computers are capable of magic, and we're just trying to make them our magic..." 59:35
Misc
"Branch Prediction: because we didn't have the words Machine Learning yet. Prediction and learning, of course they're linked. Kind of obvious in retrospect." 27:55
"Usually when you give people who are just learning computing root access, the first thing they do is totally destroy their computer." 53:40 #DontHaveKids
"You can have a talent bar for users (N.B.: sliding scale of computer capability) or you can make it really easy to fix stuff." 55:10 #HelpDesk
"[Re: Ransomware] Why is it possible to have all our data deleted all at once? Who is this a feature for?!... We have too many people able to break stuff." 58:25
To be fair, no company should have to sift through an
automated report from a static analysis tool.
It’s not worth their time. In
fact, the tone of the Oracle Blog that isn’t completely unproductive is, “Do
the research for yourself! Give me
exploits or give me death!” As a Tester,
this is the core of bug advocacy, and I want to destroy the trust lazy
researchers put in automated scanners, lazy managers put into automated checking, and the lack of human
interaction endemic in development in general.
That being said, chiding someone for spending their own coin
to find a exploit with, “But you really shouldn’t have broken the EULA. Nanny Nanny Boo Boo,” is unproductive at best
and an invitation to become the target of malicious actors at worst. No one cares about your EULA. Not even the government gives it the time of
day. Your tantrum just makes that many
more people want to do things to piss you off.
I took Ethan to the event run in parallel with DEF CON, R00tz Asylum. I think he had a blast as they covered a lot of traditional hacker topics at multiple levels of complexity. The highlights are below.
Structure
The event was held in the Crown Theater at the Rio. It was about a 10 minute walk from DEF CON proper. The separation was nice as it made for a more quiet and contained experience. The stage was occupied by a speaker almost all the time. Spread around the perimeter (mezzanine?) were tables with activities that changed every day. Kids could choose to listen, play or work on challenges. Most activities stayed the entire day, though some were more transient.
This setup was advantageous for my son. He has little ability to focus on any one thing for an extended period of time, so the variety of activities was nice. Much like its parent conference, R00tz Asylum did well when it focused on hands-on learning. Toool, Google and Wickr held contests and learning opportunities that pushed attendees and their parents to participate together. In particular, Ethan loved the puzzles, and I finally got him to solder something. He did a bang-up job.
Speakers
The speaker experience was less than optimal with a few notable exceptions. The stand-outs were Gene Bransfield's hilarious "Weaponizing your Pets" and Meredith Patterson's engaging activity "The Telephone Game" about Man-in-the-Middle attacks. Special mention goes to @muffenboy and Esau Kang for being kid attendees and speakers. For the rest, it would be good to learn that speaking to children is not the same as speaking to hackers, and most talks were too technical, lacked a hands-on component, and thus ended up being torture for the little ones. From speaking with the organizers, I can tell this is something they are trying to focus on next year.
The Gift
R00tz Asylum is the opposite of DEF CON in one respect: it relies on sponsors to add pizzazz and to make ends meet. One of those traditions that may or may not hold in coming years is the gift of a hackable piece of technology to attendees. This year brought ASUS Chromebooks care of Google. My son was enthralled, and I spent most of the conference convincing him to get off the Chromebook and out to the activities. By the end of the conference, we had Linux in addition to Chrome, and we were running Wireshark thanks to perseverance by Joe and Chris, a father/son team. This effort won Chris a trophy, even. My son begged me to put Minecraft on there, but then quickly forgot how to get back to it and reformatted his Chromebook undoing all our hard work. Hats off to Google, and congrats to Chris on the win.
Hardware Hacking
By far, my favorite part of the conference was the Hardware Hacking table. Not only did the goodie bag include a HakTeam Throwing Star LAN Tap, but a table full of old equipment was available from which attendees could rip apart and salvage components. The LAN Taps were used in an activity that taught wireshark and packet sniffing. The hardware component salvage table was exploited for speakers, LEDs, gears and motors for all sorts of toys. I am definitely bringing projects for Ethan next year. I already recommended the salvage table to the official DEF CON Hardware Hacking Village. Las Vegas thrift shops may see a run on their printers, VCRs and routers before next year's conference.
Lock picking
The one talk and table I was surprised that Ethan was interested in was from Toool. Their interactive 101 talk caught his attention, and we worked on a lock at their companion activity table. Though he ended up losing interest before successfully opening a lock, it gave me a clue of the type of activity he could do on his own between conferences.
Going Forward
I would definitely recommend any hacker parent to bring their child to R00tz Asylum. Its expanding and evolving to be a great summer camp weekend that dovetails with the DEF CON experience. As the organizers ger more experienced, I expect the content to grow and change to fit the kids and their interests. We all started somewhere, and I hope R00tz is that start for the next generation. I started a subreddit for R00tz, though it hasn't taken off.
As for Ethan and I, we are preparing a talk on how to hack Skylanders figures. We hope it will be a fun combination of encryption, hardware hacking and games that will draw the attention of attendees and inspire them to really dig in and explore the technology that is used around them every day.
This post is part of a series about building electro-mechnical PIN-cracking robots, R2B2 and C3BO.
This is a proof of concept for @JustinEngler's C3BO (https://github.com/justinengler/C3BO) using transistor controlled relays. It was prototyped by modifying Blink from the Arduino sample project.
In the video, You'll notice I've replaced the touchpad for your finger with a wire to the headphone jack's ground as the circuit ground. The two pieces of copper tape were no longer sticky enough to stay by themselves, so I am holding them down. They press two and 5 with about 8 key presses per second.
A hackable iOS App used to teach the OWASP Top Ten Mobile App Vulnerabilities. Great tool to catch up with mobile security and secure application design.
The above tweet by Dan Kaminsky really got into my system. As someone who makes lists of things to do, I often get trapped planning more than doing. Since DEFCON 21, I have tried to focus on doing. Here is a list of my successes so far:
Rooted my Sony Ericsson Xperia Play and installed Cyanogenmod 9.
Studied Arduino and created a few basic projects.
Started following security wonks on Twitter and have become fairly well-versed in the conversation.
Where to go from here?
Hack Skylanders and Disney Infinity using tag writers and custom code.
Help Ethan get through Scratch manual. He has had a blast so far.
Creating a product in Arduino. Planning a card swipe emulator to apply my skills to real world annoyance.
And probably most important: settle on a handle. VegasVic?
