Showing posts with label Google Dorking. Show all posts
Showing posts with label Google Dorking. Show all posts

Sunday, 23 December 2012

Google Web Cache and MITM attacks

What on earth do these two things have to do with each other? Well before I can discuss that, I need to dig out another forgotten vulnerability, mixed scripting!

Mixed scripting happens when an application served via https references resources including CSS,XML,JS from domains that are not served via https so a typical example would look like this:

googleusercontent mixed scripting vulnerability

So why is this a problem? well because it means in a Man in the middle attack you can influence the behaviour of a trusted domain without mirroring the entire domain! You can have your victim---during a mitm attack---use the services on their trusted domain with out having to use sslstrip or other anit-ssl tech you don't need to touch anything on the ssl layer because the application inherently serves unauthenticated content to the user! All you really need to accomplish is mapping the unauthenticated domain to a machine under your control.

So then how does this tie into the Google Web Cache? It turns out google webcache also suffers from mixed scripting!

Wednesday, 21 March 2012

GooDork : Super Charging your Google Hacking

I recently started work on a very exciting project called GooDork in its most basic function this python script allows you to run google dorks straight from your command line.

Though its real power lies what it allows you to do with the results from a google dork.

Sunday, 22 January 2012

The Science of Google Dorking

In this post I'm in proposing some new and improved Google dorks for hackers/pentesters and generally any one that likes finding web based targets based on the vulnerabilities they expose, the dorks I will discuss here include servers exhibiting:

  • Local file inclusion / Remote File inclusion vulnerabilities
  • SQL injection
  • Error based injection

Thursday, 19 January 2012

LFI attacks for Predators

What is an LFI vulnerability??
what? you don't know!!? lulz, an LFI or (Local file inclusion)  vulnerability ---much like other web attacks, exists when unclean user input is used to determine input to any of the  follow php functions 
  • include : "Files are included based on the file path given or, if none is given, the include_path specified. If the file isn't found in the include_path, include() will finally check in the calling script's own directory and the current working directory before failing. The include() construct will emit a warning if it cannot find a file; this is different behavior from require(), which will emit a fatal_error."
an interesting thing to note is that include will actually search for files with the specified name if an absolute path is not given the script will search for it in the include_path, this means if you can influence the environment variables that a script runs under, you may be able to fool it into including the wrong files!
  • readfile:"Reads a file into the output buffer"
  • include_once: "The include_once() statement includes and evaluates the specified file during the execution of the script. This is a behavior similar to the include() statement, with the only difference being that if the code from a file has already been included, it will not be included again. As the name suggests, it will be included just once"
(There may be other functions that allow LFI attacks, if so i forgot lols)

Okay all of these functions have one thing in common, they allow PHP scripts to read/display content of specified files, the hack comes in when this specification is unchecked. You could for example fool a script into reading the password file

Me performing an LFI attack

As I've done here, (hehehe i wish i could tell you who's server this was!!).

Now this part of the tutorial you expect me to demonstrate an LFI, right?? Wrong!! I actually care about whether this information is useful to you!! So I'm gonna show how to find servers with LFI vulnerabilities