Re: Anonymizing Packets yet ensuring 0 % packet loss

From: Vivek P (iamherevivek@gmail.com)
Date: Sun Sep 16 2007 - 12:55:52 EDT


Hi Strykar

thanks for writing back to me! please read inline....

I understand that my way of explaining things may be a lil weird, may
be that i am not good at explaining it! I would try & keep this as
simple as i can

On 9/16/07, Strykar <str@hackerzlair.org> wrote:
>
> > 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.

Okay! Let me define what is my target so that we can be more specific
in what we discuss here. The end result that i am looking from this
exercise of mine is to by pass the security systems in place & prove
to my authorities that they don't have a proper system in place!
They are the best, i understand tat point, still i m pretty sure that
they would have missed something! IBM, SUN SOLARIS, CISCO & MICROSOFT
directly maintain the infrastructure for IIT delhi & they have blocked
almost all the fun for the students, you cannot connect outside the
hostels, cannot set VPNs, Cannot setup LAN chat services, etc etc...

> 2. You cannot spoof your administrators public net block, 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.
>
hmmm.. i think i understand the basics (may not be the best) ! i
understand that it is not that easy to tamper with the basics! My
point of thought was to understand areas where things can be misused
(not exploited). As the saying goes " Some rules can be bended others
broken", this is what i am trying to figure out!

> > pen test is basically to describe 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.

There is no problem here! We are permitted to conduct any & all tests
on the network (permission on paper already issued to us)

> I assume you mean you're going to try to brute force FTP and other services.

No, not exactly, we will be trying any and all possible combinations!
what so ever it is..

> 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.
>

My requirement here is to send and receive packet through / as the
network administrator or anonymous (so that the ip address from which
we do the attack is not revealed)

> Why would there be a "problem" in the logs I the logs when analysed?

We do not want the administration to say that " we could have stopped
you doing this, our logs clearly show your ip addresses scanning the
network & blah blah" It will become a demerit to us when we have to
prove them wrong!

> Didn't you just say you were authorized to do this? This sounds shady to me.
>
Yes i did. we are hereby trying to do it with least possible detection
& if we are logged it is like "no cover"

> 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".
>
What if each attempt is from different machines at different time. WE
students run brutus every second day on the administration & web-proxy
servers (so if the ip is randomly shown, possibility of detection
becomes minimal)

> > 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.
>

Thanks for that! we are clear how to do pen test! We do it
professionally as a company for many clients across the world! But i
appretiate you concern.

My question was on how to handle the source ip address problem!

> 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.
>
We can do anything except bringing down the server
We students have been issued on paper that there is no legal action if
we prove them insecure. So there is no legality involved!!

> 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
>
>

I think the explanation above has helped!

i wil tell my process step by step

a. enumerate the services, administration subnets, department subnets,
library subnets, hostel subnets (already completed)

{Given all subnets operate 24 * 7 * 365 (atleast one node always online)}

b. logging enabled on all the services & firewalls, ACS, IDS IPS on
all entrypoints (CISCO, IBM & SOLARIS manages these)

c. We already have infrastructure to do simultaneous tests & determine
flaws! but they reveal the source ip (we were caught twice because of
the ipaddress)

d. WE ARE LOOKING FOR: a solution where my source ip can be spoofed
but data comes back to my machine {preferably an ip from the admin
subnet which is off line}

e. I was told to try Tor, which is underway!, still the problem stays!
we need to mask the source ip address

A question (given: the n/w has a single DNS server)

If i poison the DNS server, Will i be able to put myself inside the
admin subnet (given i know the configuration settings for the
admins..)...

& i would like to know some opensource tool to do DNS spoofing!
-------------------------------------------
Vivek P Nair
Vice President Technology
Appin Group Of Companies
Appin Security Group
Module III TBIU
IIT DELHI
Hauz Khaus
New delhi
India
www.appinlabs.com
vivek.p@appinlabs.com
+919910924675

We explore... and you call us criminals.
We seek after knowledge... and you call us criminals.
We exist without skin color, without nationality, without religious
bias... and you call us criminals.
You build atomic bombs, you wage wars, you murder, cheat, and lie to
us and try to make us believe it's for our own good, yet we're the
criminals.

Yes, I am a criminal. My crime is that of curiosity.
My crime is that of judging people by what they say and think, not
what they look like.
I am a hacker, and this is my manifesto.
You may stop this individual, but you can't stop us all!

------------------------------------------------------------------------
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