Showing posts with label Hacking. Show all posts
Showing posts with label Hacking. Show all posts

Friday, 28 December 2012

Information Gathering Techniques: Dig and DNS Servers

"information is the negotiators greatest weapon"
...especially those who negotiate with network security ;)
I used to think a security blog is all about writing about brand new attacks and dropping info on the coolest 0days. But if that's what security blogging was all about then we would not leave much opportunity for beginners to start out and experts to recap. So posts like this will always be necessary!  

This brings me to a new theme of post I'll be writing. I'll be talking about penetration testing and general assessment skills stuff that wanna be security professionals will consider valuable information, but don't fret those of you who are seasoned security researchers and penetration testers I'll make sure my perspective is quite orignal and encompasses things most security blogs don't cover too extensively.

So I hope you guys enjoy these posts!

This post in particular will be introducing the mindset(s) you should have when engaging on information gathering efforts. I also discuss retrieving information using Dig and DNS.

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!

Saturday, 28 January 2012

Bit shifting blind injection : Simplified!

I've recently been investigating Blind SQL injection, and have become quite fond of the practice. I stumbled upon a new technique documented by (see here that used Bit shifting to guess the bits that make up the chars of the information you are trying to extract from the database.

I then came up with a modification to the method to try and make it simpler and hopefully allow the development of an even faster method (which im still working on) . My method uses the XOR bitwise operation to simplify the output and operation of the attack.

Thought relatively simple methods, they still require a comfortable understanding of the binary number system and can be frustrating to use. The method I'm about to show you can be performed with minimal understanding of the binary number system. This is because you don't need to convert in and out of binary while performing the attack.

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