If you’re anywhere near the security community, you’ve probably already heard about the (supposed) end of TrueCrypt that inspired a massive hunt for an explanation on Reddit. I’m going to drop my thoughts here, but these are all just speculation, so take them for what they’re worth (which is not much).
The Facts as We Know Them
- TrueCrypt 7.2 dropped support for creating volumes. The code was massively changed, stripping out all volume creation options.
- The website was updated with terrible instructions. The directions for alternatives generally point to proprietary options (BitLocker, File Vault, or, to paraphrase, “whatever you can find on Linux.”)
- The new version is signed with the same key as previous versions. This implies whoever did the update is in possession of the key used for signing previous releases.
- Sourceforge doesn’t think the account was compromised as posted here.
- The author was forced to backdoor TC and chose this instead. This seems to be the most popular theory, and given the Snowden revelations, it’s easy to see why. Assuming the adversary in question is the US Government, this seems awfully heavy-handed, and I’m not sure under which legal authority they would attempt to compel this participation. NSLs compel the production of business records, but don’t seem to allow them to force a backdooring. CALEA is for communications tools, TrueCrypt is used for storage at rest. Even those who refer to LavaBit are referring to warrants. First LavaBit was ordered to turn over messages, then encryption keys, but I’m not aware they were ever ordered to backdoor their software. It also seems odd that government agencies would choose to go after disk encryption, seems like communications encryption would be the bigger source of intelligence. There are those who have claimed “the government can force you to do anything”, which I suppose is true, but if we’re at the stage of “backdoor your code or we treat you as a terrorist” then the game’s already over, we’re off in Stasi territory, and I’m not sure that’s a world I could live in. I hope this is not the story.
- The author tired of developing it and just gave up. This is a kind of odd approach, one would think they’d look for someone to hand the project to. I’m also not sure why someone who’d devoted years to developing secure encryption software would suddenly offer up terrible alternatives or otherwise deviate so strangely.
- A developer was compromised. While this might give access to the PGP key, I’d have thought by now we’d have some sort of communication somewhere to claim this has happened. Unless the developer is completely out of the loop as well. Why would someone use the compromise to offer up terrible alternatives as opposed to releasing backdoored binaries quietly?
- Off their meds. A couple of people have suggested that some sort of psychiatric problem is involved here. Actually seems a little reasonable, given the erratically written directions for alternatives, the sudden change in course, everything. Of course, there’s no evidence to support this, so it’s really just speculation.
I’ve turned off commenting as I think Reddit or Hacker News is a better place for such discussion, I just had a lot of thoughts I wanted to get out.
###Radare2 Book Maijin on GitHub is in the process of putting together an online book for Radare2. I’ve been looking for a good resource for using Radare2, and this is a great start.
###Reverse Engineering for Beginners Dennis Yurichev has a free eBook on Reverse Engineering. I haven’t gotten through it yet, but it looks interesting, and you can’t beat the price.
###Hacker Playbook Finally, I finished up The Hacker Playbook: Practical Guide To Penetration Testing this week. You can find my full review here.
Unlike most of the challenges in DC22 quals, this one required no binary exploitation, no reversing, just writing a little code. You needed to play 3-D Tic Tac Toe, and you needed to play fast. Unfortunately, I didn’t record the sessions, so I don’t have the example output.
Basically, you just received an ASCII representation of each of the 3 boards making up the 3d-tic-tac-toe environment, and were prompted to provide x,y,z coordinates for your next move. However, you had only a very short period of time (fractions of a second) to send your move, so playing by hand was impossible. The winner of each board was the player with the most rows won, and it did go to the full 27 moves each time. Also, it’s important to note that the player always goes first, and that you have to win 50 rounds in order to receive the flag.
I chose this basic algorithm:
- On the first move, play in the very center of the boards (1,1,1)
- For each subsequent move, consider each available position.
- Consider each row that the position sits on.
- If the row has both X and O on it, award 0 – the row is a lost cause.
- If playing would win that row for us, or block a win for our opponent (they have 2/3), award 3 points.
- If we already have something on that row, or they already have something on that row, award 1 point. We’re either making progress or blocking.
- Otherwise, no points.
- Sum the row points for each position, and play in the highest scoring position.
I had no idea if this algorithm would work, but it was actually successful resulting in the flag on the first try.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 #!python import re import socket REMOTE = ('3dttt_87277cd86e7cc53d2671888c417f62aa.2014.shallweplayaga.me', 1234) class TTT(object): def __init__(self, host, port): self.s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.s.connect((host, port)) self.state = [[[' ', ' ', ' '] for i in xrange(3)] for k in xrange(3)] self._buf = '' self._moves = 0 self._read_intro() self._read_state() self._print_state() def _read_intro(self): buf = '' while 'Play well and play fast....' not in buf: buf += self.s.recv(1024) self._buf = buf.split('and play fast....') def _read_state(self): buf = self._buf while True: if '\n' not in buf: buf += self.s.recv(2048) line, buf = buf.split('\n', 1) m = (re.match(' x.*z=([0-2])', line) or re.match('Choose .* x.*z=([0-2])', line)) if m: z = int(m.group(1)) continue m = re.match('([0-2]) (.) \| (.) \| (.)', line) if m: y = int(m.group(1)) for x in xrange(3): self.state[z][y][x] = m.group(x+2) if y == 2 and z == 2: break self._buf = buf def _send_move(self, x, y, z): self.s.send('%d,%d,%d\n' % (x,y,z)) def _print_state(self): print '\nMove: %d' % self._moves for board in self.state: print '[[' + ']\n ['.join(','.join(c for c in r) for r in board) + ']]' @staticmethod def _score_row(*row): x = 0 o = 0 for p in row: x += 1 if p == 'X' else 0 o += 1 if p == 'O' else 0 if x+o == 3 or (x and o): # All 3 filled or lost cause, we're fucked return 0 if x == 2 or o == 2: # Either blocking or winning a row return 3 if x or o: return 1 # Empty row return 0 @staticmethod def _find_diagonals(x, y, z): """This is terrible, but works.""" # Diagonals of 2 degrees of freedom if x == y: yield ((0, 0, z), (1, 1, z), (2, 2, z)) if x+y == 2: yield ((0, 2, z), (1, 1, z), (2, 0, z)) if x == z: yield ((0, y, 0), (1, y, 1), (2, y, 2)) if x+z == 2: yield ((0, y, 2), (1, y, 1), (2, y, 0)) if y == z: yield ((x, 0, 0), (x, 1, 1), (x, 2, 2)) if y+z == 2: yield ((x, 0, 2), (x, 1, 1), (x, 2, 0)) # Now the 4 big diagonals if x == y == z: yield ((0, 0, 0), (1, 1, 1), (2, 2, 2)) for dia in [ ((2, 0, 0), (1, 1, 1), (0, 2, 2)), ((2, 2, 0), (1, 1, 1), (0, 0, 2)), ((0, 2, 0), (1, 1, 1), (2, 0, 2))]: if (x, y, z) in dia: yield dia def _score_move(self, x, y, z): if self.state[z][y][x] != ' ': # Not a possible move return -1 # Straight rows score = self._score_row( self.state[z][y], self.state[z][y], self.state[z][y]) score += self._score_row( self.state[z][x], self.state[z][x], self.state[z][x]) score += self._score_row( self.state[y][x], self.state[y][x], self.state[y][x]) # Diagonals for d in self._find_diagonals(x, y, z): score += self._score_row( self.state[d][d][d], self.state[d][d][d], self.state[d][d][d]) return score def _optimal_move(self): # Initial move, go for center if self._moves == 0: return (1, 1, 1) # Score each position bestpos = None max_score = -1 for x in xrange(3): for y in xrange(3): for z in xrange(3): score = self._score_move(x, y, z) if score > max_score: max_score = score bestpos = (x, y, z) print bestpos, 'score:', max_score return bestpos def move(self): where = self._optimal_move() if where is None: m = re.search('You\'ve won [0-9]+ rounds', self._buf) if m: print m.group(0) self._moves = 0 else: self._send_move(*where) self._moves += 1 self._read_state() self._print_state() return True if __name__ == '__main__': ttt = TTT(REMOTE, REMOTE) while ttt.move(): continue print ttt._buf print ttt.s.recv(1024)
The Hacker Playbook: Practical Guide To Penetration Testing is an attempt to use a continuous series of football metaphors to describe the process of a network penetration test. Maybe the metaphors would work better for someone who actually watches sports, but I felt they were a bit strained and forced at times. That being said, the actual content and techniques described are solid and generally useful information. It’s arranged in the stages of a good penetration test, and reads like a strong guide for those relatively new to penetration testing. Unfortunately, it doesn’t set up general guides for each area as much as describing specific “plays” for each area, so once those techniques start to fall flat, it doesn’t leave you with a lot of depth.
- Chapter 1. Introduction is unsurprisingly lackluster, describing only the flow of the book and the benefits perceived by the author in thinking about the penetration test like a series of football plays.
- Chapter 2. Pregame – The Setup is all about getting into a position to conduct your test, including reconnaissance, scoping, and all of the prep required before the actual pentest.
- Chapter 3. Before the Snap – Scanning the Network will be familiar territory to anyone who’s used Nmap before, but goes into more depth and explores the other scanning tools, such as vulnerability scanners like Nexpose/Nessus, and how to get the most out of using your scanners (as well as how you can be covert when scanning).
- Chapter 4. The Drive – Exploiting Scanner Findings describes a step that too many pentesters do not follow. Altogether too many “penetration testers” deliver a report that is little more than straight output from a web security scanner. If clients wanted a Nexpose report, they’d just buy a Nexpose license and skip the pentester’s markup. The value of a pentester is in verifying findings, evaluating the real risk to the organization, and providing advice on remediation or mitigation. This chapter handily covers how you can not only verify scanner findings, but use them to pivot and escalate.
- Chapter 5. The Throw – Manual Web Application Findings really just scrapes the surface of the world of web. There’s so much to be covered in web that you really ought to go far beyond this and review The Tangled Web for an overview of the problems faced by modern web applications, and The Web Application Hacker’s Handbook for a more practical approach to web pentesting through vulnerability discovery and exploitation. However, if you’re going to be focusing on internal enterprise networks, the Playbook gives you some handy approaches to looking at internal webapps that you might find on a corporate network.
- Chapter 6. The Lateral Pass – Moving Through the Network covers basic Pass-the-Hash and other approaches to leverage the access you already have into more access. It’s important to see how far an attacker could take things, so pivot & escalate is critical, and this chapter provides a handful of plays that could fit the bill.
- Chapter 7. The Screen – Social Engineering is, again, just a brief preview into a topic far too deep to be adequately covered in a book as broad as this one. The plays here are quite basic, and focus on phishing-style social engineering, leaving out the many ways social engineering can be leveraged in reconnaissance, physical pentesting, and other scenarios.
- Chapter 8. The Onside Kick – Attacks that Require Physical Access was a little disappointing. While there are good parts to it (like the use of the Odroid U2 as a dropbox), nothing was particularly groundbreaking and I was hoping for a little more unique aspect to physical. (On the other hand, maybe I just want to live vicariously through this book – I don’t do get to do much physical pentesting.)
- Chapter 9. Special Teams – Cracking, Exploits, Tricks
- Chapter 10. Post Game Analysis – Reporting provides some sage advice on producing the report that gets you paid. Since I work on an internal Red Team, I don’t have to write the type of reports described here, but if you’re in a position to be writing reports, this will really help in crafting a clear and concise report. Most importantly: don’t ever hand a client a Nessus scan and expect to be getting paid.
- Chapter 11. Continuing Education is surprisingly thorough, though it is mostly a list of resources to help you find more things to try, such as conferences to attend, vulnerable targets to practice on, and more. There were a few vulnerable targets I hadn’t heard of, but will definitely be giving a try in the near future.
Overall, it’s an interesting book, and would definitely be good for someone who hasn’t been pentesting much, but ultimately, it’s just a collection of specific tasks (“plays” in the parlance of the book) that you can execute. I wasn’t expecting much more, and plays in there are solid, but eventually you’ll need to learn to craft your own plays, and I feel the book falls short there. It’s 294 pages and attempts to cover an entire field while remaining practical. Naturally, this is very difficult, and while there may be some shortcomings, Peter Kim manages to provide several useful plays, but probably best for those who haven’t yet developed their own playbook.