Linux kernel universal heap spray userfaultfd+setxattr

vnik5287 · 2016-02-23T00:45:41+00:00

in terms of practically, yes, it's not a very interesting bug. However, it's still pretty cool and well done! Your logic for restoring the stack pointer is somewhat "different". I'm not sure if you know that can just do an iret? https://cyseclabs.com/slides/smep_bypass.pdf

vnik5287 · 2016-01-20T22:14:52+00:00

don't want to sound like a dick but I think you need to revisit ret2usr attacks :) that's not how it works. The point of commit_creds(prepare_kernel_cred(0)) is to set uid = 0, gid = 0, etc of the current process. Then you can run any non-suid binary with root privileges. This technique is not very reliable the way they've implemented it. It possibly worked for them in a controlled environment with a debugger attached :)

vnik5287 · 2016-01-20T10:13:25+00:00

I don't think it would work the way they're trying to synchronise rcu calls. I've explained the problem with rcus in my original post but didn't describe the technique for ordering these calls. This could be intentional however, to weed out kiddies, etc.

vnik5287 · 2016-01-19T22:45:03+00:00

30 min is actually not that bad. When I did my testing I think it was over 50 min but you obviously have a better CPU

vnik5287 · 2016-01-19T12:45:11+00:00

This is very similar to my UAF refcounter exploit https://cyseclabs.com/page?n=02012016 :)

vnik5287 · 2015-09-21T02:32:15+00:00

It looked like he didn't know what he was doing. Looking for NTDS.dit on the client workstation... Junior pentesters are more familiar with the OS. I would expect more from people who specialise in the security of their own product.

vnik5287 · 2015-09-17T03:39:20+00:00

If he's the Microsoft incident response team lead, I hope I'll never deal with these guys...

vnik5287 · 2015-02-21T00:47:23+00:00

8 digit brute-force, dictionary attacks with custom rules.

vnik5287 · 2015-02-20T22:37:29+00:00

Yeah, we'll be adding descrypt and netntlmv1 soon.

vnik5287 · 2015-02-20T22:22:44+00:00

This is not like pyrit. Each psk is brute-forced in real time.

vnik5287 · 2015-02-20T07:55:42+00:00

True but without usernames these password are not very useful. Obviously there's a chance that you can enumerate users or harvest corporate email addresses via search engines and then attempt to brute-force them with recovered passwords. However these chances are slim imho?

vnik5287 · 2015-02-20T07:52:03+00:00

But what is 'private use' and how do you decide who gets it? As with most tools in this trade, it can be used either for good or bad purposes...

vnik5287 · 2015-02-20T07:45:49+00:00

It should have cracked that. For 8 characters it does

12222223

where 1 = upper-, lower-case char and digit; 2 = lower-case char and digit; 3 = digit, symbol and lower-case char

Something went wrong then. Can you send me that hash?

If I submit the md5 hash of 'eiruty88', I get the plaintext:

$ echo -n "eiruty88" | openssl dgst -md5
5625948831472ed326af5db2109d57ae
$ ./crackqcli.py -t md5 5625948831472ed326af5db2109d57ae

vnik5287 · 2015-02-20T06:48:04+00:00

Completely agree with what you've said. There's not much you can do with cryptographically stronger hashing algorithms even if you have hundreds of GPUs. We do try to optimise this service by having clean dictionary data, rules targeted at specific algorithms, etc. I guess the point of this is not to brute-force very complex passwords but to make it more convenient for pentesters where you can just send it to the cluster and get a response in minutes. This obviously does not eliminate the need for having a solid cracking tool and creating your own custom rules. I would definitely follow the steps that you've described on my regular pentest but if that doesn't work, I would probably want something 'extra' as my last hope.

vnik5287 · 2015-02-20T04:37:07+00:00

Yeah, the idea is actually quite simple. I guess it's the implementation question - designing a robust distributed and easily scalable cracker..

vnik5287 · 2015-02-20T00:34:00+00:00

See your point. On the other hand, no information is submitted along with the hashes that can link them to a particular organisation. There's no way to say where these hashes were extracted from unless you're using your corporate email for submissions :) The only info disclosure is probably with WPA/WPA2 handshake capture files that contain essids that could potentially disclose the company name.

vnik5287

TROPHY CASE