Re: Vulnerability Scan 200.127.113.193, 69.93.128.17

["Paul Scallan" <paul () eyesonsolutions com>]

I have had similiar experiences on the various networks I manage.  I 
wanted to tell you that your narrative, etc was excellently written. 

I use a rule based set for certain IPs that prompt me by e-mail when I 
have any connection attempt.  I also closely monitor my IDS system for 
anomalies and create rule sets based on attack patterns by hand.

Other than being especially vigilant, just practice good InfoSec.  

By the way, I can maybe provide you some more specific guidance, but I 
have no idea what type of IDS and/or firewall system you have in place.  
What platform, etc?

Paul Scallan, Jr.
EyesOn Solutions
paul () eyesonsolutions com
http://eyesonsolutions.com



-----Original Message-----
From: Kirby Angell <kangell () alertra com>
To: Incidents List <incidents () securityfocus com>
Date: Thu, 04 Nov 2004 00:50:39 -0600
Subject: Vulnerability Scan  200.127.113.193, 69.93.128.17

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> (parts of report redacted for confidentiality reasons)
>
> Start Of Attack:      20041101 17:11:47
> End Of Attack:                20041101 18:16:14
>
> Attacking IPs:                200.127.113.193/Windows/Brazil (A1)
>                       69.93.128.17/Linux/US (A2)
>
> Destination IPs:      XXX.XXX.XXX.XXX (V1)
>
> Type of Attack:       HTTP URL based mostly on port 80 and 443; some odd
> traffic 995 (POPs), 25 (SMTP)
>
> Summary
> - --------------------
>
> Two attackers initiated a mass vulnerability scan.  Since the scans
> overlapped and targeted the same ports (80 and 443) using the same sort
> of attacks, both are assumed to be under the direction of the same
> blackhat.
>
> Only one attempt generated a positve response.  GET requests on port 80
> of V1 for URI "/manual/" returns the Apache docs.  There must be some
> possible vulnerability here or the scanner wouldn't have scanned for
> it.
> ~ Since we don't need the Apache docs on the production server the
> directory has been removed.
>
> Narrative:
> - --------------------
> This attack was foreshadowed by a recon probe by A1 on 2004/20/29.  In
> that probe, the computer was operated by an individual as he traversed
> our website.  He came to our site via a link from one of our customers.
> ~ Over the course of an hour and 15 minutes, A1 looked over the site
> and
> tested some of the publicly available features.  He then attempted a
> couple of bogus URLs (?/images/? and ?/admin.php?) and left.
>
> A1 returns on 2004/11/01 at 17:11 and begins manually poking around for
> the next 4 minutes.  This time he tries ?/admin/? which also doesn't
> work.  A bit more poking around and then we get the opening salvo of
> what is almost certainly a vulnerability scanner; possibly SSS
> (http://www.safety-lab.com/en/products/1.htm).
>
> A1 then begins testing particular services.
>
> SNMP gets several hits with various community strings.  The source port
> is always 3656 and each request is tried twice.  None of our community
> strings matched as V1's router community strings are not left at the
> defaults.
>
> A1 connects to SMTP port 25 and says ?helo sss?.  Tries ?vrfy?, ?expn?,
> ?rcpt to:? using ?root?, ?Administrator? and ?admin?.  All commands
> were
> rejected by V1 mail server.  Sets recipient and from to
> "sssx () example com."
>
> A1 then begins trying 904 URLs on ports 80 and 443.  When connecting to
> 443, A1 makes no attempt to initiate an SSL connection.  V1 web server
> rejected all port 443 requests because they were not SSL encapsulated.
> V1 web server rejected all but 2 port 80 requests for a wide variety of
> reasons.  The two accepted requests were actually duplicates:  "GET
> /manual/? which returned the main page for the Apache manual.
>
> While A1 is sending HTTP and HTTPS requests, A2 starts sending its own
> requests.  A2 connects exclusively to port 80, but sends a whopping
> 2,316 requests versus A1's 904.  Since both A1 and A2 attacks were
> overlapping and of a similar nature, I believe they were launched by
> the
> same person.
>
> The URIs requested are all over the place as far as target environment.
> ~ Some directed at Apache, some at IIS, Linux, Windows, others for more
> obscure web servers and even some embedded devices.  It appears that V1
> was not vulnerable to any of the URIs since all but ?/manual/? were
> rejected.  The wide variety of target environments and sheer number of
> attack vectors lends more credibility to this being a large scale
> vulnerability scanner.
>
> Analysis:
> - --------------------
>
> This scan was very noisy, resulting in the web server log files being
> filled with tell-tale signs.  Here are two possibilities on the nature
> of the blackhat:
>
> a)  script-kiddie low on skills just looking to see if V1 is an easy
> target.
> b)  higher-level blackhat doing a vulnerability scan using throw away
> IPs while considering a future attack.
>
> (a) is probably the likely choice, due to the sheer numbers of
> script-kiddies vs. higher-level crackers.  However, this scan involved
> multiple IPs, on in Brazil and one in the U.S. with two different
> attacking platforms, Windows and Linux.
>
> We have shunned A1 and A2 from our network, which is a likely result
> from a non-soft target with such a noisy scan.  If (b) is true, then
> the
> attacker must have known the scan would be easily noticed and therefore
> used IPs he didn't plan on using again on this target network.  If
> true,
> this attacker may come back with an alternate plan.  Or possibly he
> expected to be able to use one of the exploits quickly before we
> noticed
> and cleanup the logs before we saw them.
>
> (rest of report deleted for confidentiality reasons)
>
> If anyone has any comments I would appreciate hearing them.  I'd really
> like to come up with some way to "watch" for traffic from paticular
> IPs.
> ~   In this case, we saw the initial poking around by the bad guy in
> late
> October and realized he might be back.
>
> - --
> Thank you,
>
> Kirby Angell
> Get notified anytime your website goes down!
> http://www.alertra.com
> key: 9004F4C0
> fingerprint: DD7E E88D 7F50 2A1E 229D  836A DB5B A751 9004 F4C0
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFBidE/21unUZAE9MARAmXhAJ9Yc2nD5krPDixhiuI/WspzDNaJfwCeNidK
> N0U27pHiYTzezUTQbNd1Cm8=
> =J8na
> -----END PGP SIGNATURE-----