Source port 445,80

[Wong Yu Liang]

Hi all ,

  Lately I've been getting a lot of awkward alerts with source port 445.
A few different source IP is connecting to one single IP
from the source port 445 , to random destination high ports. IPS is
detecting ANS.1 bit string overflow on all these alerts. Anyone
care to enlighten me about this ?  Also I've been getting a lot of
alerts with source port 80 that is connecting to port 1434 as well.


Thanks & Regards


-------------------------------------------------------------------------
This list sponsored by: SPI Dynamics

ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper
It's as simple as placing additional SQL commands into a Web Form input box
giving hackers complete access to all your backend systems! Firewalls and IDS
will not stop such attacks because SQL Injections are NOT seen as intruders.
Download this *FREE* white paper from SPI Dynamics for a complete guide to protection!

https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
--------------------------------------------------------------------------

[Valdis.Kletnieks]

On Wed, 05 Sep 2007 18:47:42 +0800, Wong Yu Liang said:

>   Lately I've been getting a lot of awkward alerts with source port 445.
> A few different source IP is connecting to one single IP
> from the source port 445 , to random destination high ports.

Is the destination IP address one that could conceivably be calling
the *source* IPs on those ports, and you're looking at the *return* traffic?

If so, it could be that the destination IP is being tricked into visiting
malicious websites and the like, and what you're seeing is the website sending
more malware down the now-open connection....

(Just asking, because for a *long* time, we had to keep a canned response
form for "ntp-1.vt.edu is hacking my ports from its port 123" complaints.
Of course, the *real* story was they enabled NTP, sent us a packet - and then
their firewall software triggered on the reply).

[Wong Yu Liang]

Thanks valdis
 I suspected so. Possibly a worm propagation and the ips detected the
*return* traffic. But yet the alerts from my ips is very strange. Some
alerts

172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected
172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected

And the list goes on to different destination IP addres



-----Original Message-----
From: Valdis.Kletnieks@... [mailto:Valdis.Kletnieks@...]
Sent: Thursday, September 06, 2007 5:36 AM
To: Wong Yu Liang
Cc: incidents@...
Subject: Re: Source port 445,80

On Wed, 05 Sep 2007 18:47:42 +0800, Wong Yu Liang said:

>   Lately I've been getting a lot of awkward alerts with source port
445.
> A few different source IP is connecting to one single IP
> from the source port 445 , to random destination high ports.

Is the destination IP address one that could conceivably be calling
the *source* IPs on those ports, and you're looking at the *return*
traffic?

If so, it could be that the destination IP is being tricked into
visiting
malicious websites and the like, and what you're seeing is the website
sending
more malware down the now-open connection....

(Just asking, because for a *long* time, we had to keep a canned
response
form for "ntp-1.vt.edu is hacking my ports from its port 123"
complaints.
Of course, the *real* story was they enabled NTP, sent us a packet - and
then
their firewall software triggered on the reply).

-------------------------------------------------------------------------
This list sponsored by: SPI Dynamics

ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper
It's as simple as placing additional SQL commands into a Web Form input box
giving hackers complete access to all your backend systems! Firewalls and IDS
will not stop such attacks because SQL Injections are NOT seen as intruders.
Download this *FREE* white paper from SPI Dynamics for a complete guide to protection!

https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
--------------------------------------------------------------------------

[Valdis.Kletnieks]

On Thu, 06 Sep 2007 12:17:47 +0800, Wong Yu Liang said:
> Thanks valdis=20
>  I suspected so. Possibly a worm propagation and the ips detected the
> *return* traffic. But yet the alerts from my ips is very strange. Some
> alerts
>
> 172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
> 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected
> And the list goes on to different destination IP addres

OK, that's a *different* well-known pattern - as mssql in fact lives on 1434.

What the attacker is doing is using a hand-set source port of 80, to get through
those older firewalls that don't do stateful connection tracking.

Newer firewalls will watch the traffic, and if they see a TCP SYN packet going
*out* to a given port/IP pair, will automagically whitelist the return path,
so the SYN/ACK packet makes it back, but traffic from *other* sites still
won't be able to enter inbound.

Older non-stateful firewalls would simply be configured with two rules:
allow outbound to port 80
allow inbound from port 80
so you could talk to webservers.  So some hacking tools abuse the existence
of such rules to improve their chances of getting in through the firewall...

Incidentally, this sort of thing is hard to troubleshoot when both addresses
are in the 172.16/12 address block, that's an RFC1918 reserved space.  So
either the source is inside your own network, or you need to go look at whatever
is doing your NAT at the border and get it to cough up the *real* IP address
of the source....

[Wong Yu Liang]

Thanks valdis,
 That makes a lot of sense. 172.16.1.254 is a sever with a lot of
critical
Services running so it's a bit hard to troubleshoot. But of course these
are not the real IPs :p. Thanks again

-----Original Message-----
From: Valdis.Kletnieks@... [mailto:Valdis.Kletnieks@...]
Sent: Friday, September 07, 2007 12:56 AM
To: Wong Yu Liang
Cc: incidents@...
Subject: Re: Source port 445,80

On Thu, 06 Sep 2007 12:17:47 +0800, Wong Yu Liang said:
> Thanks valdis=20
>  I suspected so. Possibly a worm propagation and the ips detected the
> *return* traffic. But yet the alerts from my ips is very strange. Some
> alerts
>
> 172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow detected
> 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer overflow detected
> And the list goes on to different destination IP addres

OK, that's a *different* well-known pattern - as mssql in fact lives on
1434.

What the attacker is doing is using a hand-set source port of 80, to get
through
those older firewalls that don't do stateful connection tracking.

Newer firewalls will watch the traffic, and if they see a TCP SYN packet
going
*out* to a given port/IP pair, will automagically whitelist the return
path,
so the SYN/ACK packet makes it back, but traffic from *other* sites
still
won't be able to enter inbound.

Older non-stateful firewalls would simply be configured with two rules:
allow outbound to port 80
allow inbound from port 80
so you could talk to webservers.  So some hacking tools abuse the
existence
of such rules to improve their chances of getting in through the
firewall...

Incidentally, this sort of thing is hard to troubleshoot when both
addresses
are in the 172.16/12 address block, that's an RFC1918 reserved space.
So
either the source is inside your own network, or you need to go look at
whatever
is doing your NAT at the border and get it to cough up the *real* IP
address
of the source....


-------------------------------------------------------------------------
This list sponsored by: SPI Dynamics

ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper
It's as simple as placing additional SQL commands into a Web Form input box
giving hackers complete access to all your backend systems! Firewalls and IDS
will not stop such attacks because SQL Injections are NOT seen as intruders.
Download this *FREE* white paper from SPI Dynamics for a complete guide to protection!

https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
--------------------------------------------------------------------------

[Valdis.Kletnieks]

On Fri, 07 Sep 2007 09:05:50 +0800, Wong Yu Liang said:
>  That makes a lot of sense. 172.16.1.254 is a sever with a lot of critical
> Services running so it's a bit hard to troubleshoot

If you have a critical server, and exploit packets are coming out of it,
you have some *major* issues that you need to resolve *right now*.....

[scott ingle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would suggest trying to isolate the box that is sending these
scans.It has characteristics of a worm,obviously.

The switch or router that is seeing this traffic would be where I
would start looking.

If you can find what part of the network it originates from,maybe you
can find the box that is doing the scans.

Just a thought,
redhowlingwolves
Wong Yu Liang wrote:

> Thanks valdis I suspected so. Possibly a worm propagation and the
> ips detected the *return* traffic. But yet the alerts from my ips
> is very strange. Some alerts
>
> 172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow
> detected 172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer
> overflow detected 172.16.1.254:80 -> 172.17.17.103:1434 MSSQL
> buffer overflow detected 172.16.1.254:80 -> 172.17.17.103:1434
> MSSQL buffer overflow detected 172.16.1.254:80 ->
> 172.17.17.103:1434 MSSQL buffer overflow detected 172.16.1.254:80
> -> 172.17.17.103:1434 MSSQL buffer overflow detected
> 172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer overflow
> detected 172.16.1.254:80 -> 172.17.17.103:1434 MSSQL buffer
> overflow detected 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer
> overflow detected 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer
> overflow detected 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer
> overflow detected 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer
> overflow detected 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer
> overflow detected 172.16.1.254:80 -> 172.17.17.16:1434 MSSQL buffer
> overflow detected
>
> And the list goes on to different destination IP addres
>
>
>
> -----Original Message----- From: Valdis.Kletnieks@...
> [mailto:Valdis.Kletnieks@...] Sent: Thursday, September 06, 2007
> 5:36 AM To: Wong Yu Liang Cc: incidents@... Subject:
> Re: Source port 445,80
>
> On Wed, 05 Sep 2007 18:47:42 +0800, Wong Yu Liang said:
>
>> Lately I've been getting a lot of awkward alerts with source port
>>
> 445.
>> A few different source IP is connecting to one single IP from the
>> source port 445 , to random destination high ports.
>
> Is the destination IP address one that could conceivably be calling
> the *source* IPs on those ports, and you're looking at the
> *return* traffic?
>
> If so, it could be that the destination IP is being tricked into
> visiting malicious websites and the like, and what you're seeing is
> the website sending more malware down the now-open connection....
>
> (Just asking, because for a *long* time, we had to keep a canned
> response form for "ntp-1.vt.edu is hacking my ports from its port
> 123" complaints. Of course, the *real* story was they enabled NTP,
> sent us a packet - and then their firewall software triggered on
> the reply).
>
> -------------------------------------------------------------------------
> This list sponsored by: SPI Dynamics
>
> ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper
> It's as simple as placing additional SQL commands into a Web Form
> input box giving hackers complete access to all your backend
> systems! Firewalls and IDS will not stop such attacks because SQL
> Injections are NOT seen as intruders. Download this *FREE* white
> paper from SPI Dynamics for a complete guide to protection!
>
> https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
>
> --------------------------------------------------------------------------
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG4PzIsrt057ENXO4RAtQvAJ40Y/d8C3hqNvcp4mG5R0vHRzORSwCfdiYe
GURflq2IDdRUFVd5i4L+ONE=
=D0Ju
-----END PGP SIGNATURE-----


-------------------------------------------------------------------------
This list sponsored by: SPI Dynamics

ALERT: .How a Hacker Launches a SQL Injection Attack!.- White Paper
It's as simple as placing additional SQL commands into a Web Form input box
giving hackers complete access to all your backend systems! Firewalls and IDS
will not stop such attacks because SQL Injections are NOT seen as intruders.
Download this *FREE* white paper from SPI Dynamics for a complete guide to protection!

https://download.spidynamics.com/1/ad/sql.asp?Campaign_ID=70160000000Cn8E
--------------------------------------------------------------------------