The debate over full disclosure goes back hundreds of years in the locksmithing world.  Locksmiths were historically very secretive about weaknesses in their products; interestingly, they still are – here’s an interesting note on the subject from a few years ago.

There’s nuance and detail to the recent history of disclosure practices which Wikipedia does a good treatment of, but it’s fair to say that today there are three broad categories of practices:

• silent patching (no disclosure) – this is a bad idea for fairly obvious reasons, except (some argue) in edge cases like the Linux kernel (the “every kernel bug is a security bug” argument) (one discussion of this, another)
• partial disclosure, where one issues the patch before explaining full details of the vulnerability
• full disclosure, where vulnerability details (and sometimes exploit code) are released at the same time as the patch is issued

Aside from how much is being disclosed, there’s the question of  responsible disclosure on the part of security researchers, which is in a nutshell the idea of giving software vendors a set amount of time to respond to security issues before going public with them.

How to Screw Up Disclosure

• don’t give credit in your vulnerability advisories
• don’t even bother publishing advisories (silent patching)
• be unresponsive
• demand excessive, unreasonable timeframes for patching (this is of course subjective)
• make people sign NDAs (!)
• threaten to sue people

The last two aren’t generally screwups committed by Open Source projects, of course :)
How to do it right – best practices

• have a clear security contact on your site, no more than a click away from the homepage, and easily googlable with the string “$projectname security”
• have a gpg key posted, with a good web of trust, for that contact
• have email to that contact go to an email list with a clear process for dealing with it so that you don’t drop the ball, or have it filed into the bugtracker automagically (in a private bug!!11)
• have an announce-only security mailing list for your users, and post issues to it ASAP when they come out!  An RSS feed works too.  Do both!
• ensure that someone in your project monitors lists such as full-disclosure and bugtraq for issues in both your project, upstream frameworks, and your infrastructure.  For just monitoring your project, a Google Alert works well too. “project name + bug or vulnerability or security”.  People sometimes announce vulns without disclosing at all; you want to catch these.
• if the project ends up getting abandoned at some point in the future, at the very least post a warning that it’s deprecated and unmaintained even for security issues, and possibly take down the code.

Specific Issues for web apps

• you may have a widely deployed base of users.  An auto-update system such as WordPress’s is awesome for getting them to $%^$&&* patch!
• the framework you’re building on may have (security) bugs too.
• your code may be customized by users, which makes them lazy about patching – a good plugin architecture can help mitigate this.

I mostly touched on stuff from OWASP’s vast collection of resources,specifically their top ten principles of secure programming, and their top ten web application vulnerabilities.  Slides are after the jump, but I wanted to include some related links to things which came up during the talk:

• SANS says to have good, visible security contact info
• Some more web app hacking learning resources from RSnake

Enjoy the slides!  Slideshare messed up the formatting of the additional notes, so for full effect I’d download them from here.

1. figure out what you want out of a career in information security – technical mastery, a cushy job, organizational power?  There are lots of reasons to want to work in this field, but you should put some thought into what your reasons are.
2. do your networking, especially while you’re still in school.  Build your network before you need it.  Go to user groups (SpoofIT, TASK, OWASP, UU, GTABUG, Windows-related ones I’ve never heard of, etc.).  Go to conferences – you can do it on the cheap, pay your own way when necessary.  Participate in the appropriate professional organizations (but choose wisely).  Take advantage of the network you have by default through being at school – cultivate those relationships.
3. get your big break.  Build an online “brand” (barf) even if it seems cheesy (see this blog?  That’s what I’m trying for here :) ).  Remember that the people hiring you will Google you and do things like compare your LinkedIn to your paper résumé.  They will read your blog and Twitter and look for red flags.  This can be a good thing – I don’t try to hide that I’m a feminist, because I don’t want to work anywhere that would not hire me based on that.  Lock down the privacy settings on your Facebook, though.  Volunteer.  Check out Hackers for Charity (when Johnny gets the site back up) and TechSoup.  Work HARD on your soft skills.  Learn to speak fluent Human, not just fluent Geek.  But be careful, and pick the organization you have your big break at carefully.  Judge organizations harshly.  Read the Mythical Man-Month.  We’re still making many of the same mistakes.  Orgs which have parallel tracks for technical and managerial advancement are a very good sign.  No seriously, read the Mythical Man-Month.  Pay attention to the interactions you observe while interviewing.  The interview really is about you checking out the company as much as them checking you out.
4. build yourself up.  Try things which stretch your abilities and comfort zone.   Figure out how to survive within whatever organization you’re in – it won’t be easy.  Pay your dues, whatever they are.  Expect to not be doing as much strictly security work as you want.  Expect to do sysadminning and lots of log-related stuff.  I think the idea of having a degree in security is too young to get you out of this entirely, but it will help.
5. try different things.  Big companies, small companies, non-profits, public service.  The latter two will likely make you crazy; if they don’t, you’re very lucky.  Be a generalist, and learn a bit of everything.  But make sure you stay a year.  It looks bad otherwise.

Some conference-related advice, from someone who’s lost count of how many I’ve attended:

1. go.  They are the most efficient way to network, bar none.
2. if you can’t go, download and watch talks.  The hackermedia archive is the first place to look: http://tinyurl.com/hackarchive.  Con websites will also frequently post talks soon after the con, and many cons stream content live as well.
3. talk to the speakers, but find a way to bring value to the conversation, and don’t be a fanboy/girl.  They want to hear how it relates to what you’ve been studying – that’s a good way to start the conversation.
4. bringing value to the conversation is the general rule.  Have a cool project you’re working on for fun, or some interesting coursework you can talk about.  Go out of your way to be nice to people.  Bring business cards, and write key things on them before you hand them out, and on any cards you receive from others.  I love my moo cards, even if they are a geek cliché.  Put your GPG key on them.  Follow up on contacts.  Don’t be forgettable, but don’t be remembered for being a jerk.  And, uh, party wisely lest embarrassing photos of you end up on Flickr :)
5. present at them!  The bar is lower than you think.  I’ve seen some really crappy talk at conferences.  You can do better.  Presenting well will grant you amazing opportunities and exposure.  Do manage the press aggressively, and be careful what sound-bites you offer up in interviews.  Reporters aren’t your friends, unfortunately.

I spoke a bit about Defcon, NOTACON, and SecTor.  There’s also a great calendar of all sorts of hacker / security events here.

None of these are hard rules, just things I’ve found to work, learned the hard way by doing the opposite, or been told by people whose advice I value.  I hope you find them useful.

-Leigh

As before, be sure to also check out Security4All’s post on Day 3 for a more Belgian perspective on things.

BYOGSM

Running your own GSM network

We’re really excited about the results from this talk at the hacklab, as we’re hoping to get a couple of cells (pending investigation of the appropriate Canadian licensing requirements) in order to build something awesome and shiny for Hacking At Random next summer.

• the big “why”: they wanted to demo known (theoretical) security issues with GSM networks
• the network authorizes mobile devices using their sims, the devices don’t do any sort of authorization against the network
• copious “don’t try this at home” warnings – use a good dummy load, and don’t interfere with other operators, particularly military
• like all telco / ITU protocols, the intelligence is in the network not the endpoints, protocols described as a “TDMA nightmare”
• the base station they obtained (in 2006 on eBay, then bought the whole lot of 74 when they got the one working) is a Siemens BS-11 microBTS
• there are a bunch of specifications of the base station in their slides, as well as a hierarchy of needed components
• the documentation is available under NDA but 99% of the specs are available
• they were able to get in touch with others running the same BTS
• they got it basically working using an E1 card hooked up to a Linux PC, and you can too! (With the proper licensing of course)
• fun fact from the talk: phones have code in them implementing “Egypt detection” as GPS is illegal in that jurisdiction; the phones detect that they are on an Egyptian network and disable the GPS in software
• they also did an awesome demo which I won’t describe here – feel free to ask me about it offline

Stormfucker: Owning the Storm Botnet

As far as I could tell, the talk didn’t contain any new information that I hadn’t seen in other talks about Storm.  The researchers had thoroughly reverse-engineered the Storm bot and were able to control the remains of the botnet; it’s mostly or totally dead these days, however.

SWF and the Malware Tragedy

This talk discussed some theoretical and some practical vulnerabilities in Adobe Flash, as well as how to use Flash as a sidechannel or a loader for other malware to obfuscate malicious code.  Flash can hide malicious code in externally referenced resources as well as internally stored objects, though fukami says that it does strange things to some kinds of media files which pre-empt their use in steganographic storage.

They also explored some behavioral analysys of ActionScript bytecode using erlswf, an ActionScript disassembler written in Erlang.

Methods for Understanding Targeted Attacks with Office Documents

Oh, PowerPoint...

Bruce Dang’s talk and the conversation afterwards was one of the highlights of the Congress for me.  He went over the OLE structured storage format which these attacks leverage (in addition to PDF vulnerabilities), as well as a number of easy mitigation strategies (he didn’t mention using OpenOffice, cough cough).  He pointed at a few interesting things: Technical Cyber Security Alert TA05-189A; the pythoncom wrapper for Microsoft’s COM API’s, and the MOICE tool which converts documents into the much safer Office XML.  They also have a blog here.

I’m going to leave Day 4 to another post which I’ll put up tomorrow.

After chatting with Bruce and Seth for a while I had dinner and eventually made my way to c-base again.  There was a hilarious auction in which I contributed to VHS acquiring the c-base server, a really great hackerspaces call-in featuring about 20 people at c-base, a bunch from the US, Canada, and around Europe, as well as a caller from the nascent space in Durban, South Africa (zomg!).  Afterwards there was lots more conversation about hackerspaces in Canada and a zillion other things.  It was a great night.

A lighthearted moment from Soviet Unterzoegersdorf

As with the previous posts, for a different perspective and selection of talks I highly recommend checking out Security4All’s blog post about Day 2 as well.

Finally, if you’re particularly interested in anything I’ve written about, you should check out the official recordings here.  Most of the talks have been posted both as direct downloads and torrents.  I can’t even begin to say how amazing this is given that the conference is barely over.  From what I hear as well the live streams coming from the conference while it was running were also totally solid.

And now for the actual comments about this day’s talks!

Exhaustion, jet-lag, and a late night at the space station made me miss a few talks I wanted to see, but they all conflicted anyway so I’m just going to watch the recordings on my long flight home on Sunday :)  I made it to these talks:

TCP Denial of Service Vulnerabilities

• I feel like I somewhat still don’t understand this attack, despite having read tons about it – this probably has to do with not also reading more about TCP/IP design.
• The gist is that TCP connection window scaling reduces the effectiveness of the source port randomization, which was never a security feature anyway but intended for multiplexing…
• Also there was something about resource starvation by partially opening connections akin to SYN flooding.

Scalable Swarm Robotics

• definitely wins the “cutest props” award for their demo of tiny robots (link to video!)
• the robots they built can be made for about €15 in quantities of 25+ using off-the-shelf parts exclusively except for the tiny wheels which they stamped out of rubber
• the plans are GPLv3 and CC (yay!)
• the “wheels” are driven by cellphone vibration motors with the weights replaced by rubber wheels
• they re-program eachother’s firmware on the fly and indicate their firmware status as well as other conditions via multi-colour LED’s
• lots and lots more info at their site if you are interested: http://warrantyvoidifremoved.com/formica

Banking Malware 101, or, Stuff I Found On My Sister’s Dead Laptop And Now She Has A Mac

Anatomy of Banking Trojans

• in all seriousness, I found three of the mentioned malware families on the hard drive of my sister’s dead machine, and she now has a Mac.
• given that this is what I deal with in my day-job, I took a lot of notes on this one
• what set this talk apart from your average Banking Trojans talk, which made it much more than a 101 in my opinion, was the fact that the researcher had gained access to the Command and Control servers for several variants of banking malware, and worked in conjunction with AusCERT to notify the people whose banking info he found on these servers.
• all of the covered trojans affected only Internet Explorer; the only one which has thusfar affected Firefox was ChromeInject, a drive-by-installer targeting users of the Greasemonkey plugin.  There’s more on it here; it wasn’t covered at all in the talk, and it no longer works.
• the trojan Nethell stole cookies, usernames/passwords, stored credentials (saved passwords) and could defeat “visual keyboards”
• another sample (Zeus / Wsnpoem / Zbot) could inject arbitrary HTML into forms and ask for the secondary transaction numbers in use in a number of European banks
• they had some excellent sample collection and analysis automation which I’m definitely going look into more, using CaptureHPC, Honeyclient, phoneyc
• they created a simulator based on AutoIT called “Simuser” which they could write behavior templates for
• if you’re interested, here is the presenter’s blog post linking to the recording and talk slides.

ascii’s Tricks: makes you smile

• A++ did indeed make me smile
• while the speaker was a little hard to follow at times, the talk was colourful and entertaining
• he showed off several small hacks involving sudo timeouts
• apparently putting localhost into your server’s DNS very much breaks the Same Origin Policy… oops
• he showed off a GREAT technique for fooling people into copying and pasting random things into shell prompts by using some HTML / CSS obfuscation in demo code snippets
• he presented new tools to do ICMP PMTU Denials of Service and blind SQL injection
• sadly, his website is down but hopefully it will reappear soon so that the tools and PoC’s can be obtained

I have five more pages of notes to write up on days 3 and 4, but I’ll try to get it out tonight.

Gadi Evron on Cyberwarfare

• EU security operations / CERTs are not very organized
• cyber warfare is mostly bull****

iPhone hacking

• They’ve fully soft-unlocked the phone, but it’s been done in such a way that Apple can still fix it with a software update

Memory Forensics with the Cold Boot Attack

• attack has been fully weaponized to USB keys (or functional iPods) and PXE boot
• Jake has found a somewhat unrelated bug in Mac OSX’s Login.app which results in logged-in users’ passwords being stored in RAM; Apple is aware of the issue and not fixing it.  Same for FileVault keys [o_0]
• Linux dm_crypt is vulnerable
• loop_aes devs thought they weren’t vulnerable because of some key-shifting stuff they do, turns out it just means that they store twice the keydata :)
• Co-author of USENIX paper Nadia wrote an awesome keyfinding tool which can grab keys from RAM even with something like 75% corruption
• Bitlocker default / simple mode is totally pwned
• Even with TPM in use Bitlocker is still vulnerable if precise timings are used

Dan Kaminsky – Why were we so vulnerable to the DNS vulnerability?

• random person named Paul sitting beside me on the couch by the Go boards describes it as “+5 insightful”
• My Paul is all excited that Dan is now publicly in favour of DNSSEC :)

Edited to add:  For some additional perspectives on Day 1, have a look at my Belgian friend Security4All’s blog post, which has a different selection of talks.

However, it did all lead me to discover this gem epic failboat of a password policy:

When changing your password, please remember that it must be between 5 and 8 characters in length and should contain both letters and numbers. Special characters (e.g. #, &, @) must not be used as they will not be accepted by the system. Passwords consisting of all letters or all numbers are not recommended. Although TD Canada Trust does not require you to change your password, we recommend that for security purposes you change your password every 90 days.

Okay, wtf people.  5-8 characters seems awfully permissive, and doesn’t let me put in a nice long password… but not requiring numbers and letters?  Just recommending it?  And their system doesn’t support punctuation in passwords?  Yeesh.

It gets worse.  I decided to play around with it, and was able to change my password to the following:

• foobar
• 12345
• 11111
• aaaaa
• the first 5 characters of my bank card number (which is the username when one logs in, and is common to many TD customers).

Obviously I’ve changed the password to one which is as secure as I can make it given their crappy constraints, but it really angers me that I’m paying through the fees I pay them for this kind of asinine security policy.  It almost makes me want to go through the hassle of switching banks… but I’m sure the others all have similar issues on one level or another.

Some days, though, this industry just makes me want to set things on fire – today is one of those days.

-Leigh