Posts

5 tips for better cloud security

This blog post is a summary of this weeks Information Security News put together by our Security Incident Response Team (SIRT). Read more

Security is Not a One-Person Job

Security is not a one-person job. It can’t be accomplished with one person, it can’t be accomplished with one company.

“Security is not a one-person job. It can’t be accomplished with one person, it can’t be accomplished with one company,” says Walls. “So we need partners, and we need friends in the industry to work together.” No statement could better summarize what building a culture of security looks like. Learn more about how Walls and Prime Therapeutics implemented DLP to protect highly sensitive data for millions of people.

Read more..

 

Top 5 Security links

 

Malware is so 2017: five new security trends to watch out for

Outbreaks such as Petya and WannaCry really put the malware threat on the IT agenda and made cybersecurity a priority for everyone. Fredrik Svantes, Senior Information Security Manager at Basefarm, explains the latest developments that keep the cybersecurity community busy.

We wrote tests for our third-party security libraries, and you won’t believe what happened next! (CVE-2017-8028)

On the importance of thorough testing

Much of modern software development revolves around the concept of “quality”. As with all abstract concepts, “quality” is somewhat difficult to pin down, but for this article we can define it as “how well software conforms to its requirements”. Less formally, we can say that “high-quality software does what it’s supposed to”.

One way to ensure that you consistently deliver high-quality software is to have automated tests. I’m not a Test-Driven Development fundamentalist insisting on 100% test coverage; but if some part of your software is important to your users, there should be at least one automated test demonstrating that it works. This is obviously true for your software’s functional requirements, but it applies equally to its non-functional requirements such as auditing and performance.

So what non-functional requirements are important to the users of Basefarm’s internally-developed applications?
One thing that immediately springs to (at least my) mind is security. So we need some tests for that, right?

Think like a hacker

When developing secure applications, it is always useful to try to think like an attacker. If I were to try to get unauthorized access to this application, how would I go about it?

Obviously, you’d first need to log in. For Basefarm’s internal applications we use username/password logins authenticating against our internal LDAP server; this means that an attacker must obtain a set of working credentials somehow.

This suggests three tests:

  1. An existing user can log in with the correct password (this is what we call the happy-path test, which demonstrates that in fair weather conditions the software works as intended);
  2. A non-existent user is not allowed access;
  3. An existing user logging in with an incorrect password is not allowed access

As part of these tests, it is also useful to think about things like auditing and information leakage; login attempts — successful or not — should be logged, and the error message(s) presented on failure should not give an attacker information she does not already have. In particular, authentication failures should not say “no such user” or “incorrect password”; “Invalid credentials” is a safe, neutral way to put it.

So, in pseudo-code, we have the following tests:

authenticate("existinguser", "correctpassword") must succeed

authenticate("nonexistentuser", "anypassword") must fail

authenticate("existinguser", "wrongpassword") must fail

Don’t reinvent the wheel

The developers at Basefarm, as in most other places, don’t have the time (or, to be honest, the expertise) to write everything from scratch. It is hard enough to implement our specific functionality; implementing and maintaining code to talk to databases and LDAP, handle authentication and transactions and all the other things a large-scale (dare I say Enterprise?) application needs would be impossible. So like many other teams on the JVM platform we lean heavily on the Spring framework and its attendant ecosystem of libraries; in particular, we use Spring Security for authentication and authorization.

Setting the scene

Since our LDAP server (as all good LDAP servers should) requires authentication and encrypted communication using STARTTLS, our Spring Security configuration looks something like this (ignoring some details on how, exactly, things are wired together):

<bean id="tlsAuthStrategy" 
      class="org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy" />

<ldap:context-source 
  url="ldap://monkeymachine:389/dc=springframework,dc=org" 
  username="cn=Manager,dc=springframework,dc=org" password="secret" 
  authentication-strategy-ref="tlsAuthStrategy" />

<security:authentication-manager>
  <security:ldap-authentication-provider 
    user-search-base="ou=People,dc=springframework,dc=org" 
    user-search-filter="(uid={0})" />
</security:authentication-manager>   

The idea is that the security framework, authenticating with the manager credentials, searches for a user to really authenticate as.

We believe this to be a fairly typical LDAP-auth setup; in fact, the actual configuration is more or less copy-pasted from the Spring Security documentation.

We originally implemented this in 2011; and the configuration worked well, all the tests passed, and we were happy.

Let’s dance!

Fast-forward six years, to 2017. As part of our regular maintenance cycle, I went through all of our application’s dependencies and updated them to the latest version, to get the benefit of whatever new features and fixes are available.

This is usually a cushy job: Update some version numbers; recompile everything; drink coffee while the tests pass; and then ship it.

So I upgrade Spring Security to 4.2.1, and start the test run.

Imagine my surprise when I returned from my coffee binge to see

Tests failed: 1

Waltz Tango Foxtrot?

And the test that failed?

authenticate("existinguser", "wrongpassword") must fail

Whisky Tequila Fernet? In short, WTF???

Finding the problem

I’ll spare you the details of how we debugged the issue; it’s not really interesting, involving as it did copious amounts of coffee, creative swearing, scratching of heads, wailing and gnashing of teeth, and poring over code, logs and packet captures.

It turned out that the problem was not in Spring Security per se, but in Spring LDAP; a change in Spring Security’s use of that library exposed a weakness in DefaultTlsDirContextAuthenticationStrategy, which never actually performs an LDAP “bind” operation using the provided credentials.

The desired sequence of events when authenticating in our setup is something like this:

  1. Open a new LDAP connection
  2. Secure it using STARTTLS
  3. Bind with the search credentials (username/password from the context-source)
  4. Perform an LDAP search for the DN to bind as for the real authentication step
  5. Open another new LDAP connection
  6. Secure it using STARTTLS
  7. Bind using the DN from step 4 and the provided password

The logs from the LDAP server show what really happens (I’ve removed some entries from the log; the full log can be seen here):

-- step 1
59ceb606 conn=1000 fd=15 ACCEPT from IP=172.17.0.1:33378 (IP=0.0.0.0:389)
-- step 2
59ceb606 conn=1000 op=0 STARTTLS
-- step 3
59ceb606 conn=1000 op=1 BIND dn="cn=admin,dc=example,dc=org" mech=SIMPLE ssf=0
-- step 4
59ceb606 conn=1000 op=2 SRCH base="ou=People,dc=example,dc=org" scope=2 deref=3 filter="(cn=user)"
59ceb606 conn=1000 fd=15 closed
-- step 5
59ceb606 conn=1001 fd=15 ACCEPT from IP=172.17.0.1:33380 (IP=0.0.0.0:389)
-- step 6
59ceb606 conn=1001 op=0 STARTTLS
59ceb606 conn=1001 fd=15 closed (connection lost)

Step 7 never happens; as long as you have a username, all passwords are accepted.

Further investigation showed that this had been noticed as far back as 2013 by one mwebb and reported as a bug in November 2016, but not recognized as a security issue.

We had also noticed it before, earlier in 2017, but due to time pressures we did not properly investigate the issue at that time.

Houston, you may want to look at this

The Spring Framework is currently maintained by Pivotal Software, Inc., so we notified their security team of the problem. They, in turn, notified the maintainers of Spring LDAP, who initially concluded that this is not a bug because anonymous LDAP access was involved, as it was in the original example project exhibiting the bug.

However, a slight modification of the example project showed that the erroneous behaviour persists even when anonymous bind is not used; it is clear from the log that there is no bind attempt with the user credentials at all.

After a little back and forth, the Spring LDAP team released a fixed version of Spring LDAP on October 6, 2017, nearly a year after the initial bug report.

Timeline

2016-11-11 (approximately)
Tobias Schneider discovers the issue
2016-11-18
Schneider reports the bug to Spring LDAP, with a pull request
2017-01-11
We initially notice the issue, but due to time pressures do not investigate and roll back to an earlier version
2017-08-10
We attempt to upgrade again; again, we roll back to the earlier, working version, but this time (probably due to higher blood caffeine levels) a full investigation is scheduled
2017-09-26
We isolate the problem and discover the earlier bug report
2017-09-28
We notify Pivotal’s security team that we consider this a security vulnerability
2017-09-29
The Spring LDAP team determines that this is not a vulnerability
We demonstrate that the issue exists without involving anonymous search
2017-10-06
The Spring LDAP team commits a fix and releases a working version
2017-10-11
We request a CVE via Dell EMC and Pivotal
2017-10-16
Pivotal publishes CVE-2017-8028

The moral of the story (a.k.a TL;DR)

  • Security is an important part of your application; write tests for it
  • All non-trivial software has bugs, and some of these will be security-related
  • Report security issues to the security contact for the involved software

Star Wars – Good versus Evil

In fairy tales good always triumphs over evil. In real life that is not always the case. To remedy this, we have seen a change in how businesses work on security

In stories like The Lord of the Rings, Cinderella, and Star Wars, good always triumphs over evil. In real life, however, that is not always the case. To remedy this, we have seen a change in how businesses work on security. More and more companies receive aid from the good White Hat Hackers to fight the evil Black Hat Hackers. By utilizing Bug Bounty programs, companies can receive assistance from ethical hackers. Instead of receiving the princess and half the kingdom, hackers who manage to identify vulnerabilities, receive a great reward through the Bug Bounty program.

A Frightening Menace from the Dark Side

Hacker attacks have become more frequent, and more creative. Every day, you hear about it in the media. The demand for security expertise is steadily increasing, and the number of suppliers can’t keep up, both in Sweden and internationally. This has made it ever more important for businesses to use alternative ways of finding the expertise that they need from skilled security experts.

Basefarm’s partner Detectify knows this, and has launched a new platform, Detectify Crowdsource. On this platform, they can invite independent White Hat Hackers (people who hack with good intentions) from all over the world. The initiative was inspired by the Bug Bounty programs, where companies give ethical hackers an opportunity to help them to identify holes in their website’s security. This is a way of enhancing their own security team by using freelancing security experts and rewarding them for their discoveries. The hacker world is global, and everyone has their own specialty, for example web applications, mobile applications, IOT & firmware, API, network application, and network infrastructure.

The Light Side of the Force Musters for Battle and Strikes Back

”Detectify Crowdsource helps us in accessing the best security expertise and thus enhances our tools”, says Carl Svantesson, CMO at Detectify. ”In practice, it means that our register of identified ”vulnerabilities” in various programs and technologies becomes wider and can cover niche areas.”

Through their platform, Detectify receives ongoing reports about the latest vulnerabilities that are discovered by the invited hackers. The vulnerabilities are then built into the tool by the Detectify security team, after a thorough review. For the clients of Basefarm, it means an even more reliable security scan – Vulnerability Assessment, a solution from Detectify, and offered by Basefarm.

May the Force Be With You – Test Your Applications!

Today, it’s not just the tech companies that utilize Bug Bounty programs. The programs are also used by companies in retail, the motor industry, and in banking and finance. It is primarily companies that are especially exposed that choose to start their own Bug Bounty programs, for example through the use of platforms like Bugcrowd. They do this to test their applications and to gain access to expertise and creativity from thousands of ethical hackers.

Five steps towards an increased application security:

  1. Determine the applications that need to be tested for vulnerabilities.
  2. Start work by using an automated vulnerability tool. This is good enough for most companies. If you are a Basefarm or Detectify.com client, you can use Basefarm’s Vulnerability Assessment tool.
  3. Add a manual layer by engaging the hacker world in a Bug Bounty program. This is especially important if your company is exposed to hacker attacks.
  4. Always act quickly when you have identified bugs or vulnerabilities. You can do this by using an automated tool and with a Bug Bounty program. This will enable your team to have the information as soon as a bug is discovered.
  5. Work continuously on security.

About Detectify

Aiming to offer a simple and automated security solution, Detectify was founded by the world’s best White Hat Hackers in 2013. Their solution has already been named Symantec’s Security Expert of the Future and they were also included in Europe’s hottest startups 2016 by Wired. One of the founders, Frans Rosén, came in second place in “HackRead’s 10 Famous Bug Bounty Hunters of All Time”.

Recent weeks spam\malware trends; refunds or delay complaints

Greetings good people!

I wanted to share with you the latest trends of spam and\or malware I see coming in to Basefarm this last week. Thanks to everyone who is spamming me making this possible. 🙂

The latest trend is sending a mail with very little detail, complaining about a delay in shipping, lacking tracking information, anything really. And then attaching a .doc file with a simple name like “order-confirmation.doc” or “invoice.doc”.

We, as good people, want people to be happy with our service, so we get a little worried that there has been something we have missed and rush to open the .doc-file to see how we can correct this misunderstanding. The .doc file is loaded with a bunch of macros, and upon opening it downloads whatever malware recently paid the last bid to the spammer. Mostly I have seen botnet installs, and no more crypto-software so far, but this can be changed on the fly by the malware authors.

The purpose of the botnet-infection is the traditional proxying of malicious mail or web traffic, participating in DDOS or to the more modern mining of crypto currency. Also have in mind that it is not uncommon for them to exfiltrate any address books, stored passwords and passwords typed during the infection.

Unfortunately, having an up-to-date antivirus is not enough these days, so to keep yourself from enjoying a borrowed computer from Internal-IT while yours is getting reinstalled and you changing all the passwords you have in fear it might be captured, slow down and think about what files you are opening. Being more security aware is the best solution to this challenge.

As always, if you are not sure about something, talk to your closest internal-IT or SIRT person about your concerns. It is much easier to handle this while it is still in your inbox.

Demand for Information Security skills keep rising

A few days ago, InterQuest released an interesting report on how they are seeing the demand for skills in information security keep rising and rising.

They’ve predicted that for 2015, there will be an increasing demand for the development of the information security profession on a political, economic and organisational level. InterQuest are also noting that the security industry must change its model from being reactive to threats, to being proactive about developing to meet the security demands of organisations today.

InterQuest goes on to give an example of their own growth after putting resources into a security division of their company;
“Just over two years ago, InterQuest established a small information security recruitment division aimed at helping users of our specialist recruitment practices – analytics, digital and web technologies – connect with talent to support their information security requirements. This once small division has grown and been the source of significant investment by the Group, as it responds to the upswing in demand and professionally represents candidates in a market largely misunderstood by more generic recruiters.”

With the latest breaches that has happened, it’s no surprise that “Network and Information Security” is now on top 7 on sought after skills, and is set to climb higher and higher;
“The string of high profile breaches confirms that the information security industry has a significant task on its hands, a task which has become mission critical for many organisations and a source of growing urgency.
The information security industry has evolved predominantly in reaction to threats rather than proactively developing the profession leading to a generational gap. The Information Systems Securities Association (ISSA) estimates there are between 300,000 and 1,000,000 vacant cyber security positions. Further, LinkedIn recently released a list of the 25 most in demand skills. The list is based on hiring and recruiting activity, analysing the skills and experience data of over 330 million LinkedIn member profiles. “Network and information security” skills are 7th on the UK list and set to soar higher as demand increases further.”

The full story can be found at http://www.interquestgroup.com/corporate/blog/information-security-the-impact-of-the-breach-in-skills.

Databases stolen with SQL Injection attacks and how to avoid them

Multiple Swedish websites have had the misfortune of being the target of SQL Injection attacks. For example, techworld.se wrote this monday an article about Allabolag who, unfortunately, got to experience SQL Injection attacks.

SQL Injections are possible due to mistakes done when coding an application,
and means that and as a result sensitive information from databases could be stolen.

How do you avoid attacks?

You should make sure your website cannot be the target of a SQL injection, as that can, amongst other things, read sensitive data from the database and in some cases issue commands to the operating system. Because of this, it’s highly recommended to review and test your code before publishing it online. While this may seem daunting at first, you’ll see that it does not take that much effort once you’ve read up on it and know what to look for. The two easiest ways to mitigate SQL injection attacks are Parameterized queries using bound, typed parameters and Careful use of parameterized stored procedures.

It is also advised to place a WAF, Web Application Firewall, in front as this will assist in blocking harmful attack attempts towards your website. A WAF will assist in protecting your website against SQL Injections, but it can also give you multiple other features such as being able to block known exploits, as previously mentioned in our Christmas Calendar for 2014.

Webshops responsible for security payments

Last November, the PCI Security Council introduced the third version of the Payment Card Industry Data Security Standard (PCI DSS 3.0). For the first time, the edition offers clarity about the responsibility of companies processing, storing, or transmitting data of credit card holders.

Last November, the PCI Security Council introduced the third version of the Payment Card Industry Data Security Standard (PCI DSS 3.0). For the first time, the edition offers clarity about the responsibility of companies processing, storing, or transmitting data of credit card holders. Especially for webshops that ‘redirect’ this can have a big impact.

The PCI Security Council was established by Visa, MasterCard, American Express, Discover, and JCB in 2006 to increase the security of internet payments and to prevent fraud. The fact that this topic is still important, became painfully obvious recently. The Irish marketing company Loyaltybuild was victim of a cyber-attack in which the credit card data of at least 376,000 customers were stolen. Besides the fact that this damaged the reputation of Loyaltybuild significantly and created massive turmoil among cardholders, this could also mean considerable financial loss to the credit card companies. After all, they are held responsible for payments made with stolen data.

It is, therefore, understandable that the credit card companies are increasingly stringent towards everyone that has access to areas where cardholder data is processed, stored or transmitted. These days, there are more and more access points to this data, such as via e-commerce, mobile platforms and cloud computing. With PCI DSS the credit card companies set the conditions – including mandatory certification and annual audits – to organizations that come into contact with data. PCI DSS can be summarized in six objectives, which again can be divided into twelve specific requirements.

Build and manage a secure network

  • Install and maintain a firewall to protect cardholders’ data
  • Don’t use default passwords and other security perimeters

Protect cardholders’ data

  • Protect stored cardholders’ data
  • Encrypt the transfer of cardholders’ data over open public networks

Take care of a vulnerability management program

  • Use up-to-date antivirus software on all systems that are exposed to malware
  • Develop and maintain secure systems and applications

Implement good access control

  • Limit access to cardholders’ data to ‘need to know’
  • Appoint an unique ID to everyone who has access to a computer
  • Limit physical access to cardholders’ data

Frequently monitor and test networks

  • Follow and monitor all access to network sources and cardholders’ data
  • Frequently test security systems and processes

Take care of information security policy

  • Take care of an information security policy

PCI DSS 3.0

After three years of preparation version 3.0 of PCI DSS was introduced in November 2013. Unlike previous times, the changes in PCI DSS 3.0 were first presented to experts in the industry and are thus fortunately more applicable in practice. As Participating Organization in the PCI Security Council, Basefarm also participated in this exercise.

The main objective of PCI DSS 3.0 is to help organizations take a proactive attitude towards protecting card data. Working with PCI DSS must become ‘business as usual’. Organizations should not just be motivated by the need to achieve their certification every year, but must act based upon their responsibility for security. The 98 amendments that version 3.0 entails contain many updates and increased rules to protect against the latest online threats, such as malware, viruses, and WiFi access.

But more important than rules and updates is the fact that PCI DSS version 3.0 finally provides clarity about the interpretation of PCI DSS. Especially for merchants, it creates long awaited clarity about the scope of their responsibilities, which may have major consequences. Online stores that send their customers to the vicinity of a third party to make the payment (redirect), now have to explicitly express that they meet the requirements of PCI DSS through a Self-Assessment. Securing cardholders’ data will become a shared responsibility between the merchant, payment processor and hosting company.

Although PCI DSS 3.0 will be applied as of January 1, 2014, companies involved will have the opportunity to adjust their systems accordingly until December 31, 2014. Now that the scope of the responsibility is clear for the first time, the major credit card companies that are united in the PCI Security Council will enforce it more strictly. The days when companies could hide behind the ambiguous guidelines are definitely over. We also anticipate that many online stores that still perceive security as ‘add-on’ will have a lot of catching up to do. Their primary questions will often be dictated by the fear of fines and possible loss of revenue. But we hope they continue to look one step further and create a safe handling of cardholder data as part of their operation. No one wants to be in a similar situation as loyaltybuild.

Apache Struts 2.3.15.2 – Fixes security vulnerabilities

A new version of Apache Struts has been released. This update fixes two security vulnerabilities so users are advised to update as soon as possible!

More information: http://struts.apache.org/release/2.3.x/docs/version-notes-23152.html