Archives for November 2014

Creating a Strong SNMP Community String

Creating a Strong SNMP Community String

To ensure that an attacker does not gain privileged or read access to your devices via a poorly configured SNMP community string, we would recommend that the following steps should be taken:

Follow similar guidance to mainstream password guidance.

• Use both upper and lower case

• Include one or more numerical digits

• Use special characters, e.g. @, #, $ etc.

• Prohibit use of words found in a dictionary

• Disallow passwords matching the format of calendar dates, license plate numbers, telephone numbers, or other common numbers

• Prohibit of use of company name or an abbreviation

Kerb Your Enthusiasm – Microsoft Release Critical Security Update (MS14-068)

One week after “Patch Tuesday” and contrary to standard operating procedures Microsoft has released a Critical security update (MS14-068) to fix a security hole in all supported versions of Windows. MS14-068 addresses a vulnerability in the Kerberos Key Distribution Center (KDC) component, used within a domain environment for authenticating users. The vulnerability allows an unprivileged authenticated user to elevate their privileges to those of a domain administrator. The KDC component is available remotely and the vulnerability can be initiated as long as the miscreant has domain credentials. This has severe consequences for businesses and shows why Microsoft took steps to release an out-of-band patch. The patch was actually rumored to have been included in November’s patch cycle and then pulled last minute.

Additional Information

The vulnerability takes advantage of improper validation of signatures, which can allow certain elements of a service ticket to be forged. An attacker can trick the KDC by sending forged tickets impersonating any user in the domain, resulting in compromise of the domain. The vulnerability was privately reported to Microsoft however, within the Bulletin released, Microsoft stated that they were “aware of limited targeted attacks that attempt to exploit the vulnerability.”

Quick reminder about Kerberos:

When the user first authenticates to the Authentication Service (AS) they are passed through the KDC and provided a TGT (Ticket Granting Ticket). The TGT contains an area called PAC (Privilege Attribute Certificate), which holds the user’s information. When the user wants to access a service they will present their TGT to the KDC, which will validate the PAC information and copy it to the ST (Service Ticket). The ST is then used to gain access to a service. The break down in validation occurs in the way that PAC information is validated. MS14-068 amends the way in which the validation occurs.

Log Analysis

As per the instructions in the following blog post, it is possible to detect attempts to execute this vulnerability. However, it should be noted that log data can be amended and should not be relied on for identification of earlier exploitation.


It is therefore recommended that all Domain Controllers in your environment be updated immediately with all other servers being updated in due course. The priority is Domain Controllers due to their overarching dominion of all other entities within the network.

Now for some scaremongering, the only assurance you can have that you have not been ‘pwned’ is to rebuild your entire domain. This is due to the multiple ways in which it is possible to hide backdoors and amend entities or information stored in an Active Directory Domain.

Winshock Exploits (MS-14-064) Gone Wild, Patch Now!


The MS-14-064 patch last week addressed several vulnerabilities that could allow for remote code execution in applications using the SChannel Security Service Provider. The vulnerabilities (including cve-2014-6332) affect distributions of Microsoft Operating Systems from Windows 95 IE 3.0 to Windows 10 IE 11. More background can be found in our earlier blog post and in summary, our advice was to patch your systems now without delay.

That was last week, where are we now?

Exploit: All The Things!

“As both security researchers and blackhats are inevitably working toward creating a workable exploit, enterprises need to apply the patch released to all applicable systems without delay.”

The promise of exploitation was kept by @yuange who released an exploit that allowed an attacker to remotely open notepad on a victim machine. This exploit was then adapted by Rik van Duijn. This adaptation executes Powershell in order to inject payloads directly into memory and as an added benefit, using Powershell maximises the chances of successfully bypassing anti-virus software (Powershell is often whitelisted as a trusted application).

The proof of concept code injected a “reverse_tcp” meterpreter payload into memory, resulting in a shell from which system commands could be executed.   Rik van Duijn has released this proof of concept as a Metasploit module to allow a multitude of further payloads to be delivered. This also has the associated impact of making the exploit easier to deliver, therefore increasing the overall likelihood that systems vulnerable to cve-2014-6332 will be targeted.

Meanwhile, another proof of concept has been published by Immunity Inc, this SChannel exploit using their CANVAS tool, may allow remote command execution(RCE) via the Windows remote desktop protocol(RDP).

Vulnerability Checking

Anexia have released a tool that will check if a Windows operating system is vulnerable. This tool conducts behavioural analysis based upon available SSL ciphers. Their script checks to see if the target system has been patched or not. It does this by checking if the system supports four new SSL ciphers that were introduced by MS14-066.

To run the tool you need to specify a target IP address and a port that with a service running that listens for connectable SSL connections. If the script takes too long or times-out then it is likely that a firewall is blocking the connection, you are connecting to the workstation indirectly or that no service is listening.


winshock test


Vulnerable System Result:

winshock vulnerable

Patched System Result:

winshock patched



While testing in our labs was accurate, Anexia warn that the script may, in certain cases, generate false negatives/positives and should be used as a hint for further investigation, do not take results of this script on faith.

Inevitable XP Swansong

Microsoft have not indicated plans to patch Windows XP, therefore it would be wise to decommission any vulnerable machines or where this is currently not possible, segregate legacy environments to limit potential exposure.



A WinShock Tale: The Patchable and Un-patchable


On Tuesday Microsoft released several fixes bundled in a patch, MS14-066, to address several vulnerabilities in SChannel, the standard SSL library that ships with Windows. Affecting almost all versions of Microsoft operating systems, this vulnerability allows attackers to exploit a weakness in the TLS implementation service that forms windows server and desktop communication protocols.


Cisco reports that the 19 year old bugs, covered in CVE-2014-6332, contain a complex ‘Unicorn-like’ bug found in code that IE relies on. Attackers exploiting the bug are able to sidestep the Enhanced Protected Mode sandbox in IE 11 and the anti-exploitation tool, the Enhanced Mitigation Experience Toolkit. The problem stems from the inclusion of VBScript in IE 3.0 and Cisco warn that more undiscovered bugs may still pose a threat.

Exploits Imminent

Not yet in existence, an inevitable exploit would allow attackers to run arbitrary code on targeted servers by sending “specially crafted” packets. Attackers may be able to deploy malicious code to vulnerable remote systems and Microsoft admits there are no workarounds or mitigating factors to employ against the vulnerability.


“Every major TLS stack: OpenSSL, GNUTLS, NSS, MS SChannel, and Apple SecureTransport has had a severe vulnerability this year,”

Tony Arcieri, Security engineer


This year it has become clear that attackers are choosing to attack and decipher the channels used to communicate between machines. These channels may contain usernames, passwords and financial details that are highly desirable to attackers.

“So in war, the way is to avoid what is strong, and strike at what is weak.”

Sun Tzu, The Art of War

It makes more sense to attack infrastructure that has remained relatively unchanged for many years than applications that are updated and made more secure on a regular basis.

The Un-patchable

Microsoft quickly issued patches for these vulnerabilities but neglected machines running Windows NT, 2000 or XP. As Microsoft no longer supports several of these older operating systems. Joe Barrett, senior security consultant with Foreground Security warns that due to this support expiration, we may be witnessing the first true “forever-day” vulnerability.   Microsoft’s stance on halting security patches for older operating systems, even in this case where it is clear the products were vulnerable at the point of sale, has resulted in enterprises knowing that some systems will end up exploitable-but-un-patchable. It is easy to forget that Windows XP still holds 17.18% of the market. Given how Microsoft has articulated this issue, it is clear they expect an exploit to be developed soon.


Plan of Action

While Microsoft have rightly been relatively quiet about vulnerability details, the patches released may help inform exploit creation by revealing the nature of the flaws being addressed. As both security researchers and blackhats are inevitably working toward creating a workable exploit, enterprises need to apply the patch released to all applicable systems without delay.   To prevent serious compromises, systems running un-patchable versions of Windows will need to be isolated and removed.  The most likely targets of this vulnerability are externally reachable SSL services such as Web and Mail Servers.

Johannes Ullrich, PhD of the Sans Technology Institute, has outlined several steps that should be taken to address the vulnerability:

1. Highlight for attention all SSL services, it may be useful to check your last external infrastructure scan to ensure all have been identified. It is advisable to repeat the scan on a regular basis.

2. Examine internal servers, only one infected operating system on the network could expose harder to reach systems.

3. Audit all devices, such as laptops, that leave the controlled perimeter. While they are unlikely to be listening for SSL connections, insufficient locking down mechanisms may have left vulnerable instant messenger software or older SSL VPN services exposed. A port scan should indicate the degree of vulnerability.

4. Patch in a controlled, verifiable and reproducible way. Good operations and procedures will offset the chance of vulnerable systems remaining after hurried and ill-conceived patching exercises. The system must also be rebooted after the patch is applied to be sure it takes effect.

5. Ensure you are aware of how to disable certain ciphers or SSL modes of operations in case Microsoft publish workarounds.

(An inventory of systems is essential to be prepared to treat vulnerabilities, formulate counter-measures and alternative emergency configurations)

Cisco Guidance

Cisco published a blog focusing on WinShock reporting multiple vulnerabilities bundled within the single CVE. The vulnerabilities range from buffer overflows to certificate validation bypasses. Also published were a number of Snort rules, SID 32404-3242.  For a technical breakdown of how a potential exploit may work see “IBM X-Force Researcher Finds Significant Vulnerability in Microsoft Windows” by Robert Freeman.



How bad is the SCHANNEL vulnerability (CVE-2014-6321) patched in MS14-066?

Microsoft Security Bulletin MS14-066 – Critical

IBM X-Force Researcher Finds Significant Vulnerability in Microsoft Windows

Market Share of Operating Systems

Information Security Assurance from a Resilience Perspective

Information Security Assurance from a Resilience Perspective White Paper

Today the global business environment is more complex and interconnected than ever before. Organisations rely on electronic data as their lifeblood, and the systems that enable the storage, transport, access and manipulation of this data have become critical. Even simple spreadsheets can become mission critical systems in their own right and this has resulted in an era where networks and the applications sitting within them have become the very backbone of every organisation regardless of their size and market sector. As a result, networks and applications are a primary channel for businesses and one that they must protect if they are to meet their businesses objectives and in the end, to survive.

For many organisations, their approach to information security results in a fortress mentality that focuses on the implementation of defences and preventing an attack. It is increasingly acknowledged however, that we cannot build sufficient defences to be 100% secure while allowing our organisations to effectively carry out their business, and as such, for many this siege based approach is no longer acceptable. A more resilient approach to the management of information security is therefore needed. This approach should not only take into account the mentality that organisations cannot be 100% secure but also acknowledge that the cost of securing our organisations can be large. A risk based approach should therefore be adopted which takes a more holistic approach to managing information security that accepts that the risks cannot be fully mitigated and adopts a resilient approach. Doing so will therefore place greater emphasis on the importance of gaining an appropriate level of assurance.

Following on from our recent article in SC Magazine on the topic of resilient information security, we have now issued our white paper. A copy of which can be found here.

Information Security Assurance from a Resilience Perspective

SC Magazine recently published an article by our CEO, David Stubley on the topic of resilience and the need to adopt a holistic approach to information security.

“If we accept that our defences will no longer hold against every attack and we cannot therefore 
be 100 percent secure, then we also need to think about information security from a new perspective.”

The full article can be found here and a link to our white paper can be found here.


Heartbleed: Insufficient Cauterisation

Unearthing Haemorrhages

To date much effort has been focused on remediating common sources of Heartbleed, without taking into account that the vulnerability affects more than just common ports (such as 443 for HTTPS). Many online testing tools limit the scope of tests for Heartbleed to a subset of ports, thereby providing limited assurance and are focused on externally facing assets. During recent engagements, we are still finding Heartbleed, often on internal management systems where the disclosure of sensitive information could aid a malicious insider. It is also important to understand that the vulnerability may not only lie within an Operating System but also in any application containing and utilising a vulnerable OpenSSL library. Therefore an organisation’s approach to patching must be holistic and take both of these areas into account.

For those requiring defensible assurance, any service implementing SSL on any port should be tested and if required, treated. Additionally, whether vulnerabilities are found or not it may be possible that the Heartbleed bug was already exploited prior to discovery or patching. There are techniques that can be employed to flag telltale larger-than-typical TLS heartbeat responses from a server and additionally, reveal exactly what information was compromised.

However, a single test cannot provide certainty that the vulnerability will not be reintroduced into the system via the installation of an unpatched vulnerable application or embedded system. Therefore, it is vital that your ongoing assurance activity continues to check for issues long after they have left the media spotlight.

If you would like support in completing any assurance activity then please get in touch using:



The security bug, CVE-2014-0160, known as Heartbleed was disclosed in April 2014. Heartbleed directly affects the Transport Layer Security (TLS) cryptographic protocol that uses affected OpenSSL cryptography libraries (versions 1.0.1 to 1.0.1f). The aim of TLS is to provide communications security and privacy over the Internet. Applications that utilise this protocol range from Virtual Private Networks to email and web services.

Heartbleed exploits vulnerable OpenSSL libraries to compromise secret keys used to encrypt traffic, allowing access to transmitted data including usernames and passwords.

Additional Remediation

Research from the University of Maryland has identified that while many system administrators quickly applied patches to correct the Heartbleed vulnerability, many failed to properly implement revocation of current certificates and ensure the re-issuing of new new certificates. The final step of revocation and re-issue is vital,  as the Heartbleed vulnerability could have been used to gain access to the private keys of a server.



How to Detect a Prior Heartbleed Exploit


DON’T PANIC – Drupalgeddon SQL Injection Vulnerability

On October 15th 2014, the security team at Drupal announced that all Drupal 7 web sites were vulnerable to SQL Injection attacks.

A German security firm, SektionEins, discovered the flaw, advising:

“A malicious user can inject arbitrary SQL queries. And thereby control the complete Drupal site. This leads to code execution as well… can be exploited by remote attackers without any kind of authentication…”

Drupal 7 and all following releases can be easily compromised (with the exception of the newly released 7.32 or 8 beta2). Drupal 6 is also vulnerable if it utilises the DBTNG module used for Drupal 7 PDO database compatibility. This highly critical vulnerability, CVE-2014-3704, allows anyone to execute PHP code on a vulnerable server. Remote attackers are able to delete everything, install backdoors into the website, change any data in the database including passwords and modify any data hosted on the server. The vulnerability hands over complete control of website content, and low skilled attackers are able to exploit this by deploying easily found attack scripts.

First Steps:

The first step is to check your version of Drupal, immediately. If you have 7.32 or 8 beta2 then you do not need to do anymore. If you do not have 7.32 or 8 beta2 then you should upgrade without delay.

Drupal upgraded, now what?

We will outline the bad news and then discuss some restorative and assuring good news.

The Bad News

When the security team at Drupal warned the world on Wednesday 15th October 2014 of the SQL injection vulnerability users were warned to assume their websites were compromised if not updated by October 15, 11pm UTC.

The reason for Drupal’s caution is that a late patch will potentially not affect vulnerabilities, such as backdoors, already introduced into the system. It is also possible that an attacker, once gaining control of the site in question, will have patched it themselves to retain control and stop other hackers gaining from the potential spoils of the vulnerability.

Drupal have advised, that sites not updated within the six hour timeframe, should be taken offline. All files and databases then have to be deleted and then the site must be restored from backups made before October 15th 2014. Finally, the website must be updated before bringing it back online as the backup will be vulnerable.

The Vulnerability

The bug was introduced in early 2011, allowing the execution of arbitrary code remotely with only one HTTP request and no knowledge of the site is required to conduct the attack.

Drupal handles all database queries by using prepared statements with placeholders conveniently indicating where in the SQL query the input from the user should be included.

SELECT * FROM {users} WHERE name IN (:name_0, :name_1)

Above, variables are bound to :name_0 and :name_1. As this is a prepared statement the attacker cannot inject values into it thereby controlling the SQL query. The placeholder number must be correct so Drupal expands :name to :name_0, :name_1 using a function, this function however is flawed. The flaw is that it incorrectly expands the array to :name_$key0, :name_$key1. SQL queries can now be manipulated as an attacker has control over $key0 and $key1 as seen below.

SELECT * FROM {users} WHERE name IN (:name_test) OR name = ‘Admin’ --, :name_test)

The above query results in an SQL injection giving full control of the database to the attacker. SektionEins have also published a blog demonstrating a proof of concept for an attack that takes one GET request with a cookie that will not be shown in any log.

Password Change Attack

We recreated a password attack in our lab and discovered that the only indication of the standard attack was the log below: - - [03/Nov/2014:08:49:51 -0500] "POST /?q=node&destination=node HTTP/1.0" 200 8889 "-" "-"

This log was linked to changing the username and password of the administrator using the following script.

The Good News

The advice given by Drupal to restore the website back to backups made before October 15th 2014 is what could be considered wiping the slate clean instead of trying to identify if the slate is dirty first. Drupal’s advice may also not guarantee the site was not already compromised, due to the vulnerability existing since early 2011. A proportional response should be the first step to take. We will outline steps that can be taken that will help identify the potential impact of this vulnerability on a given site. As the attacks are so simple it is likely many are being perpetrated by ‘script kiddies’. Assuming this makes it unlikely that enough foresight or effort was dedicated to removing attack trails such as footprints in logs.

Steps to take
1. A forensic investigation of the logs can reveal suspicious activity and its timing.
2. The database can be investigated for users added and modified.
3. Files can be compared to files in backup to identify changes to existing files and discover any new files created.
4. Traffic leaving the network can be analysed to uncover potential attacker connections.

Ultimately, a risk based decision needs to be made between the likelihood of a successful attack having been perpetrated against your website and the impact and complexity of restoring the site to its state prior to October 15th 2014. It may be pertinent to seek assurance before deciding to commit to a full rebuild of your website as it may not have been breached. This will offset the chance of the loss of incremental changes that were committed to the site after the October 15 backup cutoff date and the time the site will need to be offline and inaccessible.

If you would like support in completing an investigation please get in touch using:


Drupal “Public Service Announcement”

Drupal FAQ

Drupal flowchart of treatment steps and options

SektionEins Blogpost