7 biggest security news of 2017 – 10 minute mail

Cloud security, ransomware, and poor incident responses have all shaped security discussions in 2017. Another interesting year in security has gone by and although it is difficult to only pick a couple of highlights, we have put together a list of 7 security news that defined 2017.

7 Biggest Security News of 20171. WannaCry

The WannaCry ransomware attack infected thousands of computers running Microsoft Windows in over 150 countries. The NHS, Deutsche Bahn, and FedEx were among the organisations affected by the attack. Wannacry propagates using EternalBlue, an SMB exploit from the NSA hacking toolkit that had been leaked by Shadow Brokers in April 2017. This was not the only attack taking advantage of EternalBlue – about a month after WannaCry, a variant of Petya ransomware (also known as NotPetya) hit Ukraine using the same exploit. Ransomware attacks have become increasingly common in 2017 as ransomware has become a lucrative business for cybercriminals.

2. ROCA

In October, researchers disclosed a vulnerability that could potentially affect anyone with an HTTPS certificate. ROCA, a weakness in a software library used in cryptography hardware made by Infineon Technologies AG, allows an attacker to recover a valid private key. Because the hardware is widely used to generate everything from HTTPS certificates and PGP keys to  smart cards, ROCA had a considerable scope.

3. Dirty COW… again

The Dirty COW exploit was big news in 2016, but the story did not end there. This year, a new malware called ZNIU emerged. ZNIU spreads via infected apps, exploiting the Dirty COW vulnerability to gain root access to Android devices. To top it all off, the Dirty COW patch that was released last year turned out to be flawed, making it possible for an attacker to exploit a race condition and gain write-access to read-only memory. The vulnerability put several Linux distributions at risk, but had a considerably smaller scope than last year’s Dirty COW exploit as it does not affect Android. The moral of the story? Using unpatched software is risky, patches can be vulnerable and security flaws can make an unexpected comeback.

4. S3 bucket misconfigurations

Misconfigured AWS S3 buckets were this summer’s security hot topic. Companies like Dow Jones, ABC, Time Warner and Verizon made the headlines after unintentionally exposing their buckets. We wrote about S3 bucket misconfigurations and did research on how they can be exploited. Since then, Amazon has added new security features and worked to inform AWS users about the risks associated with bucket misconfigurations. Although AWS was in the spotlight this year, cloud misconfigurations in general are not uncommon as cloud security is still a relatively new frontier.

5. Equifax

If there is one security incident that sticks out in terms of scope and publicity this year, it’s the Equifax breach. Personal data belonging to millions of people was exposed, and one of the elements leading to the breach was a vulnerability in Apache Struts (CVE-2017-5638). As a patch for the flaw had been released two months before Equifax was breached, the company’s security routines were called into question. To make things worse, Equifax did not notify the public of the data exposure straightaway, and proceeded to send affected customers to a fake campaign website.

6. Uber

Equifax was not the only company dealing with security issues in a less than optimal way. In autumn 2017, news broke that Uber had paid a hacker $100,000 to conceal a serious security breach that took place in 2016. Uber issued a statement and confirmed that two security officials involved in the incident had resigned, but it remains to be seen how – and if – the company regains consumers’ trust.

7. Google Chrome implemented the “Not Secure” warning

2017 was not all about ransomware, misconfigurations, and companies not taking responsibility for their security shortcomings, it was also a year of increased security awareness. In January, Google Chrome rolled out the “Not secure” warning that flags  websites that do not use https and contain login forms or credit card input fields, while Mozilla announced a similar warning would be implemented in Firefox. The warnings do not only help website visitors become more aware of security risks, they also guide developers as they make their own websites more secure. Hurray for a safer internet!

What’s 2018 going to bring?

What can we expect in security news in the coming year? With the increasing popularity of cryptocurrency, we will probably see a growing number of leaking wallets. We might also encounter more NSA leaks similar to those published by Shadow Brokers, followed by sophisticated exploits based on the leaked hacking tools.

As gadgets like Amazon Echo enter consumers’ homes, it would not be surprising to see attacks targeting smart home devices. Same as last year, we believe the trend of exploits with catchy names will continue. 2017 definitely lived up to this prediction with names like KRACK, WannaCRY, CloudBleed, and EternalBlue. This year, we didn’t see any major DDoS attacks like the DYN attack of 2016, but unfortunately, this does not mean DDoS is not a threat anymore.

But don’t worry, things are moving in the right direction! Developers and internet users are becoming more aware of security issues and potential threats. As governments implement measures like the GDPR to protect private data, we hope that organisations look at this year’s cautionary tales and begin to secure their websites. After Equifax, Uber, Yahoo, and many more, dealing with security breaches in a timely and transparent manner is more important than ever before. Let’s make 2018 the year of awesome security! 

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

Cloud security basics: 9 security issues to address as you move to cloud services – 10 minute mail

The scalability advantage of cloud computing can only be sustained with the application of cloud security basics. A cloud service provider takes care of the physical security of their data centres, while the organization storing data up there needs to take responsibility for their own cloud security configurations. Cloud providers are addressing concerns with added security features, yet we continue to see data in the cloud compromised due to misconfigured settings. This tells us just how widespread the issue has become since reporting on this last year. We’ve highlighted this and 8 others cloud security basics every cloud users should know:

1) Data Breaches and misconfigured cloud storage:

What can we learn from recent S3 bucket leaks? Misconfigurations are common, they happen and they can be fixed easily. If we don’t fix it, that’s when disasters occur. Many instances were due to misconfiguration or weak configuration of the access control list. Whether you’re managing Amazon S3 buckets, Azure blobs or Google cloud storage, it’s something that the organizations must take ownership over to safeguard sensitive information stored in cloud storage units. By doing so, you can make sure the right people have the right credentials to access to keep out malicious hackers and any other unauthorized users including third party vendors.

2) Check for forgotten subdomains:

Subdomains can be taken over by a hacker with the help of external services. In 2014, the Disposable mail security researcher team discovered a serious attack vector which allowed one to take control over a subdomain due to DNS misconfigurations, and in a manner that is not noticeable to the domain owner. Thanks to this research, we automated tests to check for this called Asset Monitoring. If you are not using our scanner, you can still remediate this manually by looking through all DNS-entries and removing all entries which are active and unused OR pointing to external cloud-based services which you do not use anymore.

3) Weak Identity, Credential and Access Management:

Using Two Factor Authentication, password or identity controls and proper employee off-boarding are simple measures to take to ensure information doesn’t fall into the wrong hands. Not only are strong password protocols encouraged, but it is also important to encrypt the information traffic flowing by implementing SSL/TLS certificates and setting secure email protocols like SPF- and DMARC-records. When an employee leaves a company, their access accounts should be deactivated immediately to ensure they’re not forgotten and vulnerable.

4) Broken authentication:

It’s critical that a user should not be able to execute functions they are not authorized to do on cloud services. An example of this would be denying an unauthenticated person from uploading files into a “protected” cloud storage bucket. This is defined by an upload policy with a set of requirements and unfortunately, these are at risk for weak controls as shown in Frans Rosén’s research, Bypassing and exploiting Bucket Upload Policies and Signed URLs. It is recommended that an upload policy should be created specifically for every file-upload request or per user.

5) Check that user details and API keys are not left out in the open:

With sharing comes responsibility that you’re not sharing too much. Several high-profile companies including UBER and Slack have learned the hard way unfortunately as they accidentally uploaded code onto Github without attention to the details of sensitive user information. The ubiquitous use of GitHub and other open source coding platforms benefits the developer community with knowledge and best practice sharing. However security still applies here and code that is uploaded, especially legacy code, should be checked that no sensitive information like passwords, user tokens or API keys are exposed. Default settings should not be relied on either as they’re often set to ‘public’.

6) Logging and Monitoring:

Good practices around logging and monitoring activity on the server are essential to keep on eye on the cloud security status. With sufficient logging and monitoring practices you may become better aware of any malicious activity and can answer the questions, “are we even interesting enough to hack?” However collecting information here is not enough, immediate action is also required to ensure any substantial risk to the cloud is mitigated as soon as possible.

7) Continuous monitoring of common vulnerabilities and patch them:

Injection is listed on the OWASP Top 10 vulnerabilities list and for good reason. Cloud services can be exploited with injection attacks. If you’ve migrated to cloud, it’s especially needed to check the security status in legacy code. SQL injection is a prevalent modern vulnerability and when detected it should be patched without hesitation. It can easily be automated which makes the risk even higher. Conveniently, they are detected easily with an automated scanner. This concerns vulnerabilities including XML External Entity (XXE) and Server-Side Request Forgery (SSRF).

8) Always update your technology:

Using the latest version of technology is crucial for security. Often patches are released with bug fixes but not everyone feels the urgency to install them, leaving applications vulnerable.  “jQuery is a good example of this where multiple outdated versions of this framework are used despite all their known vulnerabilities,” Disposable mail CIO Johan Norrman explains about lack of updating, “someone has even developed a website to make the information readily available.”

photo of Disposable mail CIO Johan NorrmanDisposable mail CIO Johan Norrman sees a lack of updating tools to be a security concern.

9) Due diligence and cleaning up superfluous tools:

Even if you cover the cloud security basics you may still be at risk for a breach, which means doing your due diligence on the incident response routine is needed. You can stay prepared by rehearsing the contingency steps, test your recovery and make sure the backups work. When auditing your toolbox, apply the use it or lose it rule. This eliminates the need for keeping unused tool updated or left as a preventable risk. As the CSA states, “this applies whether the company is considering moving to the cloud or merging with or acquiring a company that has moved to the cloud or is considering doing so.” They published a list of cloud security risks, the Treacherous 12, last year.

How can Disposable mail help?

With a tool like Disposable mail, you can continually monitor your web apps with a scanner that is updated with security tests at least bi-weekly to keep up with the fast rate which web vulnerabilities could be found. We are a SaaS-service, hosted in the cloud, which means you can scan your web applications without downloading any software. We test for OWASP Top 10 versions 2013 and 2017, AWS S3 Bucket misconfiguration and various key disclosure vulnerabilities. We also offer Asset Monitoring to help identify potential vulnerabilities related to DNS misconfigurations. Our services are hosted on AWS and we are also recognized as a preferred technology partner of AWS, and offer a connector to Route 53 so you import information from your DNS directly for monitoring.

How does it work? The moment you log into the tool, you’ll be running the most updated version. We start up a server on AWS to scan your web applications and once that’s done, we report findings to you and then the server is killed. None of your web application data is stored by us on AWS. It’s the beauty of the cloud.

Are you ready to try out Disposable mail with your cloud services? Sign up for an account and scan with a free trial here.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

9 biggest web security news of 2018 – 10 minute mail

The year started off with a bang as the research of Meltdown and Spectre rendered almost all computing devices to be vulnerable. As the year moved on Facebook, Magecart and 2FA alternatives also were also part of security discussions. Here are our top 9 picks for biggest web security news of 2018:

Image for top security news for 2018

1. Meltdown and Spectre

Meltdown and Spectre are collectively 3 critical vulnerabilities had anyone with a computer made since 1995 on their feet. Meltdown (CVE-2017-5754) is a hardware vulnerability found to attack general memory data security and the name was given due to the ability of the attack to “melt” security boundaries. Spectre (CVE-2017-5753 and CVE-2017-5715) is reported to affect every single computer device, as it’s been verified that they affect Intel, AMD, and ARM processors. Their exploitation allows hackers to access passwords stored in a password manager or browser, personal photos, emails, private messages and even business-critical documents.

2. Facebook – “View As” feature

Facebook has been in the public eyes on several big occasions this year including the Cambridge Analytica scandal and Mark Zuckerberg’s testimony in front of the US Congress about data privacy. The year wouldn’t be complete without a hacker attack. Late September, 50 million people were automatically logged out of their Facebook accounts due to a hacker attack via the “View As” feature. The hackers began by exploiting the video uploading feature and eventually chained this together with a weakness in the “View As” feature. During this process a user token was generated when it wasn’t intended to happen for the one subject to “view as” and this appeared in the HTML code. From there the hackers gained access to the user account and automated their attack which eventually resulted in an activity spike to catch Facebook’s attention and take action in time. In total, there were 3 bugs that the malicious actors were able to chain together to gain access to user tokens. When Facebook was aware of this, it forced log out to reset tokens for 50 million users and an additional 40 million who were potentially affected. Whilst Facebook’s logging and monitoring practices were able to act fast and alert users well, the company seems to not want to take more security risks as there are plans to add a cybersecurity company to their group.

3. Marriott – 500 million users had data stolen.. Hackers had access since 2014

Going down as one of the largest data breaches to happen so far, 500 million Starwood guests had their personal details such as names, addresses, passport information and emails compromised to malicious hackers. Reports state hackers were in the system back in 2014 which happened before Marriott acquired the Starwood Hotel brand in 2016, and this has angered many security experts and people in general knowing that SPG aware of the issue and it was failed to be addressed during the acquisition. The personal information taken was encrypted however given 4 years time, one could be certain that the hackers were able to decrypt the details. It’s not certain whether Marriott was aware of this or not but we can expect cybersecurity to be taken more seriously in future business acquisitions.

  4. Another year of leaky S3 buckets, which led to AWS finally changing the privacy settings for bucket configurations

As in 2017, this year saw several high-profile companies fall victim to customer data leak to cloud storage, especially S3 bucket, misconfigurations including FedEx and GoDaddy. These are often the fault of the company due to AWS S3 bucket misconfigurations but we even saw a case where an AWS employee made the mistake of S3 bucket misconfiguration for GoDaddy. The consequence: public exposure of highly sensitive information including GoDaddy’s hosting infrastructure, operating system, workload and more which gave out a lot of competitive intelligence. This finally prompted AWS to make changes to the bucket settings and make it easier for users to block public access to buckets.

5. Implementation of GDPR and Google and Facebook slapped with fines

2018 also was the year for GDPR to come into play and this has all sorts of professionals scrambling to make sure their practices are compliant, lawyers were banking in on new business, some opportunists upgraded their careers to becoming a DPO and end users were bombarded with emails regarding GDPR, all before May 25th. There was no grace period to GDPR enforcement as Google and Facebook were given fines immediately. Not only did GDPR get ordinary people to start thinking a bit more on the privacy of their personal details, but it has challenged companies to work more proactively with security.

6. Magecart and third-party javascript

Magecart, an online criminal hacker group, has been using cross-site scripting (XSS) tactics to injection malicious code into different online credit card forms. By doing so they’ve been able to steal sensitive information including, yes of course, credit card details and personal names. This method is used widely and companies compromised by this attack are many and include British Airways and Inbenta, a 3rd party javascript used by Ticketmaster. This serves as a good reminder to always check web applications for XSS and especially third-party software as Magecart does not show signs of stopping.

7. SMS 2FA not secure

Reddit was hacked in June and their employee accounts were compromised despite having 2FA via SMS enabled. As their report explains, the attacker was able to intercept SMS messages containing the access code and use this to log into the employee accounts. This prompted a great discussion on what kind of 2FA is needed. Reddit themselves suggest using a token-based 2FA as well as ensuring passwords are complicated. You can find these tips and more in our tips for secure remote work.

8. Drupalgeddon

There was a remote code execution found in Drupal, and this critical vulnerability was aptly named Drupalgeddon v2.0. This affects versions between 6 and 8, and if exploited the bad actor would have access to all non-public data and also have the ability to modify or delete items. According to official notes, updating Drupal along will not remove backdoors or fix compromised sites. Therefore anyone affected would have to update right away but also run their own security checks to remediate the issue.

9. Stop playing security whack-a-mole

Parisa Tabriz, Director of Engineering at Google, opened up this year’s Black Hat USA calling on everyone to implement long-term defensive security. Rather than playing what she called security whack-a-mole and tackling security issues as they come up, there needs to be more strategic and proactive action to ensure security in a company. She cited the Google Project Zero as one way they’ve used offensive security examples to improve defensive security tactics, leading to more transparency and collaboration to make end users safer. Companies should build ongoing security processes and invest in training, build up security champions and develop a security culture in the organization. Some argue it needs to be thought of earlier in the development cycle, given more support for the adoption of DevSecOps.

What can we expect next year? We asked our security researcher and technical content writer, Linus Särud:

In 2019, we can expect more cloud-related issues on the rise as well as misconfigurations with third-party providers. They may not necessarily be from S3 bucket leaks due to the changes, but could be of similar nature.

Serverless, microservices and API are the “new thing” and we can expect acceleration in migration over to these services. As a consequence we anticipate more SSRF attacks. When companies go serverless and the traditional RCE is no longer possible, SSRF takes its place. It can be used to request internal servers and steal tokens or credentials used for cloud configurations. Early 2018, Google was vulnerable against this. Here is another write-up on how SSRF can be a problem when running on Amazon, causing the cloud to rain credentials.

Lastly, we expect more subdomain takeovers to occur and while this has been hyped for long there will be a lot to be discovered in this area. On the positive side, we anticipate more awareness of cloud security risks and the continued rise of devsecops where security is considered earlier in the development cycle and companies apply proactive defence instead of reactive measures, enabled by more automation and testing. There will more open discussions about personal data management because of the GDPR, NIS directive and other security regulations. People will start to think differently about the security of personal information, in a more protective way, which is a good thing!

Here’s to an even more secure 2019! Is your team equipped with all the tools to make 2019 a secure year for your teams? You can automate some of your security checks using Disposable mail. Ready to give us a try? Sign up for a free trial.


Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

What is server side request forgery (SSRF)? – 10 minute mail

Server Side Request Forgery (SSRF) is a type of attack that can be carried out to compromise a server. The exploitation of a SSRF vulnerability enables attackers to send requests made by the web application, often targeting internal systems behind a firewall. Sometimes a server needs to make URL-request based on user input. A clear example would be an import-function, where you can import images from a URL, perhaps when setting a profile picture. When you as a user enter a URL, the server will make a request to that URL and fetch the image. 

Server-side request forgery

Interesting things happen when this function can be used to make request to internal services, for example, local IP-addresses (RFC1918) which are not publicly accessible from the internet.   If the URL given by the user is not an image, the error page will often show the response of the requested URL. That makes it easier to exploit, but is not a requirement. You can no longer request information from internal systems, but can still make internal API-calls. Imagine the following PHP code:

//getimage.php

$content = file_get_contents($_GET['url']);

file_put_contents(‘image.jpg’, $content);

The above code will fetch data from a URL using PHP’s file_get_contents() function and then save it to the disk. A legitime request would then look like:

GET  /getimage.php?url=https://website.com/images/cat.jpg

And the web application would make a request to https://website.com/images/cat.jpg. This code could be exploited with SSRF. Such an attack could look something like:

GET  /getimage.php?url=http://127.0.0.1/api/v1/getuser/id/1

In this case the vulnerable web application would make a GET request to the internal REST API service, trying to access the /api/v1/getuser/id/1 endpoint. This REST API service is only accessible on the local network, but due to a SSRF vulnerability it was possible for the attacker to make such an internal request and read that response.   Sometimes you can make a request to an external server, and the request itself may contain sensitive headers. One of many examples would be HTTP basic passwords, if a proxy has been used. SSRF can therefore be carried out to both internal and external services. The vulnerability often occurs when you are supposed to be able to make requests to a certain domain, but are able to bypass the parser/filter. A security researcher known as Orange Tsai spoke about this previously at Black Hat 2017. Not to be forgotten, sometimes it is possible to use other schemes and protocols in a SSRF attack other than HTTP. Examples of these are file://, phar://, gopher://, data://and dict://

Traditional setup

It is common to have a proper firewall/routing rules for external applications, but normally nothing inside the network. That means that an attacker is able to make a device already on the network send the requests, there are no security restrictions to care about for internal systems.

Cloud services

Due to microservices and serverless platforms, SSRF will probably be a bigger thing in the future. Making internal requests now means that you can interact with other parts of the service, pretending to be the actual service. Get familiar with cloud security basics including SSRF as we are already seeing examples of how a SSRF vulnerability more or less leads to RCE in companies running on modern technologies. Examples: $36k Google App Engine RCE SSRF reports on hackerone If you are using a service such as AWS or Google Cloud, it is often possible to request sensitive tokens/credentials through some API. Metadata in AWS, Google Cloud, and others: https://gist.github.com/jhaddix/78cece26c91c6263653f31ba453e273b

There is no universal protection against SSRF attacks, however there are a few things to have in mind:

  • A blacklist is not a good protection because with so many different protocols, schemes, encodings and super complex URI syntax, bypasses will most certainly occur. Because of this, a whitelist is a better approach.
  • When developing REST API’s, it is better to accept other HTTP verbs than POST and GET which will make it harder for a SSRF vulnerability to make correct requests to the API service. If a SSRF vulnerability is only able to make internal GET requests it won’t be able to speak with the API. It is also important to validate both the request and response to internal services.
  • Services such as Kibana, Redis, Elasticsearch, MongoDB and Memcached do not per default require authentication, and adding that to those services may make it harder to exploit a SSRF vulnerability.  

The most common way for Disposable mail to detect this kind of vulnerability is by using Out-of-Band-Exploitation. For each test we generate a unique string, which we then try to send a request to as part of the domain name. For a specific test we might generate foobar. We then make a request to the server including foobar.poem.detectify.com. If the nameserver for that subdomain then get a lookup-request for foobar we know that the server has tried to send a request to it, even if we were unable to read the response. For specific tests we may have other solutions in place. 

Start your Disposable mail free trial today.

Additional reading:

SSRF definition on OWASP.org

MITRE: CWE-918: Server-Side Request Forgery (SSRF)


Written by: Kristian Bremberg Linus Särud Disposable mail is automated web application scanner checking for 1000+ known vulnerabilities including OWASP Top 10 and SSRF. Start your Disposable mail free trial today to see whether your applications are vulnerability to SSRF and more.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.