Home > 2014

Archives for 2014

7E supports Scottish talent

February 24, 2014 by

One of the key motivations in establishing 7 Elements was a drive to deliver customer focussed security testing that provided clients with a service they need and to proactively support and develop the wider security community for the benefit of everyone.

As part of this commitment, 7 Elements recently offered two students from Glasgow Caledonian University (GCU) the opportunity to write a blog post on the recent changes to PCI DSS. Doing so would provide vital hands on experience for these undergraduates. Both are studying Digital Security, Forensics & Ethical Hacking at GCU and share our passion for information security. Their post on PCI DSS v3 in a Nutshell can be found here.

In addition to guest blog spots, 7 Elements are also taking on two interns over the summer of 2014.  As well as providing them with the opportunity to gain industry experience in the field, the interns will be assisting 7 Elements with the development of customer focussed projects and bespoke security research.

PCI DSS V3 in a Nutshell

February 24, 2014 by

The following blog post outlining PCI DSS V3 in a nutshell has been submitted by two students from Glasgow Caledonian University. This is part of our approach to work closely with local universities to provide vital hands on experience for undergraduates.

What is PCI DSS and why is it required?

As many of you will be aware PCI DSS has recently been updated and a new version released.  This article reviews the biggest changes in PCI DSS from version 2.0 to version 3.0 and is aimed at providing a brief overview of the changes of which you may want to be aware.

PCI DSS is the card industry’s standards for securing card data (see our previous blog here for more detail) and is applied to all entities involved in payment card processing (e.g. banks, supermarkets, retailers) and those who store, process or transmit cardholder data and/or sensitive authentication data.  Payment card data has long been the target of attackers aiming to steal that information and PCI DSS introduces measures to defend against those attacks.  Whilst PCI DSS is nothing new to those that process or deal with that data, the online threat landscape is rapidly evolving.  The standards that protect against those attacks therefore need to keep pace with the threats, environments and organisations they are applied to. Version 3 has been released to encourage and enhance cardholder data security and promote consistent data security measures worldwide.

How v3 differs from v2 in order to address risks

In response to the developing threat landscape and driven by inputs from industry, PCI DSS has been revised to reflect methods of enhancing security and addressing perceived weaknesses in the standards. These include a lack of education and awareness, weak passwords and authentication, third-party security challenges, slow self-detection, malware, and inconsistency in assessments. The revisions and additions defined in version 3.0 are designed to assist organisations in adopting a proactive approach to the protection of cardholder data, focusing on the adoption of security mechanisms rather than promoting a compliance based approach.

Key Differences

While the twelve core security areas remain unaltered, there have been several new additions and implementation strategies devised for sub-requirements, of which we will highlight some of the main differences:

Requirement 1.1.3

To assist and ensure organisations understand and monitor the scope of their environment and identify the potential attack points where data could be breached, there is a new requirement for companies to devise an illustrative diagram which depicts how cardholder data is stored, processed, or transmitted across networks, between individual systems and devices. However, this valuable information (e.g. network layout, hardware and software employed, and security mechanisms in place) could be potentially employed maliciously and assist in the development of attack vectors if such diagrams became available. As such, organisations will need to take steps to ensure that the correct level of protection is afforded to these new diagrams.

Requirement 2.4

Similar to the previous requirement, this places an expectation on businesses to maintain an inventory of system components that impact PCI DSS in order to support the development of configuration standards. As this inventory is designed to provide a detailed list of all hardware and software components including descriptions of their function and use, there is a potential security impact if this information was to become available.

Requirement 5.1.2

In a reactive development to malicious threats, there is now a requirement to evaluate evolving malware threats for systems that presently do not require anti-virus protection. It is envisaged that this will raise awareness and encourage the monitoring of the current threat landscape.

Requirement 6.5.10

This focuses on broken authentication and session management by examining software development policies, procedures and coding techniques. These have been devised as a means of preventing unauthorised individuals from compromising legitimate account credentials and session tokens that would allow session hijacking.

Requirement 9.9.[1-3]

By concentrating on the physical protection of devices that have direct interaction with card data, this requirement promotes security awareness of the potential for fraudulent activity, tampering, substitution and identification of suspicious behaviour. This in turn places an emphasis on training and education.

Requirement 11.1.[1-2]

The increasing threat of rogue access points, potentially leading to man in the middle attacks, provides a new type of threat. To proactively minimise the exposure of the Cardholder Data Environment (CDE) and secure data transmission, this requirement aims to address this potential area of exploitation through the verification of trusted access points. Implementing an incident response procedure in the event unauthorised wireless access points are detected is also a key part of this requirement.

What is the impact of implementing PCI DSS?

A review of the requirements has highlighted that the transition and implementation of the new set of expectations will have a significant financial impact, particularly on SMEs.

The requirements that are likely to cause the greater financial burden are:

Requirement 5.3

In response to the ever changing threat landscape, there is now the requirement for companies to ensure they are actively implementing the most recent anti-virus solutions. This will have a significant financial implication as companies will have to invest in effective anti-virus software and ensure hardware has the capability to run the associated processes.

Requirement 11.3

Identifying that security mechanisms have to be tested to ensure effectiveness, there is now the requirement to implement a methodology for penetration testing to actively identify the weaknesses and threats within a system. For SMEs with limited or no in-house security team, this will require external assistance.

Requirement 11.3.3

This requirement reinforces that it is not only essential to implement penetration testing, but the outputs must have an active response.  For example, identified vulnerabilities must be resolved, with confirmation achieved through retesting. This demonstrates a willingness by the company to improve their security through remediation, thus ensuring that their systems will be kept up to date and as secure as possible to reduce the risk of a breach.

Requirement 12.2

It has now become mandatory for companies to actively identify their assets and their associated threats and vulnerabilities, through the implementation of risk assessment exercises (e.g. ISO 27005, OCTAVE, etc.) both annually and at points of significant change. This encourages companies to adopt a more proactive stance rather than a reactive response to attacks. However, it should be questioned within a fast evolving landscape whether an annual approach to risk assessment is sufficient.

Clarification of PCI DSS services from providers is stated in the following two requirements:

Requirement 12.8.5

To establish transparency and responsibility between entities (e.g. service providers and organisations) this requirement dictates that each entity identifies their role within the process and that this is efficiently managed. This translates to assurance and awareness of the provider’s compliance status and whether their requirements comply with that of your organisation.

Requirement 12.9

In an extension of 12.8.5, there is also an expectation for the service provider to provide written communication informing their customers of the expectations that are to be placed on them and their personal responsibility, as part of the new `shared responsibility’ theme. The confirmation of the service provider’s responsibilities creates a consistent level of understanding between provider and customer by demonstrating their commitment and transparency to maintaining proper security of cardholder data that it obtains from its clients.

Recognising the scale of change between the different versions, some sub-requirements will be considered as best practices only until the 1st of July 2015, with version 2.0 remaining in operation until December 31st 2014 to allow for companies to plan ahead for a lengthy transition period in order to effectively adapt.

Considerations & Conclusion

This blog entry has highlighted only some of the perceived differences between the PCI DSS version 2.0 and 3.0. In doing so we have established that the adoption of the stronger framework will have a significant impact with many challenges for companies to overcome, especially as there has been a shift from ambiguous terms such as “should” towards the more definitive “must” with regard to the requirements. However, while some requirements are still debatable with weaknesses still existing, improvements have been established, such as unique authentication and promoting awareness of device tampering and substitution. Furthermore, additional guidance has been provided within the documentation to establish understanding of the different technologies at a foundation level.

By Ross Bingham & Steven MacFarlane

How Card Payments work and PCI DSS

February 20, 2014 by

How Card Payments work and PCI DSS

The following blog from our Principal Security Consultant, first published back in 2011, provides a great high level primer for those who are not familiar with the underlying processes and terminology around PCI DSS. This may be particularly useful for small businesses who are just starting out with card payments and the PCI DSS.

How do card payments actually work?

At the very top we have a collection of organisations known as the card schemes. VISA and MasterCard are examples of card schemes but there are plenty of others. Essentially they each operate a network over which card payment transactions can occur and they make money from their members through connection fees and something called interchange.Interchange is a complex set of commission fees paid by members on each card transaction.Card scheme members go through a certification process to prove that their IT and business systems are able to correctly communicate with the scheme’s network and, once approved, they are issued with a range of Bank Identification Numbers (BIN, more on that later), and are permitted to connect and send transaction messages to other members on the network.The majority of members are also ‘issuers‘. Issuers are the people who actually produce and issue cards, be they credit, debit, prepaid or other. For the purposes of illustration, I will use HSBC and debit cards as an example. An individual has a personal bank account with HSBC. HSBC will issue that individual with a debit card that they can use with that bank account. The debit card itself has an account number, something called the Primary Account Number or PAN. You and I know this as the card number, typically 16 digits and printed across the middle of the card.HSBC will issue the card under one of the card schemes (this is a business decision based on the rates offered to them by the scheme, acceptance rates and other factors). For this illustration I have been issued with a VISA card. The PAN assigned to my card is not a random string, it has meaning. The first part of the PAN is allocated from the issuer’s BIN range. The BIN range is a range of numbers, typically six digits in length which denote who issued the card and what it’s for. The BIN for HSBC VISA debit cards is 465942 (see http://en.wikipedia.org/wiki/List_of_Bank_Identification_Numbers). The rest of the number is arbitrary and up to the issuer but in order to be considered valid it must pass something called the LUHN check which is a simple checksum algorithm. This algorithm is not designed to offer any kind of security, merely to prevent accidental errors with the PAN.So, this is all great but what does that machine do when I go in a shop and put my card in it (or near it), or that website when I put my details into the form? Enter ‘Merchants‘ and ‘Acquirers’. A Merchant is the shop, website or other organisation with which you interact when you make a card payment. They are the ones you are paying money to for the goods or services you are purchasing. How they get the money is down to something called a Merchant Account which is a credit account with an Acquirer. The Acquirer supplies the Merchant with a Merchant Account and a means to take card payments, be this over the Internet in the case of e-commerce or physical terminal equipment in the case of real life. They also take care of communications with card issuers via the card scheme networks. The Acquirer makes money by charging a regular fee for the account as well as commission fees on each transaction.In the case of many large financial institutions, such as HSBC, they are both an issuer and an acquirer. This has obvious benefits in terms of an overall proposition to customers and in reducing costs.So, I’ve just walked into my local shoe shop and picked up a new pair of Converse All Stars and I pull out my HSBC debit card. What actually happens? I insert my card into the slot, enter my PIN and the card machine makes a telephone call, yes, literally a telephone call, to the acquiring bank. To make things interesting let’s say that my local shoe shop is “acquired” by Barclays, not HSBC. The Point-of-Sale (POS) terminal dials up Barclaycard Merchant Services (BMS) phone number, makes a network connection with its authorisation systems and begins transmitting authorisation messages.

BMS’ systems will derive the BIN from the incoming PAN, work out which issuer and scheme this relates to and send an authorisation over the relevant scheme network to the issuer. In this example therefore, BMS will send an authorisation request over VISA’s VISANet to HSBC. HSBC’s systems will check the bank account associated with my debit card and decide whether or not to allow payment. In my case I’m in luck, the boss has decided to pay me this month so I can have those Converse. HSBC respond with a success and include something called an Authorisation Code.

BMS tell the terminal that the payment was successful, I breath a sigh of relief, remove my card from the machine, collect my little slip of paper (which has the authorisation code on it along with information about the POS terminal id and amount debited) and head out of the shop.

All done right? Nope. The authorisation is only part of the process. No funds have actually been debited at this point. At the end of the day, the merchant will cash up. Through interaction with the POS terminal they perform an upload of the transactions to the acquirer, via the same phone call mechanism. The acquirer receives the transaction list and proceeds to upload settlement batch files to each of the card schemes requesting payment. The card scheme ensures the delivery of this information to the correct issuer who is then responsible for remitting the funds to the card scheme. The card scheme deducts its interchange and sends the remaining funds to the acquirer. The acquirer deducts their fees and the merchant is then paid the remainder. This generally happens over night.

The overall process is the same for an Internet merchant except that the payment service provider takes care of all the interaction with the acquirer (and in many cases actually is the acquirer), including the transaction upload at the end of the day. Many Internet payment service providers maintain what is called a Master Merchant Agreement with an acquirer which allows them to use their merchant account in order to process transactions on other sub-merchants behalf.

A brief history of crime

As with just about any process, criminals look to find a way to abuse it. Right from the start fraudsters realised that copying cards or acquiring card details provided them with a rich revenue stream. The boom in Internet e-commerce in the early 2000’s provided criminals with two significant new attack vectors, end user PCs through malware or viruses and web site databases. It’s fair to say that few e-commerce companies were developing secure sites in those early years, both in terms of code or storage, and it was common for websites taking payments to have databases full of unencrypted card payment details. Criminals quickly worked out ways to infiltrate these databases and walk away with thousands, or even millions of card numbers.

Due to chargeback rules, if a cardholder detects misuse of their account they can contact their card issuer, declare transactions as fraud and the issuer will return the funds or reinstate the credit. The card issuer is then left with the problem of tracking down the fraudster to try and recover the monies. Not an easy task. The card schemes needed to find an approach to deal with this.

The PCI DSS is born

Five of the card schemes, VISA, MasterCard, American Express, JCB and Discover, combined their independent card security programmes in 2004 to create the PCI DSS. Its aim is to provide a baseline level of security for card payment processing. The PCI DSS is a set of six “control objectives” made up of twelve high-level requirements. These high-level requirements are then broken down into nearly three hundered individual low-level requirements.

The control objectives are as follows:

Build and Maintain a Secure Network
Protect Cardholder Data
Maintain a Vulnerability Management Program
Implement Strong Access Control Measures
Regularly Monitor and Test Networks
Maintain an Information Security Policy

You get a feel for the sort of things they are looking for here. I won’t take up any more space on this blog post regurgitating the long list of requirements, they can be found at the PCI DSS website http://www.pcisecuritystandards.org.

The PCI DSS is overseen by the PCI Security Standards Council (PCI SSC), comprised of representatives of each of those card schemes. Other businesses can join the SSC as a Participating Organisation (for a fee of course) and review proposed changes to the DSS.

The PCI DSS applies to all merchants that store, process or transmit cardholder data. The SSC breaks merchants down into levels based on transaction volume with the validation requirements for each level varying as appropriate for their size. The standard itself doesn’t change however, just the process of validation.

Merchants who comply with the PCI DSS are given “safe harbour” from fines and penalties associated with any card data theft which occurs from them, if they are proven to be PCI DSS compliant at the time of the breach. The scope of an assessment can be one of the hardest parts to nail down, before you even start to think about whether you comply or not. If you took the scoping statement literally you could argue that any device with an Internet connection is in scope and herein lies one of the core problems that we shall discuss in a further post, there is an awful lot of interpretation to be done with the PCI DSS and so much of a successful compliance assessment is in correctly understanding the standard and applying it appropriately.

In November 2013, the PCI Security Standards Council released version 3 of the ‘Data Security Standard and Payment Application Data Security Standard’. Our next blog on PCI DSS will cover the major changes introduced as part of version 3.

Graduate Junior Security Tester Vacancy

February 19, 2014 by

7 Elements is looking to take on another Junior Security Tester in the summer of 2014. Through our dedicated Graduate Junior Security Tester Training and Development Plan they will gain the skills and experience necessary to become an independent, effective and highly skilled manual security tester. More information on this vacancy can be found on our careers page.

Cyber Security 2014

January 29, 2014 by

Our CEO David Stubley will be opening the Cyber Security 2014 conference at the Gogarburn Conference Centre, RBS World Headquarters, Edinburgh next Thursday 6th February 2014.

His talk will be on ‘Cyber Security: Setting the Scene‘.

During this talk David will explore the question of “What is Cyber Security?” Using real life case studies David will provide insight into the current and future threats faced by UK businesses.

More information on the event can be found here.

 

OWASP AppSec Eu 2014

January 28, 2014 by

OWASP AppSec Europe is returning to the United Kingdom in 2014 and 7 Elements are proud to announce that we will be sponsoring this event.

Hosted this year in Cambridge, the event will take place from the 23rd to the 26th of June and will include:

  • Two days of training and a two day conference
  • Three tracks, focusing on the core OWASP mission (Builder, Breaker, Defender), with an added Research track
  • Keynote addresses by highly respected Industry experts

Update from Thecus

January 28, 2014 by

On the 28th January, Thecus made further contact with our team to advise of fixes to the vulnerable firmware reported by 7 Elements, please see our blog for further details.

CVE-2013-5668 Thecus NAS Server Domain Administrator Password Disclosure

January 23, 2014 by

Advisory Information

Title: Thecus NAS Server Domain Administrator Password Disclosure

Date published: 13 January 2014

Reference: CVE-2013-5668

Advisory Summary

The Domain Administrator Password within the ADS/NT Support page is disclosed due to clear text storage of sensitive information within the GUI.

Vendor

Thecus <http://www.thecus.com/>

Affected Software

Thecus NAS Server N8800 Firmware 5.03.01

Description of Issue

The Domain Administrator Password within the ADS/NT Support page is disclosed due to clear text storage of sensitive information within the GUI. Any user who has access to this page is able to retrieve the ADS/NT administrator ID and password. This could enable an attacker to gain access to the domain hosting the storage server.

PoC

Attackers can use a browser to exploit these issues.

Fix

ThecusOS 5 (32 bit):

http://www.thecus.com/Downloads/beta/FW/Thecus_NAS_FW_beta_5.03.02.4.rom

ThecusOS 5 (64 bit):

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N2800_N4510U_N4800_N5550_N7510.rom

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N6850_N8850_N10850_N8900_N12000_N16000.rom

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N7700PROV2_N8800PROV2.rom

 

CVE-2013-5669 Thecus NAS Server Plain Text Administrative Password

January 23, 2014 by

Advisory Information

Title: Thecus NAS Server Plain Text Administrative Password

Date published: 13 January 2014

Reference: CVE-2013-5669

Advisory Summary

The Network Attached Storage (NAS) Administration Web Page for Thecus NAS Server N8800 transmits passwords in cleartext by default, which allows remote attackers to sniff the administrative password.

Vendor

Thecus <http://www.thecus.com/>

Affected Software

Thecus NAS Server N8800 Firmware 5.03.01

Description of Issue

The issue exists because by default the Thecus NAS Server N8800 sends NAS administrative authentication credentials in plaintext across the network. The credentials may be disclosed to attackers with the ability to intercept network traffic, which may enable them to gain unauthorised access to the NAS administrative interface.

PoC

Attackers can use a browser to exploit these issues.

Fix

ThecusOS 5 (32 bit):

http://www.thecus.com/Downloads/beta/FW/Thecus_NAS_FW_beta_5.03.02.4.rom

ThecusOS 5 (64 bit):

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N2800_N4510U_N4800_N5550_N7510.rom

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N6850_N8850_N10850_N8900_N12000_N16000.rom

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N7700PROV2_N8800PROV2.rom

 

Multiple vulnerabilities in Thecus NAS

January 23, 2014 by

Introduction

During an internal infrastructure test last year, we identified a Network Attached Storage (NAS) device that piqued our interest, primarily due to the administration web page being served over HTTP and not HTTPS. Generally not a good sign from a security point of view!

A few moments later and with access to the device granted through the use of default administrator password (admin | admin) we had the opportunity to take a look around the management portal and in a short amount of time, we were able to identify a number of interesting security vulnerabilities. Of note would be disclosure of the domain account in use within the enterprise and the ability to conduct OS command injection attacks against the device itself.

The device in question is the Thecus NAS Server, version N8800 running Firmware 5.03.01.

It should be noted that the default configuration for the device allows for the administrative interface to be available via HTTP. This makes it possible to intercept and manipulate the traffic between a device operator and the device. The credentials submitted to the administrative interface would be vulnerable and would be intercepted and read by a well-positioned malicious agent. During further investigations, we have identified over 100 devices running this version of the Thecus NAS with Internet facing access enabled, therefore increasing the potential attack surface against this type of device.

Detail

The following two vulnerabilities were of particular note.

  1. Domain account password disclosure (CVE-2013-5668).
  2. OS Command Injection (CVE-2013-5667).

Domain account password disclosure

After gaining access to the device’s configuration webpage, it was possible to see credentials configured on the NAS. They were stored in plain text and were shown in the webpage’s source. The Domain Administrator Password within the ADS/NT Support page is disclosed due to clear text storage of sensitive information within the GUI. Any user who has access to this page is able to retrieve the ADS/NT administrator ID and password. This could enable an attacker to gain access to the domain hosting the storage server.

Thecus

 

OS Command Injection

The issue exists because the application accepts user input through the get_userid parameter that can be used to create OS commands that are redirected to the operating system. An attacker can use this flaw to execute arbitrary commands.

 Proof of Concept

We have generated a proof of concept (PoC) to prove the existence of this issue. Firstly to baseline how the device handles requests, we will use the following valid request:

get_userid=1&username=sales

Which generates the following response:

{"get_userid":"1456","groupname":false,"data":[]}

Command Injection PoC:

1. Write string for user admin to /tmp

get_userid=1&username=user1`echo+sales+>+/tmp/xpto`

2. Read value from /tmp

get_userid=1&username=`cat+/tmp/xpto`

Response:

{"get_userid":"1456","groupname":false,"data":[]}

The response shows that we have been able to directly execute OS level commands. In our proof of concept, the string ‘sales’ (1456) was written to the /tmp directory of the NAS device. In step two this value is then able to be recalled from the /tmp file, proving that we are able to execute commands. This type of vulnerability could enable an attacker to gain full control of the device.

Disclosure

Back in August 2013, we engaged with Thecus to raise three security issues. Since that point, we have tried on multiple occasions to engage with Thecus to help them understand these issues. Unfortunately this has not been successful and the lack of engagement from Thecus is disappointing with all communication handled though their generic support system.

The responses received to our questions suggested a lack of security awareness and understanding of the potential impact to Thecus’ customers. The support team has also failed to understand that the issues raised could impact on multiple platforms and not just the single device / firmware version that we were able to identify. They have also not asked any further questions that would help them in gaining this understanding.

After sending the following message to the support team, the ticket was closed by Thecus:

“We raised this issue 73 days ago with you. As the issues are security related, we would look to issue public advisories as soon as patches or work arounds are available and as such would prefer to coordinate any notification with you.”

The closure of the ticket, suggests that Thecus does not wish to engage in any further discussion on the security issues identified or work with our organisation in the managed disclosure of the vulnerabilities. After this point we started working with the CERT Coordination Center (CERT/CC) to progress this issue. CERT/CC has not recieved any communication from Thecus on this matter. Details of these vulnerabilities have now been released as part of their responsible disclosure policy.

https://www.7elements.co.uk/news/cve-2013-5667/ (CVE Entry)

https://www.7elements.co.uk/news/cve-2013-5668/  (CVE Entry)

https://www.7elements.co.uk/news/cve-2013-5669/ (CVE Entry)

At the time of publishing this blog, there are still no security updates from Thecus. For users of the vulnerable platform, we would recommend that users change default credentials and configure the device to use HTTPS only. Further to this and due to the potential for OS command injection, we would advice that network level filtering be implemented to restrict access to the device.

Update

On the 28th January, Thecus made further contact with our team to advise of fixes to the vulnerable firmware and provided the following response:

“Thanks to your detailed emails, we have released an updated version of our firmware for units running ThecusOS 5 (please see links below) and will be providing similar updates to our ThecusOS 6 models within a month (updates for OS 6 can be automatically downloaded and installed via the UI).”

ThecusOS 5 (32 bit):

http://www.thecus.com/Downloads/beta/FW/Thecus_NAS_FW_beta_5.03.02.4.rom

ThecusOS 5 (64 bit):

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N2800_N4510U_N4800_N5550_N7510.rom

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N6850_N8850_N10850_N8900_N12000_N16000.rom

http://www.thecus.com/Downloads/beta/FW/64_V2.04.05_build7464_FW_N7700PROV2_N8800PROV2.rom

“Again, please accept our thanks for your engagement and patience, you have our sincere gratitude.”