Hi again, folks. This is a sort fo follow-up to the Syleham gathering, since as I started to drive home after the meeting a programme "Hacked to Pieces" had just started on Radio 4.
It is about computer crime, and how vulnerable most people are because of naivety about security.
The programme can be found at 17:00 on
http://www.bbc.co.uk/radio4/programmes/schedules/fm
for today Sunday 3 May (in case you're reading this later). If you click on the link "N days left to listen" you can hear it.
The bit that raised my eyebrows starts at 5min 30sec into the programme, where the presenter (Jolyon Jenkins) takes his laptop to be hacked into by Peter Wood of First Base Technologies (who provide a "hack your computer, guv?" service to companies who want to check their security). It lasts to 7min 40sec into the programme.
In particular, I transcribed the following short extract:
JJ: I was genuinely suprised by, in fact, how vulnerable I turned out to be.
PW: The first thing I'll do is an easy check to see whether I can get a nice little automated tool to cough up your password straight away so I can log on as you.
JJ: I'm fairly confident you're not going the get my password, because it's not a natural language word.
PW: This isn't dependent on any dictionary-based word, it's just trying every permutation of letters and numbers up to 14 characters long.
JJ: Ah, I'm feeling less confident because ...
PW: Ah! There's your password
JJ: Oh!
PW: That took two hundred and ninety seconds of computational time.
Well, my jaw would drop if I believed it! Even if the password is case-insensitive, that's 36 letters+numbers to try every "permutation" of. There are 36^14 different 14-character strings where each character can independently be any letter or number. And that's just the full 14-character string -- there's also all the shorter strings as well.
Now, 36^14 is about 10^22, or 10^13 billion, or 10,000 billion billion.
A 1-GHz CPU would take 10,000 billion seconds to execute that number of CPU cycles, or about 300,000 years. So there's no way the guy's password hacker is going to do what he said it would do.
It's not too plausible when it comes to searching for shorter passwords either. An 8-character password (case-insensitive) still potentially requires 36^8 or about 3*10^12 tries; so (based on the previous calculation) that's 3,000 seconds or 0.83hr to execute 3*10^12 CPU cycles. Then you have to multiply that by the number of CPU cycles needed to work through each try, which is presumably not a small number.
And it's worse if passwords are case-insensitive, since then there are 46^8 approx = 2*10^13, or 20,000 billion tries for an 8-character password, and it's 5.6 hours to execute that number of CPU cycles on a 1 GHz CPU.
So the "outcome" of that little experiment strikes me a implausible, and I susepct that it was "rigged" in order to sex up the story. (Maybe JJ used a shortish password -- 46^6 is only 9.5 billion).
This sort of thing is supposed to take place in the context of people (e.g. attending meetings/conferences) leaving their laptops unattended for say half an hour, thus allowing the hacker physical access. (And, by the way, it seems they're thinking of Windows machines).
I'd be interested to hear if any of you folks have comments on the above!
Ted.
-------------------------------------------------------------------- E-Mail: (Ted Harding) Ted.Harding@manchester.ac.uk Fax-to-email: +44 (0)870 094 0861 Date: 03-May-09 Time: 22:41:30 ------------------------------ XFMail ------------------------------
On Sun, May 03, 2009 at 10:41:33PM +0100, Ted Harding wrote:
PW: The first thing I'll do is an easy check to see whether I can get a nice little automated tool to cough up your password straight away so I can log on as you.
Well, my jaw would drop if I believed it! Even if the password is case-insensitive, that's 36 letters+numbers to try every "permutation" of. There are 36^14 different 14-character strings where each character can independently be any letter or number. And that's just the full 14-character string -- there's also all the shorter strings as well.
My first instinct would be to suggest that they weren't brute force guessing the password. I'm guessing that they were recovering the encrypted password file from disk and breaking/reversing the format it was stored with using something like L0phtcrack and rainbow tables which make it much much easier to recover passwords quickly.
In short, this kind of attack is very feasible and I have done similar in the past. Nearly 10 years ago I grabbed a set of users passwords from a windows domain and ran an automated scanning tool against about 80 users passwords, took me about 20 hours to get 95% of them and keep in mind the machine I was using to do this was about Pentium III vintage with 512MB ram.
Without a proper explanation of what they were trying to break and how then it would be hard to say if it was genuine or not, but it is entirely feasible.
Thanks Adam
On Sun, 3 May 2009 23:01:01 +0100 Adam Bower adam@thebowery.co.uk allegedly wrote:
On Sun, May 03, 2009 at 10:41:33PM +0100, Ted Harding wrote:
PW: The first thing I'll do is an easy check to see whether I can get a nice little automated tool to cough up your password straight away so I can log on as you.
Well, my jaw would drop if I believed it! Even if the password is case-insensitive, that's 36 letters+numbers to try every "permutation" of. There are 36^14 different 14-character strings where each character can independently be any letter or number. And that's just the full 14-character string -- there's also all the shorter strings as well.
My first instinct would be to suggest that they weren't brute force guessing the password. I'm guessing that they were recovering the encrypted password file from disk and breaking/reversing the format it was stored with using something like L0phtcrack and rainbow tables which make it much much easier to recover passwords quickly.
Confirmed.
I asked Pete from First Base. He said "it was a partial rainbow tables attack (LM hashes) using Ophcrack Live".
So no - not a straight brute force attack.
Mick
---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
2009/5/3 Ted Harding Ted.Harding@manchester.ac.uk:
JJ: I'm fairly confident you're not going the get my password, because it's not a natural language word.
Neither is 'a56'
PW: This isn't dependent on any dictionary-based word, it's just trying every permutation of letters and numbers up to 14 characters long.
Yup, brute force crunching.
JJ: Ah, I'm feeling less confident because ...
PW: Ah! There's your password
JJ: Oh!
PW: That took two hundred and ninety seconds of computational time.
Well, my jaw would drop if I believed it! Even if the password is
If find your surprise, quite surprising.
case-insensitive, that's 36 letters+numbers to try every "permutation" of. There are 36^14 different 14-character strings where each character can independently be any letter or number. And that's just the full 14-character string -- there's also all the shorter strings as well.
Now, 36^14 is about 10^22, or 10^13 billion, or 10,000 billion billion.
A 1-GHz CPU would take 10,000 billion seconds to execute that number of CPU cycles, or about 300,000 years. So there's no way the guy's password hacker is going to do what he said it would do.
No, that would be a Worst-Case scenario. eg. If the password was 'ZZZZZZZZZZZZZZ' (and the brute force algorithm did lowercase first then uppercase last).
If your password was 'charlie4567' it would take a lot less time to crack in a sequential brute force attack, than the ZZZZZZZZZZZZZZ case.
Also, to do this in code, one would probably not do an attack on the 14 char password in the first instance.
You would most likely do: 'a' 'b' etc. to 'z'
Then 'aa', 'ab', 'ac' and so on.
So if your password was 'gitkip123', you do not have to cover the entire 14 character textspace to find a matching pattern.
Did the people on the programme say what the password is? How long it was?
Srdjan
(Ted Harding) wrote:
Hi again, folks. This is a sort fo follow-up to the Syleham gathering, since as I started to drive home after the meeting a programme "Hacked to Pieces" had just started on Radio 4.
<snip>
I'd be interested to hear if any of you folks have comments on the above!
I would expect it to be quite possible. I haven't done any password cracking since 1995 so I hope things have moved on since then, but I was able to get a password 8-12 chrs long in about 30 seconds. This was on a unisys A16 mainframe. I had the advantage that, even though the encryption was one way, I knew that the algorithm used processed a password left to right. So as I passed a single character into the routine the resulting encryption got "closer" to the target encrypted password. This would give me the first letter. I then only had to try each 2nd chr to get closer still. That is the left most chrs were more significant in producing the encrypted form. So I would get a working password[1] in only 12*36 passes. Where 12 was the max length and there were 36 characters available for the password. [A-Z,0-9].
I have no idea haw passwords are encrypted on windows machines but I would not be surprised if they still get processed left to right.
[1] eg if the actual password was "ab21cd43ef65" There would be others that were similar that gave the same encrypted form like "ab21cd43ebl0" (I just made them up so don't look for any algorithm)
2009/5/4 nev young pasiphae1953@yahoo.co.uk:
I have no idea haw passwords are encrypted on windows machines but I would not be surprised if they still get processed left to right.
Even old Unix DES was not that dumb. These days the password is stored as a pretty strong hash where a one bit change in the input causes the output to be completely different. The addition of a salt (DES used 2 extra random characters) reduces the risk of two people with the same password having the same hash.
In Windows the hashes are stored in the registry while most unixes use /etc/shadow which can only be read by root. Windows NT4 hashes are weaker to guessing, and recent versions of Windows still generate that hash to maintain backwards compatibility with NT4 servers. At least SMB/Samba passwords are no longer sent in clear text!
Tim.
-
Adam Bower -
mick -
nev young -
Srdjan Todorovic -
Ted.Harding＠manchester.ac.uk -
Tim Green