My webserver is telling me that it has received the following
types of accesses repeatedly from several of my fellow comcast
subscribers.
1. they access port 80 but they fail to send by HTTP
request: zero bytes received.
2. soon after they access port 80 again and send a very short
HTTP request, consisting of "GET /" line, a Host line,
and sometimes a long Authenication line. My server
successfully write()'s bytes back to the client program.
Once, the Authentication line looked very odd, like a
bunch of zero bytes with a chunk of perhaps program code
in the middle.
Keep in mind that no domain is associated with my server's
IP.
On 30 Jul 2005 06:07:49 -0700, Bush is a Fascist wrote:
> Hi all,
>
> My webserver is telling me that it has received the following
> types of accesses repeatedly from several of my fellow comcast
> subscribers.
>
> 1. they access port 80 but they fail to send by HTTP
> request: zero bytes received.
>
> 2. soon after they access port 80 again and send a very short
> HTTP request, consisting of "GET /" line, a Host line,
> and sometimes a long Authenication line. My server
> successfully write()'s bytes back to the client program.
> Once, the Authentication line looked very odd, like a
> bunch of zero bytes with a chunk of perhaps program code
> in the middle.
>
> Keep in mind that no domain is associated with my server's IP.
>
> IPs of offenders are always similar to my own IP.
>
> So they're port scanning, right?
No. They are Way Past port scanning you. They've now found a 1D10T.
They're cracking -- or, attempting to crack.
Why in the hell do you have an open port 80 (or, _any_ open port)
as a ".. fellow comcast subscriber."
It's a buffer overflow crack (attempt).
"Bush is a Fascist" <z333r@yahoo.com> writes:
> Hi all,
>
> My webserver is telling me that it has received the following
> types of accesses repeatedly from several of my fellow comcast
> subscribers.
>
> 1. they access port 80 but they fail to send by HTTP
> request: zero bytes received.
>
> 2. soon after they access port 80 again and send a very short
> HTTP request, consisting of "GET /" line, a Host line,
> and sometimes a long Authenication line.
The long authentication line gives it away.
Sounds like an attempt to exploit a buffer overflow that likely exists
on some web server at some point that had a limit checking problem
with the authentication line of an http request.
So, they're trying to hack you. But, that's about par for the course
on the open internet. If you don't have a need to have that port open
or be running a web server, close it up. If you are running a web
server, stay vigilantly on top of updates. And because we're in the
age of the zero-day exploit (exploits written the day vulnerabilities
are announced), intrusion detection, recovery plans, backups, and all
that jazz are all part of the equation.
Bush is a Fascist wrote:
> Hi all,
>
> My webserver is telling me that it has received the following
> types of accesses repeatedly from several of my fellow comcast
> subscribers.
>
> 1. they access port 80 but they fail to send by HTTP
> request: zero bytes received.
>
> 2. soon after they access port 80 again and send a very short
> HTTP request, consisting of "GET /" line, a Host line,
> and sometimes a long Authenication line. My server
> successfully write()'s bytes back to the client program.
> Once, the Authentication line looked very odd, like a
> bunch of zero bytes with a chunk of perhaps program code
> in the middle.
>
> Keep in mind that no domain is associated with my server's
> IP.
>
> IPs of offenders are always similar to my own IP.
>
> So they're port scanning, right?
>
> Thanks
> 333
>
Of course comcast itself always checks for webservers and ftp servers on
their subscribers addresses.
>My webserver is telling me that it has received the following
>types of accesses repeatedly from several of my fellow comcast
>subscribers.
>1. they access port 80 but they fail to send by HTTP
> request: zero bytes received.
>2. soon after they access port 80 again and send a very short
> HTTP request, consisting of "GET /" line, a Host line,
> and sometimes a long Authenication line. My server
> successfully write()'s bytes back to the client program.
> Once, the Authentication line looked very odd, like a
> bunch of zero bytes with a chunk of perhaps program code
> in the middle.
These are standard attempts tomake use of bugs in Windows http servers, and
trigger a buffer overflow inthem.
>Keep in mind that no domain is associated with my server's
>IP.
Yes, it is. All computers are part of a domain, or addresses could not be
mapped to them.
>IPs of offenders are always similar to my own IP.
The infection searches for nearby IPs before distant ones.
In article <dcgcd4$86u$1@nntp.itservices.ubc.ca>,
Unruh <unruh-spam@physics.ubc.ca> wrote:
>"Bush is a Fascist" <z333r@yahoo.com> writes:
:>Keep in mind that no domain is associated with my server's
:>IP.
:Yes, it is. All computers are part of a domain, or addresses could not be
:mapped to them.
How's that again, Bill?
The assignment of an IP address to an interface does not depend upon
the computer being part of a "domain" in any networking sense of the word
"domain" that I am familiar with.
If you wish to be able to look up a host by name to get its IP
address, and your lookup is DNS based (as opposed to NETBIOS say),
then Yes, then one still has the degenerate case that private DNS
servers could be in use and that the host could be "top level"
in the scheme of those private DNS servers.
A hostname doesn't need to be part of a domain until you start wanting
it to be registered in a public DNS namespace.
Meanwhile, the port-scans and probes often go directly by IP address,
skipping DNS, as they don't -care- what the hostname is,
just whether they can infect the host or not. Registered hostnames
are NOT necessary for direct access, only for symbolic access.
--
This signature intentionally left... Oh, darn!
>In article <dcgcd4$86u$1@nntp.itservices.ubc.ca>,
>Unruh <unruh-spam@physics.ubc.ca> wrote:
>>"Bush is a Fascist" <z333r@yahoo.com> writes:
>:>Keep in mind that no domain is associated with my server's
>:>IP.
>:Yes, it is. All computers are part of a domain, or addresses could not be
>:mapped to them.
>How's that again, Bill?
He says that "no domain is associated with my server's IP" Not with his
hostname. IP addresses naturally fall into "domains" (the class of the
address, the gateway through which the messages are routed, etc). That was
what I was refering to. Hostname be damned, nothing really depends on them.
IP addresses are all that counts. (Of course the poster mayhave thought
that somehow the worms required a fully formed name for his machine to
work. They do not. They simply make up IP addresses and try them. They are
a lot simpler than names to guess.)
>The assignment of an IP address to an interface does not depend upon
>the computer being part of a "domain" in any networking sense of the word
>"domain" that I am familiar with.
>If you wish to be able to look up a host by name to get its IP
>address, and your lookup is DNS based (as opposed to NETBIOS say),
>then Yes, then one still has the degenerate case that private DNS
>servers could be in use and that the host could be "top level"
>in the scheme of those private DNS servers.
>A hostname doesn't need to be part of a domain until you start wanting
>it to be registered in a public DNS namespace.
>Meanwhile, the port-scans and probes often go directly by IP address,
>skipping DNS, as they don't -care- what the hostname is,
>just whether they can infect the host or not. Registered hostnames
>are NOT necessary for direct access, only for symbolic access.
>--
>This signature intentionally left... Oh, darn!
In comp.os.linux.networking Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca>:
> In article <dcgcd4$86u$1@nntp.itservices.ubc.ca>,
> Unruh <unruh-spam@physics.ubc.ca> wrote:
>>"Bush is a Fascist" <z333r@yahoo.com> writes:
> :>Keep in mind that no domain is associated with my server's
> :>IP.
Completely unrelated, your box doesn't need to be part of
anything, just that it has a public route able IP is enough.
Sounds like one or another M$ virus/etc, trying to propagate
itself through other vulnerable doze system. It's just increasing
IPs, perhaps starting from the one it comes from, thus you see
them all from your own ISP.
> :Yes, it is. All computers are part of a domain, or addresses could not be
> :mapped to them.
> How's that again, Bill?
> The assignment of an IP address to an interface does not depend upon
> the computer being part of a "domain" in any networking sense of the word
> "domain" that I am familiar with.
> If you wish to be able to look up a host by name to get its IP
> address, and your lookup is DNS based (as opposed to NETBIOS say),
> then Yes, then one still has the degenerate case that private DNS
> servers could be in use and that the host could be "top level"
> in the scheme of those private DNS servers.
> A hostname doesn't need to be part of a domain until you start wanting
> it to be registered in a public DNS namespace.
> Meanwhile, the port-scans and probes often go directly by IP address,
> skipping DNS, as they don't -care- what the hostname is,
> just whether they can infect the host or not. Registered hostnames
> are NOT necessary for direct access, only for symbolic access.
--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 414: tachyon emissions overloading the system
On 30 Jul 2005 06:07:49 -0700, "Bush is a Fascist"
<z333r@yahoo.com> wrote:
>Hi all,
>
>My webserver is telling me that it has received the following
>types of accesses repeatedly from several of my fellow comcast
>subscribers.
>
>1. they access port 80 but they fail to send by HTTP
> request: zero bytes received.
>
>2. soon after they access port 80 again and send a very short
> HTTP request, consisting of "GET /" line, a Host line,
> and sometimes a long Authenication line. My server
> successfully write()'s bytes back to the client program.
> Once, the Authentication line looked very odd, like a
> bunch of zero bytes with a chunk of perhaps program code
> in the middle.
>
>Keep in mind that no domain is associated with my server's
>IP.
>
>IPs of offenders are always similar to my own IP.
>
>So they're port scanning, right?
>
>Thanks
>333
Somebody probably reloaded windows XP on their computer from
their CD and got hacked with a trojan before they could even
download the patches. Last summer I got a new laptop with XP home
and connected it to the net to download some programs. I picked
up a trojan within an hour just using the unpatched IE for
brousing. Without the security patches you can be hacked within
minutes.
> He says that "no domain is associated with my server's IP" Not with his
> hostname.
What I meant was that I hadn't yet bought a domain and told
the domain company to associate it with my IP. Technically yes,
there is a longish hostname that includes comcast.net that
is associated with my IP. I always thought though that "domain
name" refers only to company.com etc. not blah.blah.company.com.
> Sounds like one or another M$ virus/etc, trying to propagate
> itself through other vulnerable doze system.
Sounds plausible because it's certain IPs that are producing
these connections. However this is a new phenomenon.
A few weeks ago the connections came from overseas exclusively.
Then I block those with my hosts.deny. Lately they come exclusively
from other comcast IPs.
At first I considered that these requests, which are small in
number, might be spoofed IPs. However I have two arguments to
disqualify that hypothesis:
1. The second ("GET /") request is large, e.g. 15kB, which
I assume is too large for one packet hence it would require
a bidirectional stream connection.
2. My server's response to the client process's GET request
is written successfully, whereas a spoof has to be
unidirectional.
> Somebody probably reloaded windows XP on their computer from
> their CD and got hacked with a trojan before they could even
> download the patches. Last summer I got a new laptop with XP home
> and connected it to the net to download some programs. I picked
> up a trojan within an hour just using the unpatched IE for
> brousing. Without the security patches you can be hacked within
> minutes.
My first step on using a new XP install is to install
a firewall from CD, then go to mozilla.org and get Firefox,
then in that disable the feature to allown software installs
by websites, and disable Java. I don't use IE but probably
it can be house-trained somewhat.
>> He says that "no domain is associated with my server's IP" Not with his
>> hostname.
>What I meant was that I hadn't yet bought a domain and told
>the domain company to associate it with my IP. Technically yes,
>there is a longish hostname that includes comcast.net that
>is associated with my IP. I always thought though that "domain
>name" refers only to company.com etc. not blah.blah.company.com.
comcast.net IS your domain name.
On 30 Jul 2005 17:21:10 -0700, "Bush is a Fascist"
<z333r@yahoo.com> wrote:
>
>Si Ballenger wrote:
>
>> Somebody probably reloaded windows XP on their computer from
>> their CD and got hacked with a trojan before they could even
>> download the patches. Last summer I got a new laptop with XP home
>> and connected it to the net to download some programs. I picked
>> up a trojan within an hour just using the unpatched IE for
>> brousing. Without the security patches you can be hacked within
>> minutes.
>
>My first step on using a new XP install is to install
>a firewall from CD, then go to mozilla.org and get Firefox,
>then in that disable the feature to allown software installs
>by websites, and disable Java. I don't use IE but probably
>it can be house-trained somewhat.
>
I use a number of webcam web based servers on odd ball ports with
no issues. I run an apache variant on port 80 and look at the
logs for the weird stuff comming in. I can actually copy/paste
some of the exploits to see what they look like. So far the only
virus I've gotten since getting a connection to the internet in
1994 was from an old dos based program. MS products have been the
most succeptable to being exploited due to "helpful" features
that aren't secure or well thought out from a security stand
point.
"Bush is a Fascist" <z333r@yahoo.com> writes:
>Unruh wrote:
>> The infection searches for nearby IPs before distant ones.
>Ah, yes. But I didn't mention that this was preceded
>by very similar behavior from overseas IPs.
Overseas or not is irrelevant - it's the distance between the IP
numbers that are important. E.g. were they in the same /16 as the
attacked computer?
--
The first entry of Sin into the mind occurs when, out of cowardice or
conformity or vanity, the Real is replaced by a comforting lie.
-- Integritas, Consonantia, Claritas
>Sounds plausible because it's certain IPs that are producing
>these connections. However this is a new phenomenon.
I get scans of port 80 every other minute from telecable.es who are in
the same /16 as I am. As of now, they get 403 as answer.
>A few weeks ago the connections came from overseas exclusively.
>Then I block those with my hosts.deny.
AFAIK Apache is not started via inetd and does have its own file
httpd.conf in which you should put
Order deny,allow
Deny from all
Allow from 127.0 <whatever else>
at the right place. hosts.deny won't do you any good in this case.
>I assume is too large for one packet hence it would require
>a bidirectional stream connection.
IIRC HTTP uses TCP/IP only, not UDP. It's very hard to forge
the originating IP number in such a case, at least with modern TCP/IP
stacks.
--
The first entry of Sin into the mind occurs when, out of cowardice or
conformity or vanity, the Real is replaced by a comforting lie.
-- Integritas, Consonantia, Claritas
-------------------------------- snip ------------------------------------
vb@elk:~ $ grep ^http\ /etc/services
http 80/udp www www-http # World Wide Web HTTP
http 80/tcp www www-http # World Wide Web HTTP
vb@elk:~ $
-------------------------------- snip ------------------------------------
But most people do use TCP for HTTP.
> It's very hard to forge
> the originating IP number in such a case, at least with modern TCP/IP
> stacks.
Yes, if the client doesn't run Windows 98 or something ;-)
F'up corrected.
Yours,
VB.
--
Irony has to be marked as clear as possible. Please use asterisks
AND underlines AND <irony>-tags to make that clear - and don't forget,
that closing </irony>-tags are needed to compensate any sarcasm.
>vb@elk:~ $ grep ^http\ /etc/services
>http 80/udp www www-http # World Wide Web HTTP
>http 80/tcp www www-http # World Wide Web HTTP
>vb@elk:~ $
Quite a lot of services have reserved ports for both tcp and udp ...
>But most people do use TCP for HTTP.
[comp.infosystems.www.servers.misc re-added to solicit comments]
.... but Apache (at least in the standard config) doesn't listen to
incoming udp.
- -
I'm often seeing "Microsoft-WebDAV-MiniRedir/5.1.2600" as user agent
in these crack attempts. Is that real or just a joke as "we're l33t
h8x0rs from six centuries in your future"?
--
The first entry of Sin into the mind occurs when, out of cowardice or
conformity or vanity, the Real is replaced by a comforting lie.
-- Integritas, Consonantia, Claritas
In comp.security.misc Wolfgang.Schelongowski@gmx.de wrote:
> Volker Birk <bumens@dingens.org> writes:
> >In comp.security.misc Wolfgang.Schelongowski@gmx.de wrote:
> >> IIRC HTTP uses TCP/IP only, not UDP.
> >vb@elk:~ $ grep ^http\ /etc/services
> >http 80/udp www www-http # World Wide Web HTTP
> >http 80/tcp www www-http # World Wide Web HTTP
> >vb@elk:~ $
> Quite a lot of services have reserved ports for both tcp and udp ...
> >But most people do use TCP for HTTP.
> [comp.infosystems.www.servers.misc re-added to solicit comments]
> ... but Apache (at least in the standard config) doesn't listen to
> incoming udp.
Having a look to RFC 2616, I stand corrected:
----------------------------- snip -----------------------------------
HTTP communication usually takes place over TCP/IP connections. The
default port is TCP 80 [19], but other ports can be used. This does
not preclude HTTP from being implemented on top of any other protocol
on the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the
transport data units of the protocol in question is outside the scope
of this specification.
----------------------------- snap -----------------------------------
"HTTP only presumes a reliable transport" - that is clear. UDP? No way.
Hm... interesting, that in nearly every operating system the file
services contains an entry for http/udp. Searching:
we can read many discussions, wether it could be a good idea to use
UDP also, especially in the HTTP/NG project. But those efforts didn't
make it into the standard.
Yours,
VB.
--
Irony has to be marked as clear as possible. Please use asterisks
AND underlines AND <irony>-tags to make that clear - and don't forget,
that closing </irony>-tags are needed to compensate any sarcasm.
In comp.security.misc Yortuk Festrunk <"Yortuk Festrunk"@snl.com> wrote:
> No surprise there, you fukken idiot.
*plonk*
VB.
--
Irony has to be marked as clear as possible. Please use asterisks
AND underlines AND <irony>-tags to make that clear - and don't forget,
that closing </irony>-tags are needed to compensate any sarcasm.
this is a port scan, right? 
Linear Mode
