XSS For Managers

What is Cross-Site Scripting (XSS)?

Cross-Site Scripting (XSS) is a type of vulnerability which is very widespread and allows an attacker to insert malicious code (JavaScript) into your web browser via the use of a vulnerable web application. The attacker can deliver their malicious code in a number of different ways.

They can trick you into clicking on a link (Reflected XSS), or wait for you to visit a page which already has the malicious code embedded into it (Stored or Persistent XSS).

That annoying pop-up box with the number 1 in it? That's just a way that some people visually prove that their JavaScript (XSS) has been run. But don't let that lousy pop-up box fool you, there is a lot more to XSS than that!

What can hackers do with XSS?

• A hacker may be able to steal your 'cookies' and login to the application as if they were you!
• They may be able to redirect you to a malicious web site without you knowing in an attempt to trick you into giving away sensitive information such as your bank details.
• They could add fake login pages to the vulnerable application to trick you into giving them your username and password.
• They could even use XSS to bypass other security measures which are built into the application and your web browser to protect you.
• The possibilities are almost limitless. Take over your webcam? Yep! Listen in on your computer's microphone?

For advanced attacks see the The Browser Exploitation Framework (BeEF) tool.

Who's been hacked using XSS?

• The Apache Foundation, the creators and maintainers of one of the most popular web server software on the Internet had their servers compromised by an initial XSS attack.
• An XSS attack on the official forum of the popular Linux Operating System, Ubuntu, allowed the attackers to download the usernames, email addresses and passwords for 1.82 million of their users.
• XSS attacks typically target the application's users and their local networks; however, as seen in the examples above, when those users are administrative users the application's web servers are also at risk.
• XSS vulnerabilities are discovered within Facebook, Yahoo, Google, Twitter and other high profile websites on a daily basis by independent security researchers participating in bug bounties.

Here is a list of other hacks using XSS -https://www.google.com/fusiontables/DataSource?snapid=S1158702BBoV

What can I do to protect myself against XSS?

• Make sure that your web browser is kept up to date and that it has all of its security features enabled, such as Cross-Site Scripting (XSS) filtering. If your particular browser does not have an XSS filter, like Firefox, then you can download an XSS filter add-on called NoScript.
• Be careful about what links you click on. A link may look harmless enough, but may contain malicious XSS payloads.
• Log out of web sites when you are finished with them, this makes it harder for hackers to steal your 'cookies'.

The technical bit! What can I do to protect my web application against XSS?

• Cross-Site Scripting occurs when untrusted input is output to a page without first being sanitised and/or properly encoded. For example, if a user supplies their username to login and then you display that username without sanitising and/or encoding it, what happens if the username contains HTML characters?
  
  The web browser will not be able to tell the difference between the user's username and what is the page's valid HTML. Data (the username) is being mixed with code (the HTML)! This could allow a user to login with a username that contains malicious JavaScript and have it execute in the browser within the context of your web application.
  
• Make sure that you sanitise the username before using it, for example, if users should only have alpha numeric characters in their usernames then enforce this with input sanitisation. Use a whitelist! Compare the username against known goods instead of known bads.
  
• Use the right encoding! If the username is going to be used within HTML, then HTML encode all of the username's characters.
  
  This way the browser will know what is meant to be rendered as HTML and what is not. It's not all about HTML encoding though! You must encode for the right output 'context'. See the links below for further information.
  
• Scan your applications for XSS issues. There are many automated web application security scanners which can detect XSS issues in web applications. You could try giving the Open Source OWASP ZAP a go.
  
• Set your session cookies with the HttpOnly flag. This tells the browser that the cookie should not be accessed by JavaScript, helping protect your users from having their sessions stolen.
  
• A HTTP header called Content Security Policy (CSP) can be set by the web server to tell the web browser what and where JavaScript is allowed to be executed from. It uses a whitelist!
  
• Finally, why not install a Web Application Firewall (WAF) such as the Open Source mod_security! A WAF will give your application that extra layer of defence to defend against those attackers but should be used in a defense in depth scenario and not as the only solution as bypasses are found often.

Where can I find further information?

The two types of XSS mentioned on this page (Reflected and Stored) are not the only two! We have only touched upon the subject here. Want to find out more?

The Open Web Application Security Project (OWASP) is a great resource for all things related to the security of web applications. Check out their wiki article on XSS or their XSS Prevention Cheat Sheet. For information on other types of web application vulnerabilities take a look at the OWASP Top 10.

Sandcat - Penetration Testing Oriented Browser for Pen-Testers

Sandcat Browser brings unique features that are useful for pen-testers and web developers

Sandcat is targeted at penetration testers - people who test websites for security holes - but could also be useful for developers, or anyone else who would like a little more low-level control over their browsing .. This is a capable security testing and developer-oriented browser.

Sandcat Browser is a freeware portable pen-test oriented multi-tabbed web-browser with extensions support developed by the Syhunt team. It is built on top of Chromium, the same engine that powers the Google Chrome browser and uses the LUA language to provide extensions and scripting support.

It has many useful security and developer oriented tools updated to version 4.0 with the fastest scripting language packed with features for pen-testers such as: 

• Live HTTP Headers — built-in live headers with a dedicated cache per tab and support for preview extensions
• Sandcat Console — an extensible command line console; Allows you to easily run custom commands and scripts in a loaded page
• Resources tab — allows you to view the page resources, such as JavaScript files and other web files.
• Page Menu extensions — allows you to view details about a page and more.
• Pen-Tester Tools — Sandcat comes with a multitude of pen-test oriented extensions. This includes a Fuzzer, a Script Runner, HTTP & XHR Editors, Request Loader, Request Replay capabilities, Tor support and more.

Features inherited from Chromium include:

• Multi-Process Architecture — each tab is its own process
• Developer Tools — in addition to the Chromium Developer Tools, Sandcat comes with a Source Code Editor and its own JavaScript and Lua consoles.

8 Steps to Promote Secure Mobile Apps

FTC Issues Guide on Getting It Right from the Start

Developing secure mobile applications is just one part of the process in creating new programs. Communicating how applications are secured - whether informing end users in your enterprise or marketing to consumers - is crucial in building IT security awareness among stakeholders.

The Federal Trade Commission has just published a guide to help mobile application developers observe truth-in-advertising and basic privacy principles when marketing new mobile apps. The FTC's new publication, Marketing Your Mobile App: Get It Right from the Start, notes that there are eight general guidelines that all app developers should consider.

The FTIC guidelines are:

Tell the truth about what the app can do.

False or misleading claims, as well as the omission of certain important information, can irritate users and land the application developer in legal hot water.

Disclose key information clearly and conspicuously.

Most people react negatively if they think a company tries to pull a fast one by hiding important information. Users are more likely to continue to do business with an organization that gives them the straight story up front.

Build privacy considerations in from the start.

Limit the information collected, securely store data and safely dispose of information no longer needed. For any collection or sharing of information that's not apparent, get users' express agreement. That way, customers aren't unwittingly disclosing information they didn't mean to share.

Offer choices that are easy to find and easy to use.

Make it easy for people to find the tools that are offered and design them so they're simple to use. Follow through by honoring the choices users have made. 

Honor privacy promises.

Chances are assurances are made to users about the security standards and how personally identifiable information is used. App developers must live up to those promises.

Protect children's privacy.

Mobile application developers have additional requirements under the federal Children's Online Privacy Protection Act if the application is designed for minors or if the application collects personal information about children.

Collect sensitive information only with consent.

Even when not dealing with children's information, it's important to get users' approval before collecting any sensitive data from them, such as medical, financial or precise geolocation information.

Keep user data secure.

The law requires application developers marketing their programs to take reasonable steps to keep sensitive data secure. One way to make that task easier: Don't collect information in the first place if there's no specific need for it.

People rely on mobile technology for a lot of stuff and they need to know what the developer has done to lock down apps, to protect against the types of attacks we're seeing.

How to protect your Facebook account from hackers?

Nine Major Ways Criminals Use Facebook

1. Hacking Accounts
   
   When criminals hack a Facebook account, they typically use one of several available “brute force” tools, Grayson Milbourne, Webroot’s Manager of Threat Research for North America, told 24/7 Wall St. in an interview. These tools cycle through a common password dictionary, and try commonly used names and dates, opposite hundreds of thousands of different email IDs.
   
   Once hacked, an account can be commandeered and used as a platform to deliver spam, or — more commonly — sold. Clandestine hacker forums are crawling with ads offering Facebook account IDs and passwords in exchange for money. In the cyber world, information is a valuable thing.
   
2. Commandeering Accounts
   A more direct form of identity theft, commandeering occurs when the criminal logs on to an existing user account using an illegally obtained ID and password. Once they are online, they have the victim’s entire friend list at their disposal and a trusted cyber-identity.
   
   The impostor can use this identity for a variety of confidence schemes, including the popular, London scam in which the fraudster claims to be stranded overseas and in need of money to make it home. The London scam has a far-higher success rate on Facebook — and specifically on commandeered accounts — because there is a baseline of trust between the users and those on their friends list.
   
3. Profile Cloning
   Profile cloning is the act of using unprotected images and information to create a Facebook account with the same name and details of an existing user. The cloner will then send friend requests to all of the victim’s contacts. These contacts will likely accept the cloner as a friend since the request appears to be from someone they’re familiar with. Once accepted, the crook has access to the target’s personal information, which they can use to clone other profiles or to commit fraud.
   
   As Grayson Milbourne puts it, “Exploiting a person’s account and posturing as that person is just another clever mechanism to use to extract information.” Perhaps what’s scariest about this kind of crime is its simplicity. Hacking acumen is unnecessary to clone a profile; the criminal simply needs a registered account.
   
4. Cross-Platform Profile Cloning
   
   Cross-platform profile cloning is when the cyber criminal obtains information and images from Facebook and uses them to create false profiles on another social-networking site, or vice versa. The principle is similar to profile cloning, but this kind of fraud can give Facebook users a false sense of security because their profile is often cloned to a social platform that they might not use. The result is that this kind of fraud may also take longer to notice and remedy.
   
5. Phishing
   Phishing on Facebook involves a hacker posing as a respected individual or organization and asking for personal data, usually via a wall post or direct message. Once clicked, the link infects the users’ computers with malware or directs them to a website that offers a compelling reason to divulge sensitive information. A classic example would be a site that congratulates the victims for having won $1,000 and prompts them to fill out a form that asks for a credit card and Social Security number.
   
   Such information can be used to perpetrate monetary and identity fraud. Grayson Milbourne of Webroot, also explained that spearphishing is becoming increasingly common, a practice that uses the same basic idea but targets users through their individual interests.
   
6. Fake Facebook
   A common form of phishing is the fake Facebook scam. The scammers direct users via some sort of clickable enticement, to a spurious Facebook log-in page designed to look like the real thing. When the victims enter their usernames and passwords, they are collected in a database, which the scammer often will sell.
   
   Once scammers have purchased a user’s information, they can take advantage of their assumed identity through apps like Facebook Marketplace and buy and sell a laundry list of goods and services. Posing as a reputable user lets the scammer capitalize on the trust that person has earned by selling fake goods and services or promoting brands they have been paid to advertise.
   
7. Affinity Fraud
   In cases of affinity fraud, con artists assume the identity of individuals in order to earn the trust of those close to them. The criminal then exploits this trust by stealing money or information. Facebook facilitates this type of fraud because people on the site often end up having a number of “friends” they actually do not know personally and yet implicitly trust by dint of their Facebook connection.
   
   Criminals can infiltrate a person’s group of friends and then offer someone deals or investments that are part of a scheme. People can also assume an identity by infiltrating a person’s account and asking friends for money or sensitive information like a Social Security or credit card number.
   
8. Mining Unprotected Info
   Few sites provide an easier source of basic personal information than Facebook. While it is possible to keep all personal information on Facebook private, users frequently reveal their emails, phone numbers, addresses, birth dates and other pieces of private data. As security experts and hackers know, this kind of information is often used as passwords or as answers to secret security questions.
   
   While the majority of unprotected information is mined for targeted advertising, it can be a means to more pernicious ends such as profile cloning and, ultimately, identity theft.
   
9. Spam
   Not all spam — the mass sending of advertisements to users’ personal accounts — is against the law. However, the existence of Facebook and other social sites has allowed for a new kind of spam called clickjacking. The process of clickjacking, which is illegal, involves the hacking of a personal account using an advertisement for a viral video or article.
   
   Once the user clicks on this, the program sends an advertisement to the person’s friends through their account without their knowledge. This has become such an issue for the social media giant that earlier this year that the company has teamed up with the U.S. Attorney General to try to combat the issue.

How Developers Can Secure their Code?

5 Application Security Tips

Over the last 30 years, many organizations have done an amazing job of automating their business, resulting in productivity gains, efficiencies and innovations.

Unfortunately, the threat landscape has changed dramatically during this time. A lot of that application code, written without security in mind decades ago, is still the heart-and-soul of many enterprises. That code was designed for a world where computers could not be accessed remotely.

Since then, it has been wrapped, integrated, connected, ported, and most importantly, exposed. That application code is not strong enough to withstand today's threat.

OWASP has a number of free and open-source resources that developers can use right now to help secure their code.

5 Tips for Developers

Start with the OWASP Top Ten - This awareness document will help you understand, identify, and fix the most critical application security risks quickly.

Get hands-on with WebGoat - WebGoat is a deliberately flawed application that is riddled with holes to give people the opportunity for hands-on learning. It is open-sourced to help developers and security testers get experience with real vulnerabilities.

Leverage the OWASP Cheat Sheets - This is a fantastic series from leading experts globally. Let me know what you think of the Cross-Site Scripting Prevention Cheat Sheet, one of OWASP's most popular pages.

Verify Your Applications - There is no substitute for getting real facts about the security of your application portfolio. OWASP Application Security Verification Standard helps developers get started scanning, testing and code reviewing with tools like OWASP Zap and CSRFTester.

Get Training - Perhaps the hardest thing about application security is that there are so many different ways that software can fail, particularly when it's targeted by a motivated attacker. The key is training to get started with securing applications quickly.

If instructor-led training isn't possible, eLearning solutions are available to allow developers to learn on-demand and get hands-on, practical experience with vulnerabilities, security controls and real code. Training is a remarkably effective way to reduce vulnerabilities.

Before you trust your business to application software, make certain that the people who are writing your code know how to defend your business and its assets. It's time to learn.

Hole in Google Chrome that granted unauthorised access to gmail accounts

Web extensions to become a new attack vector

A penetration tester has exploted a hole in Google Chrome that granted unauthorised access to gmail accounts.

WhiteHat Security researcher Matt Johansen identified the vulnerability in a Chrome OS note-taking application. He disclosed the hole to Google which patched it and gave him US$1000 as part of its Chromium security initiative.

Johansen told Reuters he intercepted data travelling between a Chrome browser extension and the Google cloud. Google has not yet revealed details of the security hole which Johansen plans to release at the Black Hat conference in Las Vegas this year.

Google extensions, written by third party software developers, were a ripe target for attack because they were granted more privileged access rights to Google cloud data than what the browser offered to web sites.

WhiteHat security detailed in a 2007 research paper a series of web application security vulnerabilities that could also be used to attack web browser extensions in Chrome and Mozilla FireFox.

Chrome OS director Caesar Sengupta said there are "significant benefits to security" by storing apps within the browser.

Android app can 'hack' Facebook and Twitter account

FaceNiff enables an Android smartphone to detect unsecured Facebook or Twitter login

Facebook and Twitter users face a new security headache from an Android app that allows anyone to hack social media accounts at public WiFi spots.

The developer of the FaceNiff app mentioned on their website that the app is for educational purposes only, and urges users not to install it if it is illegal in their country.

FaceNiff enables an Android smartphone to detect any unsecured Facebook or Twitter login made on the same WiFi network by a desktop or laptop using a standard web browser.



The app is a major security risk as it allows hackers access to a user's private contact details and those of all their friends. Using the app, it would be possible for hackers to collect personal information needed for identity theft simply while having coffee at an internet cafe.

FaceNiff needs to be side loaded onto an Android device that allows root or superuser access to the device. While some users would not be capable of configuring "root user" access on their Android phones, many would, and a list of compatible phones is listed on the developer's website.

The developer claims the app works not only on open networks, but WiFi networks secured by WEP, WPA-PSK and WPA2-PSK network protocols.

The developer's website states the app can be used to access Facebook, Twitter, YouTube, Amazon, and Nasza-Klasa -- a Polish version of Facebook with "new coming soon".

FaceNiff however is understood not to work if social media is accessed with https secure protocol.

Facebook and Twitter by default do not automatically use https browsing and users have to activate it.

Facebook caught exposing millions of user credentials

App bug overrides user privacy settings

Facebook has leaked access to millions of users' photographs, profiles and other personal information because of a years-old bug that overrides individual privacy settings, researchers from Symantec said.

The flaw, which the researchers estimate has affected hundreds of thousands of applications, exposed user access tokens to advertisers and others. The tokens serve as a spare set of keys that Facebook apps use to perform certain actions on behalf of the user, such as posting messages to a Facebook wall or sending RSVP replies to invitations. For years, many apps that rely on an older form of user authentication turned over these keys to third parties, giving them the ability to access information users specifically designated as off limits.

The Symantec researchers said Facebook has fixed the underlying bug, but they warned that tokens already exposed may still be widely accessible. “There is no good way to estimate how many access tokens have already been leaked since the release [of] Facebook applications back in 2007,” Symantec's Nishant Doshi wrote in a blog post published on Tuesday. “We fear a lot of these tokens might still be available in log files of third-party servers or still being actively used by advertisers.”

Refer here to read more details.

Application Security Intelligence

Free Online Event

Forward-thinking organizations have begun to adopt a holistic approach to securing applications rather than investing in perimeter defenses like firewalls and intrusion prevention systems.

Join on May 19th for a full day of interactive webcasts to hear leading IT security experts discuss the role of application security intelligence in enabling software security assurance programs to proactively reduce business risk across the enterprise.

About the event:

"Traditionally, organizations have responded to security threats by investing in perimeter defenses like firewalls and intrusion prevention systems. While effective in the short-term, this approach is simply a bandage that offers reactive protection only, falling short of proactively and programmatically securing the applications and assets that are the lifeblood of any modern business. Recently, some organizations have begun to adopt a holistic and strategic approach to securing their applications. Join us to hear leading software security experts discuss the role of application security intelligence in enabling software security assurance programs to proactively reduce the business risk of insecure software across the enterprise."

Presentations include:

"Application Security Intelligence: Managing Application Risk"
Roger Thornton, CTO & Founder, Fortify Software, an HP company

"Optimizing Security in Software Development: Secure at the Source"
Derek Brink, VP & Research Fellow, Aberdeen Group

"Application Security Strategy in a Mobile World"
John South, CISO, Heartland Payment Systems

"Cloud Security and Its Impact on Application Security"
Dennis Hurst, Founding Member, Cloud Security Alliance

"Addressing the Top 5 Web Application Security Threats"
Dave Wichers, OWASP Board Member & COO, Aspect Security

Sign up to attend any or all of the May 19 webcasts at: http://bit.ly/mPYS1V

Massive SQL injection attack

Mass Injection hits over 694,000 URLs

Hundreds of thousands of URLs have been compromised—at the time of writing, 694,000—in an enormous and indiscriminate SQL injection attack. The attack has modified text stored in databases, with the result that pages served up by the attacked systems include within each page one or more references to a particular JavaScript file.

The attack appears to be indiscriminate in its targets, with compromised machines running ASP, ASP.NET, ColdFusion, JSP, and PHP, and no doubt others. SQL injection attacks, which exploit badly-written Web applications to directly perform actions against databases, are largely independent of the technology used to develop the applications themselves: the programming errors that allow SQL injection can be made in virtually any language.

The underlying cause is a programmer trusting input that comes from a Web page—either a value from a form, or a parameter in a URL—and passing this input directly into the database. If the input is malformed in a particular way, the result is that the database will run code of the attacker's choosing. In this case, the injected SQL is simply updating text fields within the database, to make them include an extra fragment of HTML. This HTML in turn loads a JavaScript from a remote server, typically "http://lizamoon.com/ur.php" or more recently, "http://alisa-carter.com/ur.php." Both domain names resolve to the same IP address, and presently that server is not functional, leaving browsers unable to load the malicious script when they visit infected pages. Previously, it contained a simple script to redirect users to a fake anti-virus site.

The massive scale of these attacks (and the rapidly growing number of affected URLs) was first noticed by Websense Security Labs. On Tuesday, around 28,000 URLs were compromised; now more than 20 times more URLs are infected, and the numbers are still growing. The injected code is also found on a number of product pages on Apple's iTunes Store. Apple fetches RSS feeds from podcasters that broadcast using iTunes, and in a number of cases these broadcasters have been compromised by the SQL injection attack. As a result, the malicious code has made its way into Apple's system.

However, due to the way Apple processes the RSS feeds, there appears to be no exploitation vector; the injected HTML is safely nullified. SQL injections following this pattern appear to have been happening off and on for six or more months now. The domain name hosting the JavaScript changes each time, but the file name—ur.php—and the style of injection remain consistent. The actions of the scripts have been similar too; pop-up windows and malware downloads. Previous efforts were on a much smaller scale, however: hundreds of compromised URLs instead of hundreds of thousands.

In these earlier cases, the attacks originated from IP addresses in eastern Europe and Russia. It's been a busy week for SQL injection; at the weekend, MySQL.com, the website of Oracle-owned open source database MySQL, was hacked, again using SQL injection. A little embarrassing for a database vendor to be unable to use its own database securely.

SC Magazine’s recent study of less-shouted-about THREATS

Risks and Rewards of Archiving!

Cloud and social media security are much discussed areas of focus within our profession but what about some of the less shouted-about threats? I thought you might be interested in SC Magazine’s recent study of some of these, which will be discussed in greater detail in 3 of their upcoming webcasts; found at http://www.scwebcasts.tv and http://www.scstudio.tv respectively.

Below is a little more info on the 3 topics to help you assess their relevance to your organisation:

STAMP OUT COSTLY SECURITY DEFECTS IN SOFTWARE DEVELOPMENT
Going live at 2pm GMT, 30th March

The Coverity Scan found an alarming 50,000 defects in just 300 open-source software products. This webcast will give you an instant understanding of the secure coding practices that you should adhere to to eliminate these increasingly costly security vulnerabilities.

Speakers: Robert Seacord, Secure Coding Director, CERT - Software Engineering Institute, Michael White, Technical Director, Coverity

You can secure your free place at: http://www.scwebcasts.tv

ARE RISKY APPLICATIONS UNDERMINING YOUR BUSINESS SECURITY?
Going live at 3pm GMT, 12th April

With 75% of new attacks (CERT) targeting applications and with the lines blurring between personal and business devices, this webcast will shed vital light on the real security repercussions of risky apps in the workplace and what you can do to secure them.

Speakers: Tim Mathias, Director of Security, Thomson Reuters Chris Wysopal, Co-founder & CTO, Veracode

You can secure your free place at: http://www.scwebcasts.tv

THE RISKS AND REWARDS OF ARCHIVING

This webvideo is live now on SC’s site at http://www.scstudio.tv

83% of the 200 IT professionals that SC spoke to (representing both SMEs and larger enterprises) reckoned the cost of email downtime to their business to be over $500,000. This interesting SC Studio show which you can watch right now at http://www.scstudio.tv , offers some interesting pointers on one of the most effective ways to reduce this risk/cost – archiving.

Speakers: Brian Shorten, Risk and Security Manager, Cancer Research UK Giovanni Alberici, Archiving & Continuity Specialist, Symantec.cloud

I hope the shows are relevant to your organisation. As always, do feel free to get in touch with any thoughts on these topics or ideas for future ones.

For the webcasts, if you can’t make the live date of the webcasts you can of course watch them live in the archive at your leisure at http://www.scwebcasts.tv. The studio show you can watch whenever you like at http://www.scstudio.tv .

Google Reward Program: $1337 to find vulnerability on Blogger

Gaining Administrative Privileges on any Blogger.com Account

Interesting POC:

Watch out for "Boy-in-the-Browser" attacks - (BitB)

Boy-in-the-Browser attacks are hard to detect, BUT easier to execute

The Boy in the Browser is a sophisticated trojan, a "dumbed-down" version of MitB. In essence, a BitB is a less mature version of the MitB trojan, hence the name.

With a BitB, the trojan takes control of the victim's traffic and re-routes the information through an attacker's proxy site. It is very difficult to detect since the victim's address bar continues to present the address of the intended destination. For example, you as an infected victim are surfing to a bank's website, but in fact, that traffic is sent to the attacker. Yet, on your browser, you continue to the bank's normal website.

Once all traffic is re-routed via the attacker, the attacker can do whatever it wants with that data. For example:

• It can act as a proxy just logging sensitive information before passing the request on to the original destination.
  
• It can act as an "active" proxy modifying requests (for example, to transfer sum to a different bank account) before passing it on.
  
• Committing fraud schemes. For example, we have seen a scheme which defrauds Google.

This is a growing, resurging, trend amongst hackers, since, in short, it works. Since these trojans are so quick to evolve, anti-viruses do not always detect variants. More people fall prey to these attacks as they are so difficult to detect. Hackers have realized this and are continuing to release more and more variants of BitBs.

A Man in the Browser intercepts user requests and server responses while "sitting" on the victim's browser. In effect, it listens directly on that communication. For example, when the victim is authenticated to the bank and requests a transfer from his checking account to savings account. The trojan may modify that request in order to make a transfer from the checking account to an account in the Ukraine.

In the case of a BitB, the trojan redirects the traffic to a 3rd-party site which is an attacker-controlled server. This means that all traffic does not go immediately to the bank, rather it passes through that extra link. Only at that server, can the attacker modify the transaction request before continuing to pass it along to the original destination.

Let's consider first MitBs – these are a huge deal for enterprises and banks to deal with for the following three reasons:

• Impact user transactions.
  
• Very difficult to detect. - They last a long time.

Similarly to the MitB, BitB is just as dangerous and just as hard to detect. However, this sort of attack requires much less resources for attackers to execute. There are two main required resources:

1. The trojan code.
2. Attacker- controlled server.

As opposed to MitB, the BitB trojan code is much simpler to write. It is a very short piece of code to redirect the traffic. As for the server, they just require a domain. Today's automated tools will set up the server within just a couple of clicks. The BitB setup is a no-brainer. However, the MitB code is much more complicated. Consider your banking application. It has tabs for different operations, different options for transactions and in general, quite a complex application. The MitB code needs to be customized for each of these operations in order to hook into each of the application's feature. The big guns are required to carry out these MitB schemes.

Each of these Trojans have the same impact and scare banks and businesses alike. BitB is much easier for an attacker to pull off. However, they are most useful for a one-shot sting operation. Once uncovered, the attacker-controlled server is shut down and business is as usual. On the other hand, MitB attacks are a continuing process much more difficult to fight out once uncovered. In that case there is no single pain-point to bring down.

Imperva have witnessed BitB as a resurging as a tool of attack. Below are a couple of notable ones that they have seen:

1. Nine Latin American banks were targeted. This is one more supporting evidence that BitB is in fact a lucrative scheme. As hackers gain from this sort of attack, they continue to target numerous banks.

2. Click fraud. This is an interesting scheme since the target is not a banking application, rather it is used in order to commit fraud. In this case, to defraud Google. The victim accessing a regional domain of Google, for example www.google.co.uk would be redirected to the attacker-controlled server. When a user performs a query, the attacker would fetch the results and ads from Google, but serve them on his own page. The result is that when a user clicks on a specific ad, the commission is attributed to the attacker, and not to Google. 36 Google regional domains were targeted in this scheme showing that the attacker's aimed to target victims worldwide.

The Latin banks were a classic case which provided no visual clues as to the traffic take-over. On the other hand, with the click fraud campaign, the visual clues were ridiculously apparent as we show in our advisory on the site.

Imperva's research arm, the ADC, has established the Hacker Intelligence Initiative (HII). Under this initiative, the researchers attempt to understand the threat landscape. Their research methods involved:

1. Tapping into hacker forums
2. Monitoring and recording attacker traffic
3. Analyzing attacker resources

As part of the HII ongoing research, they witnessed these campaigns being carried out. The team started investigating and this lead to further understanding of hacking operations.

Although BitB is presumably the consumer's problem, one cannot expect the user to know that his browser is under an attacker's control. For sake of comparison – even anti-anti virus do not flag most of these Trojans as malware as they are so quickly being modified. It is time then for online services, such as banks and retailers, to recognize this problem and provide solutions. Similar to the car industry where accidents drove the manufacturers to deal with car safety by providing seat belts, anti-brake lock systems, air bags, etc, the online banks need to consider how to deal with infected customers.

Boy-in-the-Browser attacks have the same impact as a Man-in-the-Browser attack and are just as hard to detect, BUT they are easier to execute. Banks need to start paying more attention to these types of attacks and provide the correct response to deal with them.

Open WiFi and Firesheep

Hijack Facebook Using Firesheep

What’s new about Firesheep isn’t the exploit – HTTP session hijacking has been well known for years – it’s that Firesheep is a simple Firefox plug-in that is available to anyone and requires no technical expertise to utilize. In other words it allows anyone with Firefox and Firesheep to be a hacker. No experience required.

What’s the problem with unsecured WiFi?

If you connect to the internet at unsecured WiFi hotspots, like say your favorite coffee shop or book store, then you have always been at risk of the vulnerability exploited by Firesheep. So what exactly is this vulnerability?

This exploit is commonly referred to as HTTP session hijacking or side-jacking and, it’s been known and used by bad guys for a very long time. Up until now it required some modicum of expertise on the part of the hacker to accomplish a side-jacking attack. The attacker had to use a packet sniffer to capture all those packets flying around, decode the packets to find session cookies in the clear and then create spoofed session cookie responses to join your session. For experienced hackers this wasn’t terribly challenging since they usually had software that would automate the process.

Firesheep was developed for the express purpose of exposing the HTTP session hijacking problem to everybody on the internet, ostensibly to force sites like Facebook to quit making it so easy. This Firefox plugin is named for the notorious Blackhat Wall of Sheep where clueless, unsuspecting users’ unprotected private information is intercepted and displayed very publicly. If you are foolish enough to attend the Blackhat conference in Las Vegas without seriously locking down your communications you will end up on the Wall of Sheep where you will be mocked and worse by other participants.

Firesheep automates side-jacking attacks in a very simple way by building it all right in to your Firefox browser. Facebook advised checking their new Account Security Page, which gives you a history of sign-ins by IP address thereby letting you know if there are two IPs currently signed-in from the same access point.

Anti-Firesheep tools like Fireshepherd were released. Written by Gunnar Atli Sigurdsson, an electrical engineering student at the University of Iceland, Fireshepherd periodically jams the local wireless network with a string of junk characters intended to crash Firesheep when the snooping program reads them.

How can websites keep you secure over unsecured WiFi?

The vulnerability that is exploited by side-jacking has been well understood for years, so too has the solution / mitigation. Consequently your bank has been using this more secure mechanism for most of those years.

On Internet banking websites, an HTTP over SSL (HTTPS) connection is established before you send your credentials to the your bank’s web site. But note that after your credentials are validated, the secure HTTPS connection is maintained for the entire session. In other words once you establish that secure encrypted channel with your bank, everything for the entire session is protected. I know what you’re thinking now:

Why doesn’t Facebook, Twitter and Flickr do their sessions like this? Clearly they have the SSL capability because they use it for the logging in part of the session. It turns out that Eric Butler, the developer of Firesheep, was motivated by exactly these questions. Quoting from the announcement on his blog:

This is a widely known problem that has been talked about to death, yet very popular websites continue to fail at protecting their users. The only effective fix for this problem is full end-to-end encryption, known on the web as HTTPS or SSL.

There are several reasons that websites don’t use strictly HTTPS sessions. First, they want their sites to be accessible to the largest possible audience, including users of older mobile devices that may not support HTTPS connections. Second, there is a lot more overhead involved on both ends when everything is encrypted. Those are the main reasons, but I don’t mean to imply that they good reasons. The first reason may have been valid five years ago, but smart phones and other portable devices have come a long way in that time. The second reason may have been valid before broadband internet connections were ubiquitous, but certainly no one in a WiFi hotspot is connecting via a modem at 28K. Besides, it would be easy to keep the legacy mode connection for those few users who actually have old smart phones or dial-up connections. As always, the real reason is financial.

They would have to develop and roll out changes to not only the web servers but to all of those slick little apps that everybody is using. Remember the problems that Microsoft encountered when making Hotmail use fulltime HTTPS that were mentioned earlier.

What can you do to be secure over unsecured WiFi?

So while popular websites like Facebook are trying figure out how they can fix this problem with the smallest amount of effort, what can you and I do if we want to mess around on Facebook while enjoying a latte at our favorite coffee shop? There are several approaches you can take but the goal is to create a secure connection between your web browser and the insecure website. The best way to do this is to connect to a secure Virtual Private Network (VPN) and once that secure connection is established, surf wherever you like since the last hop on the journey to and from your web browser will be secure. This is great if you have access to a VPN like most road warriors use to connect to the office. Problem with that is that most businesses take a dim view of using VPN bandwidth and company resources to play around on Facebook.

You could install a VPN at home, but that is not an exercise for the fainthearted. There are some subscription based VPN services such as Hide My Ass (HMA http://hidemyass.com/ vpn/) that will provide a VPN to anyone for a fee. It’s not terribly expensive (1 month for around $12 US or a year for around $80 US) and is certainly easier than setting up your own VPN and way cheaper than getting fired for misusing the company VPN.

Finally there are browser add-ons that attempt to force HTTPS connections to sites that don’t offer them, like say Facebook, Twitter or Flickr. Unfortunately there are many websites where these just won’t work. Furthermore most of these add-ons are implemented as intrusive toolbars and egregious ad-ware.

Criminals are harvesting and selling Facebook users' information

Facebook users 'easy prey'

Facebook users have become easy prey for criminals as more and more people share personal information on the social networking site, says a computer anti-virus company.

Criminals are harvesting and selling Facebook users' information, stealing identities, sending spam and planting viruses, according to AVG (AU/NZ).

People put themselves at risk every day by carelessly clicking on invitations sent by 'friends' to join groups or write on their wall. They put all their personal information including date of birth and photos on their page. They even respond to fake Facebook requests for security details.

To help people stay safe on Facebook, AVG gave 10 tips:

1. Think about who you add: accepting a friend request provides your new mate with access to posts, photographs, messages and background information about yourself. Perhaps go through your list of friends and think about who you really want accessing your stuff.

2. Check privacy settings: Facebook recently got a face-lift, changing default privacy settings. It's worth going through them again - you may be sharing more than intended.

3. Why are you on Facebook? Is it just to share photos? Keep in touch with people? Share links and updates of your activities? Ask yourself what you want to achieve with your profile. It could be better to cut down on information-sharing.

4. Be smart about your password: try not to use the same passwords for all your accounts. Think about the type of security questions you set and where you are sending your updates.

5. Be aware of where you sign in from: When signing in from a different computer, check that it doesn't store your e-mail address and password. It's easy to accidentally choose it to "remember you".

6. Be careful what you say: once status updates and comments are posted, anyone can see, copy, and post it elsewhere. Do you really want people to know you'll be home alone tonight or away on vacation next week?

7. Watch out for phishing attacks: there have been numerous attempts to get users' login and passwords by tricking them with fake Facebook e-mails. Never select any e-mail links asking you to reset your password. Always go directly to Facebook.

8. Take immediate action: If friends start receiving spam from you or status updates appear that you didn't make, your account may be compromised. Immediately change your password. If you can't log into your account, go to the Help link at the bottom of any Facebook page and click on "security" to notify Facebook.

9. Protect your mobile device: Many mobile phones have direct access to social networking sites, including Facebook. Be mindful about who has access to your cellphone and make sure you log off the sites.

10. Monitor suspicious activity: Watch out for suspicious activity on your wall, news feeds and Facebook inbox. Never click on a suspicious link. Look closely, if the link does not look authentic, don't click.

Google Chrome 3.0 arrives with 3,505 bugfixes - Whoaaa!

Google's Chrome browser grows faster and more stable - Really? :)

Google Tuesday launched Version 3 of its Chrome Web browser, which keeps the pressure on competing tools by boosting JavaScript performance by 25% vs. the latest stable release. Improvements to tabs and video/audio handling round out the major new features in the release of Google Chrome, which can be downloaded here. The update comes about a year after Google Chrome made its debut. "This release comes hot on the heels of 51 developer, 21 beta and 15 stable updates and 3,505 bugfixes in the past year," Google writes on its blog.

Refer here to read the review on NetworkWorld.

Online Social Networks Leak Personal Information to Third-Party Tracking Sites

Leakage Puts Social Network Users at Risk of Having Their Identity Linked With Their Browsing Behavior

A Worcester Polytechnic Institute (WPI) study by professor Craig Wills found that the practices of many popular social networking sites can make personal information shared by users on their pages available to companies that track Web user browsing habits. The study, presented at the Workshop on Online Social Networks, part of ACM's recent SIGCOMM 2009 conference, described the method that tracking sites could use to directly link browsing habits to specific individuals.

Wills says users are given a unique identifier when they sign up with a social networking site, and when social networking sites pass information to tracking sites about user activities, they often include the identifier, giving the tracking site a profile of Web browsing activities and the ability to link that profile to a user's personal information. Wills says this is a particularly troubling practice for two reasons. "First, users put a lot of information about themselves on social networking sites. Second, a lot of that information can be seen by other users, by default." A unique identifier could give a tracking site access to a user's name, physical address, email address, gender, birth date, education, and employment information.

Wills says he does not know what, if anything, tracking sites do with unique identifiers given to them by social networking sites, and while the Web sites provide users with tools to protect themselves, the best way to prevent privacy leaks would be for social networking sites to stop making unique identifiers visible.

Please refer here to read the full research details.

Why "Due Care" is extremely critical?

Crown Plaza Venice Hotel suffers GBP90,000 loss due to sloppy coding

Web site code auditing could have avoided the 90,000 pound online booking loss incurred by the Intercontinental Hotels Group. Richard Kirk, Fortify's European Director, said that the online booking fiasco - in which rooms at the Crown Plaza Venice East Quarto D'Altino hotel were sold for pennies - has lost the group tens of thousands of pounds.

Rooms, which normally cost between up to 150 pounds a night at the four star hotel in Venice, have been booked by savvy Internet punters, most of whom are well aware of the law of contract. After the company initially blamed the fiasco on hackers, they quickly realised their own coding and data mistake - and are now effectively locked into completing the contract with customers.

Kirk says that the incident, which will cause a hole in the hotel's annual profits, could have been avoided if the hotel group - or its booking IT services provider - had used standard code auditing techniques on the Web site server system and its allied data. Standard auditing techniques that look for non-standard patterns in bookings, as well as erroneous low or high value card authorisations, would have picked up this anomaly.

According to Kirk, because of these failings in the audit process, more than 5,000 bookings were reportedly made within hours of the one pence rate being offered on the Crown Plaza Web site.
The irony of the situation is that the hotel - and the Intercontinental Hotels Group - will probably gain in the publicity stakes, but this is an expensive way to learn that your Web site code auditing and allied safeguards have failed you.

Joomla! Security / Vulnerability Scanner

Detect vulnerabilities on target Joomla! website...

I stumble across another cool scanner from yegh community. A regularly-updated scanner that can detect file inclusion, sql injection, command execution vulnerabilities of a target Joomla! web site. It's handy utility to check your website after designing on Joomla! platform.

If you are not aware - Joomla is an award-winning content management system (CMS), which enables you to build Web sites and powerful online applications. Many aspects, including its ease-of-use and extensibility, have made Joomla the most popular Web site software available. Best of all, Joomla is an open source solution that is freely available to everyone.

You can download it from here.

Criminals are looking for ways to turn browser vulnerabilities into money.

Security vs. Usability

Usability and security have been long been at odds with each other in software design. The web browser is no exception to that rule. When browsing the Web or downloading files the user constantly needs to make choices about whether to trust a site or the content accessed from that site. Browser approaches to this have evolved over time - for example, browsers used to give a slight warnings if you accessed a site with an invalid HTTPS certificate; now most browsers block sites with invalid certificates and make the user figure out how to unblock them.

Similar approaches are taken with file downloads. Internet Explorer tends to ask the user several times before opening a downloaded file, especially if the file is not signed. Prompting the user for actions that are legitimate most of the time often creates user fatigue, which makes the user careless in walking the tightrope between software with a "reasonable but not excessive" security posture and a package that is either too open for safety or too closed to be useful. Most browsers today have evolved from the "make the user make the choice" model to the "block and require explicit override action" model.

In some cases the security of the browser has had a major impact on Web site design and usability. Browsers present a clear target for identity theft malware, since a lot of personal information flows through the browser at one time or another. This type of malware uses various techniques to steal users' credentials. One of these techniques is form grabbing - basically hooking the browser's internal code for sending form data to capture login information before it is encrypted by the SSL layer.

Another technique is to log keyboard strokes to steal credentials when the user is typing information into a browser. These techniques have spawned various attempts by Web site designers to provide more advanced authentication with a hardware token and use of various click-based keyboards to avoid key loggers.

Another usability feature of the Web browser that has been attacked by malware is the auto-complete functionality. Auto-complete saves the form information in a safe location and presents the user with options for what he typed before into a similar form. Several families of malware,such as the Goldun/Trojan Hearse, used this technique very effectively. The malware cracked the encrypted auto complete data from the browser and send it back to the central server location without even having to wait for the user to log in to the site.

Giving all the vulnerabilities out there and the willingness of attackers to exploit them, you might think that users would be clamoring for more security from their browsers. And some of them do as long as it doesn't prevent any of their desired features from working.

There are a number of documents available that list steps one can take to lock down a Web browser. For example, one of those steps often is something like "Disable JavaScript." But few people actually ever do that - at least not permanently, because using a browser with JavaScript turned off is annoying, and in many cases prevents you from visiting sites you have legitimate reasons to visit.

"Attack and defense strategies are evolving, as the use and threat models. As always, anybody can break into anything if they have sufficient skills, motivation and opportunity. The job of browser developers, network administrators, and browser users is to modulate those three quantities to minimize the number of successful attacks."