System Overlord

A blog about security engineering, research, and general hacking.

Reading List for 5/9/2014

09 May 2014 in Security (Reading time: 2 minute)

###On XTS Mode for Disk Encryption Thomas Ptacek writes You Don’t Want XTS, and suggests that though XTS works well enough in practice, it is far from ideal for Full Disk Encryption, and should not be used at all for other encryption operations (i.e., anything that doesn’t resemble FDE). XTS is useful only in that it makes “random access” encryption more secure, as you need for a disk. For encryption of whole blocks of data at rest, you probably want CBC mode, and for anything on the wire, AES-GCM is the new hotness.

###The Six Dumbest Ideas in Computer Security mjr has a post on The Six Dumbest Ideas in Computer Security. I actually disagree with several of his points (but, of course, I work on a Red Team doing, among other things, penetration testing), but I think it’s good and important to hear about opposing views, and if nothing else, they make you think. Specifically, he seems to think penetration testing is about finding holes to be fixed. It’s not, though that is a nice outcome. Penetration testing is about seeing how an attacker moves through your network, understanding the interconnections, the lateral movement, the mindset of the attacker.

###Fishing for Hackers Draios has an interesting post on what attackers do on a system. To me, the most interesting part was not actually the actions, but a tool sysdig that I’d never heard of before. Looks like an interesting tool I’ll need to play with and see how useful it is in analyzing software behavior.

Announcement: PwnableWeb Released

08 May 2014 in Security (Reading time: 4 minutes)

In addition to my primary interest in the technical aspects of information security, I’m also a big fan of wargames & CTFs as educational tools, so a while back, I decided I wanted to build a web-based wargame and CTF scoreboard system. Today I am releasing the results of that, dubbed PwnableWeb, under the Apache 2.0 License. It includes web-based wargame-style challenges and an accompanying scoreboard.

###The Framework Each vulnerable site is built on top of a small framework that provides common functionality, and also provides a framework for building a client for interactive exploitation. (It provides a target to exploit XSS and XSRF against.)

The current framework is written in Python, using Flask and SQLAlchemy for speed of development. The vulnerable apps so far run just fine with a sqlite DB, but I usually use MySQL. This isn’t for load, but because SQLi is more interesting against the sort of DBs that are commonly used in the “real world”.

###The Games Currently, there are 2 games with a total of about a dozen vulnerabilities. One is a shopping cart system and the other is a microblogging platform. I do have plans to add a couple of more games in the near future, and will probably include new platforms (PHP being the top priority) to demonstrate new classes of vulnerabilities (LFI/RFI, serialize, preg ‘/e’, etc.) and provide variety.

Obviously, to a certain extent, open sourcing these games makes them less useful for a “real” CTF: players can easily have seen these before and become aware of where the vulnerabilities are. (And what the default flags are.) However, I believe they are still useful for practice for CTF teams, for use in educating developers, or even for internal CTFs where people are unlikely to have seen this before or you just don’t care.

GitHub repository: https://github.com/Matir/pwnableweb

###The Scoreboard The scoreboard resides in its own git repository because, though released as part of the PwnableWeb “suite”, it is completely independent and is designed to be usable for any CTF scoreboard. Currrent features include:

  • Unlockable hints
  • Locked/unlocked question state
  • Support for Teams and Individuals

Future development priorities:

  • File management for pwnables
  • Real-time updates via push messaging

GitHub repository: https://github.com/Matir/pwnableweb-scoreboard

###Notes on Running It Do not run these on a server shared with anything else. The vulnerable applications contain, well, vulnerabilities. Some of these vulnerabilities may lead to RCE as the user running the application. Run them in a dedicated VM or physical machine. In the near future, I plan to provide a VM image for super-easy-setup.

###Conclusion/Contributing There will be quite a bit of polish being applied to the current release over the next few days; it’s admittedly very raw and could use better documentation and configuration examples, but I’m happy to be able to release it at this point.

If you end up using this for something, I’d love to hear about it, and hear about your experience using it. I’m also quite open to pull requests, suggestions, and feedback.

Book Review: Red Team Field Manual

02 May 2014 (Reading time: 3 minutes)

I recently picked up a copy of the Red Team Field Manual on Amazon after hearing good things from a few people in the industry. It’s information dense, basically a concatenation of cheat sheets for everything you’d want to do during a pentest. I’m mostly a Linux/Unix guy, and given my role on an internal red team for a mostly Linux company, I don’t do a lot of Windows. However, I recently had an engagement where we were targeting Windows, and I wish I’d had the RTFM handy then: there are a number of great pointers for Windows that I could’ve leveraged to make my engagement go more smoothly. Additionally, the book provides coverage for other platforms, like Cisco IOS, and for various scripting situations in Powershell, Python, or even Scapy.

Here’s the complete list of coverage from the table of contents:

  • *NIX
  • Windows
  • Networking
  • Tips and Tricks
  • Tool Syntax
  • Web
  • Databases
  • Programming
  • Wireless
  • References

There are also various tables of pure information scattered throughout the book, ranging from an ASCII chart to regex syntax to a subnetting guide.

Unfortunately, the book is not without its shortcomings: many of the command lines provide no explanation for the “fill in the blank” options, leaving that to the memory of the reader, and others refer to config files (such as for wpa_supplicant) without providing any information on the contents or syntax of the files. Additionally, there are 3 characters that are consistently unreadable throughout my copy of RTFM: *, <, and >. I’m not sure if these were in a different color before the printing, leading to them being extremely light in the text or what could’ve caused this, but I have to read carefully for them. Ben Clark uses <foo> to delimit the fill-in-the-blank options, and obviously they’re used for shell redirection as well, which both makes them critical characters to be hard to see as well as leads to potential confusion from less-experienced readers. The formatting is also inconsistent, with some commands prefixed with something similar to a shell prompt (often ‘> ‘) and others lay bare, and line wrapping leads you scratching your head at a few, though an experienced pentester should be able to overcome both of these with little trouble.

Overall, this is definitely a handy quick reference for any pentester (or for that matter, anyone who has to do administration or networking where they might find themselves without an internet connection) and for $9, it’s totally worth having a copy in your kit.

VPS Upgrade

23 Apr 2014 in Linux (Reading time: 5 minutes)

As I’ve mentioned before, my blog is hosted on a VPS at Linode. Just under 3 years ago, I moved to my current VPS in their Newark DC to take advantage of their native IPv6 support. I’ve now moved within Linode again, this time to take advantage of their awesome free upgrades.

$20/month gets you a 2GB Xen VM backed by enterprise-grade SSDs, Ivy Bridge Xeons, and a 40Gbps backbone. Think that 40Gbps is going to waste? Think again. I downloaded a 100MB test file from Cachefly in 1.2 seconds. That’s 85.5 MB/s. Consider my mind blown.

I’ve been a Linode customer since 2009, and have probably had about 3 outages in the 5 years. All have been short, and have had good explanations with great communication from the Linode staff. There may be cheaper options out there, but I care about uptime and infrastructure, and Linode makes the necessary investments there.

Full ApacheBench tests for my old and new hardware are below.

32 bit VM on Old Hardware

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

% ab -c 10 -n 200 -q https://epsilon.systemoverlord.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking epsilon.systemoverlord.com (be patient).....done


Server Software:        nginx/1.2.1
Server Hostname:        epsilon.systemoverlord.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.1,ECDHE-RSA-RC4-SHA,2048,128

Document Path:          /
Document Length:        26 bytes

Concurrency Level:      10
Time taken for tests:   7.878 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Non-2xx responses:      200
Total transferred:      121600 bytes
HTML transferred:       5200 bytes
Requests per second:    25.39 [#/sec] (mean)
Time per request:       393.898 [ms] (mean)
Time per request:       39.390 [ms] (mean, across all concurrent requests)
Transfer rate:          15.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      277  298  17.6    292     386
Processing:    89   93   4.3     92     112
Waiting:       87   93   4.1     91     112
Total:        367  391  17.7    387     481

Percentage of the requests served within a certain time (ms)
  50%    387
  66%    393
  75%    398
  80%    401
  90%    414
  95%    426
  98%    448
  99%    458
  100%    481 (longest request)

64-bit VM on New Hardware

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

% ab -c 10 -n 200 -q https://lambda.systemoverlord.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking lambda.systemoverlord.com (be patient).....done


Server Software:        nginx/1.2.1
Server Hostname:        lambda.systemoverlord.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.1,ECDHE-RSA-RC4-SHA,2048,128

Document Path:          /
Document Length:        26 bytes

Concurrency Level:      10
Time taken for tests:   2.999 seconds
Complete requests:      200
Failed requests:        0
Write errors:           0
Non-2xx responses:      200
Total transferred:      121600 bytes
HTML transferred:       5200 bytes
Requests per second:    66.68 [#/sec] (mean)
Time per request:       149.959 [ms] (mean)
Time per request:       14.996 [ms] (mean, across all concurrent requests)
Transfer rate:          39.59 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       68   90  21.8     84     199
Processing:    22   57 100.4     31     623
Waiting:       20   57 100.3     30     623
Total:         95  148 105.4    115     707

Percentage of the requests served within a certain time (ms)
  50%    115
  66%    120
  75%    128
  80%    143
  90%    212
  95%    479
  98%    566
  99%    706
  100%    707 (longest request)

A Brief History of the Internet (Security-Wise)

15 Apr 2014 (Reading time: 5 minutes)

I originally posted this to the DC404 Mailing List, but got some positive feedback, so I thought I’d post it here as well. The broad strokes should be correct, but there might be some inaccuracies here — if you’re aware of one, please let me know and I’ll correct it.

There was a thread ongoing about Heartbleed, and it turned into a question of why security on the Internet is so complicated, and couldn’t it be any simpler? Well, the truth be told, security on the Internet is a house of cards.

Part of the security problem on the Internet is also what makes the Internet so great: people using technology for something other than what it was designed for. Back in the beginning, the internet (or even Arpanet) was a system of interconnected computers where all of the computers and operators were trusted, and we weren’t shipping financial records, health records, personal communications, or whatever else over it.

At every layer, we’ve had to bolt on security features, scalability features, and anything else.

/etc/hosts is roughly what existed (though in different forms) on systems in the early years. When a new system got added to the network, all the other operators would add it to their hosts file. That obviously doesn’t scale, so DNS gets invented. But these are the trusting years, so DNS gets no security built in, it’s just a central directory for publishing name -> IP mappings.

Next, we’d like a way to exchange information in a linked “web” structure. We’ve played with Gopher, Archie, FTP, whatever, but let’s add more structure. So along come two standards: HTTP and HTML. Since we’re publishing information for people to consume, and everyone gets the same information, and we’re all trusted on this network, we just want something simple without the complexity of layers like encryption, authentication, etc., or notions of state.

Now some people come along and want to have the ability to change content via the internet, and since we’re using HTTP to fetch the content, we’ll also use it for updates, so we get verbs like PUT, POST, DELETE, etc. It’s not long before someone decides that not everyone should be able to make those changes, so we’ll add some authentication by having people send special headers with each state-changing request.

It’s around this time that people realize the Internet is getting too big to trust all the nodes, so we need to start thinking about encryption. And Netscape comes along and produces SSL, which is a wrapper around any other arbitrary protocol, and offers encryption and integrity. To ensure that, we need a way to verify the identity of the endpoint, so we need some sort of directory of that. But of course, DNS isn’t secure, isn’t designed for such large payloads, so we need something else. Something preloaded into the client, but adaptable, so we build a “Certificate Authority” that will sign the certificates that will be served by the servers. And we’ll allow some other organizations to also sign certificates. And maybe some more. [And more, and more…]

So, around 1995, Netscape began to develop the idea that we could have “applications” on the Internet, and they wanted to provide interaction between the client and the server. So they go and build a variation of Java for the client, called JavaScript. And where do we put it? Oh, just in the webpages. So now we have data & executable code mixed together, and thanks to the server-side languages we’re using at this point (C, Perl, etc.) we’re able to output any combination of it based on user input.

Now we come to the first dot-com era, where we have people starting to use the internet for things like “online banking” and “e-commerce”. At first, it’s small potatoes, but it gets big, and keeps growing into the 21st century. Now everything is online, from personal emails to banks, stores, governments, power plants, whatever touches a computer. But we’re still sitting on a technology stack where security was an afterthought, bolted on like training wheels on a kids bike.

So, I know that doesn’t fix your complaints, but it’s important to realize how many moving parts are involved and where they came from. If you want to know the gritty details, the best book I’ve seen is Zalewski’s The Tangled Web. It’s pretty technical, but it’s a really great book about the state of web security.