Most web applications have areas that are accessible for all visitors while other areas are only accessible for users with an account. Examples on this are users logging in to a webshop or a forum, but it could also be a protected development/pre-production environment.
A user often have access to more functionality when logged in than when not logged in, e.g., to post comments on a forum, upload pictures to their profile, or complete a purchase. Hence, a comprehensive security evaluation of any web application need to be able to test areas behind a login.
Two common methods of login/authentication are Basic auth and HTML forms.
To authenticate Detectify with Basic auth just provide the credentials for the domain under domain settings in the dashboard.
HTML forms are “normal logins” you see on most websites like facebook or detectify.com.
To authenticate Detectify with HTML forms you need to record the login sequence and upload it to the domain under domain setting. The sequence should be recorded with our newly released Chrome plugin. In the plugin there is a simple wizard that will guide your through the process of recording the login process. When the wizard is completed you should save the trail and then upload it to the domain.
Do you feel that something is missing from Detectify or have a general comment? Hit us up at @detectify or email@example.com. We are aiming to improve Detectify and make the Internet a safer place.
We are releasing multiple major changes to Detectify and this is the beginning of the new Detectify. Many hours have been invested in a new and improved UI. There are also multiple changes under the hood in the core of the service, e.g., updated engine to better handle JS-based pages.
New user interface
The ambition with the new UI is to create a flexible design where it is easier for us introduce new functionality to our users. The release plan is packed with features that will help you as a developer and security tester.
We have introduced new features for improved usability, e.g.,
Scanning behind login and testing of predefined user flows (e.g., check-out flows)
Released the API for you to build integrations into your development tools
Improved coverage of new and updated attack vectors
New and updated modules for vulnerability testing in this release are e.g., CSRF (testing of forms), SSL Breach, Flash content sniffing (Rosetta Flash), DNS SPF (fake the sender of e-mails), DNSSEC tests, CSS parser and for all of you with internal legacy systems, VBS. An update of our JS-engine brings improved coverage of DOM-based XSS.
Set-up recurring testing
Don’t forget to set up recurring scanning of your site to make sure you are always tested for new security issues. New attack vectors are constantly being identified and we release new versions of the scanner frequently.
Do you feel that something is missing from Detectify or have general comment? Hit us up at @detectify or firstname.lastname@example.org. We are aiming to improve Detectify and make the Internet a safer place.
These days a lot of websites allow users to upload files, but many don’t know about the unknown pitfalls of letting users (potential attackers) upload files, even valid files.
What’s a valid file? Usually, a restriction would be on two parameters:
The uploaded file extension
The uploaded Content-Type.
For example, the web application could check that the extension is “jpg” and the Content-Type “image/jpeg” to make sure it’s impossible to upload malicious files. Right?
The problem is that plugins like Flash doesn’t care about extension and Content-Type. If a file is embedded using an <object> tag, it will be executed as a Flash file as long as the content of the file looks like a valid Flash file.
This basically means that if a website allows file uploads without validating the content of the file, an attacker can bypass any CSRF protection on the website.
Based on these facts we can create an attack scenario like this:
An attacker creates a malicious Flash (SWF) file
The attacker changes the file extension to JPG
The attacker uploads the file to victim.com
The attacker embeds the file on attacker.com using an
The victim visits attacker.com, loads the file as embedded with the
The attacker can now send and receive arbitrary requests to victim.com using the victims session
The attacker sends a request to victim.com and extracts the CSRF token from the response
So if you allow file uploads or printing arbitrary user data in your service, you should always verify the contents as well as sending a Content-Disposition header where applicable.
Another way to remediate issues like this is to host the uploaded files on a separate domain (like websiteusercontent.com).
But the fun doesn’t stop at file uploads! Since the only requirements of this attack is that an attacker can control the data on a location of the target domain (regardless of Content-Type), there’s more than one way to perform this attack.
One way would be to abuse a JSONP API. Usually, the attacker can control the output of a JSONP API endpoint by changing the callback parameter. However, if an attacker uses an entire Flash file as callback, we can use it just like we would use an uploaded file in this attack. A payload could look like this:
To stay on top on the latest security alerts we often spend time on bug bounties and CTF’s. When we were discussing the challenge for the weekend, Mathias got an interesting idea: What target can we use against itself?
Of course. The Google search engine!
What would be better than to scan Google for bugs other than by using the search engine itself? What kind of software tend to contain the most vulnerabilities?
Old and deprecated software
Unknown and hardly accessible software
Proprietary software that only a few people have access to
Alpha/Beta releases and otherwise new technologies (software in early stages of it’s lifetime)
For you bounty hunters, here’s a tip:
By combining one thing with another, we started Google dorking for acquisitions and products to antique systems without any noticeable amount of users.
One system caught our eyes. The Google Toolbar button gallery. We looked at each other and jokingly said “this looks vuln!”, not knowing how right we were.
Not two minutes later we noticed that the gallery provides users with the ability to customize their toolbar with new buttons. If you’re a developer, you’re also able to create your own buttons by uploading XML files containing various meta data (styling and such).
Fredrik read through the API specifications, and crafted his own button containing fishy XML entities. The plan was to conduct an XXE attack as he noticed the title and description fields were printed out when searching for the buttons.
Never the less. The file got uploaded… and behold! First try:
Second try (for verification purposes):
Boom goes the dynamite.
What you see here is the /etc/passwd and the /etc/hosts of one of Google’s production servers. Our payloads served as a proof of concept to prove the impact. We could just as well have tried to access any other file on their server, or moved on to SSRF exploitation in order to access internal systems. Too say the least, that’s pretty bad.
We contacted Google straight away while popping open some celebration beers. After 20 minutes we got a reply from Thai on the Google Security Team. They were impressed. We exchanged a few emails on the details back and forth during the coming days. In our correspondence we asked how much the vulnerability was worth. This is what we received as reply:
The bottles (or whatever it is that falls out), turned out to be worth $10.000, enough to cover a road trip through Europe.
tl;dr: We uploaded a malicious XML to one of Google’s servers. Turned out to be a major XXE issue. Google financed an awesome road trip for the team.
What is the Chrome XSS protection?
The Chrome XSS Protection (also known as XSS auditor) checks whether a script that’s about to run on a web page is also present in the request that fetched that web page. If the script is present in the request, that’s a strong indication that the web server might have been tricked into reflecting the script. So in short, it blocks reflected XSS attacks.
A couple of months ago I discovered that the Chrome XSS Protection could be bypassed in Rails. Later, when I saw the issue brought up on twitter by homakov, I figured I’d write something about it as well. Here’s how the testing went down:
First off we started with creating a dummyscript with a straight forward XSS scenario. Here’s the code:
<h1>Variable: <%= raw params[:variable] %></h1>
Let’s test it with a basic cross-site scripting payload:
GET /?variable=<script>alert(1)</script> HTTP/1.1
Oh, no! The XSS auditor blocked the attempt. Let’s try something a bit different!
GET /?variable[<script>]=*alert(1)</script> HTTP/1.1
It works! But why? Let’s have a closer look at the source code strip away everything except the <script> tag:
<script>"=>" * alert(1)</script>
The XSS auditor probably misses this because Rails doesn’t print exactly what the browser sent, making it hard to filter automatically. However, Internet Explorers XSS auditor as well as NoScript finds it.
TL;DR: Chrome’s XSS auditor can be bypassed with rails like so: ?variable[<script>]=*alert(1)</script>.
But our service is made for finding web vulnerabilities, how come we need a Disclosure program? Well. Even though our services are based around finding security bugs in web applications, we are not as naive as to think that our own applications are 100% flawless. We take security issues seriously and will respond swiftly to fix verifiable security issues. If you are the first to report a verifiable security issue, we’ll thank you with some cool stuff and a place at our hall of fame page.
So how does the reporting process work? It’s a 5 step process:
A researcher sends a mail using the correct template to email@example.com
The researcher will get an automatic response confirming that we have acquired the issue
A support case is automatically created
The person assigned to the support case responds to the researcher, verifying the issue
The issue is patched and the researcher is showered in eternal
What bugs are eligible? Any typical web security bugs such as:
Cross-site request forgery
Server-side code execution
What bugs are NOT eligible? Any typical low impact/too high complexity such as:
Missing Cookie flags on non-session cookies or 3rd party cookies
In our previous post we covered a bug released yesterday where anyone can break into a phone that is using iOS7.
We also wrote about some additional ways to trigger the bug, but all versions could be prevented by shutting off the Control Center on Lock Screen. So that’s what we, and everyoneelse suggested.
However, we have discovered that this does in fact not prevent a similar bug from exploiting the lock screen. The new way is based on the fact that Voice Control/Siri can make phone calls to known contacts, and by using the shutdown screen while calling, the double tap trick can still be done.
• Make sure the camera app is running. This can be achieved by either using the control center, or swiping the bottom right corner on the main lock screen.
• Enter the control center (swipe the bottom center on the main lock screen)
• Open the timer app, in the bottom left corner next to the flashlight app
• Hold down the power button
• Press cancel
• Between the shutdown screen and the timer app, double tap the home button and hold down the second click for around half a second
• Swipe to the camera app
If you did everything correctly, you can now access the gallery and everything inside. This includes sending mail, using twitter and sending text messages as well.
Other ways to trigger the bug
We also discovered that this bug can be triggered in some other ways. For once, the bug can be triggered not only in the timer app, but also in the calculator app. Another way is to use Siri/Voice control instead of the shut down screen. Then you could apply the same “magic double tap” between Siri/Voice control and the calculator app.
Temporary fix So what could we do to protect ourselves until Apple releases a patch for this bug?
You can shut off access to the control center while locked if you go to Settings -> Control Center -> Access on Lock ScreenRead more
Today’s updates fills the needs of many of you out there! You asked for it, and now it’s in the Detectify engine! Here’s a breakdown on the stuff we’ve put in:
Verify your domain with Google Analytics
Having trouble editing your code? Don’t want to upload files? No problem! You can now verify the ownership of your domain using your Google Analytics account. Try it out in the dashboard or in the sign up!
National Vulnerability Database
Our fingerprinting has been extended using the U.S national vulnerability database. Detectify will now try known vulnerabilities based on the versions we fingerprint from your domain. We will then warn you when there’s a security issue in the version you’re using.
Our site at detectify.com now sends a Content-Security-Policy header. Content-Security-Policy is a header for security that allows website owners to declare from what sources the users may load content from. Read more about Content Security Policy here.
Yes, we finally added support for downloading your reports as PDF files, conveniently making them accessible offline. The design of the PDF reports is still in progress and if you have any issues/suggestions, feel free to mail us about it at firstname.lastname@example.org!
HTTP Strict Transport Security, or just HSTS, is a security mechanism for websites and browsers. HSTS is used when web servers want to tell its clients that they should only use HTTPS, and not HTTP.
HSTS is initiated by the server in its Strict-Transport-Security header, which also specifies how long it will take before the HSTS header expires. After this, the website is considered non-HSTS by the browser unless another HSTS header is received.
If, for example, Alice had been using Firefox or Chrome, which both have a preloaded list of websites employing HSTS, she would have been a lot better off. (Given that the website was using HSTS and was mentioned in the preloaded HSTS list.) Everything would’ve been transferred through HTTPS. This is a nice way to prevent SSL stripping attacks. SSL stripping is a method which enables the attacker to conduct Man-In-The-Middle-Attacks unencrypted by moving the SSL “end point” from the user (Alice) to the man in the middle (Eve), while the traffic between Eve and the web server is encrypted. This way, the web server thinks everything is okay, and Alice has no idea that the traffic is supposed to be encrypted unless the web server uses HSTS. If HSTS is used, Alice’s browser knows that the traffic is supposed to be encrypted, and can therefore determine that something fishy is going on when it isn’t.
If you feel like going more in-depth, you may read RFC6797, which can be found at the IETF website or if you wish to integrate HSTS on your website, then check out this OWASP page regarding the subject.