Bruteforce 32bit Stack Cookie. stack0: part 3 - bin 0x23
ฝัง
- เผยแพร่เมื่อ 5 ต.ค. 2024
- Bruteforcing stack canary, stack guard, stack cookie with a C program.
brute_cookie.c: github.com/Liv...
DigitalOcean (referral):* m.do.co/c/826f...
=[ 🔴 Stuff I use ]=
→ Microphone:* geni.us/ntg3b
→ Graphics tablet:* geni.us/wacom-...
→ Camera#1 for streaming:* geni.us/sony-c...
→ Lens for streaming:* geni.us/sony-l...
→ Connect Camera#1 to PC:* geni.us/cam-link
→ Keyboard:* geni.us/mech-k...
→ Old Microphone:* geni.us/mic-at...
US Store Front:* www.amazon.com...
=[ ❤️ Support ]=
→ per Video: / liveoverflow
→ per Month: / @liveoverflow
=[ 🐕 Social ]=
→ Twitter: / liveoverflow
→ Website: liveoverflow.com/
→ Subreddit: / liveoverflow
→ Facebook: / liveoverflow
=[ 📄 P.S. ]=
All links with "*" are affiliate links.
LiveOverflow / Security Flag GmbH is part of the Amazon Affiliate Partner Programm.
#BinaryEXploitation #BufferOverflow
You Asking for our ways ?! I mean before the video i though i was an expert at C but after it turned out i was still a baby in C :D
“Ghetto parallelization” made my day xD
Dude, that program is sick. I am absolutely going to steal that code and reuse bits and pieces. I love how you included some of the iterations of the code. I wish this video would have been longer and covered why you made the changes, your thought process, and the various trials and errors. Excellent video!
if the cookie is already random, why do you have to randomize the input while brutforcing? Or am i missing something?
If the cookie is really random, sending the same value as argument has same (or even more) chances find match, without considering the performance penalty of random generation that will slowdown the brutforce. Except if the generator has some kind of non uniform distribution.
now THIS is what I'm looking for.
programming might not be mathematics, but exploit development certainly is. Time to go learn some probability.
Top tier videos as always, cheers.
3:04 "And I was like, 'That process had a child'"
Cool, actually had a good deal of info on things I was curious about! And I love C programs :P
bro... this video is just WTF... I was like.. do I even know any programming at all? great job man
My wife was like "What is this sh*t you're watching about killing children???" xD
I have not tested this so I might be wrong, but I believe it would be possible to inspect "status" argument of waitpid call and determine what signal killed child process. I think stack smashing detection should use SIGABRT, and in the case when we correctly guess, SIGSEGV occurs.
This might speed things a little bit as there is no need for string operations with standard streams.
For all the comments "wooow" that's a super pro level of coding in C etc etc those are just normal skills you can acquire studying in university and in particular operative systems. For the rest, kudos!! I like all your videos :):)
Recommend books
Can confirm. Am enrolled in a mediocre CS program and don't think any of our undergraduate classes teach this stuff. Even our Operating Systems class uses some shitty Java OS emulator.
@@nombreapellidos1094 "The C programming language" and "Hacking the art of exploitation"
We had to program a shell for a course
I agree that the code is 'wow'. I suspect that he has contacts, colleagues, ctf team members, etc. that he can lean on for some expert suggestions/advice. That program gives me something to study hours on. I totally don't get how he executed 8 of them with logical AND's (&) and somehow gathered results cumulatively.
Could you try to find patterns or correlations in the stack cookie random data? Unless it's backed by a powerful RNG, there's gotta be some weakness, right? Maybe it's just me being ignorant.
It’s backed by kernel’s RNG which is feed real entropy (from random hardware events) plus uses a cryptographically secure algorithm.
You're probably right.
Most devices do NOT come with a True RNG source, afaik
and instead have to rely on daemons such as haveged to feed the RNG source.
It's better than nothing and makes it a lot harder, but it's not unbeatable.
There has been some research where PUFs have been "cracked" using AI learning.
So maybe the same approach can be used for exploiting the RNG used in Linux kernel.
And even if the kernel actually was to use "entropy" from the real world, it would be quite limited.
Keyboard, mouse, camera, microphone, CPU temperature or usage and hard drive aren't good entropy sources to begin with.
Another great and useful video (:
@10:01 - That might not be completely true in this context. Typically (in the unix/posix world), the child will remain sitting around as a zombie process until the parent has reaped it (via wait*()). So until waitpid() returns > 0, the child should either still be running or in a zombie state. However, I didn't notice a condition where it exited the loop for such a condition, so would probably trigger the (wait_ret==0 ...) in a later loop, as the child would be gone then.
Also, a pid is probably not reused right away (e.g. round-robin assignment). So unless there are tens of thousands (or billions with 32bit+ pids) of processes spawned on the system in that short window, chances are good it wouldn't collided with another process in any case.
You amaze me every fucking time
me too >.>
Thank You
you're amazing
Can we add some concurrent programming here? A pool of 50 processes may speed up things i think
I think so, and it would be much easier to add that in python rather than fiddle with C
I don’t understand why not using a const value for the stack cookie.
For example if I’m dropping a coin and always picking tales the chances are 1/2 but if I’ll randomly pick the minimum chance will be 1/1 while the max will be 1/infinite is there some mathematical prof that supports picking a random value for this ? This is not a typical brutforce because the value is randomized.
I don't understand what you are saying. If it's a constant value this exploit would have only taken like 256*3=768 executions to find the correct cookie. Because we would have been able to try byte by byte. Once we find a valid byte of the cookie, we move to the next one.
also about your coin example, picking a random side will still have the chance of 1/2. The exact same chance as if you only pick tales. It's no different ;)
I think I get what you are trying to say - why not use a valid, constant value for the cookie but randomize every byte while bruteforcing?
If that's what you meant - it doesn't matter probability wise (you would still have the same chance of hitting the correct cookie because of symmetry), but it is a tiny bit easier to code :)
Damn so if the probability remains the same then the optimization will be better using a constant value and i still don’t get it why it remains the same first of all it always tricks me how computers generates random numbers as far as I know in Linux system the random number generation is done by collecting allot of information about running programs which means in any given point at this space the value is not a pure random which makes sense because we know it’s pseudo random but that also means that it would be very hard to randomize the same number or rather very simple.
So this solution is not that accurate and not that optimized as far as I understand
+jonatan no a constant cookie value will be bad in this case, as you can then guess each single byte individually.
And the value does not remain the same in our example, it's random each execution. I don't know what you mean :S
I think there is an easier way to do that. The main idea is not to bruteforce the 3 bytes of the cannary (those differents from the lsB 0x00) at the same time, but one by one. for example, you have a buffer with 32 bytes then, if you send a message to this buffer with "A" * 32 and a 0x00 byte at the end to the "server", it won't return you "try again". Then, the next string you will send will be "A" * 32 + "\0x00" + . That way you'll move on bruteforcing the bytes and every time you get that try again you'll increment that byte if you don't receive it, you'll move to the next byte.
So, instead of 256*256*256 possible combinations you will have 256 + 256 + 256.
I'm working on an exploit that does this thing right now ; )
Thanks for the great content as usual.
It won't work, since the cookie is randomized on every run - if you found one of the bytes in a certain run, it won't be correct on the next one :
If you can directly execute the program to brute force the stack cookie, you might as well write a debugger which would read the cookie from the memory. I guess brute force is a option in situations where you cannot execute the application directly .
You need CAP_SYS_PTRACE for that. Executing another program != being able to debug it.
I have all the time the feeling that you are from germany because you have a german like accent :D. But nice vids btw :D
+Ali Bozna I am
10:07 - that’s not accurate. When a process dies it becomes a zombie and hangs in that state until its parents collects its status through waitpid system call. Since you went with a signal handler, the correct way to approach this would be to have a single nanosleep in the main loop and a signal handler which would atomically set some global flag. The main loop would then wait for the sleep time to run out (in which case the process can be killed) or for it to be stopped with an interrupt (in which case check the global flag and collect the status of the process).
so if you check for a random PID you may have race conditions, but if you check for a child PID you may be sure that there is no such problem because you are responsible for cleaning up before the same PID number can be reused right?
Can you recommend me any low level C book?
Start by reading the K&R C book, then get the book by Michael Kerrisk ; it is the modern day Stevens equivalent.
Couldn't you just use system() instead of execv since it creates a new process? Using execv and all the forking seems a bit of over-engineering to me unless I'm missing something about those 2
Just want to ask: is this a random canary (random value everytime the program runs)? or is it a fixed canary value that you are trying to bruteforce?
random with every program run
@@LiveOverflow does it stays the sames throughout the whole program execution? Could it be possible to get the canary value at some point during program execution and exploit it later (with two different attack surfaces on the same executable)?
@@pqnet84 This is an old comment, but yes, that's correct. I'm sure my knowledge here is incomplete and I worry I'm in "a little knowledge is a dangerous thing" territory, but my impression is the main ways of exploiting a stack canary rely on this. The impression I have is there are two common stack canary circumventions. The first is to use a memory disclosure vulnerability (e.g. a buffer overread) to just read the canary out of the process, then turn around and use that in a subsequent injection attempt.
The second way actually uses an even stronger property -- canaries don't even change when a process is *forked*, just exec'ed. (The child process will continue running as if it were the parent, and that will have canaries sprinkled throughout the stack; if the canary changed, either the child would break when it returns from a function that uses the old canary value, or it would somehow have to know what stack addresses hold canary values that would need to be updated.) What this means is that if you have a server process that processes requests by forking and then handling the request in a subprocess, and if you can detect a subprocess crash (from a bad canary) from continuing execution, you can brute force the canary one byte at a time. Even on a 64-bit machine, that means a maximum of 8 * 256 = 1,024 attempts to carry out the brute force.
@@EvanED This is an old comment, but are you sure about the brute forcing one byte at a time part? I mean most of the time the copying function will put a nullbyte at the end of your input. So the canary will most likely always be wrong unless you bruteforce the whole thing at once. Or maybe I'm missing something ...
@@purplelix8357 I mean, that depends on what the underlying problem is. You're right that you wouldn't be able to do that if it's like a `strcpy` problem, but there are plenty of others. `memcpy` won't null terminate, `read`/`recv` etc. won't null terminate, or a hand-written loop in the code won't necessarily null terminate. I've *done* this with an nginx vulnerability. :-)
Can you make a video about "Ret 2 dl-resolve" ?
What's more promising for bruteforcing? 3 random bytes each run or enumerating the 3-byte number space?
+Vanilla Thunder I think in this case I should have just used a static value. I didn't think :P
Oooh.. yes, that's also possible >_>
can we use structured exception handling!
It was kind of hard to follow the code exactly, and yeah I know I could look at the github, but when you randomize the cookie guesses, I don't see anything that prevents the same combination being tried several times. Seems like you just try random combinations, but maybe I'm wrong. Edit: Or is that because of every time you try a combination you have to reset the program and thus have a new cookie, possibly the one that was wrong on last attempt?
Why would he try unique combinations each time? We know that the stack cookie is randomly generated and we can think that the randomization is independant of the previous ones. Imagine flipping a coin and trying to guess what side you'll get, the best strategy would be to guess randomly each time without tracking previous guesses, it doesn't matter if the coin felt 1000 times on heads, the next time you will still have a half chance of getting heads or tails.
Bro serious question where did you learn all that skills i'm really need to know ? hope you answer me of any topis or articles should i read it or practice it
+Ale ll i learned most of the basics by playing exploit-exercises.com myself
Thank you sir for your reply i really apprecaite it
for me now the essential is how to find a 0day vulnerbalities in php scripts and in OS linux (no more questions sir thank you ) where i can get skills to get what i'm looking for
10:00
why not pkill?
first: if you are not expert then who is?! really i mean whats that like ?
second: really ? one video in week ? i know your kinda busy with work and this kinda tutorials take so mush time. but PLZ make more. i'm really wait for your videos and count days. so yeah. make more . thanks
+mahdiar faramarzpoor "kinda busy with work"? Hahahha
whats funny about that?! :|
So if you have to brute force the stack cookie in order to get an exploit, and it seems that the 64 bit cookie is not brute forcible, is it even possible to exploit code on 64 bit systems? And if it is, how would you get around the stack cookie?
This simple example is not possible. But I’m more complex applications you might find bugs to leak stackcookies or Just other vulns. Stack cookies protect only against one thing.
What kind of calculator are you using on mac machine? Default doesn't understand signed values.
Just found info about 2'nd completement, but still, what if I want to work with 32 or 16 bit integers.
BTW, first line of your exploit on github got corrupted. Probably because of vim's "i"-input mode switching
nclude
Did anyone manage to do this against 64x system?
[assembly noob here] Wouldn't a popad and pushad prevent the crash all together if you just inject a huge NOP sled? Or am I just that stupid
+007order007 I'm not sure if I understand. What's up with the push and pop? Also why a nopslide? The stack is not executable, we can't inject instructions ;)
WOW
Got lost XD
Stupid question: Do we even gain anything by doing it this way? we don't get any more privileges because we are launching the target executable from our own low-privilege code, do we? So the RESULT is essentially the same if we attach gdb and modify the cookie from inside the debugger, isn't it?
Or am I missing something?
no privileges are kept when doing exec. Otherwise you couldn't exec a setuid program from your shell ;)
gdb requires the ptrace syscall (and more), which the kernel doesn't allow on processes you don't have privileges to. So gdb drops them before exec.
That's a good point :D Thanks for the explanation!
What's your job? And your mother lenguage?
+Nombre Apellidos security stuff. German
🤐🤐😥😥😮😮
For brute forcing something like this, I would suggest using a GPU for speed
+Nathan Mack doesn't make any sense because this is not something you can do on a GPU. We are not bruting a hash or so.
First! :D