HACKED! How a Buffer Overflow Exploit works, plus Code Red!
ฝัง
- เผยแพร่เมื่อ 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.
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
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 :-)
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 the sinister intro followed by that cheerful and glorious smile and salute with "Hey I'm Dave"
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!
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.
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.
You editing has really improved, it is very entertaining. And the content is even better.
Keep up the good work!
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.
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!
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.
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
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
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 😆
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. :)
It really is interesting to see a programmer's perspective on vulnerabilities rather than just hearing people reporting on it.
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.
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!
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!
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.
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 love your channel! My career spans from 1977 to 2010. I lived through most of what you discuss!
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!
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.
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!
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
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
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!
This is a great explanation. Possibly the best I've ever seen.Thank you.
Top vid. I always enjoy listening to folks who actually know what they are talking about.
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.
Good job yet again. The quality and entertainment value of your videos are increasing.
Great video Dave, I for one appreciate your dedication to the art of programming and this channel.
Loved learning about how the heap stack works on a deep level! The information on the worm was the cherry on top.
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.
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
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.
Thank you for this thoughtful and entertaining look at Code Red. I've watched several of your other videos and love them all. Cheers.
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.
Very well explained man! Always a pleasure to watch these videos!
Glad you like them!
The bloopers are great lol, keep up the good work mate!
Thanks Dave for doing a super job of explaining this phenomenon in a very clear, yet minimalistic way! I'd like to point out that it has always been possible to prevent buffer overflows in C, because any programmer can write functions which explicitly check for overflow before writing to a buffer; only naivete, laziness, and/or lack of creativity are to blame for the abundance of these exploits. That said, it is nice that most versions of libc now offer standardized functions to help with this vulnerability, and compilers that warn about potentially irresponsible code.
Yes I'm working a video now where I explicitly say that it's POSSIBLE to write secure code in K&R C, just very difficult, and that modern C14 or later makes it much easier!
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.
Excellent video, Dave! Thank you for explaining (and showing) how this happened (happens).
I don't know much about low level stuff, so seeing the memory addresses like that, and the EBP being overwritten was really cool
Great description of how a buffer overrun works! Thanks Dave
Thanks again Dave for explaining this in an understandable format :) Loved it!!!
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.
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 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. :)
Its good to watch someone that actually knows what they are talking about.
Thanks Dave that was a fun episode! … like the bloopers too 😊
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.
I loved this video, please do more like these. The small code demo was great :)
More to come!
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.
Wow, am I ever glad I took that assembly course. I’m surprised at how much sense this makes to me.
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
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.
Excellent explanation! I loved the story telling parts as well.
Love it!!! You sir are showing the world how it's done...
Great video Dave. Entertaining and informative. Keep them coming.
Hey Dave, I would love to see a video with your thoughts on the strict Windows 11 TPM 2.0 requirement and oddly specific CPU compatibility list.
ThioJoe explained these in a video.
There is no any such requirements.
@@lolerie You are allowed to eat the chicken but heating it up above 40 degrees C is forbidden!
Hey Dave, brilliant video again! I so wish you could have been my mentor when I worked at Microsoft!!! Keep up the good work!
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 😂
Love the outtakes at the end of the video And the content of the video is amazing
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.
Amazing video as always! Hi from Italy ^^
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.
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!!!
Very entertaining yet informative! Great stuff.
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?
Great video Dave - not going to pretend that I fully understood all of this but very interesting nonetheless. Thanks mate :)
This is absolutely fascinating, great video!
Probably my favorite video of yours. Keep it up.
Wow, thanks!
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!
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
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
thank you for your time and always a pleasure to watch your videos keep up the ace work 🙂
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!
I remember Code Red. It targeted Microsoft's IIS web server. My internet was so slow because everyone on my local cable modem ISP was infected and swamping the bandwidth for everyone. After examining some of those PC's that were attacking I found hundreds of freshly imaged corporate PC's all with IIS enabled by default on workstations. What sort of IT worker would do that? A very bad one. A white hat released a perl script that would run on Apache and it would automatically use the worms own backdoor to remove the infection and patch the IIS server. Wherever this was deployed, it greatly reduced the traffic jam caused by Code Red. The name of this Perl script? ICE as inspired by William Gibson's Neuromancer. In the 1984 cyberpunk fiction, ICE was an automated technology which stood for Intrusion Countermeasures Electronics. Since everyone was jacked into VR hacking away and surfing the net. ICE could potentially fry an attackers rig or perhaps their brain.
Love this kind of story Dave. More please.
I respect you and your work. Thank you, Dave, for making such great content and sharing such fascinating information!
you are kinda relaxed for a guy who worked hand in hand with people creating all that flawed and bugged software that made all those viral epidemics possible
Great video. Thanks Dave. Please do more C++ tutorials
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!
Dave, that was GREAT. More please.
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
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!
very nice explanation of how to actually get code to run through a buffer overflow exploit :)
The first buffer overflow exploit I wrote was back in 2002 for the Cisco VPN client under Linux giving instant root privileges, developed and exploited under Gentoo Linux and also by-passed the additional security measures they implemented back in the day and was filed under CVE:
2002-1447.
Thanks for sharing this. Your efforts are much appreciated.
Ace video. Brilliant. And the outtakes are 👍👍
Strong Rod Serling for the intro. That was fun.
I always appreciate a good Archer reference.
Can you believe that's the ONLY instance of anyone EVER saying "Use your powers for good" on TV that I could find? I thought it'd be common, but Archer is the only one!
@@DavesGarage Well with a bit of hair gel you could pass for Krieger :P
@@DavesGarage Bob's Burgers S4E16, Deadpool, Jimmy Neutron movie, Paw Patrol movie, there's lots :D