Fyodor's talk was the first real talk I attended at Black Hat. TO be honest it was quite a thrill seeing "the creator of nmap". I did feel a bit dumb not knowing that Fyodor wasn't his real name, and thinking his family emigrated when he was young because had such a thick American accent.
Continue reading "Fyodor's NMAP Talk at BlackHat USA '08"
There's an e-mail going around in response to petrol attendants at Caltex service stations handing out free keyrings. The alert says:
Syndicates are giving away free key rings at petrol stations. Don't accept them as the key rings have a tracking device which allows them to follow you.
Some of my friends in this mailing list LOVE FREE THINGS. Watch out!
Forward to your friends and family.
Continue reading "Caltex Key Fobs and a Chain Mail Security Alert"
Dan has posted two replies in the comment section of my previous post on his BlackHat talk. I think his comments indicate that his motivations were good and well reasoned before hand, and the net outcome of his find-and-fix was good. I believe they could have been better, but it's easy for me to comment from a removed, theoretical position, and "could have been better" sounds like a pretty weak position already. I've literally changed my opinion of Dan, and believe I judged him too harshly. Thus this entry isn't just a brown nosing affair.
Nice work Dan.
Dan's talk at Black Hat on 'The DNS Bug' aka CVE-2008-1447 was packed. By this time I had worked out that BH attendees, much like Catholics fill up from the back, so you can usually just walk to the front and find a seat. I did and ended up three rows away from Dan and his podium, a decision I later regretted.
It's a long entry, so I've bold'ed the key parts of my rant.
Continue reading "Dan Kaminsky's BlackHat USA '08 Talk on the DNS Flaw"
I've got an SSL cert I use for back-end stuff. If I mistakenly link to the HTTPS version, or you wear as much tinfoil as me, here's a brief explanation.
Continue reading "HTTPS, SSL, TLS etc. on singe.za.net"
* Kaminsky DNS Cache Poisoning Flaw Exploit for Domains
- Advisory: http://www.caughq.org/exploits/CAU-EX-2008-0003.txt
- Exploit: http://www.caughq.org/exploits/2008/bailiwicked_domain.rb
* Kaminsky DNS Cache Poisoning Flaw Exploit for Hosts
- Advisory: http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
- Exploit: http://www.caughq.org/exploits/2008/bailiwicked_host.rb
The blog entry. The list. It's even on Packetstorm.
I'm not sure my not posting these would limit their distribution in any significant way, and given the detailed breakdown provided us by Matasano, the bad guys could already have a working version. At least we are empowered to test and understand (without waiting for BlackHat).
Schneier once proposed a vulnerability life cycle in a Crypto-Gram newsletter. He was wrong. During the time of writing my thesis, there were several important pieces of research no-one had put together to come up with a 'more correct' vulnerability life cycle. Given some recent discussions between Symantec and Verizon, I thought I would provide this is a more accessible format that a previous presentation I did on the subject, so that I could refer to it later.
The benefits of having an understanding of the life cycle, is that it provides a model to 'predict' the behaviour of various role players (e.g. bad guys, vendors and administrators) and understand how that behaviour impact on important parts of the risk management equations such as vulnerability, threat and impact. This is an important building block of any threat model.
The detail after the jump.
Continue reading "Vulnerability Life Cycle"
Some older versions of SELinux and OpenSSH compiled to support it allow you to log in with an arbitrarily chosen SELinux role. You'll need a valid account, and some fairly undefined conditions, but the attack is:
ssh --l<username>:/<chosen role> <host>Haven't seen a (potential) stuff up like that since the MIT Kerberos telnet daemon flaw (which was significantly worse). I'd like to think that people who've gone to the effort of setting up SELinux also patch regularly. Source, milw0rm.
I am interested in this because it is dreadfully simple, has some weird implications for how SSH and SELinux interact, and there is scant information about this. Maybe a few more eyes can uncover something.
Disclaimer: I haven't tested this. The author only tested it on a limited subset and it didn't work on up-to-date distros.
Update: Explained my motivations and authority (or lack there of) of the exploit thanks to foobar's comments.
I never remember how to do this, so for my own personal blog-memory:
rsync --partial --progress --rsh="ssh -p <remote ssh port>" <from file> <partially downloaded file>
- The --rsh parameter can contain all of your normal ssh command line-fu such as keys, options, ports etc. (Who runs public ssh on port 22 these days anyway?)
- The <from> and <to> follow the normal SCP format of <username>@<hostname>:<filename> or just <filename> for the local copy.
Rain Forest Puppy (rfp) in a merry Christmas of an article entitled "NT Web Technology Vulnerabilities", published in Phrack Magazine, Volume 8, Issue 54 on December 25th, 1998. He didn't actually call it SQL injection yet, that honour either goes to SANS or Chip Andrews in 2001. Source, Litchfield.
Here's the beginning of his summary, from the section entitled "ODBC and MS SQL server 6.5":
- WHAT'S THE PROBLEM? MS SQL server allows batch commands.
- WHAT'S THAT MEAN? I can do something like:
SELECT * FROM table WHERE x=1 SELECT * FROM table WHERE y=5
Exactly like that, and it'll work. It will return two record sets, with each set containing the results of the individual SELECT.- WHAT'S THAT REALLY MEAN? People can possibly piggyback SQL commands into your statements. Let's say you have:
SELECT * FROM table WHERE x=%%criteria from webpage user%%
Now, what if %%criteria from webpage user%% was equal to:
SELECT * FROM sysobjects
It would translate to:
SELECT * FROM table WHERE x=1 SELECT * FROM sysobjects
It's official, I'm going to Black Hat and Defcon this year. I'm very excited. A *huge* thank you to the SensePost guys who are sorting me out only proper. Make sure you go, to, their, training. We've also pulled together a fairly decent Deloitte contingent.
I'll be there from the 29th of July to the 11th of August if all goes off according to plan. Give me a shout if you want to meet up, or if you have invitations to sexy parties.
If you've decided you want to make better coffee, here are my tips for the changes that will yield the biggest results. These aren't comprehensive, just some quick tips for quickly making better coffee.
- Don't use instant, use proper Arabica grounds.
- Espresso is the best, then French press, then percolator. A Moka Express or Brikka are quick ways to get into espresso.
- Use hot milk. This makes a big difference in taste, 30-40s in the microwave should do it. A French Press can be used with hot milk to make decent froth for cappuccino too.
- Grind your own beans. A grinder is cheap, and freshly grinding your own beans just before you make a cup makes a subtle increase in flavour. Remember to store your beans in an airtight container in a cool dry place (not the fridge).
This will be fun to watch. Dan Kaminsky has sort-of published not-so-sekret ways to break DNS. Patches have been released to make things more random. "Full" disclosure at BlackHat.
From ISC:
"The method used makes it harder to spoof answers to a resolver by expanding the range of UDP ports from which queries are sent, thereby increasing the variability of parameters in outgoing queries."
I laughed with mirth and glee at the Emergent Chaos comment:
"DJBdns is in fact not affected as DJB had already implemented port randomness even though he didn't know it was an issue."
This means *all* DNS (except DJBdns) is vulnerable, many vendor patches to follow. Although, DNSSEC is the *right* answer.
The South African Police Services have released the crime stats for the last financial year. I still need to wrap my head around the numbers, as many of the categories don't seem discreet, or intuitive. However, I think the executive summary contains some good insight into the 'threat landscape'. It also backs up several of my 'gut feel' assertions about crime in SA. However, as Russell points, there may be an independence issue, as the report is "written by the guys whose job is on the line", and I haven't found any information on how the stats were independently verified. I've culled some sections from the executive summary and given them my own headings, formatting and order. Whatever your take on crime in SA, these stats are a good read, and certainly more likely to be accurate, even with bias, than the eight year old drivel on Wikipedia.
Continue reading "SA Crime Stats 2008"