I concede that it's not obvious how udp/53 connections (basically,
DNS
queries) on the PIX could be used to compromise the network or a
particular
server on it, but, again, that doesn't mean it's not possible or probable
that someone did just that.
If I can get your machine, by whatever means, to send its DNS queries to
me,
there's no end to the havoc I can wreak. All sorts of "safe" destinations
may
suddenly be reached through a malware-adding proxy....
To do that, I might have to hack your firewall to allow those DNS queries
to
reach me.
[We recently had a case where malware had taken over the DNS server
address
settings of a workstation that sometimes accesses sensitive information. It
turned out to "just" be adware, but we were somewhat aghast to realize what
a
dedicated attacker could have done to exploit that.]
David Gillett
________________________________
From: Compuoso [mailto:compuoso@gmail.com]
Sent: Tuesday, January 03, 2006 9:07 PM
To: firewalls@securityfocus.com
Subject: Re: Strange entries in Cisco PIX 515e
I spoke with Cisco tech support about the strange command lines in
our PIX 515e, and following is what the Cisco tech "concluded":
> Following our phone conversation here is a summary of our
conclusions and the agreed action plan.
>
> Facts:
> 1. Configuration differences were found
> 2. Third interface was installed without administrator's knowledge
>
> Analysis:
> The configuration differences are not allowing outsider to access
the internal network
> * new Access-list found but not applied
> * even if applied, they were only about udp/53 (dns, not obvious
how this could be used)
>
> * connection from outside possible, but through router -> takes
two password cracking before reaching PIX.
>
> Conclusions:
> There is no clear evidence that the network is/was compromised
Changes could result from internal tests done without administrator's
knowledge/approval
>
> Action Plans:
> -------------
> Recommendations to improve security:
> 1. close outside telnet access to router (using access-list on
outside interfaces)
> 2. stop using telnet for administration, even from inside, use
only https or ssh
> 3. Install syslog, configure it to monitor configuration changes
> 4. Use AAA to control who is accessing the PIX for administration
My first observation is that the additional, unauthorized command
lines ARE "clear evidence" of intrusion. Only the IT manager and I would
authorize and oversee someone making changes to the PIX, and and neither of
us did so. Moreover, the telnet and enable passwords on file for the PIX
were changed months ago and, thanks to an oversight on my part, are not even
recorded anywhere. Clearly, someone hacked into the firewall and changed its
configuration.
My second observation is that the external IP address
(63.176.109.161) used in the unauthorized access-list "test1" is, according
to Sprint, part of a Sprint dial-up account rotary. I occasionally
troubleshoot DNS issues, but I have never used and I have no knowledge of
any consultant using a dynamic IP address for a dial-up account to
investigate or troubleshoot DNS issues on our PIX.
Third, the internal server (172.17.7.10) specifically targeted in
the unauthorized access list "test" is the company's main file server, on
which resides all the company's proprietary data, trade secrets, customer
information, pricing information, etc. Not only so, but that server is
running an obsolete NOS (Windows NT 4) and is showing signs of infection.
Indeed, every time we attempt to do anything like reconfigure some of
server's applications and services, scan it for virus, spyware, and other
malware, or even remove the propietary data from it, it blue screens!
Fourth, that an access list wasn't applied does NOT mean that it was
never applied. It certainly is conceivable that the intruder accomplished
what s/he set out to accomplish, removed a few damning command lines, and
moved on.
I concede that it's not obvious how udp/53 connections (basically,
DNS queries) on the PIX could be used to compromise the network or a
particular server on it, but, again, that doesn't mean it's not possible or
probable that someone did just that.
For whatever reason, my manager seems to want to believe that, since
someone could telnet from an external host to our Internet router and then
from the router to the firewall, that someone probably did so and, in the
process, cracked two telnet passwords and two enable passwords to gain
unauthorized access to the router and firewall in this manner. That's a bit
far-fetched to me, though not a completely unrealistic scenario.
So, my sixth and final observation is that the intruder configured
an additional interface on the PIX (intf2). This interface was down when I
discovered the unauthorized changes to the PIX's configuration, but, again,
that doesn't mean that it wasn't used at some point. It should also be noted
that the intruder configured telnet on intf2, in this case using the an
internal (perhaps spoofed?) address of our default gateway/frame router.
What's puzzling about this, to me at least, is that the intruder would have
needed to have physical access to the firewall to make this telnet
connection (because there's nothing attached to this interface card in the
back of the firewall!), but then there wouldn't have been any need to commit
this physical breach of security because the firewall and servers are
located in the same room. Of course, as someone suggested at work today, the
intruder could have simply uploaded some generic configuration to the PIX
that included command lines for the third interface.
Regardless of the details and specifics, it's clear to me that the
firewall has been breached and, therefore, that network and server security
has been severely compromised. Not surprisinly, my manager acts as though
he's oblivious to seriousness of this security matter.
On 1/1/06, Compuoso <compuoso@gmail.com> wrote:
Would someone please tell me the overall meaning and
implications of the following PIX command lines? I discovered them in our
PIX 515e configuration earlier this morning. I suspect that our corporate
network has been hacked. Thanks for your collective insight.
nameif ethernet2 intf2 security4
access-list test permit udp host 172.17.7.10 any eq domain
access-list test permit udp any eq domain host 172.17.7.10
access-list test1 permit udp host 63.176.109.161 any eq
domain
access-list test1 permit udp any eq domain host
63.176.109.161
access-list test1 permit udp any any eq domain
access-list test1 permit udp any eq domain any
mtu intf2 1500
no ip address intf2
