Security Testing Scheduler required

e-Placement Scotland are working with us to help find a Security Testing Scheduler.

Security Testing Scheduler:

The role will be based from 7 Elements’ office.
The placement will be for 6 months, starting in January 2014.
Salary £15,000 per annum pro rata.

Apply online here

Senior Security Tester

We are looking for a Senior Security Tester to join the team. We pride ourselves on our expertise in technical information assurance, as such the candidate must have a high level of technical ability and share our passion for information security.

If this sounds like you then visit our careers page to find out more.

Advanced Persistent Threat – Redux

Given that media coverage keeps going in terms of discussing ‘Advanced Persistent Threat’ and the need to keep a balanced view, I thought that I would revisit this topic. We first blogged and presented on this issue back in 2011 and those discussion points appear to still be valid now.

To be fair, I still have a love – hate relationship with the term Advanced Persistent Threat (APT). It is used to describe state sponsored espionage, which i know exists and can be a significant threat to specific entities such as government departments and defence contractors. I’m also aware of APT style attacks on corporate organisations. However, the term can be banded around and badly applied to security ‘hacks’ as well as being seen as a ‘China’ only issue. This is especially true when dealing with the media and specific security vendors. This is the side of APT that I hate.


So what is APT anyway?

APT is used to describe a variety of attacks but has its origins in what would be categorised as state sponsored cyber espionage. This traditional cyber espionage was concentrated on government agencies and supporting defence contractors. This has been extended to encompass a wider focus, resulting in what is known today as APT.

The objective of APT can be seen as;

  • Gain access to information,
  • Maintain access to gather large quantities of data,
  • To serve a specific set of goals / objectives.

APT stands for Advanced Persistent Threat. So what do these terms really mean? A number of definitions exist, but from my perspective I see APT as:

Advanced – This relates to the ability of the attacker. It doesn’t however mean that they will only use custom created code to launch what is known as ‘zero day’ attacks on a network. It is important to understand that they will use the path of least resistance when looking to compromise a network. If this can be done through trivially guessable passwords then this is the method they will use, but they have the capability to research and develop new attack code if required.

Persistent – This is a key differentiator with other threat actors. The aim of those conducting APT is to gain access to information. The information that is targeted is of greatest value when gathered in volume. APT attacks therefore seek to maintain access to the network for as long as is required to achieve this. Smash and grab attacks, such as those that target credit card information fall within a different class of threat actor, and should not be confused with APT. However, APT style attacks could be completed in such a fashion if they are able to meet their objectives with one short attack.

Threat – The use of the term threat within the context of APT relates to the fact that this is a targeted attack, which is directed to achieve a defined purpose and has both the intent and capability to gain access to the desired information.


So how does APT differ from cybercrime?

For me there is a degree of cross-over between cybercrime and APT. Highly capable threat actors within both areas are highly organised, well-motivated and funded. This makes both these actors a real threat. The key difference between an attack being classified as APT or cybercrime is the intention or driver of the behind attack. At a high-level, cybercrime has a focus on making money by stealing data to commit fraud, APT is looking to gain a commercial advantage through the information that they gain access to.


The Hype

APT has become over hyped and this has been used to sell products and services based on the APT threat. As an example, major security vendors now sell anti-APT services and products, with strap lines such as:

“Do You Know if Your Network Has Been Breached by Botnets, Advanced Malware or Persistent Threats?”

“threats such as the Advanced Persistent Threat (APT). These are one of the most dangerous types of threats”

“Introduces New Security Solutions to Counter Advanced Persistent Threats”

“Enterprise Computer Protection from Advanced Malware Threats/APT”

“New Security Solutions to Counter Advanced Persistent Threats”

Tom Reilly (CEO of ArcSight.Symantec) explained that revenue for the second quarter is expected to be in the range of $55 million to $57 million (that is 21%-25% growth over the same quarter last year). This is based partly on “growing cybercriminal activity and heightened awareness of the Advanced Persistent Threat”. So as you can see, APT is big business.


Even the media carry provocative statements around this topic that help fuel the hype:

“The APT attackers, however, employ undetectable zero-day exploits and social engineering techniques against company employees to breach networks.”

All of this feeds on the fear, uncertainty and doubt that exists around the term APT and implies the big bad guys are going to get you, regardless of who you are! Media focus is clearly on China and how they are behind all APT attacks. However this paints a very narrow picture of the reality and is predicated by the belief that all APT is state sponsored and worse, that China are the only players. By focusing on just one potential avenue, we may fail to address this issue.


The Reality

In reality the threat is wider than that posed by ‘China’, in fact evidence leaked as part of the WikiLeaks stories showed that the US believed that “French espionage is so widespread that the damages [it causes] the German economy are larger as a whole than those caused by China or Russia.” (

If we look more closely at APT, we can see that it falls into two categories. Firstly with its roots firmly as a method of cyber-espionage, it was focused on gaining government information and this would clearly be an activity undertaken by nation states. Secondly as a style of attack that is broadly aligned to gaining access to intellectual property (IP) and commercially sensitive data. This second category indicates that APT style attacks may not just be the preserve of state sponsored entities.

The aim of targeting commercial IP is to gain access to knowledge that can provide a competitive edge, such as blue prints, merger information and strategy documents. This type of information would give competitors an advantage over their rivals and this is the real driving force behind the wider use of attacks classed as APT. These motivating factors could be attributed to individual organisations as well as governments pursuing economic growth. This also extends the threat surface to include those you partner or share information with.


Are you at risk?

If we listen to the hype then we are all at risk, even the mighty Google and the IMF have fallen foul of APT! Then again we are not all in the same market as Google (with all its sensitive customer data) or the IMF. So the first question to ask yourself is; do you hold information that someone is willing to spend time and effort in trying to obtain? If the answer is no, then you can sleep soundly in bed at night. Well, from an APT perspective at least. If your own data or that of a client that you hold has value then you will need to consider the threat posed by APT.

I believe that we are at the most risk when we are looking in the wrong direction. Before we became aware of APT, organisations assessed that commercial data that had no value from a cybercrime or fraud perspective wouldn’t be a target in a hack. As a result, breaches went unnoticed. However, this continues to be the case. Why therefore do the attacks go unnoticed, how do they breach the network in the first place? In my opinion a lot of this is down to the wrong focus within the organisation and in what they are trying to protect (if anything!).

What do I mean by this? Well, within the UK we have a number of regulatory drivers that help organisations focus their priorities. The Information Commissioner and Data Protection requirements keep an organisation focused on protecting personal sensitive data. Financial regulation and PCI-DSS keep others focused on protecting financial data, however there is no requirement other than an individual organisations risk appetite in terms of protecting intellectual property. This is exactly what those conducting APT are targeting. They are going for something you didn’t think to protect. You made a risk based decision to focus on regulatory drivers, they made the decision to target your corporate network and steal as much data as they could and then see what was useful.



So what is the solution? How do we defend against APT? In reality, in the same way you defend against other cyber threats, through a resilient approach to information security. This will depend on how a business approaches risk management, the level of assurance required and based on organisation’s risk appetite.

Any approach taken should be driven by a clear business need and understanding of the risk environment and the organisation’s risk management structure. The business needs to be aware of the threat environment that they are in and be able to make informed decisions, and not just be blinkered into making regulatory based decisions only.

We also need to accept that we are not able to achieve 100% security, especially through appliance based solutions or by just doing penetration testing or by being regulatory compliant. Instead we should approach this problem from the point of view of business resiliency, which captures the ability for an organisation to be robust to attack and to be able to detect / react / recover from an incident. Therefore as an organisation you will need to take steps to look for evidence of compromise and act accordingly if it is found.

Security Testing Project Manager

We are looking for a Security Testing Project Manager to join the team.

The role of the Security Testing Project Manager will be to work within 7 Elements’ busy technical team to manage the delivery of security testing whilst ensuring 7 Elements’ high standards of customer service are met.  The main focus of the role is to ensure the smooth and effective delivery of security tests through technical project management. This role is key to the effective functioning of the overall test team. The project manager will be responsible for ensuring process is followed and that standards are met. This will require effective communication with clients and the testing team.

This role is ideal for an individual with a solid technical understanding of information technology and associated terminology and a basic understanding of information security looking for their first role within the information security industry.  The role will allow an individual to gain an understanding of the broad spectrum of security testing in a business environment and the challenges this brings. As a customer facing role it will also enable the individual to gain that vital experience of working with businesses and understanding their requirements.

For further information visit our careers page.

Cloud Security

On the 24th September I had the opportunity to talk at the Cloud Security Alliance Symposium, a free event in support of the Cloud Security Alliance EMEA Congress 2013 hosted in Edinburgh on Cloud Security. My talk focused on real life examples of cloud security issues and internal research that we at 7 Elements had been working on. Our earlier paper on cloud security issues can be found here. This blog post covers some of the themes discussed during my talk.


Cloud Basics

What is the Cloud? Well, in short, it is a great marketing gimmick. There is no one such individual thing as the ‘Cloud’. The Cloud is a term used to describe multiple service offerings such as Software as a Service (SaaS), Platform as a Service (PaaS) as well as Infrastructure as a Service (IaaS). All of this is characterised by the use of on-demand provision, rapid ability to scale and are based on payment solely for the amount of resource required at any given point.


Key Risks

What are the key risks presented by using the Cloud? For me, the key risks and some of the issues that an organisation should explore when looking at the Cloud break down as follows:

Cloud Security Risks


Legal Jurisdiction

As an organisation you should be aware of how legal requirements to disclose data may be affected by the geography of where the data is stored. If you are based in the UK and use a US based Cloud provider, consider the impact on your organisation if the US courts enforce disclosure of your sensitive data. Where the Cloud is used to store or process sensitive personal data, there may be an impact on your compliance with the required regulation (Data Protection Act,) which you will need to fully understand and mitigate.


Geographical Location

Different geographical locations mean different legal jurisdictions, which will have an impact on your legal and regulatory requirements within each of those regions. This may restrict the type of data that can be stored or processed or limit how the data in question can be transferred between locations. The ability to encrypt data will also be impacted within certain locations due to export restrictions.


Access to Data

Many Cloud services are based on the use of shared services or multi-tenancy solutions. The benefit to the end user is reduced costs, but this can also lead to security concerns. The data may be at risk of attack from another user of the same Cloud service due to the architecture in use. Consideration should be given to how the Cloud provider has limited the possibility of data compromise.


Data Destruction

With the Cloud, you can grow and shrink your resource requirement. When the data on disks is no longer needed then it will need to be destroyed. You will need to gain assurance that this has been destroyed in compliance with your organisation’s standards, that the next user of that environment will not accidentally gain access to your data, and that you have met any regulatory requirements.


Data Availability

The Cloud sells itself as always being there. The data is ‘in the Cloud’, so you will always have access to it. However, the Cloud brings its own impact in relation to your organisational business continuity plans and disaster recovery approach. Consideration should be given to scenarios where the Cloud provider fails, or your ability to connect to the Internet fails. This may render the data unavailable.


Economic Denial of Service

What controls do you have in place to protect against unauthorised provisioning of cloud instances? Based upon a simple example of an attacker gaining access to an organisations provisioning capability (a real life example of gaining access is included later in the blog), we have estimated that an attacker could cause an individual organisation £14,000 of costs in a single day. More on this will follow in a separate blog on Economic Denial of Service.


Cloud Security

The talk then moved on to real life examples of cloud based security issues.


Geographical Location

The first focused on the geographical location for data. Did you know that internally created or ‘private’ cloud installations can be configured to automatically connect to the public cloud if capacity is reached?

The following example shows a private cloud, configured to do just this:


Server instantiated on Eucalyptus.
Number of instances running: 1
Auto-scaling successful
instantiated eb server: instanceID i-35AE00C1
Number of servers: 2
Cloud bursting successful
Instantiated web server on EC2: instanceID i-32CB323A
Number of servers: 3


The issue here is that data is now outside of the organisation’s boundary and is stored on Amazon EC2. Given this scenario, there would be no prior warning and no assessment of the data that is now in the public cloud. This could lead to potential information disclosure or breach data handling requirements.


Access to Data

We then looked at the issue of who has access to your data. A recent article outlined how Dropbox were accessing uploaded word documents. The researcher discovered his documents were being opened by Dropbox-owned Amazon EC2 instances automatically 10 minutes after they had been uploaded, although other file types were not being accessed. The following screenshot shows the EC2 IP addresses accessing the documents:




More on this issue can be found in our previous blog post here.


At the end of the talk, I then provided a live demo of how easy it was to identify valid Amazon EC2 and S3 access and secret key values and use these to enumerate running cloud instances.


$ ruby enumerate.rb
Enumerating AWS account AKWWR5MSIHCI7FH3HIAA
EC2 Instances
[*] i-828b26e4 / running /

S3 Buckets
– /home/data/_backups/20130902.database.sql.tgz
– /home/data/_backups/20130901.database.sql.tgz


An individual who has access to these credentials could choose to start new cloud instances (potentially leading to an economic denial of service), stop current services leading to a more common denial of service or more importantly, access the data currently stored within that instance. This issue will be covered in more detail in our next Cloud Security blog.


As we have seen in many ways, the Cloud is no different to the wider challenges of managing an organisation’s data securely. However, with these unique opportunities, unique risks will also arise. As such, we need to understand those risks and assess the data that we wish to put into the Cloud and understand how important  that data is in terms of confidentiality, availability and integrity to the business.



Cloud Security Alliance Symposium

Our CEO, David Stubley will be presenting on the subject of Cloud Security at the Cloud Security Alliance Symposium on the 24th September. Further information can be found here.

CVE-2013-5669 Thecus Pain Text Admin Password

Advisory Information

Title: Thecus NAS Server N8800 Firmware 5.03.01 plain text administrative password
Date published: August 2013
Ref: CVE-2013-5669 CWE-319

Advisory Summary

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



Affected Software

NAS Server N8800 Firmware 5.03.01

Description of Issue

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.


There is no exploit code required.

CVE-2013-5668 Thecus Domain Administrator Password Disclosure

Advisory Information

Title: Thecus NAS Server N8800 Firmware 5.03.01
Date published: August 2013
Ref: CVE-2013-5668 CWE-317

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.



Affected Software

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.


Attackers can use a browser to exploit these issues.

CVE-2013-5667 Thecus OS Command Injection

Advisory Information

Title: Thecus NAS Server N8800 Firmware 5.03.01 get_userid OS Command Injection
Date published: August 2013
Ref: CVE-2013-5667 CWE-78

Advisory Summary

A lack of input validation allows an attacker to execute OS commands directly on the operating system.



Affected Software

NAS Server N8800 Firmware 5.03.01

Description of Issue

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.


Standard request:




Command Injection PoC:

1. Write value for user admin to /tmp


2. Display value of /tmp




Apache Struts 2 Exploit – have you patched?

Apache Struts 2 Exploit – have you patched?

In early July and then in mid July, Apache Struts 2 released information on two new vulnerabilities.  These recent vulnerabilities for Struts 2 appear to have gone under the radar in terms of patching urgency and active exploitation is now happening in the wild. The vulnerabilities appear to have gone unnoticed because they have received little media attention and the vulnerability description perhaps doesn’t do justice to the potential scope of the vulnerability:

Apache Struts 2 before allows remote attackers to execute arbitrary OGNL code

Of course, the vulnerabilities will have been dealt with through organisations’ patching programs, if they were picked up. But have you assessed the potential impact correctly and taken steps to remediate this issue?

So what’s the true potential impact of the vulnerability if it were exploited?

The vulnerability alone may not be hugely significant, but when put into the context of an attack it can have much greater consequences. The vulnerability allows for some post-exploitation techniques to be utilised, such as installing backdoors and JSP post-exploitation tool kits. This allows for more elaborate and complex attacks to occur.

The true impact of the exploitation of this vulnerability when combined with post-exploitation tool kits could be full compromise of a system with the ability for that system to be used for onward compromise of connected hosts.

How easy is it to use?

7 Elements has discovered an exploit kit designed to target Struts 2 vulnerabilities. Whilst the exploit code itself required reasonable skill to construct, the toolkit enables attackers with a low level of skill to use the toolkit to attack Struts 2 vulnerabilities. The Chinese built toolkit essentially allows an attacker to enter their target via copy and paste, press a button and view the results.

Struts2 exploit code

Struts2 exploit code

(It comes with instructions on how to use the tool in a blog post that can be easily translated via online translators. As such, this isn’t just available to Chinese speaking script kiddies!)


The exploit code makes use of the following arbitrary code execution vulnerabilities within Struts 2:

– 2010 S2-005: (CVE-2010-1870)

– 2011 S2-009: (CVE-2011-3923)

– 2013 S2-013: (CVE-2013-1966)

– 2013 S2-016: (CVE-2013-2251)


The vulnerabilities exists due to a lack of proper input validation. Input validation occurs where end user information is not validated before being used by a web application. If an attacker can embed malicious commands in these parameters, the system may execute those commands on behalf of the web application, resulting in the execution of remote code. A more detailed explanation on the inner workings of the exploit can be found here:

The option to choose which of the four Struts 2 vulnerabilities to exploit indicates that all are still useful to an attacker, and show that vulnerabilities from three years ago are still to be found.

What can you do?

Confirm that your current patching process has identified the need to apply this patch and correctly triaged the effort and priority. If you are yet to deploy a patch, then Apache has “Strongly recommended” that Struts 2 users upgrade to Struts Doing so will address the current vulnerabilities.

If historically your organisation has chosen to not patch and deploy other mitigation techniques such as filtering, revisit these controls to ensure that they are still effective and provide the desired protection from the current Apache Struts 2 Exploit.