HACKED! How a Buffer Overflow Exploit works, plus Code Red!
HTML-код
- Опубликовано: 19 авг 2021
- How does a buffer overflow work? Join retired Microsoft developer Dave Plummer as he explains how CODE RED was unleashed on the world and how it worked so that you can avoid the mistakes of the past. Dave explains how a buffer overflow works and develops one before your eyes so you can be prepared to defend against them.
For those with absolutely no sense of humor, this is a technical explanation of how a buffer overflow works so that diligent software engineers can avoid them in their code. You can't protect against what you don't even understand, so this explanation is to empower developers. Hackers are already well-acquainted with this decades-old problem. Even someone doing 'ethical hacking' should know how this all works in order to perform even basic penetration testing, etc. 
Наука
I'll never forget the first time I saw Code Red in our lab. I had a FreeBSD server that I used for various things which was running apache. I came into the lab one morning and saw there were these strange errors in the system logs. I called the IT department and advised them of what I was seeing and I was basically told to get lost - I was a contractor at the time. I escalated this to my boss who escalated it to his boss then all shit hit the fan. Fun times. BTW, this was in a giant healthcare organisation with a presence across the globe.
FDA
@@Wokculture69 what does this have to do with the FDA
The code red worm was filling my Linux web log drive partitions for months and years afterwards! Thanks, Dave for the great explainer piece to camera!
I bet a LOT of Unix admins got very used to processing the DEFAULT.IDA requests out of their logs! Of course I guess even the properly patched Windows guys would too.
Even years afterwards, I would see Code Red requests in my Linux access log
Was this the one which tried to scan a specific port? I remember checking the addresses showing up in my firewall log for the backdoor. I could use 2 or 3 of those (i got a lot more entries in the log). I placed a readme file in their rootdir about the backdoor.
@@kylestubblefield3404 nicely done sir!!
I was in University at the time, and we were all called in for the weekend, which we spent scanning the network looking for people running web servers and then making sure they were patched. In several cases, this meant breaking into offices which had somehow been re-keyed to not use the building master that we were issued as admin staff.
Good times.
As an admin, during this time, I remember people freaking out when this happened. Within the government space almost nothing was properly patched, so it is a small miracle that Code Red wasn't worse. As for patching, Microsoft's buggy patches were as much to blame as the worm itself. When a new critical patch came out, the game of chicken started. From Tuesday through the Weekend you would watch newsgroups and forums to see if this patch would take down your servers. If you were lucky you had a bare metal server clone you could test the patch on and see if it broke your company software. This was the era where being an admin meant you not only managed the servers, but you wrote the business software and managed the database.... full stack started at bare metal back then.
in reality Microsoft patches are still rather buggy and the only patches i ever ran while using windows were security. any other patches went by the wayside until a week after and sometimes more to make sure they didn't break shit.
@@KaziiTheAvali_inactive Currently a sysadmin, and can confirm we do updates on the FIRST Tuesday of each month, 1 week before patch Tuesday. This is to make sure the updates have had about 3 weeks to get all their shit re-patched with OOB updates.
Glorious patch Tuesday, breaking forensic software every month without fail.
You should research the old Burroughs MCP tagged memory implementation and none of this would not happened. Your C program would have gotten a run time Segmented Array error as soon as the buffer length was exceeded and the program killed.
Good video, clear explanation. As a mainframe assembler programmer from the 80s I was surprised by the C functions that made assumptions around 'looking for' e.g. a 'string terminating character' and not insisting on somewhat more control over what you were doing. Later when using C myself I discovered how easy it could be to get in a mess. Definitely a good and well-presented video, thank you. While I was already very familiar with the exploit (I've been in cyber security >15 years) this was a smooth and clear description. The more people aware of these elementary exploits the better.
Thanks for the kind words! If you have any cool language experience that would apply to our Primes project, please check it out on Github! I'd love to see a System/360 assembler version that we can run in an emulator!
The standard C library has some issues with these unchecked string buffer access and the varying convention of putting source or target as first argument. Long time ago I had to solve mysterious crashes in an application and it had these unsafe string buffer access all over the place. Any serious programmer would have made a safe string struct wrapper or use C++.
Me too. Moving from 1990s MVS/ESA to x86 I was shocked at the amount of blind trust placed in other code and the incoming data. gets() is the classic example--ouch!
I ended up writing my own functions for almost everything, and then my own compiler (long story).
I like the idea of trying primes on S/360.
For anyone unaware, the "TK4-" Hercules install with MVS 3.8 is literally TurnKey.
I began in Unit Record Equipment, 407s etc then moved to 1401, 360, 370, 4300 series, then S390. I have written millions of lines of code in mainframe assembler and even some micro code on a 360/30.
I built my own microcomputer utilizing IBM Op codes and EBCDIC so i could test my code before getting valuable actual machine time to test.
Once I got my code running on the mainframe I crashed the program by implementing an invalid Op code from the front panel. I got a core dump, then corrected my source code to reflect proper operation.
I then was fascinated by the Intel 8080 and built another machine using this and the S-100 bus where I could obtain I/o cards etc. I made my own front panel as well. The whole stack pointer and very limited registers left me puzzled as to why they didnt adopt tried and true technology of IBM.
I trained COBOL programmers how to read core dumps as well. And even got COBOL to dynamically call other COBOL programs. Something that IBM said could never be done.
I also got mainframes to talk to another using the 3270 protocol, again something IBM said was not possible (later they developed Bisynchronis Pass Thru or BPT) this allowed applications to talk to another application directly using STD COBOL under CICS.
I LOVE mainframe assembly programming and consider INTELs x86 model a toy that wants to play in a grown up world .
What i could do in 32k of memory could not even be dreamed of in C or C++
@@rty1955 Sounds as though you had some fun over the years!
From my POV, x86 suffers from compatibility going all the way back to its roots with the 4-bit 4004.
x64 is a lot cleaner, and if we can just exterminate every null-terminated string I'll be happy :-)
Mountain Dew Code Red also fueled most of my late night studying sessions in college. Stuff was great.
Hitting up a 7-11 at 2AM to resupply with Code Red. Made mention to the clerk the stuff seems a bit on the addictive side. He mentions he goes through a case every few days.
My health tanked shortly thereafter.
@@quintessenceSL I drank so much I became allergic to red food coloring.
As I recall, when Code Red happened the Canadian version of Code Red wasn't caffeinated
You editing has really improved, it is very entertaining. And the content is even better.
Keep up the good work!
Great content! I learned a lot from this. You show examples without going overboard and do a great job with the explanations. Please, keep it up!
I really like your videos like this where you tell a story and explain how something happened. I especially like the ones where you track down inside information of what was actually said or done by the people that said or did it. It's a extra bonus when examples, such as the buffer overflow demonstration, are presented like this video.
I love the sinister intro followed by that cheerful and glorious smile and salute with "Hey I'm Dave"
This is one of my favorite videos on this site so far. A little over my head initially. Please do more of these with similar explanations as to the buffer overrun explanation. I tried to get into similar stuff like this a long ago using the SoftIce debugger however couldn't find a replacement (with the same ease and power) for this after windows xp.
These are terrific accounts, *please* keep them coming! The addition of bloopers is a nice touch.
Glad you like them! If you've ideas for other topics, please do share, as I enjoy doing them! The bloopers are hit or miss, depends how it went that day, so sometimes I don't include them!
I love this channel man, I’ve been super interested lately about low level programming along with just interesting software engineering concepts such as your quake video. I have never heard of you before yesterday but as a cs student your skill set is something I strive to achieve. Thanks for the videos
I have been really enjoying your channel. The last 96 seconds of this video are gold, I like that you don't take yourself so serious and are able to show the outtakes. Keep up the good work. Story 10/10 would recommend.
Thanks much!
I enjoyed watching your bloopers at the end of the video and presenting them in B&W was an extra nice touch. I hope you'll consider doing this in all of your new videos too
Well this certainly brings back some memories! I've worked in the field since 1995 (currently at MS as a digital forensics investigator.) I recently found your channel and really enjoy it. I run a security-focused channel and I can certainly appreciate the amount of time you put into making this content, especially with the high production value.
This is by far the best explanation of how buffer overruns work. When I first encountered such things, I felt it was a bit of "black magic", until I saw the updated source that fixes such things. It took me a great while to understand the details because the patch was only explained in terms of the fix: to perform bounds checking on a buffer. Obviously the reason for such vagueness is to prevent exploits from spewing everywhere. Thanks for the deep-dive into how all this works....and, hopefully as you said, people will "not use their powers for evil" ;).
I missed this when it came out. This was a really good explanation of the buffer overflow exploit. My software experience is limited (I'm mostly a hardware guy) but I programmed in assembler and BCPL in the 80s and a little C in the 90s. I understood pretty much all of this. Thank you.
Your code was a concise and perfect example of what can happen with a buffer overflow. It brought back early-90s memories of unintentional buffer overflows, when my code would cause my DOS machine to beep (ASCII 07, I believe) and display blinking characters. Ah, the good old days. :)
Thanks mate for this, as a hobbyist programmer it's always interesting to see the full power of the debugger in an interesting and engaging way.
Wow, was just thinking of researching something along these lines. Thanks, Dave! Now i can properly enjoy my Friday evening. Let me grab a cold one, Cheers!
Have fun!
Most content creators who discuss this stuff would have said '...the stack is more complicated that this for several reasons', ending there and moving on. You, on the other hand, have just made me a very happy man. As soon as I heard 'Firstly,...' I knew you were going to detail why its more complicated which is exactly why I am now subscribed. Love to learn and you're a great teacher and story teller!
I really like your stories! I was a nerdy kid in a small farm town the 90s. I dreamed of computers but had little access. So learning what was actually going on at the time is very satisfying. Thank you
This is awesome. Absolutely love the idea of covering viruses and bugs through history, and showing how they worked. Please make more of these! Great work Dave!
Very well explained man! Always a pleasure to watch these videos!
Glad you like them!
This is such a fantastic video, both entertaining and educational.
I work mostly with embedded systems which lack a lot of the protections a full blown OS and a lot of static analysis tools provide. More and more embedded systems are being connected to the internet each day and I think we will see them experience many of the exploits that have been protected against, on servers and desktops decades ago.
It's videos like these I share with many embedded Devs to hopefully help them understand and protect their code against attacks like this while maintaining lean code bases.
Thank you!
Your blooper reel on this one makes me feel extremely seen; I don't Make Videos or anything but the way I talk to myself anytime I'm alone while I'm just doing whatever is a LOT like that, lol.
Been really enjoying your channel & learning some interesting stuff as well! Thanks for sharing such a cool assortment of information here :3
It really is interesting to see a programmer's perspective on vulnerabilities rather than just hearing people reporting on it.
Dave, I love your podcasts and most importantly your edits at the end! I laugh at each edit and wonder how you ever geta podcast completed! Keep it up!
I love your channel! My career spans from 1977 to 2010. I lived through most of what you discuss!
Love the direction you're headed with these types of videos, Dave! Might be a fun time to pivot to ROP-based exploits if you have any examples you think would be worthy enough to cover. :)
Agreed. Would love to see it.
Heh heh, I see what you did there 😆
This is a great explanation. Possibly the best I've ever seen.Thank you.
My God. I discovered this series by accident and I’m glad I did. I haven’t written a line of code for a couple of decades but this sure takes me back to my roots (pun intended). I was, at one time, quite proficient in C/C++ and assembler. There was a time when we had no choice but to write and maintain our own drivers for new hardware on some platforms. I go back to the time when all our programs had to be written in 32K overlays and manually swapped to execute. I’m fascinated by the idea that techniques I used back in the day will still work 30 years later.
I appreciate you showing a basic buffer overflow without overrunning the buffer into the heap or heap smashing. Still gets the point across with out allowing for system wide access. Although I suppose since code red already had system access they didn’t have to heap smash just execute the payload.
Loved learning about how the heap stack works on a deep level! The information on the worm was the cherry on top.
I'm not a developer, coder or anything related to IT except I look after my own business systems and have coded in the past and am old enough to have been around for most of these stories :-)
You're easy to listen to Dave, I enjoy the background.
Great video Dave, I for one appreciate your dedication to the art of programming and this channel.
The bloopers are great lol, keep up the good work mate!
Thank you for this thoughtful and entertaining look at Code Red. I've watched several of your other videos and love them all. Cheers.
Great description of how a buffer overrun works! Thanks Dave
Good job yet again. The quality and entertainment value of your videos are increasing.
Excellent video, Dave! Thank you for explaining (and showing) how this happened (happens).
Top vid. I always enjoy listening to folks who actually know what they are talking about.
I loved this video, please do more like these. The small code demo was great :)
More to come!
Dave, not only have you had a hand in creating many useful and well-used features of popular operating systems, you're a great storyteller too. Keep making good content.
I don't know much about low level stuff, so seeing the memory addresses like that, and the EBP being overwritten was really cool
Thanks again Dave for explaining this in an understandable format :) Loved it!!!
Oh my goodness your visuals are amazing! 🤩 What camera do you use?
Thanks Dave that was a fun episode! … like the bloopers too 😊
Great video Dave. Very informative and well explained. Could you maybe cover the heartbleed exploit as a follow up? I think it's a great example for how poor oversight can compromise cyber security
I loved the blooper part. Man, makes me feel so much better about recording shorts. I always have a foot in my mouth as soon as the camera is rolling.
Dave: "As you can see, my channel is still fairly small."
Me who is subscribed to classical music channels which are 10 years old with
Hey Dave - Enjoying your vids serves to make me wish even more I actually understood even a small bit of the details. I've probably got about 10 years on you, and even considering attempting to learn enough to grasp the bits mostly makes me need a nap. Regardless, fascinating and entertaining.
Thanks! ... DT
After all these years…. I still double check my targets, but I yell under my breath “FIRE!!!!” Love your content. Thank you for all you do.
Great video Dave. Entertaining and informative. Keep them coming.
Hi Dave love the channel I’d be really interested in hearing you explain more low level computing concepts for example someone mentioned a hook to me the other day and even after reading up on it I’m still somewhat confused
Thanks! I'd love to show how Windows Hooks work, they're cool. I once wrote a "Task Recorder" app called WinMonkey that set various hooks and then recorded everything you did, so it could play it back as a macro. I got it to about 99.5% reliable, which I deemed a "tech support nightmare" so I never released it! But I got plenty of experience.
Long story short, you write a DLL with an entry point called "MyWindowsHook() in it". If you set a global hook, when you do so, your dll is loaded into EVERY windows process immediately. I assume threadattach runs for every thread, etc... Then your DLL is called whenever the thing you've hooked happens. Let's say it's a keyboard hook. So every time anyone presses a key, every windows process calls their "MyWindowsHook()" function in your DLL. But each is loaded separately into each process, and they can't see each other. When I did it, I created a C++ template for a shared memory object that could be seen by all instances, and I remember that being complicated to write (sempahores, mutexes, etc) but handy to use!
It's been a lot of years, I'd have to look back, but I think you can hook down to the Get/Peek message level... so you can inspect and/or modify any and every windows message sent or received by any process. It's an immense amount of power, and a real bitch to debug when you make a mistake!
I love these trips down memory lane. When Code Red hit I had been using Linux for a few yers already. I recall watching millions of hits on my Apache server at home from Code Red. I then found a request on the net that was crafted to target such a buffer overrun. Of course I could not resist trying it on some random servers. Soon I found I had a directory listing and access to some server or other. At which point I thought better of that game and backed out.
Very entertaining yet informative! Great stuff.
Wow, am I ever glad I took that assembly course. I’m surprised at how much sense this makes to me.
Excellent explanation! I loved the story telling parts as well.
Pretty interesting. I already knew about the stack and that putting too many things into unsafe functions could result in access to wrong addresses but so far I haven't been able to figure out how this would be utilized to inject malware. Thanks for the video.
Amazing video as always! Hi from Italy ^^
I enjoyed your video very much, even if it went right over my head, due only to my ignorance. Still very interesting and well put together. Hopefully one day I will be able to follow along properly. Keep up the good work!!!
Its good to watch someone that actually knows what they are talking about.
It's almost like you heard me recommend your videos to our team the other day.. Using the interactive debugger and running through it the way you did is great, easier to follow along (I suspect) than the way I did it (jumping in and out of gdb) - wish I'd thought of that.
Awesome video Dave. Very informative.
Glad you enjoyed it! Trying to strike a balance of "real technical info" without scaring too many away!
This is crazy! I wanted to analyze Code Red when it came out but never got very far. I did track it in web logs for a while though. Now, just two weeks ago I started a new job at a well know cybersecurity company and I’m looking for ways to simulate malware. I’m definitely subscribing, I just got finished watching your Quake algorithm video. One of my co-workers also used to work at Microsoft.
Love it!!! You sir are showing the world how it's done...
I remember this exploit very well! I also remember the month the whole company focused on nothing but a search-and-destroy mission to find exploitable buffer overruns and other security enhancements (February 2002 IIRC), resulting in XPSP2. There were a lot of long hours on the IE team that month. Have you thought about doing a video on the Trustworthy Computing initiative?
For how common these attacks are, there is drought of videos that do even half this well explaining. Thanks for demonstrating.
Also, the blooper real is a nice touch
Glad you enjoyed it!
Great video. Thanks Dave. Please do more C++ tutorials
Fascinating. Thank you Dave!
Back in the days before file storage services like OneDrive, Dropbox, Google Drive etc. I used the IIS function of my home PC to save files from my work laptop as I traveled. I had a static IP on an early DSL line, so it was pretty convenient. Somehow; someone managed to get my IIS password. They didn't install malware, but they did uploaded several massive password-protected RAR archives which were subsequently downloaded many times, using all the bandwidth of the connection. I still don't know how they got into the server, but it was frustrating. I never figured out the contents of the archives, but I expect they were pirated movies or pirated software of some type.
This virus still stands as one of my biggest technology nightmares. I work for a large ISP and our CMTS's (cable modem routers) couldn't keep up with the number of new sessions that were being created by our customer's infected Windows machines - effectively taking our entire network down for days. We learned how to find the signature of infected machines on our network, shut down each one manually, and tried to contact the customer to beg them to patch their machine. The problem is, the customers couldn't download the update from MS because we shut their access down due to the virus! So we had to open them back up, one by one, until enough of our customers patched to break the session-overrun log jam. Once we got things under control, I remember me and my colleagues installing fresh versions of Windows, plugging them into the Internet with no firewall/protection, and they would be infected with code red in literally seconds. It was a terrible virus. Thanks Microsoft.
Great video Dave - not going to pretend that I fully understood all of this but very interesting nonetheless. Thanks mate :)
I'm new to your channel. I'm no CS savant but I love what I've seen. This is my sixth video in my binge watching adventure. :)
Welcome aboard!
A very insidious side effect of code red was that infected machines attempt to set up thousands of connections per second. I was working for a tiny ISP at the time, back then very few routers did TCP handshaking in hardware (even if they did promise hardware routing or layer 3 switching as Cisco called it) and this meant that our carrier grade router's CPU was inundate with connection set up and tear down tasks.
This is absolutely fascinating, great video!
Great video Dave! Will you ever bring the Dave's Garage mugs back? Would absolutely love to get one.
Of course, they've always been available in the channel store. And if you grab one before year's end, all profits go to special needs kids. If you have trouble finding them let me know, but you should be able to just visit the channel and pick the "store" tab!
Love the outtakes at the end of the video And the content of the video is amazing
Hey Dave, brilliant video again! I so wish you could have been my mentor when I worked at Microsoft!!! Keep up the good work!
thank you for your time and always a pleasure to watch your videos keep up the ace work 🙂
I was involved with cleaning up a few servers hit with Code Red. Wasn't a fun experience. Thanks for the clear explanation of how malicious payloods are delivered. :)
Probably my favorite video of yours. Keep it up.
Wow, thanks!
This was one of my first informal lessons in computing being heavily involved with MUDs back in the day. They were all poorly coded out-of-the-box and much fun/headaches could be had depending on whether you were an owner or user. Pretty much any place there was text input (it was all text), you could bet it's length wasn't checked. Segmentation faults a plenty!
haha that sounds like a good time
Fascinating video; thanks for sharing! And, I also enjoyed the reinflected payludes at the end; I always hate it when my payludes get reinflected. :-)
Thanks for a great session as always!
I respect you and your work. Thank you, Dave, for making such great content and sharing such fascinating information!
Strong Rod Serling for the intro. That was fun.
Me being a retired "Fork Bomb" coder, I loved this video.
Just badly written code, and that happens, not sure hosting service/compile farms too happy about that.
Awesome info , great video * thumbs up * .... oh and i really loved the 'blooper' section
Thanks! They're a little embarrassing but at least they're natural that way :-)
I love this kind of stuff, it might be entirely out of your field but, it would be awesome to see someone who knows the fundamentals of this kind of attacks take a look into Arbitrary Code Execution exploits in old videogames from the outside
I'm new to your channel but i love your vids. Specially the stories from the ms office 😂 the outro wins on this one though xD
Love this kind of story Dave. More please.
I don't know why I listened to 25min of a foreign language gibberish, but for some reason, I feel compelled to learn to code.
Thanks for sharing this. Your efforts are much appreciated.
We all need you as our wise teacher. I feel real respect for you, and yes, I loved your software when it was fresh back in the day. A Russian software developer here. Get me right, I believe we engineers can still live in our creative world where borders and politics do not exist.
Ace video. Brilliant. And the outtakes are 👍👍
This reminds me of my college assembly project. My project overwrote parts of my professors OS because of a math error on my part. I did get a passing grade because the project did most of what it was supposed to, where other's projects wouldn't even run. Good times.
Hilarious 😂
Thanks for the learning.
Thank you for these wonderful videos.
very nice explanation of how to actually get code to run through a buffer overflow exploit :)