Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Firewalls
[Top] [All Lists]

Re: Strange entries in Cisco PIX 515e

Subject: Re: Strange entries in Cisco PIX 515e
Date: Wed, 4 Jan 2006 00:07:14 -0500
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

<Prev in Thread] Current Thread [Next in Thread>