New Risks in Penetration Testing

Published: 2010-02-22. Last Updated: 2010-02-22 13:58:22 UTC
by Rob VandenBrink (Version: 1)
10 comment(s)

In a recent IPS (Intrusion Prevention System) deployment, I noticed that the newest version of the OS for the appliance I was putting in had a new feature - "Reputation Filtering".  How this works from a customer point of view is:

  • if an inbound attack is seen, the IPS reports the attacker and the attack back to the reputation service.  This affects the reputation of the attacking IP address
  • The reports of all users of the reputation service are aggregated, and attackers are "scored"
  • Traffic inbound into the network is evaluated against the reputation database, such that traffic from lower reputation addresses is penalized from an IPS detection perspective

Since I work on the attack side of the things as well as the defence side, this got me thinking about Penetration Testing and Vulnerability Assessments.  This now means that when Pentesting, care should be taken in selecting the public ip address that you mount attacks from.  If you attack from home or from a free desk at work, you may find that because of this new Reputation Filtering feature, you've just blocklisted an IP address that you need every day to do "real work".  You might be blocklisting your entire company, or even worse, your spouse (from personal experience - you just never want to do this ! ). 

This adds another factor into the process of deciding where exactly you should run a Penetration Test or Vulnerability Assessment from.  Other factors might include:

  • ensuring that your ISP does not filter suspicious traffic, or in fact any ISP between you and your target
  • ensuring that your activity is actually legal on all ISP's between you and your target
  • if using GHDB (Google Hacking Database) methods, you can blocklist your public IP with Google (spouses hate this too!)
  • If the client uses load balancers, you may find that subsequent tests might be against different hosts


All these factors conspire to move your penetration test or vulnerability assessment as close as possible to the target systems.  Using the same ISP as your target is often a reasonable solution, but if you can negotiate it, using a free ip address and switch port on your target's external network takes care of a many of these issues nicely.
 

=============== Rob VandenBrink, Metafore ===============

Keywords: reputation filtering intrusion prevention penetration test pentest
10 comment(s)

Comments

This is another reason for me to dislike IP-based anything (ACLs, blacklisting, dynamic filtering). There's too much potential for 'collateral' banning of innocent users (or penetration testers in this case, and preventing them from making a full assessment). Even if these techniques can stop some of the bad guys right now, then by tomorrow they'll just run all of their attacks from malware-infected PCs.

Steven Chamberlain

Feb 22nd 2010
1 decade ago

The reputation lists for spam, when responsibly maintained, have been dealing with malware-infected PCs quite well. Yes, there are some reputation lists for spam that are poorly maintained (no reasonable appeal process, and/or immense attitude on the part of those maintaining them, particularly when directed against customer sites getting access from a bandwidth provider the spam list maintainers don't like) but I use the lists regularly for quarantining mail and find them to be helpful.

Depending on how an IPS' 'problem child' database is maintained, this could be a useful thing - though one would expect that unlike spam, more of the kinds of attacks that are really harmful would involve automated recon from compromised hosts and a low and slow exploitation of the automated results from a different set of IPs under direct control. The hope, I suppose, is that different attackers' list of usable IPs would overlap, so that attacker A would already have advertised the botnet which attacker B was hoping to stage a manual attack through.

peter

Feb 22nd 2010
1 decade ago

The second point -- making sure the ISP isn't filtering -- is actually a very tricky one. I once had a custom service I was running on port 4444, which I arbitrarily picked. (At the time I was unaware that this port was associated with Kerberos.) A remote user had trouble connecting, and I figured out that packets to port 4444 were being silently dropped -- not by my ISP, and not by her ISP, but by one in between somewhere.

tcptraceroute is your friend when trying to sort out this kind of issue.

David

Feb 22nd 2010
1 decade ago

"...then by tomorrow they'll just run all of their attacks from malware-infected PCs." Well, malware infected PCs (drones) should be blocked already, so I fail to see the reasoning there. (We currently have over 3 million IP's addresses on our blocklist.) But back to the assessment, if the pentest is authorized, certain provisions should be made on the side of the tested party. If defenses should be tested, disable reputation reporting but leave blocking enabled. Once this has proven to be effective, the pentest should probably continue with the IP addresses of the pentester being whitelisted. Afterall, if you have Trustware or Qualys scan your network, you already have their networks whitelisted in order to ensure correct reports, right?

Frank

Feb 23rd 2010
1 decade ago

Argh.

IP based blacklisting is always a losing proposition.

If I want to wreck a network's "reputation" with a service like this, all I have to do is pick a network that doesn't do source IP egress filtering (practically every network), and blast you with malicious-looking stateless traffic (UDP/ICMP) with spoofed source IPs of the network I want to have blacklisted.

Stupid.

Mark

Feb 23rd 2010
1 decade ago

IP blacklisting or any kind of IP throttling that might result from blacklisting seems like a great precursor to DNS cache poisoning.

Also, I think that blacklisting one's spouse every time and again adds a certain spice to the relationship.

William

Feb 23rd 2010
1 decade ago

@Mark: Well, I've been running a distributed blocking fabric for the last 8 years, and I don't have a single bullet hole in my feet. The argument of "I can spoof UDP and block the root servers!" and the like is way off. Those arguments were wrong 8 years ago and they are still wrong now. IP reputation doesn't mean "Hey there's a weird packet, let's blindly blacklist it"! Only analyzed traffic should enter a reputation or block list. You don't let these things run autonomously. Nefarious traffic aside, there is also a lot of non-hostile traffic on networks that a dumb automated system might block on. All sorts of backscatter, late DNS replies, P2P, content networks and other "fastest-route" probes come to mind. You have to be smart about it. It can work extremely well and managed properly.

Frank

Feb 23rd 2010
1 decade ago

So, IP-based reputation may help with 'hygiene' on the wider Internet, identifying troublesome networks and malware infections.

I'm just not sure that it helps a network's security all that much though to use these as blacklists, since a targetted attack may come from a clean IP address.

Steven Chamberlain

Feb 23rd 2010
1 decade ago

@Steve: Well it doesn't prevent a targetted attack from an unknown IP. However, when such a targetted attack is detected, the IP can be banned and placed on the list, allowing OTHER sites to be proactively protected :) So they benefit from it. (Again, the key is detection and solid intelligence on IPs, not a knee-jerk-blockem-all ;)

Frank

Feb 23rd 2010
1 decade ago

As far as i am concerned enhancements will happen in every aspect of business so i think our focus should be more on Testing Scenarios i found Penetration Testing Scenarios in the following link

https://www.eccouncil.org/certification/licensed_penetration_tester.aspx

Smith

Smith

Feb 24th 2010
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives