RE: Anonymizing Packets yet ensuring 0 % packet loss

From: Strykar (str@hackerzlair.org)
Date: Sun Sep 16 2007 - 11:36:24 EDT


 
> I am working with a research Team out of IIT Delhi, the best
> educational & research center in India, we were having some debate
> this week were we were asked to break the security infrastructure of
> our intranet! We have found out that the rules are written based on
> the ip classes! & the admin classes are given full access! but the
> problem is that the admins connect to internet over a different
> internet backbone than ours. So we need the IP adress of a machine to
> be spoofed permenantly as the admin's ip adress!

1. Administrators are expected to have "full" access, nothing wrong/new in
that.
2. You cannot spoof your administrators public netblock, forget permanently,
and use that as a pad to find chinks in the security. That's not how TCP
works. You may pull off a few probes spoofing his/an address, but the minute
you need anything that needs a reply from the network, you're back in the
same boat.
This is a good primer on the above:
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
3. Which rules are written on IP classes, and what's wrong with that?
The Internet is made up of machines identified by IP addresses, it's
expected that filtering using this very property of IP will be commonplace.

> pentest is basically to desribe that i will be conduction network
> exploration & default pwd enumeration where ever required.
> I would use the hidden Ip adress to do FTP & other access so that
> there is no problem in the logs when they are analysed!

If you are authorized to conduct a pen-test, why can't you access the
network? <-- You lost 10 points right here.
You HAVE to have been given some access, even if this was an argument
started over some chai one afternoon.
I assume you mean you're going to try to brute force FTP and other services.
You can do this from any IP address for public (visible to Interweb)
services on the network.
Using Tor might help displace a single source as the attacker.
As far as the internally accessible services go, start from a terminal
inside the network, peeking at the WiFi setup should be your first stop.
Test their switches for port security, the list here goes on and on.

Why would there be a "problem" in the logs I the logs when analysed?
Didn't you just say you were authorized to do this? This sounds shady to me.

Irrespective of the IP ranges you connect from, the logs are going to show
up anything half-noisy as a brute-force attack. If they have an IPS/IDS in
place, that will ring alarm bells before you move finish name strings
starting with "AA".
 
> I really appretiate the concern, I would assure you that it is
> strictly for an academic view point!
> we are nt testing it on a real world scenario!
> It is just to make some new n/w rules! and assure that the basics are
> correct!
> Just to test the architecture & the technologies that run it...
>
> thank you...
>
> Expecting some clarity of hw can i go abt it...

If this is an experiment in the interest of academia, and legal, here's a
few things you can start with:

1. Find and list the netblocks owned by them, so you know where to start
looking.
2. Identify the operating systems and software used for all public services
esp. web/mail/ftp/ and see if they are all patched for known
vulnerabilities. Make a list and map the entire network on paper.
3. Scan and check them for open services. Check for services running over
UDP and IPv6 too, as these are oft overlooked.
4. Build a list of services and check them for known vulnerabilities; simple
banner grabbing may be misleading, actually connect and test for versions
and capabilities.
5. Ask users/students what the password, network and security policies in
place. This will give a good feel of the setup.
6. Present all this with your opinions in a report.
- End of friendly academic viewpoint.

Remember that the legality of a verbal agreement between you and a network
administrator (this is what this seems like to me) to test his network is
dicey, and will wind up with you in the soup in a court of law.
Port scanning in India is legal, last time I checked; brute-forcing services
is not.

There's no point delving into exploiting of services for privilege
escalation as that definitely moves into areas shaded grey.
If this is a contracted pen-test agreement, you should look into getting a
qualified person to do this.
This is an area which is too vast to be spoon-fed, besides being the
ethically right thing to do.
Your vagueness on actual results expected from you doesn't help.
At best you could run automated vulnerability checks and present their
reports - again, grey areas, and no value added to them.
The best ones are open source, well there's Core, but it's not something the
client's IT team couldn't have done themselves.

If you can get less vague than " It is just to make some new n/w rules! and
assure that the basics are correct! Just to test the architecture & the
technologies that run it...", try, then someone may help with specifics.

- S

------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:58:07 EDT