Thursday, March 15, 2012
How to install window 7 from a usb drive
installing Windows from a USB flash drive has several advantages – First of all, the overall speed of the installation process will increase significantly, carrying a USB stick is much more convenient than a DVD, and finally it becomes possible to install the OS even on those systems that do not have a DVD drive, such as a netbook.
In this post, I will show you how to load the Windows installation on to your USB flash drive and make it bootable just like the DVD.
Tools Required:
1. USB flash drive with a minimum capacity of 4 GB.
2. Windows 7 set-up DVD.
Step-1: Plug-in your USB flash drive and backup all the existing data in it.
Step-2: Open the command prompt. If you are using Windows 7/Vista then open it with administrator rights*.
* Goto Start -> All Programs -> Accessories -> Right-click on “Command Prompt” and select “Run as Administrator”.
Step 3: In the command prompt, type in the following command:
DISKPART
This will start the Microsoft DiskPart utility as shown below:
Now issue the following command:
LIST DISK
This will show you a list of available disks on your system. Disk 0 is usually the hard disk. In my case, Disk 5 is the USB drive (this can be a different one in your case). Now issue the command as shown below:
SELECT DISK 5
NOTE: In the above command, 5 is the USB drive number on my system. If you have a different number on your system, then you need to replace 5 with that number.
Step-4: Now issue the following list of commands one by one as shown below:
CLEAN
CREATE PARTITION PRIMARY
SELECT PARTITION 1
ACTIVE
FORMAT FS=NTFS QUICK
ASSIGN
EXIT
Minimize the command prompt and proceed to the next step.
Step 5: Insert the Windows 7/Vista installation disc and note down the “drive letter” of your DVD drive. In my case, it is “H:”. Now type the following list of commands as shown below:
H: CD BOOT
CD BOOT
BOOTSECT.EXE /NT60 M:(NOTE: M: is your USB drive letter)
EXIT
Step-6: Copy the contents of your Windows 7/Vista installation disk into the USB flash drive.
That’s it! Your USB stick is now ready to boot and install the OS for you. Don’t forget to enable the “USB Boot” option and change the “boot priority to USB device from hard disk” in your BIOS settings.
I hope you like this post. Pass your comments to express your opinion.
Wednesday, November 30, 2011
HOW TO HACK A WEBSITE
How to hack a website - tutorial without pretty pictures by myfix.
This is actually based on a true story, but I've obviously not left in all details
Part 1: Finding holes, bad coders and open doors
Requirements: Patience, imagination, HTML knowledge - specifically forms. Basic SQL or a willingness to learn once you find a hole. URL Encoding/Decoding.
So, we fire up our Tor or whatever proxy we are using and go investigating our target site. Actually what happens a lot of times to someone experienced is they are idly browsing the web and spot something in a site they're just visiting. Once you've found a few exploits in sites and got experience you'll become aware of these and almost have a supernatural act of finding them. It's a lot harder to target a specific site than it is just to find a random one. Don't bother trying with forums or popular PHP systems at this point as they're generally well patched/protected. Go find some random site somewhere, ideally in another country from you and one that does not appear to be using a off-the-shelf solution.
So first thing we do is ensure we are using a highly configurable browser like FireFox with a few neat plugins, cheifly TamperData. We also ensure that all popups etc.. that the site opens for us are NOT gonna hide their status bar or their URL bar. The reason I say this is many times the URL of the popup contains GET data, that is data such as www.mysite.com/popup.asp?blah=12 If we had the URL not visible for popups we wouldn't see these clues.
Now we know not to waste time too much looking at .htm or .html pages as these are generally static content. What we wanna find are pages that accept user input, or pages that pass variables from one page to another. Example of the former could be a registration page, example of the latter could be a "Click Here To Buy Now" button which links to something like www.mysite.com/shop?productid=1234 There might be a few HTML pages that pass values onto ASP/PHP pages so these are also worth looking at from a point of view of how they pass the data. Perhaps on some site you won't see the extension - maybe it'll be written as www.mysite.com/shop/products/1234 - you should assume that this is either PHP or ASP code. Go read up on PHP/ASP for how this is done.
First thing we wanna do is get some sort of idea as to the security-awareness level of the web designer. So go open up the web code on what appears to be a main part of the site and look for things such as "Made with Frontpage" and other such stuff that would indicate it's someone who knows little about making websites. Also, always remember on PHP pages/ASP pages sometimes in the source code you can find PHP/ASP code commented out in such a way (i.e. the <!-- HTML way) that you get to see non-functional code on the webpage, which can always be a help to the inner workings of the website.
So let's first just get an idea of the web designers level. Most sites will have a Contact Form so lets go there. Contact forms generally have client and/or server validation, and then use a sendmail routine to send whatever you typed in as a normal email from the server to the admin. Now unless you fill in all the required fields you shouldn't have any worries about the contact form being sent.
OK, so this is our imaginary contact form:
(all 4 fields it states are required)
So we'll go fill in our first name on the contact form as My'Fix... we'll put our last name as <script>alert('HI');</script> We won't put in an email address (which is required), and in out comments we'll put a few thnigs like \ ' <script>alert('HI'); </script> just for good measure.
The reason I suggest avoiding trying to exploit the email field in particular is because most websites will have filtering code on the email fields - not for security, simply to prevent Joe User typing in a stupid value. These filters basically check for the existance of alphanumeric characters only, dots, hyphens and a @ symbol - i.e. the only allowable characters in a email address so will be no good for exploiting.
OK, so we are gonna hit to OK button and expect to be told we haven't put in our email address. Let's see what happends.....
As soon as I hit OK I get a Message Box appear on my screen before my browser has even sent anything to the server. This is good, this means they're using client-side validation. That is they have generally some Javascript code validating these values locally on your machine to prevent their server doing too much work. Now whilst this is not a bad thing, and web coder should not rely on this alone - his server should still validate afterwards. You can confirm this by viewing the webpage source (and possibly any Javascript includes if not direct in the page) and you'll see they're doing validation.
This is where TamperData comes into play.... spend a few minutes doing legit things such as Google searches and learn the basics of this tool. This is my #1 Firefox plugin, I can give it no higher accolade than that.
Go back to the form and enter in valid values - for everything. Turn on TamperData and hit OK on the form. At this stage what will happen is the Javascript will run as normal and everything will be validate as OK.... but just as the data is about to passed over to the webserver TamperData will pop up asking if you want to Tamper (edit) the data being sent, or if you want to just send it. Hit Tamper.
Now you should see these fields being passed across as a POST (go read up on HTML forms). Now go edit those values in TamperData so they are similar to the ones we tried the first time. Remove value from the email address too, as we don't actually want a contact email sent. We've already bypassed the Javascript local validation, so lets see if the web developer is a clueless prick and has accounted for this scenario....... Right so values edited, tell TamperData to submit our edited data.....
BOOM!
We get some strange PHP/ASP error page telling us that the SendMail function failed due to no from email. Perhaps it won't say it in such simple terms, you might have an error code and a object name you'll have to Google for. Now this is a bad thing already, as you'll of picked up an idea of the servers internal paths from the error message - e.g. /web/live/contact.php = www.thesite.com/contact.php The web developer didn't account for user bypassing his Javascript validation, this was a hard failure of some code due to it having bad data. NO WELL DESIGNED WEBSITE SHOULD FAIL WITH A INTERNAL ERROR. What should of happened even if he still didn't do the server-side validation was a webpage appear such as "Sorry that request had a problem. Our administrator has been informed", complete with normal website banner and all. Allowing internal code to fail and leave descriptive messages might be a great help to developers, but is also a huge help to anyone trying to get into the site.
In this case our injected Javascript alert didn't pop up quite simply because it was never written out to the page. Say we were to repeat this task again and fill in a valid email address what we might see is a new page with the Message Box we injected popping up, but of course this email would have been sent to someone which would probably put somebody onto us. Never mind, not all has been wasted - we have a general idea that we can keep looking and find some interesting things here, due in part to any time us causng the site to error thanks to the admins incompetence we're gonna see internal messages.
Now if he'd of done server side validation too, you should of got a message stating "Invalid email address" or similar. Another thing worth trying is to turn off Javascript and see how a site reacts. If a site demands that you use Javascript then it gives more of an idea that they are relying on Javascript for a lot of the validation.
So where we go now? Well this is where things can be found in minutes or in days. My record was 4 days laborious inspection of hundreds of pages of a huge site to eventually find a way of injecting. Ths site was specifically targeted, I probably wouldn't of spent so long on any old site.
Let's keep looking around the site. There doesn't appear to be many links with variables... it mostly appears to be static content just wrapped up in PHP/ASP...... But by now you should have a keen eye for detail.. and you've spotted something on a seemingly worthless page:
Let's see.....
MANAGERS OF THESITE.COM
Fred Smith - CEO. Click for full corporate profile.
Mike Hunt - CFO. Click for full corporate profile.
+ more pics of people in suits
We look at the link for full profile and at last have found a dynamic link..... Except using IE we wouldn't of noticed it, as when we click it it opened up a frameless popup.
In Firefox with our settings tuned we see the following URL above the popup: www.thesite.com/profiles.php?pid=2
Now webdesigner probably never ever thought about this too. This is a boring section of the site, seemingly non-critical so why would he bother validating for a valid profile id? Let's find out.....
Insert non-numeric data in obvious numeric field:
We get a blank window. Hmmm...
Insert no value in the field:
We get a blank window. Perhpas it's thinking pid=0 ?
We put a alphabetic value in the field:
We get a SQL error stating invalid value or similar
OK, so pid is a numeric field in the database.
(oh yeah you should learn about URL encoding/decoding)... what the pid=pid=2%20OR%20pid=3 is translated to is "pid=2 OR pid=3". The %20 is spaces. Hehe, what happened here is we got a garbagy looking page but worked out that the profiles of Fred Smith & Mike Hunt were shown on the same page
(pid=2 OR 1=1). 1 is always equal to 1 so every record will be selected. So what we saw here was a really garbage looking page with all the profiles on one page.
Perfect, we've found a hole..... now stay tuned for Part 2 where we'll go further. In the meantime comments/questions here would be appreciated (on what has been covered so far).
I should note here for Part 2 you'll need lots of patience, or Perl. Or the ability to code something similar to what I'll be writing in your language of choice. But believe me for this sorts of things Perl really is the best choice.
This is actually based on a true story, but I've obviously not left in all details
Part 1: Finding holes, bad coders and open doors
Requirements: Patience, imagination, HTML knowledge - specifically forms. Basic SQL or a willingness to learn once you find a hole. URL Encoding/Decoding.
So, we fire up our Tor or whatever proxy we are using and go investigating our target site. Actually what happens a lot of times to someone experienced is they are idly browsing the web and spot something in a site they're just visiting. Once you've found a few exploits in sites and got experience you'll become aware of these and almost have a supernatural act of finding them. It's a lot harder to target a specific site than it is just to find a random one. Don't bother trying with forums or popular PHP systems at this point as they're generally well patched/protected. Go find some random site somewhere, ideally in another country from you and one that does not appear to be using a off-the-shelf solution.
So first thing we do is ensure we are using a highly configurable browser like FireFox with a few neat plugins, cheifly TamperData. We also ensure that all popups etc.. that the site opens for us are NOT gonna hide their status bar or their URL bar. The reason I say this is many times the URL of the popup contains GET data, that is data such as www.mysite.com/popup.asp?blah=12 If we had the URL not visible for popups we wouldn't see these clues.
Now we know not to waste time too much looking at .htm or .html pages as these are generally static content. What we wanna find are pages that accept user input, or pages that pass variables from one page to another. Example of the former could be a registration page, example of the latter could be a "Click Here To Buy Now" button which links to something like www.mysite.com/shop?productid=1234 There might be a few HTML pages that pass values onto ASP/PHP pages so these are also worth looking at from a point of view of how they pass the data. Perhaps on some site you won't see the extension - maybe it'll be written as www.mysite.com/shop/products/1234 - you should assume that this is either PHP or ASP code. Go read up on PHP/ASP for how this is done.
First thing we wanna do is get some sort of idea as to the security-awareness level of the web designer. So go open up the web code on what appears to be a main part of the site and look for things such as "Made with Frontpage" and other such stuff that would indicate it's someone who knows little about making websites. Also, always remember on PHP pages/ASP pages sometimes in the source code you can find PHP/ASP code commented out in such a way (i.e. the <!-- HTML way) that you get to see non-functional code on the webpage, which can always be a help to the inner workings of the website.
So let's first just get an idea of the web designers level. Most sites will have a Contact Form so lets go there. Contact forms generally have client and/or server validation, and then use a sendmail routine to send whatever you typed in as a normal email from the server to the admin. Now unless you fill in all the required fields you shouldn't have any worries about the contact form being sent.
OK, so this is our imaginary contact form:
CODE C Language
1 | FIRST NAME: |
2 | LAST NAME: |
3 | EMAIL: |
4 | COMMENT: |
(all 4 fields it states are required)
So we'll go fill in our first name on the contact form as My'Fix... we'll put our last name as <script>alert('HI');</script> We won't put in an email address (which is required), and in out comments we'll put a few thnigs like \ ' <script>alert('HI'); </script> just for good measure.
The reason I suggest avoiding trying to exploit the email field in particular is because most websites will have filtering code on the email fields - not for security, simply to prevent Joe User typing in a stupid value. These filters basically check for the existance of alphanumeric characters only, dots, hyphens and a @ symbol - i.e. the only allowable characters in a email address so will be no good for exploiting.
OK, so we are gonna hit to OK button and expect to be told we haven't put in our email address. Let's see what happends.....
As soon as I hit OK I get a Message Box appear on my screen before my browser has even sent anything to the server. This is good, this means they're using client-side validation. That is they have generally some Javascript code validating these values locally on your machine to prevent their server doing too much work. Now whilst this is not a bad thing, and web coder should not rely on this alone - his server should still validate afterwards. You can confirm this by viewing the webpage source (and possibly any Javascript includes if not direct in the page) and you'll see they're doing validation.
This is where TamperData comes into play.... spend a few minutes doing legit things such as Google searches and learn the basics of this tool. This is my #1 Firefox plugin, I can give it no higher accolade than that.
Go back to the form and enter in valid values - for everything. Turn on TamperData and hit OK on the form. At this stage what will happen is the Javascript will run as normal and everything will be validate as OK.... but just as the data is about to passed over to the webserver TamperData will pop up asking if you want to Tamper (edit) the data being sent, or if you want to just send it. Hit Tamper.
Now you should see these fields being passed across as a POST (go read up on HTML forms). Now go edit those values in TamperData so they are similar to the ones we tried the first time. Remove value from the email address too, as we don't actually want a contact email sent. We've already bypassed the Javascript local validation, so lets see if the web developer is a clueless prick and has accounted for this scenario....... Right so values edited, tell TamperData to submit our edited data.....
BOOM!
We get some strange PHP/ASP error page telling us that the SendMail function failed due to no from email. Perhaps it won't say it in such simple terms, you might have an error code and a object name you'll have to Google for. Now this is a bad thing already, as you'll of picked up an idea of the servers internal paths from the error message - e.g. /web/live/contact.php = www.thesite.com/contact.php The web developer didn't account for user bypassing his Javascript validation, this was a hard failure of some code due to it having bad data. NO WELL DESIGNED WEBSITE SHOULD FAIL WITH A INTERNAL ERROR. What should of happened even if he still didn't do the server-side validation was a webpage appear such as "Sorry that request had a problem. Our administrator has been informed", complete with normal website banner and all. Allowing internal code to fail and leave descriptive messages might be a great help to developers, but is also a huge help to anyone trying to get into the site.
In this case our injected Javascript alert didn't pop up quite simply because it was never written out to the page. Say we were to repeat this task again and fill in a valid email address what we might see is a new page with the Message Box we injected popping up, but of course this email would have been sent to someone which would probably put somebody onto us. Never mind, not all has been wasted - we have a general idea that we can keep looking and find some interesting things here, due in part to any time us causng the site to error thanks to the admins incompetence we're gonna see internal messages.
Now if he'd of done server side validation too, you should of got a message stating "Invalid email address" or similar. Another thing worth trying is to turn off Javascript and see how a site reacts. If a site demands that you use Javascript then it gives more of an idea that they are relying on Javascript for a lot of the validation.
So where we go now? Well this is where things can be found in minutes or in days. My record was 4 days laborious inspection of hundreds of pages of a huge site to eventually find a way of injecting. Ths site was specifically targeted, I probably wouldn't of spent so long on any old site.
Let's keep looking around the site. There doesn't appear to be many links with variables... it mostly appears to be static content just wrapped up in PHP/ASP...... But by now you should have a keen eye for detail.. and you've spotted something on a seemingly worthless page:
Let's see.....
MANAGERS OF THESITE.COM
Fred Smith - CEO. Click for full corporate profile.
Mike Hunt - CFO. Click for full corporate profile.
+ more pics of people in suits
We look at the link for full profile and at last have found a dynamic link..... Except using IE we wouldn't of noticed it, as when we click it it opened up a frameless popup.
In Firefox with our settings tuned we see the following URL above the popup: www.thesite.com/profiles.php?pid=2
Now webdesigner probably never ever thought about this too. This is a boring section of the site, seemingly non-critical so why would he bother validating for a valid profile id? Let's find out.....
Insert non-numeric data in obvious numeric field:
CODE C Language
1 | www.thesite.com/profiles.php?pid=54544 |
We get a blank window. Hmmm...
Insert no value in the field:
CODE C Language
1 | www.thesite.com/profiles.php?pid= |
We get a blank window. Perhpas it's thinking pid=0 ?
We put a alphabetic value in the field:
CODE C Language
1 | www.thesite.com/profiles.php?pid=A |
We get a SQL error stating invalid value or similar
OK, so pid is a numeric field in the database.
CODE C Language
1 | www.thesite.com/profiles.php?pid=2%20OR%20pid=3 |
(oh yeah you should learn about URL encoding/decoding)... what the pid=pid=2%20OR%20pid=3 is translated to is "pid=2 OR pid=3". The %20 is spaces. Hehe, what happened here is we got a garbagy looking page but worked out that the profiles of Fred Smith & Mike Hunt were shown on the same page
CODE C Language
1 | www.thesite.com/profiles.php?pid=2%20OR%201=1 |
(pid=2 OR 1=1). 1 is always equal to 1 so every record will be selected. So what we saw here was a really garbage looking page with all the profiles on one page.
Perfect, we've found a hole..... now stay tuned for Part 2 where we'll go further. In the meantime comments/questions here would be appreciated (on what has been covered so far).
I should note here for Part 2 you'll need lots of patience, or Perl. Or the ability to code something similar to what I'll be writing in your language of choice. But believe me for this sorts of things Perl really is the best choice.
Subscribe to:
Posts (Atom)
