Sunday, November 9, 2008

Alexa - The Informational Gem


Hello all, it's been a while since I have posted. I apologize for this delay, but I have been studying the wonderful works of marketing. My time has been reserved between school and work that I perform on behalf of the many types of marketing strategies. I may not be posting for a while after this one, simply because I am dedicating my time in another industry as stated above. I still continue to operate my business full-time and keep up-to-date on all of the events that are occurring in the rapid world of web application security. Let's start! Alexa for the most part, isn't an accurate tool to use when analyzing your websites' traffic. This is mainly due to the fact that Alexa is still a small percent of the market share in user population.

What is Alexa?

Alexa is a type of "search" engine that determines traffic ranking using their browser toolbar.

Using the Alexa Toolbar is the only way Alexa can understand who and what users are visiting. If you do not have the Alexa Toolbar, you can watch for the HTTP request it sends out by using the toolbar for a quick install. The HTTP request it sends out will let you know what it sends back to the Alexa network in order for them to record statistics. I recommend using Alexa as a penetration tester when you conduct profiling on a website. When I perform some analysis on profiling a website, I use WHOIS query, search engines, McAfee SiteAdvisor, and Alexa of course!

How Alexa can help a penetration tester:

As a pen tester, you will find Alexa useful because it helps you understand where users of all sorts go to on a specific website. On Alexa's 'Where people go on to' feature you will see visible some external sub-domains users visit. This is particularly resourceful because you might bump into some secretive sub-domains which will reveal interesting information for the most part. With this interesting find, you will be able to expand and further operate your penetration analysis deeper. Good luck!

How Alexa can be dangerous:

As an organization, I don't believe it is in best interest to stumble upon a few sub-domains that your team uses to login 'internally', update account information, or register on. Alexa will not pick up every sub-domain unless a large number of users or hits occur onto the sub-domain using Alexa. To be safe, don't create the sub-domain unless you can internally use it. Require authentication at the very least. Additionally, uninstall Alexa on every browser you have (Internet explorer and Firefox) if you don't *need* to record statistics. If you depend on Alexa as your statistical source, then simply visit this URL on the occasion that you must use it:

http://www.alexa.com/data/details/traffic_details/URLHERE.COM?q=

Wednesday, July 2, 2008

Botnets/DDoS Overview

Hello all, I'm sorry for not posting for a while. I've been busy brainstorming some interesting attack structures and working on an IDS/WAF that I might release soon. In the meanwhile, I'd like to get into Botnets and what's really happening. There's a phase now going on more than ever, and it's the intercommunication of Botnets. It's the ultimate zombie of chained computer networks combined to cause havoc. I'll admit that was bit corny, but it's really how it's usage today is seen. Anyways, here we go.



What is DoS/DDoS?


DoS stands for Denial of Service. As the name states, it's a condition in which an application or service becomes unavailable, hence denial of service. This condition can be induced through many ways, such as bad programming, which often leads to vulnerabilities that cause CPU usage to skyrocket, as well as crashing, lag, and freezing. For our article's purpose, we'll count DoS-like conditions as being achieved through more common means--through the flooding of packets.


So...We've got DoS down, but what is DDoS?

DDoS, or Distributed Denial of Service, uses DoS methods, but expands on the concept by making many computers at once attack the target. DDoS, however, focuses on flooding the victim's port(s) to (A) Lag them (B) Crash them (C) Stop legitimate traffic from reaching the port/service. Though individual computers can be DDoS'ed, websites and IRC servers are primary targets.


Bots?

DDoS can be a group effort done by friends, or, most commonly, through a botnet. A botnet has usually one commander that talks to all the "friendly" computers to tell them what to do. Called "bots", these computers are often infected with a "backdoor" that allows the commander of the botnet to easily execute commands, download/execute files, etc. Majority of the time, these computers don't even know they're infected with a backdoor.


How are the bots controlled?

They can be controlled through a variety of ways. However, the most common method is through IRC. Each infected computer connects to an IRC server and joins a channel (that's likely password protected). The commander logs in to the bots through writing a command to the room, and then does as he/she wishes, often issuing commands to initiate a DDoS on a remote target.


What type of flooding methods are there?

There are many different flooding methods that can be used--

  • General TCP Flooding -- AKA the bots connect to a given remote port, then simply flood until disconnected, in which case they reconnect and start over again.


  • HTTP -- Done through TCP as well, this method works web servers hard (on port 80 generally) by requesting many files at once via bots in an attempt to (A) Waste bandwidth (B) Lag the website (C) Stop legitimate traffic. Depending on how the attack is carried out, you can flood with HTTP Post Requests. HTTP Post Requests are done when submitting a form (i.e. a tag board message, forum post, registration page, or even a blog comment). Flooding using HTTP Post Requests not only cause normal HTTP disruption, but also can cause the script being flooded to create huge logs. If the script is also tied to a SQL database, then it's even more deadly.


  • UDP -- This method doesn't use a direct connection, as UDP does not really require one. As with the other methods, flooding is used to disrupt service on the port in question.


  • IRC Flood -- All bots connect to the IRC server, then have several different flooding methods available -> Private Message (PM) flooding, room creation flood, file sending flood, join room and spam text flood, etc. (excuse my lack of a good name for each of these sub-IRC methods :) )


  • Ping Flood -- As with normal pinging, once Computer A pings Computer B, Computer B sends a reply. This causes incoming and outgoing flooding when applied to a botnet, as the victim is receiving many requests over and over again, while attempting to respond to them all. This method is easily blocked.


  • Syn Flood -- One of the most well-known methods out there, this method involves sending a "SYN Request" to the target. The target then replies to it to acknowledge the request, then waits for more data. Generally, there is no more data afterward, causing the server to wait a little bit until timing out. Though not usually a problem, issues can arise when applied to a botnet. The victim will have many of these partial connections, causing a waste of resources and disruption of possible traffic.



  • How are botnets made?

    Botnets are created through many ways. Sometimes, people bind a botnet client to another exe, then send it to people or post it on websites (usually in the disguise of a hack). Spam in email inboxes can contain these files as well. However, using vulnerabilities is the most preferred way. Some use internet browser exploits or email software vulnerabilities to cause the automatic downloading (and executing) of a file (i.e. bot client/backdoor). Some use Instant Messaging (IM) software (including IRC and other chatting software). However, OS vulnerabilities are the most commonly used. Worms are created to exploit these vulnerabilities and often spread bots (and the worm) while doing so. This creates a nice army for a botnet. In fact, many botnets are self-spreading. A plugin is simply installed on the clients (pre-installed or installed via an update through a bot command) that allows allows for scanning and exploiting of IP ranges. When victims are found, these self-spreading bots pass themselves along, creating a rising army. However, self-spreading bots is a nice way of getting bots destroyed. A raise in suspicion is caused by this and leaves a long trail of activity leading to the owner.


    Other uses of a Botnet

    Botnets don't have to be used only for flooding. They can be used for spamming (E-mail, forums, IM, Net Sending, etc.) and cracking/brute forcing passwords, which can significantly cut down the time it takes for a successful crack. They can also be used to crack encryptions, a very useful concept for those who do not have their own super computers. They can be used to P2P files, as well as distribute files in general as well.


    Disadvantages of a Botnet

    Generally speaking, paper trails are left with a botnet. When performing an attack on a website for example, server logs capture loads of data that can be used to find the attacker. Even personal computers have firewalls to grab IP addresses that they can report to their ISP, of which is likely to have a much better log of the attack. If you're adept in the field of security, then keep this in mind if a "friend" of yours attacks you with a botnet -- bots are commonly created through infecting a computer that lacks security updates. If that computer was so easily infected with a backdoor, chances are, that you too may be able to hack it and grab the bot client. After doing so, you can do a number of things, such as send a copy to your ISP/authorities or even reverse engineer it to grab the password/server info/etc. If you get the user name and password, you may in fact be able to hijack the entire botnet (or break it up). Packet sniffing can even grab this data for you.


    Protecting Bots

    Bots should be packed, encoded, or altered a lot to avoid detection. Custom-made clients are the most undetectable type, however, as attempts to avoid detection can also RAISE detection (i.e. most virus scanners recognize packers such as UPX). To avoid firewall detection, bots should add their server's IP to the firewalls "trusted" or "accepted" list. Bots should also have a login system of their own so that they're unusable by anybody other than the person logging in to them. If the bots communicate with the owner through an IRC server (or even other means of communication), then a backup server should be available for them to connect to incase the server is ever down . Also, if using a public IRC server to communicate, bots should not have random names derrived from random letters and numbers. A dictionary list should be used to avoid suspicion, as well as fake version info (i.e. they use random versions of mIRC), and join a secret, password-protected channel.


    Protecting Against Bots

    People should update their OS with the latest patches to avoid being infected through worms and vulnerabilities, while also avoiding unfamiliar websites, odd emails, and making sure to have the latest anti-virus protection (and definitions). Firewalls should be used (hardware and software) to increase security.


    How to Protect from a Botnet Attack

    Protecting yourself can be difficult and often happens before you get the chance to do much about it. A great computer with a great internet connection can take a beating without issues depending on the size of the botnet. If you have a server, a backup computer or connection that kicks in if the primary server/connection is having issues is a great fail switch. Blocking the IP of the attacking computers is helpful, but still requires your computer to work itself a bit, as it has to look at the IP still, then ignore it. Plus, IPs can be spoofed (changed to show a different IP). Filtering has the same issue. If being DDoSed/DoSed on your home computer, you can call your ISP and request a new IP address. If you have a dynamic IP, then simply disconnect and wait for a new IP (release and renew via IPConfig can do this usually).


    Misc

    Most bots are coded in C++ and are more known to infect Windows users. However, Java bots that work on Windows, Mac, and Linux/Unix aren't entirely uncommon. When a new big vulnerability is out, a botnet is likely to be using it relatively soon. Sometimes though, bots use unknown vulnerabilities. When this is the case, they're eventually discovered, reverse-engineered, then dissected until the exploit is found and an attempted patch is made. Botnets can spread through networks too. Though I have not seen this done yet, bots can be given the ability to spread through wireless access points, especially if the access point is insecure.

    Sunday, May 11, 2008

    Make $$$ From Your Web Applications



    Every once in a while you'll stumble upon a user who likes to snoop around the website in places that shouldn't be wide in the open. A great example of that instance is when someone checks for the /images directory. That's a very common directory where sensitive information is often obtained because web masters forget to keep that folder locked. It's mostly referred to as "information leakage" and so it lures attackers into the location because the /images folder doesn't always contain image-related content, and rather exposed material such as logs, password files, and other discreet information. Displaying ad's on your website and receiving many visitors daily is a good advantage in helping you make money.

    Make money every time a user views your /images directory. Setup an index.html file and have it redirect the user to a site of your choice. This is even more ideal if you are a popular website because of the likelihood of hits you earn. Not only are you increasing the security of your website, but you are making money. If you want to dig into this more, perhaps you could even setup a CPC (Cost-Per-Click) or in this case, a CPA (Cost-Per-Attack) deal in affiliation with advertising. For example, Site A will give you a referrer URL and you will take that URL and embed it in the source of your index.html located in the /images directory and have it point to that domain given. Without a unique URL given, maybe you just want to be kind enough to direct some users to another website, then in that case both of you win.

    The idea is to generate money by setting up such a deal and in turn provide traffic to the other party. Additionally, if you know the precise URL of an ad that you run through another service, you can have your page point to that URL and you've just earned yet another click. Displaying ads are of no use if they aren't clicked, and so this is a valid way in making sure it all works out. Furthermore, you can include IFrames inside the index.html page which will load upon the page and maybe you can create 6 IFrames that will load all different domains which in turn will generate even more revenue. Plus, you can load any domain you want at a time you set and if you aren't loading yet another referral URL, then loading ads should not take up much bandwidth, thus allowing the user to load up the content at a quicker pace, and giving you the opportunity to earn some money.

    Thursday, May 1, 2008

    Web Application Security: Log & Alert 6



    Delay. Load. Capture. Requests are very useful, but also suck up a ton of space in the pile of logs. A common directory that is checked manually is /demo. Whether demo might be a secret promo code, activation to a certain service, or perhaps where beta features are firstly released, it is an interesting find if valid. In most cases, if someone viewed that directory, it would most likely be an attacker. A typical consumer's behavior doesn't consist of browsing for that directory. Attacker seek into venturing to that directory because of a common insecurity that is most commonly referred to as Information Leakage.

    There may be sensitive information left in such a directory that is often left behind by IT administrators or webmasters. Time is an essential part of what makes up a log. Knowing the time a request is issued provides great evidence in any case where legal action must be taken. It also helps to understand when users like to visit the page most, and to figure how long a user has been active or idle. For a company who provides an IT Department dedicated to supervising activity through logs and user behavior, handling requests and determining the precise activity might not be too much of a hassle.

    If a few or simply one administrator is left to watch the logs, there is a vast chance that bad requests might just pass by without the administrators notice. What I have in mind, is to redirect .SWF objects to .SWF objects and maintain a delay of a second or two to process requests. The SWF object will redirect itself to an existing SWF object on the page and that secondary SWF file will then redirect itself back to the primary SWF object. There will be made many requests shown because of the rapid interval at which redirection will operate, but you may choose to set a delay if you prefer. This obviously must occur when the user browses to whatever directory you want to enable this to work on, specifically for security reasons.

    You can simply set a password or make the folder forbidden but another solution just adds on to the overall value of entry and it's detection. Looking through a bunch of requests produced at such a rate is easy to follow through, but I suggest you do this: Allow the main . SWF to redirect to another page, and simply place content such as images, videos, or text to appear in a sequential order in terms of data such as Flowers.GIF, which will be 2 KB. Following that page will redirect you to a streaming audio or video that might be 3KB.

    So the number will surely increase or if you would like, set it to decrease. Keep in mind that also this may take some time (15 minutes) it will benefit you from being able to view in sequential order the time, and the data size. Also, within the page you will still have a .SWF file along with the image but you will set the flash file to load in a time you set it to appear and function. An efficient example of how this can be done is presented greatly by Sam Burdge.

    Wednesday, April 23, 2008

    XSS Shredder



    I made a small application that scans for XSS vectors. It works automated but you control the vector to see if it's valid or not. Also, I tried my best to make it Web 2.0-- because I know much you all hate Web 2.0 :) Additionally, for the URL you would put in an example like http://www.test.com/pwned.php?id= and it will then try different set-attacks to append to the value. I programmed this in Visual Basic 6. Credit goes to RSnake (Rober Hansen) for producing such an effective list of XSS attacks that by-pass most filterization. You may download the tool here, enjoy!

    *Update- Don't forget to stop by at our 'Resources' page @ V.A.P.T. and check out the latest White paper on Cross-Site Request Forgery. CSRF- Threating browsers at an entirely different level. Spoof Spoof, Frame Frame!

    Tuesday, April 22, 2008

    Web Application Security: Log & Alert 5



    Various methods in which this concept can be appended to:

    1.) If a URL is manipulated to change TokenID
    2.) If a certain folder is accessed
    3.) When attempting to SQL inject or several other attacks (XSS, Directory Traversal, etc)
    4.) Searching for specific keywords you otherwise, have restricted access to
    5.) If a E-mail form is available and certain input or fields are limited in characters
    6.) Over 5 failed login attempts have been tried
    7.) Accessing a specific file extension
    8.) If a default/test cookie and TokenID have been setup, and then accessed (hidden)
    9.) Multiple connections detected on the same online account
    10.) Brute forcing .htaccess files

    -- When any of the following have been done, through the means of automation and server configuration, the "attacker" will be redirected in this fashion:

















    You may create a sub-domain, username, or folder to review the requests and apply, but in this example I am using a sub-domain.

    -- On Warning.App-Site.com, you will be forcefully submitted to search for "HackingYou" into a search engine of some kind to several websites such as: Fbi.gov, Nike.com, and PhotoBucket.com.

    query: http://www.App-Site.com/us/en/_search/search.htm?qt=Hacking+You

    This clearly leaves you as a suspicious target for attempting to "attack" the website, while you were merely searching for keywords that administrators despise. In this example, the user was framed, but you can come up with your own creative style in how to adjust this concept to meet your needs. This is all about reviews in your logs. It gives you a bold choice of hot key words to assemble when identifying a users behavior. In this case, we'll be detecting the anomalies by looking at who accessed the sub-domains and why.

    The user is bound to be migrated through a series of immediate redirects issued by a .SWF file. Redirecting a user can be prevented in several ways, but using a Flash File (.SWF) is rarely what a user can identify as a redirection, and will have to debug the file to it's original format to figure out if a redirect of any sort exists.

    --Include this ActionScript in your flash file as a funtion to execute the redirection:

    PoC (Proof of Concept)

    1 getURL("http://App-Site.com/redirect/owned", "_self");
    2 stop ();

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

    Common log file displaying access to those sub-domains:

    Host: 11.22.33.444

    Warning.App-Site.com
    Warning.App-Site.com/redirect.swf

    Http Code: 200 Date: Apr 22 17:57:16

    Http Version: HTTP/1.1 Size in Bytes: 522569

    Referer: http://App-Site.com/data
    Agent: Opera/9.27 (X11; Linux i686; U; en)

    Saturday, April 19, 2008

    Web Application Security: Log & Alert 4


    Perhaps you want to communicate in real-time with your enemy (attacker)? Let's say that someone is navigating through your website in an attempt to attack your web application(s). The attacker is logged in through some sort of portal; otherwise known as a forum. The attacker also has the lowest privilege set for usage. You notice that very few to almost no other user on the site is active, interacting, and browsing in the same area within the website as the attacker. You might want to scare away the hacker or analyze in-depth what their motive/intention(s) might be.

    Firstly, you will create an in-house automated script that will embed an XSS vector inside any original image of your choice; injected in the source code, replacing it with the vulnerable image. You can connect to your website through various means to switch the image, but an automated script can deliver the "message" quicker. While the attacker is dealing with your website, you can make this XSS display in alert in this form stating:



    Preferably, you can use the following wording-- "You are caught and will be reported, and legal action will be taken."

    * When you do implement the XSS, make sure no form of parameter tampering can be done in terms of modifying values, strings, variables, and overall crafting of any URI to cause a change in the set-attack.

    Since the attacker is signed (as it is a forum), it's reasonable to assume that you should replace an image that only exists when you are signed in to the section of the forum. Doing this, the XSS won't be available upon request or exposed to any common visitor when stumbled upon, unless logged in. This stabilizes the fact that less users will be interrupted if unnecessary. The XSS shouldn't be valid or up for too long because it might affect several users that weren't targeting the website at all, thus resulting in complaining to the owner of the website about such an "error". Hopefully, the attacker will go away. To be honest, I think most attackers understand their situation clearly in terms of legal obedience.

    To further my point, if a website includes a TOS (Terms of Service) or some kind of policy; specifically announcing that legal action will be enforced if any kind of hacking is done to the website, then in general most hackers will simply withdraw from attacking the website, or in most cases restrict and limit some forms of attacks. It's fair to say that if you are "caught" hacking, it's likely that you won't stick around. It's merely a legitimate illusion constructed to prevent a defacement or compromise, and just tailor into taking care of the matter. Moreover, if the user is utilizing Firefox to browse your website, you can choose to instead replace a .SWF object and simply construct the form of XSS using ActionScript. Additionally, if you are certain that it is indeed an intruder, terminate their session, suspend the account, and also consider taking suitable action in relation to the law.