Serious Steps To Pennetration

First and foremost i did not write the article below . A gentleman by the name of M3DU54 (The name i know him by) wrote this . His handle in this article is Meduz . He wrote this for me in reponse to a question i had on how to hack into websites the right way . Not using someone elses exploits tools and programs to do it , but only your own skill .

Heres the link to the original thread i started on this topic :

http://igniteds.phpworkshop.info/phpBB/viewtopic.php?t=11563&sid=52914e97ef2be8a7a9694316f214d70e

This article is comprised of two of Meduz's posts on the matter :

Im looking to learn the steps or mehods to website , forum , & / or server pennetration .

Example :

You have a perticular site you want to gain entry to and gain admin priveldges . But it is not vulnerable to exploits , rfi , sql , or any other noob method ! What are some other methods you can try to find vulnerabilties that will grant you this kind of access ? Serious advanced techniques only please !

Also can anyone give some pointers on how to aproach server attacks , wether it be in regards to attacking a site or what ever the purpose ?

7h3s0urc3

P.S. : If theres any up to date articles on the matter that would be helpfull i will gladly read those . Or if there is anything else on this topic at another URL let me know !

I'm not sure how to best approach this question. If we assume that the site is NOT vulnerable to exploits then we mean one of two things…

1. It is not vulnerable to the usual published exploits, in which case you really need to join a decent group and start picking up fresh exploits before some whitehat ruins your playtime. -or-
2. You want to examine approaches which do not involve standard exploits, in which case the approach depends almost entirely on your level of determination and available resources.

For example, sometimes it pays to examine the whole IP block. Often this will bring to light test servers which are less well defended. In the case of colocated boxes you may find a number of unrelated vulnerable systems at the same facility which can certainly give you some room for probing the hosting agents topology… for example, switches exhibiting CAM (Content Addressable Memory) flaws and similar can be easily turned into rather expensive hubs for short durations - perhaps long enough for you to explore the topology behind them and sniff data on other segments. If you're lucky one of the vulnerable systems will be on the same switch as the target, if not you may want to bide your time and try to sniff SNMP and Configuration sessions to see if that gives you a foot into the wider topology.

Listen for router traffic too, particularly routing protocols and CDP or similar. Very often you can disrupt the routing table by advertising preferred routes to the target over your own subnet to cause their traffic to be dragged over your switch… this is administratively loud though and WILL cause hosts to lose connectivity. In a managed network you will set alarms off pretty quickly… If you have to do this then I'd suggest picking your times well… if you can coincide it with a bot flood (Engineered or incidental) all the better, since any flapping servers will be assumed to be suffering from excessive load and all attention will be on the perimiter any way.

Another approach may be to explore DNS poisoning in order to MITM connections into the target server. This is an advanced topic and is often very much an opportunistic thing. Other similar opportunities may present themselves if you can disrupt BGP route data. Basically, use your head… if there's anything you can use to your advantage then do so.

If the target is not collocated a site visit may be neccessary. Opportunities here range from mailing in product updates/documentation/errata CD's (on printed silvers) with full colour letterheads. Use your head though, find out what equipment/software they use and then contact the vendor to get hold of letterhead samples etc… also get hold of samples of their mailout style where possible… and try to verify the contact name with the vendor where possible (A little smooth talk works)

Approaches like this have worked in the past. Sweet talking an admin out of their cisco account details by faking a callback from TAC… Then, contacting cisco to change the correspondence address to a maildrop company… Collecting the periodicals and updates from the maildrop company and resealing them with the target address and reposting… this gives you a great opportunity to swap out any documentation/product/update CD's for 'suitably altered' ones whilst the original packaging and literature and prior expectation does all the convincing.

Again, use your head - there are many variations on the theme.

Also, with a direct site attack you have the benefit of access to their own telephones (to place outbound calls and intercept inbound callbacks) using standard beiging techniques and a little hacker magic with a soldering iron and a DECT handset ; ) It is pretty easy to put an agent onsite if they call out for a contractor - One of the easiest places for this type of handiwork is callcentres since they take just about any applicant due to high turnover… So, place a trained monkey in there for a month… a little damage to a network laser printer (like nail-varnish on the ethernet socket) is enough to intercept a maintenance callout from the printer vendor and take the laser away… a quick 'board change' later and that same laser printer could include a wifi AP piggybacked onto their network… and now you have an unprotected node on the LAN whenever you want. The best thing about this approach is that they welcome you through the door with a smile and a contractors pass, hell, they will even hold the door open for you while you take their printer out to do a swap-out or board change. If they do a verification call to check you out, this is intercepted too… so, the end result is absolute plausibility.

Okay, so there are some fringe cases… Your target will be different. Thats the problem here, once you rule out exploitable conditions at the tagets internet-facing equipment you no longer have any generic methodology… it all comes down to evaluating what you know about the target and leveraging it in any way you can to either effect some form of direct or indirect access or to at least further increase your knowledge of the sites operation. At some point cracks WILL emerge, you may have to jump through several hoops to take advantage of them (like in switching contact details to intercept vendor periodicals), but thats all part of the game.

But how can I cover it in one post ? Well, I cannot. You just have to see what falls out when you start probing your target… your final vector may be a personal (hence undetected) rootkit installed via an otherwise legitimate vendor CD or it may be something close-range like employee positioning, tapping a centrex line or dropping some line-attached equipment to divert any outbound calls made to their vendors contract services department.

So, I suggest joining a strong active group to get access to <0-day exploits whilst they still have their potency. If all else fails, well, you just have to have plenty of determination and be prepared to keep an open mind as regards alternative methods of entry.

Hell, if all else fails blackmail is always a good fallback ; ) A prostitute paid to pose for your happily married target in a bar in the hope of getting him to her apartment (Complete with covert cameras in stuffed bears or an alarm clock) is probably sufficient to get him to do the electronic equivalent of leaving a window open. What does that cost? $400 or less ? If the information you're after has value to a competitor you may find such conventional approaches a worthwhile speculation.

It's just horses for courses.

-Meduz

@TH3SOURC3

There are people who wander around neighbourhoods looking for open windows. they ain't experts in their field, just kids looking for a quick score. Their technique is not refined so they rely on opportunistic attacks on the weakest targets they can find.

Similarly, many hackers are armed with little more than published exploits - they scan whole IP ranges looking for weak servers. Thats all good fun, but will normally let you down if you've a particular target in mind. To be able to comfortably attack specific servers with a reasonable chance of success you need to be a great deal more flexible.

TH3S0URC3 wrote:
Wow that was amazing . Im a bit winded after all that . Most of it was like something out of "Sneakers"

The point I was trying to get across is that more conventional approaches are often the most reliable way to get what you want - indeed, sometimes the only way. Sometimes you don't have the luxury of choosing your target but you still have to get the work done : )

Whats the saying? Theres 'more than one way to skin a cat' ?

Remote methods

First of all, don't give up on exploits simply because the target is up to date with patchlevels. These days this is pretty normal. You really need to build an arsenal of unpublished exploits. So…

1. Get some primers on exploits, both heap and stack.

2. Examine past exploits and single step through them with a debugger such as Ollydbg or SoftICE till you understand how it looks in the codespace of the vulnerable process.

3. Redesign the payload of a POC and/or look for different ways to generate the return addresses you can use to execute the payload. If you manage both of these tasks then you are definately ready to hunt down your own exploitable conditions.

4. Sit on help forums for various server-side software looking for reports of obscure crashes. Those that are repeatable should be examined in a debugger to see if it is a potential exploit. If so, use the skills learned in the previous step. Otherwise push, pull, twist and poke anything you can until the app spews in a more interesting way.

5. Check out Metasploit.

Once you have a couple of exploits under your belt visit a few of the less commercial conferences and build up a circle of friends. You need at least one unpublished exploit to get into most decent blackhat groups. Most consider a <0-Day exploit as hard currency. Don't give it up until you know they can match it… otherwise you'll give up your advantage to some crappy little defacer or warez group and next thing you know the exploit will be public.

If you're not too worried about your exploit getting some exposure you can always try your hand at a CTF. A lot of recruiting begins behind the scenes following CTFs but you have to be careful, they are also great opportunities to honeypot.

TH3S0URC3 wrote:
#1 : Exploreing DNS poisoning in order to MITM connections into the target

Yep DNS. You may get a few extra targets here. Walk through the DNS record looking for the servers holding both dom and subdom data. These services become valid targets since a record change can redirect traffic via a host you control.

Also look at the hosting company… do they offer a control panel ? Which ? If so, getting into another server hosted with the same company represents a significant opportunity for exploiting flaws related to the control panel and how it is integrated with the local DNS and other facilities. If the control panel runs on a seperate server then this too becomes a viable target.

By now you should have several services and IP's identified… some on-site and some off-site. Compromising any of these can be a stepping-stone into the target system via DNS or the control panel scripting setup.

Next look at softer targets with the same host. You may find a number of sites that are only partially operational and still have test passwords, misconfigured/unconfigured scripts, poor HTACCESS control etc… These can give you a valuable method of entry onto the hosting agents LAN … this immediately opens up ARP, Switching appliances and routing protocol attacks.

For example, by flooding a switch you may be able to turn it into a hub (Look up 'Content Addressable Memory') - By completely filling the CAM the switch can no longer maintain its switching integrity. Depending on the type of switch this can cause anything from a restart (resulting in a flapping switch) to falling back to a hub. Several common switches exhibit this behaviour although the problem has been known for quite some time. The good news is that while it is dumbed down to a hub you get to sniff traffic on the whole segment which can get you a handle on other services, routing protocols, etc.

TH3S0URC3 wrote:
#2 : Listen for router traffic too, particularly routing protocols and CDP or similar .

Yep Routing Protocols, very often you find these are vulnerable to false router advertisement. Advertise a route to the target with a much better metric and the other routers will reconfigure their routing database with you as the best gateway into that subnet. You can either redirect the targets entire subnet, advertise a smaller subnet within the targets subnet, or attack some other facility such as the local DNS server to capture interractions from the control panel (Where the control panel is located on a machine other than the DNS service) What you can get away with here will depend on the routing protocols in use on your network and how they are configured as regards authentication. Surprisingly often you find weak or no authentication used on routing updates.

As I said in the previous post this is administratively loud but can be quite effective. If you coincide this with a botnet DoS attempt some 'flapping' may be ignored.

I mentioned SNMP, CDP and similar… SNMP you're probably aware of, CDP (Cisco Discovery Protocol) are packets by which cisco appliances announce themselves (Model and Name) to their other cisco neighbours. If the routers are directly connected then you're only going to see these if you're actually on one of the routers… but, in a switched environment you will often see CDP crossing the switch and this identifies the routing and switching equipment hanging off the switch.

TH3S0URC3 wrote:
How do you disrupt BGP route data ?

Oh my, I just knew you would ask that. It is one of those things that one could devote an entire book to and not quite cover. I suggest getting familiar with BGP and then googling for BGP related problems. I suggest starting with 'Bogon routes' as these are easiest to understand… when it comes to advertising fake routes from an AS you really need to know your BGP4 inside out and have a good launch platform at a compromised AS preferrably close to the backbone… like so many things this isn't something you can do from your home line.

TH3S0URC3 wrote:
Is there a way to disrupt the routing table by advertising preferred routes to the target over my own subnet to cause their traffic to be dragged over my switch

without being too loud ? Keep in mind the target is not a corporate target . It is merely an online store. To my knowledge they do not have a vast staff that would recognize an interference on a scale that you depict.

You need to know whether they are hosting their own equipment or are located at a hosting or colocation facility. It is the staff of a collocation facility or hosting company that would be likely to investigate a flapping server or route. But if the target hosts their own equipment then it is less likely that they will have appropriate technical staff on hand.

So, just because the site staff are non-technical doesn't mean the hosting company itself isn't going to notice if you accidentally take down a subnet or cause routes to flap.

Whether you can influence the routing tables will depend on a lot of factors. Firstly, theres the routing protocols in use (there may be more than one), the way routes are being aggregated, whether the RP's use strong authentication and even the firmware and appliance models themselves.

TH3S0URC3 wrote:
Also a little direction on how to perform this would be awesome !?

You said to coincide it with a bot flood (Engineered or incidental) , could you possibly inform me on how to perform this task as well ?

Well, you would arrange for a DDoS attack at the same time as you start messing with their routing. If a server or subnet starts flapping then it is likely to be attributed to high load caused by the DDoS… the trick is to apply just enough flood traffic to put the site under a little strain, yet not finish the job completely - you still need to be able to get your own traffic in and out. Obviously a successful DoS attack would prevent you from connecting to your target which isn't good.

Normally this would be achieved using a botnet - this is where the seedier groups on the scene come into play. You probably know some people who like to DDoS … talk to them, sometimes they are useful ; )

TH3S0URC3 wrote:
#3 : Examine the whole IP block ?

By this do you mean all of the IP addresses i found in the dns searches i performed ? If not , what exactly do you mean ? I think i understand what you mean by exposing test servers which are less well defended . I figure you mean that i could possibly get in to my target site by means of pennetrating a site that is on the same server as my target

Yes, sites which are less well defended and use the same hosting facility. To find these pull a whois on the IP of your target and look for the IP block and who owns it, also, find other IP blocks owned by the same entity… this will give you a lot of IP's into the facility. If the hoster has multiple facilities then a traceroute should tell you which IP blocks are being held at the targets facility and which are not. Then, go explore ; )

It seems like you have the basic idea. But not ONLY sites on the same server… sites on other servers in the same subnet… indeed, any site at the same hosting facility. But yes, obviously, the closer it is to the target the better. If you're on the same server then a conventional escalation of privs is required - pretty standard stuff.

Where the sites on a shared server are virtualised then you may as well regard them as being seperate servers. This is when you need to use the vulnerable machine as a platform for manipulating network services, traffic patterns and exploiting trust arrangements with services such as exist between control panels and the local DNS. Heres where any real commentary falls apart… what you do next depends entirely on what you see.

Imagine if on your first sniff you see a RIPv1 packet ; )

TH3S0URC3 wrote:
You said find switches exhibiting CAM (Content Addressable Memory) flaws or vulnerabillities similar . How ? I know you said probe the toppology but in what manner do you mean ? Using what tools or methods ?

That depends on where you are in relation to the target. If you're on the same box (virtualised or not) then sniffing may be immediately viable as may a local exploit to subvert privs. However, if you're on a different box then the chances are you have a switched connection and sniffing will not get you the targets traffic… in most cases this is the situation you will find yourself in.

Lets say the target has the subdom 'webshop' (webshop.sometarget.com) and the hosting agent provides a panel to administrate the subdoms… well, this means you also have access to the panel and this can provide clues about the local DNS, the panels location and how it fits in the topology, the location of critical resources, etc. Again, it all depends on what you see when you get there.

If you're on the same subnet as your target then the switch is the only obstacle. what type of switch is it ? Does it have MAC based port security ? Check for banners, SNMP, CDP, etc… once you know the switch you can look at specific attacks… or, you can try something generic like a MAC flood to break the CAM.

The way this works is quite simple. Switches keep a table of all of the MACs they have seen on each switch port. By flooding the port with a large number of MAC addresses you can fill up this table… when the table becomes full it can no longer operate as a switch as it has incomplete information on the hosts attached to each port. At such times the switch can either crunch or choose to 'fail open'… that is, it gives up on trying to switch frames depending on the MAC address and its internal table and instead starts flooding every frame out of every port. Essentially, it becomes a big expensive hub. Obviously, this is key to sniffing the targets traffic or sniffing network appliance traffic above the switch in an attempt to cross subnets.

The classic demonstration tool for this is MACOF although you can do the same thing on any platform with quite simple code. MACOF is a MAC flooder which used to turn most cisco catalyst switches into hubs in little over a minute… that is over 128,000 bogus MAC entries but the code is rather dated. It still works against many brands and configurations though.

The solution is to set up port security options to limit the number of MACs that can be learned per port, embarassingly few people seem to do this. Another solution is where fixed MAC's are assigned to ports and the switch no longer 'learns' any new MAC/port associations. The latter approach is very secure but the administrative overhead means that you seldom see this in practice. So, you still have a good chance at overflowing the CAM with a MAC flood.

There are other tricks, but this is probably where you should start if you manage to break a parallel system to the target and find yourself in a switched environment.

TH3S0URC3 wrote:
The remainder of the paragraph im reffereing to mentions sniffing . Im going to need to learn this as well ! I think if i can get the principal of the method i can further abuse the concept .

Well, you need to get to grips with the OSI model and the Protocol Data Units used at each layer of the TCP/IP protocol. I suggest downloading ethereal (now WireShark) and looking at your own traffic captures whilst reading up on TCP/IP. the Cisco CCNA material is a great introduction to TCP/IP, Encapsulation and routing/Routed protocols. If you don't have learning difficulties then there is always the RFC's ; )

TH3S0URC3 wrote:
I do indeed want to explore approaches which do not involve standard exploits . Mainly because my knowledge of reading languge and writing exploits is none .

But ontop of that i would rather learn some more indepth methods of pennetrationrather than exploiting validations and typical exploits of that nature

Ever thought of taking some GIAC courses ? Perhaps some Cisco Certs ?

Exploits are important, true. But just knowing how to deploy them isn't enough - you need to understand how and why they work in order to be able to find exploitable conditions in software. Take some time to look at ASM. You don't need to understand how to write full applications… just understand what each register does and have a basic understanding of common opcodes. Most importantly understand segment registers and the stack.

Once you've got the hang of this go read some basic primers on exploits. You need to understand the difference between stack and heap exploits, how the offsets are found and understand how to generate a return address into your payload. Once you have this try applying it to other exploits you see dissected or discussed on the net. Once you are comfortable you should look at these in a debugger such as ollydbg or softice and step through each instruction so that you can follow exactly how the exploit happens.

Daunting isn't it : ) I know it seems like a lot to take in, but it really isn't so difficult once you get started.

TH3S0URC3 wrote:
Thanks alot for all your help Meduz . I appreciate it . Recomend any groups that would be willing to take on an Uber Greenhorn like myself ? I got determination i just dont have the skill from knowledge to go along with my creativity and abbility to think on my toes . I just need knowledge ad time . Ill put in all the time i can offer if can only get the knowledge !

If you're bright, inquisitive and prepared to put in a little extra time you're going to pick all this up real fast. Right now you don't need a group. Make a start on ASM and C as a minimum. If you don't already use linux then get a spare machine or VM and play with BSD, Solaris and Redhat till you are comfortable with them. Get metasploit and keep playing with published exploits until you understand what is happening in a step-by-step debugging view. Also, read ALL the RFC's that interest you… pay particular attention to TCP/IP, ICMP, SNMP, etc… Later look at various routing protocols such as RIPv1, RIPv2, OSPF, EIGRP, IS-IS, BGP4 and try to get familiar with various network appliances from common vendors like Juniper and Cisco. You can pick up low-end models on eBay real cheap and these will be essential in understanding corporate LANs.

Right now you should be soaking up information on every subject that interests you. Want to know what a 'subnet mask' is… then go read wikipedia and some RFC's… Did you see terms you didn't understand like VLSM… great, go read those too. Then come back and tell me exactly how to partition a class C IP block into various sizes, what the network numbers and broadcast addresses of each are… etc. If you chase down each question mark you find then before long you'll be pretty well-rounded. Then you can start making sense of the security issues which only appear when all of these different contexts come together.

I guess what I'm saying is just go do it. Go download wireshark today, make a packet capture… then go search the RFC's, wikipedia and eBooks until you can explain exactly what every bit in that packet means. Then go explore everything else… How is a MAC address created, what is an OUI?, What are broadcast MACs… Look up ARP/RARP… capture the packets, explore the protocol, examine the effects…

Just keep going until you're happy. The more you read the more everything will just start falling into place and suddenly things will just start making a whole lot of sense. If you find it a chore then you're never going to get anywhere. IT Security is a very deep subject and you're going to need to be pretty capable across the board. So, get coding, debugging, capturing, analysing and, most of all, wading through all those heavy RFC's.

Good luck with that,

-Meduz

I know most people seem to hiss at articles that werent written by the author and instead copied and pasted by a lesser pion of a source . But from my expereince i have not seen such detail , acuracy , fact , and simplicity in direction and design of a post in three years . Nor have i seen many since that go into such depth . Most people say google it . Or if they do try to write an article its vague hard to understand or just outdated point blank . This article is real and will not become an outdated source of knowledge for quite sometime . That is until the internal structure of Routers , servers , and computers themselves are completely re-engineered . This article will not become obsolete in one month like most SQL injections . Or Javascript injections . Or PHP , IPB , vbullitin exploit . This attacks the core of a system witch hasnt changed significantly in years unlike that of some of the other scripts mentioned !

Me personaly im still learning from this article . I re-read it all the time .

All thanks and credit go to M3DU54 . A legend and genious .

Include that in the article, i would suggest you go to the article, click edit and include that it's not your work in BIG BOLD LETTERS.

I did . I thought my description of the article would of been sufficient enough to state that the article was written by M3DU54 . I am the 7h3s0urc3 not M3DU54 but i guess it wasnt enough . Or not bold enough or big enough . I hope this solves the problem !

All i wanted to do was post a great article not be a problem !