Vulnerabilities « IT Security Geeks

The Times They Are A Changing….

There’s been a lot going on over at ITSG over the past few months and we’re almost ready to share it with everyone.
Keep an eye on the blog as we’ll be posting all updates and news on here over the upcoming weeks.
Stay safe out there people.

An Obfuscating Furore

When something goes wrong, it is common for those affected and those responsible to play the blame game, often to place the responsibility on any doorstep but their own. Last week, as the result of Chinese app developers using a counterfeit version of Xcode now dubbed “Xcode Ghost”, a number of malware-infected apps (currently believed to be in the region of 300) made it past Apple’s vaunted review process and onto their App Store. As the dust settles and the situation is now believed to have been brought under control, many are now pointing fingers as to who or what allowed this to happen.

Some background; Xcode is Apple’s own suite of development tools for iOS and OS X, it is freely available to developers for download and use. A large number of Chinese app developers were duped into downloading and using a version of Xcode from an unverified source. This version, the afore-mentioned “Xcode Ghost”, was embedded with malicious code that could then perform a number of functions. Primarily it was found that the code could upload device and app information to a command and control server, however it was later discovered to also be capable of phishing user credentials; hijacking and opening specific URLs; reading and writing data to and from a user’s clipboard. Also, debated by some, it is believed to be capable of phishing for iCloud passwords. All quite scary stuff for the end user. But can any one party be blamed and made responsible for this?

Apple have long prided themselves on the security and quality control of their App Store. Certainly, this is the largest influx of malware infected apps ever to make it past their system of checks. It is also very difficult to protect against the unprecedented. How can you put measures in place to guard against an angle previously unconsidered? While many would say that this leaves Apple with egg on their face and a dent in their reputation, it would be hard to accuse them of neglect or carelessness.

The developers who were duped by the counterfeit Xcode Ghost must surely bear some of the brunt? Apple’s Gatekeeper software is shown to have thrown up warning flags regarding the use of the maliciously modified software, warnings that the developers would had to have deliberately ignored to proceed in using the tool for their work. This could be seen as very naive, but why was this fake version ever able to make it into their hands in the first place?

In answer to that, some point to the Chinese government’s stringent Internet restrictions, their “Great Firewall”. As a result of this, cross border downloads such as those from Apple’s official store, can take a very long time to complete. Apple software, particularly Xcode, is notorious for how long downloads can take even in Western countries. Because of this it appears that many Chinese developers chose to try and obtain Xcode from quicker, unofficial sources. This is how hackers were able to trick so many developers into downloading and utilising Xcode Ghost.

Amongst all of this there has been little discussion of who created Xcode Ghost. Who was it who set these wheels in motion, who was their target and what were they aiming to achieve? The consensus at present seems to simply be “Chinese hackers”. The basis for this assumption appears to be the fact that it was Chinese developers who were tricked into crafting the malware infected apps. The apps affected were those most popular in China, leaving them with the majority of affected users, though that is not to say that users globally were not also affected.

The truth is that there is simply not enough evidence to make any valid accusation of culprits at this point in time. What is concerning as is often the case when the blame game is played, is that too few seem to be asking the right questions. How can the stolen data be used, to what end and who benefits the most from it? With these angles considered it seems increasingly less clear that simple “criminal hackers” are behind this attack. Maybe such speculation at this stage is pointless and focus should instead be on prevention; never the less, it is our opinion that uncovering the true source and intent of Xcode Ghost would allow pre-emptive prevention, instead of just re-active measures. By keeping a close eye on further developments and seeing how any stolen data gets used, we may yet get some clues as to the purpose and origin of this attack on China.

The dangers of pre-installing Java on corporate laptops

For the last couple of weeks all the IT security news headlines have revolved around the OpenSSL Heartbleed vulnerability (CVE-2014-0160), so we’ve decided to write about something completely different to keep things interesting.

For years now, we have been advising clients that it is good practice to have secure laptop, desktop and server builds across their estates. This allows for a baseline of each Operating System that gets deployed and also means that your network and system administrators have a high level of control as to what software is installed across the estate. This does mean that more time will need to be spent upfront making sure that these Operating System builds are both functional and secure for the end users, but the rewards for doing this considerably decrease the overall risk to your organization. When using an Active Directory domain, it is also highly recommended to lock down the Operating System builds even further by using Group Policy Objects (GPO’s.)

Our team were recently asked to conduct a penetration test for one of our clients, with the scope being a web based problem ticketing system. We were issued a corporate laptop to allow us to familiarize ourselves with the application, to read internal documentation and the relevant processes and procedures around it. This was to allow the team to perform a complete end-to-end security review for the client. The laptop was also configured with VPN access, allowing the team to work remotely from our offices.

The laptop was running Windows 7 and had been locked down, preventing us from installing any standard programs onto it (such as various penetration testing tools.) The laptop also did not come with Local Administrative rights configured (thankfully,) and we were only given standard user privileges. To add to the layers of protection around the client’s internal infrastructure, all connections to the Internet had to go through the internal corporate proxy server.

One thing that our team discovered is that the corporate laptop included Java within the build. The internal corporate proxy server was configured to block downloads of Windows executable files and installers (.exe’s and .msi’s,) however, downloading of Java applications (.jar files) was allowed. Thanks to this, the team were able to run a web application proxy on this laptop. This in turn lead to our team being able to perform the full penetration test of the application, all from the client’s corporate laptop.

During the penetration test, the team discovered that the application was vulnerable to numerous high-risk web application vulnerabilities, however, this really is the least of our client’s worries at this point. We never increased the scope of the penetration test to perform this testing and never violated the client’s security policy either, as we didn’t install anything on the laptop, we just downloaded and ran software. Technically, Java ran the application, we just downloaded it.

There are no security controls in place to stop internal users from performing the same steps that we did to run BurpSuite, or any other Java applications on these corporate builds. This poses a huge risk to this client, their internal applications and ultimately, their overall reputation. Yes, there is monitoring software and anti-virus software installed on these PC’s and attacks could be traced back to IP addresses and user names, however, host monitoring logs would only be reviewed after the attack and would be a responsive counter measure, not an active protection measure.

Our team were tasked with performing a penetration test of just one of the internal corporate web applications, but just like other large corporate clients, there are a lot more internal web applications in use within this organization. This means that an internal attacker could easily target any one of the client’s numerous other web applications, all from their own corporate PC. When you have over 100 internal users, this exponentially increases the risk to all internal web applications, and to the organization as a whole.

This vulnerability would also allow internal users to download these tools and to attack other external applications not within the client’s infrastructure or realm of control. If an internal user were to compromise (or attempt to compromise) a web application hosted by the client’s competition, this attack would be seen as coming from the client’s network. This, in turn, could lead to all sorts of legalities and difficult conversations.

We highly recommend that all corporate Operating System builds be penetration tested before being deployed so that vulnerabilities such as this can be mitigated before the builds are issued to internal users. At ITSG we take the security of our clients’ networks very seriously and this is why we always aim to point out as many vulnerabilities as possible during all our penetration testing engagements.

If you currently have a corporate Operating System build that hasn’t been through a thorough penetration test, then please consider doing this as a matter of urgency. ITSG will gladly assist you with developing secure Operating System builds or performing penetration testing of these builds if you already have them in place. Please contact us for more information.

Follow us on Twitter and/or Facebook to see more updates.

Vendor Security Challenge

To keep things interesting, we’ve decided that we’re going to open up a challenge to all computer hardware/software vendors out there.

We’re looking for 10-20 vendors to come forward and put the security of their devices and/or applications to the ultimate test. So, do you trust your developers and the security of your devices, if so then get in touch.

What we’ll be doing is performing an in-depth penetration test again the device/application, and then publishing a overall security score out of 10 for the Vendor and the product tested. We will not be disclosing any vulnerabilities publicly for this, only the ratings, vendor’s name and device/application name. Each item tested will have a Blog post written about the device/application, and the overall winner will also get additional Blog post about your device/application and why it won overall in our security testing.

As we will be performing a full penetration test against these devices, we will also be writing reports and documenting any findings and how to mitigate against these vulnerabilities. These reports will remain ITSG company property, and your respective report will be available to purchase for a fixed cost, should you wish to have a copy.

*Please note that we will only sell the report to the vendor, you will not be able to buy competing vendors reports.*

Are there any vendors out there who are up for the challenge? If so, please use get in touch via the Contact Us page, and good luck!

We’ll keep you all updated of entries and any vendors that take us up on this challenge.

LinkedIn vulnerability.

We have tried to contact LinkedIn via two mediums, their social media service and twitter. We have as yet received no response regarding our communications. We have subsequently decided that we ought to alert people to this.

On the morning of 07/06/2012 an I.T. Security geeks team member changed his LinkedIn password.

The changes were implemented via a web browser.

Several hours later the user received an app store notification of a LinkedIn app update for an IOS device; and proceeded with the  update to LinkedIn version 5.0.3 dated 06/06/12.

User was however still able to view and functionally use the LinkedIn app despite not being authenticated with the new password on his mobile device.

It appears that when passwords are changed on site, the revocation of access and subsequent re-authentication of all previously authenticated devices in the user’s access matrix does not occur.


To test the theory again, user logged back into LinkedIn via web browser, changed his password and then used the IOS device in question to post a test status to his own profile and to send a message to a connection.

Despite 2 password changes, the IOS device still maintains its active session and allowed full compromise to the users account.


This poses a high risk to users.


Personal Data may be compromised.

Users cannot effectively revoke access to their profiles by changing passwords in the event of their devices being lost or stolen. If you have in the past attempted to lock out unauthorised user access on a lost or stolen device by changing your password, please be aware that this does not seem to work. Try to contact LinkedIn to assist. Our best possible advice is to uninstall the LinkedIn IOS application until further notice.

Multiple vulnerabilities in ZyXel GS1510

A few of weeks ago, one of the vulnerabilities that we identified was publicly released on These vulnerabilities were discovered in our testing environment while playing around with a ZyXel GS1510 ethernet switch.

This advisory was publicly released on the 2012-03-14 12:57:15 with an Upsploit reference of UPS-2011-0042.

The vulnerabilities that were discovered where the following:

1. The cookie for the admin user of the switch stored both the admin username password in clear text within the cookie.

2. The passwords of any users logging into the switch were being submitted in clear text over HTTP via the following form:

HTTP Request

GET /login.htm HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1) AppleWebKit/534.48.3 (KHTML, like Gecko) Version/5.1 Safari/534.48.3 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Cache-Control: max-age=0
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: admin=password123
Pragma: no-cache
Connection: keep-alive
Proxy-Connection: keep-alive

3. Cross Site Scripting

The payload fe07b</title><script>alert(xss)</ script>b7e71e54af6 was submitted in the name of an arbitrarily supplied request parameter.

This input was echoed unmodified in the application’s response, as can be seen below.

This proof-of-concept attack demonstrates that it is possible to inject arbitrary JavaScript into the application’s response.


GET /images/?fe07b&lt;/title&gt;&lt;script&gt;alert(1)&lt;/script&gt;b7e71e54af6=1 HTTP/1.1 Host:
Accept: */*
Accept-Language: en
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0) Connection: close
Cookie: admin=password123


HTTP/1.1 200 OK
Server: thttpd/2.25b 29dec2003 Content-Type: text/html; charset=iso-8859-1 Date: Sun, 18 Sep 2011 16:30:14 GMT Last-Modified: Sat, 01 Jan 2000 00:00:03 GMT Accept-Ranges: bytes
Connection: close
&lt;HEAD&gt;&lt;TITLE&gt;Index of /images/?fe07b&lt;/title&gt;&lt;script&gt;alert(1)&lt;/script&gt;b7e71e54af6=1&lt;/TITLE&gt;&lt;/HEAD&gt; &lt;BODY BGCOLOR=&quot;#99cc99&quot; TEXT=&quot;#000000&quot; LINK=&quot;#2020ff&quot; VLINK=&quot;#4040cc&quot;&gt;
&lt;H2&gt;Index of /images/?fe

Congratulations go out to Neil Fryer for identifying and reporting this issue.

We would also like to extend out gratitude to the staff at ZyXel and also the guys at for working with us to get these vulnerabilities patched in a timely manner.

This is just another reason why it’s always a good idea to have a penetration test or at the very least a vulnerability assessment conducted on all new devices that will be deployed within your organisations network.

If you would like any details on our device security testing or penetration testing services please feel free to contact us.


Filed under: Vulnerabilities— Tags:

Ever changing faces of vulnerabilities.

McAfee’s latest proof-of-concept showed the ability to seriously injure someone with a direct cyber attack. This involved an attack on an insulin implant pump. The pump could be induced to fully discharge it’s contents. In a diabetic, this will cause hypoglycæmia. This may result in death or brain damage if prolonged.

We’d like to congratulate Barnaby Jack for bringing attention to this.

We at I.T. Security geeks have long held the belief that this sort of thing is possible. While our focus has largely been directed at conventional, common place vulnerabilities we spend a fair amount of time working with obscure appliances and identifying issues with those products.

In my own area of influence, I’ve exploited rectifiers in controlled circumstances to effect power failures and fires (Easier than Jack’s Medtronic exploit, as you really don’t need to have much knowledge and most rectifiers are deployed with factory default PIN codes for administrator access). Don’t believe me? One of the world’s foremost suppliers of DC power systems has a default password for the user: “Admin” that is: “1”

Yes, the number 1.

I have personally accessed production power systems in operators where this default was discovered, and upon making my recommendations for immediate action was told, “No. We keep it like that to make it easier for our technicians.” or “We don’t perceive a problem with that.”

No perceived problem? How so? The manual for this particular device tells me:

The User has full access to all menus; including update the OS application and modifying, adding, and deleting Users.

Via the WEB Interface, a User (with proper access level) can:

View real-time operating information (rectifiers, converters, AC, DC, Batteries, etc.).

View and download information recorded in logs.

Send control commands.

Set programmable parameters.

Download and upload configuration files.

Download firmware to the Controller.


Curious, is it not?


I truly guarantee that if you are a telecommunications operator or co-location provider, you have this vendor’s product somewhere in your network. Call us to chat.


Moving Towards A Darker Future…

Smart grids are being hailed as a potential solution to the impending energy supply problems the world will face over the coming years.

The intent is to intelligently manage use in accordance with supply and alter tariffs to drive healthy usage patterns; Fair enough. It’s clever business welcomed by all, that is if we ignore the obvious high cost of delivery.

Accounting and sentiment aside, the real issue we see is the inherent risk in creating a management network such as a smart grid.

Many current investigations into the technology, as well as planned deployments tout trendy capabilities.

Mobile device compatibility i.e. the ability to control your homes appliances remotely to take advantage of low tariff times. Despite the obvious limitations in the theory, I am somewhat surprised that this is even being thought of anywhere; that is anywhere with an eye on Health and Safety.

Random and malicious attacks on grid residents could compromise authentication details in a number of ways and while mischief and damage could result, the same problem exists elsewhere where damage would be so much more significant.

Mobile Network Infrastructure 

In the ever demanding economic climate, many telecommunications operators across the globe have invested significantly in expenditure reduction programs.

In one way or another, smart meters are finding themselves part and parcel of a mobile network for this reason. Smart meter solutions get installed with relays for cutting supplies of energy, allowing to switch energy sources or disconnecting of subtended devices such as network equipment.

In almost all cases, solutions are scoped in a manner that gives very little consideration to direct attack scenarios. It is a fact most solutions are sold on the basis of cost savings, unified control and management capabilities and not security. If we are learning one thing of late, it is co-ordinated infrastructure attacks are possible and happening as we speak. We are also certain Iranian Nuclear Enrichment facilities are a lot harder to penetrate than your average mobile operator and it was done with impunity and anonymity.

It’s not all doom and gloom though, our high value penetration testing team at I.T. Security geeks can help. Contact us for more information.

An Open Letter to Software Vendors

On the 28th September 2011, we notified a vendor about multiple security vulnerabilities in one of their products, and requested contact details of who to send the details on to.

The initial response from the vendor support team took 6 days.

The complete details of the vulnerabilities were disclosed to the vendor on the 5th October. These included screen shots, HTTP requests and responses, and Proof of Concept code for the vulnerabilities. After that no response was received.

We then sent another e-mail to the vendor on the 11th October, asking for an update on these issues, or if they had even received our original e-mail with the details of the vulnerabilities.

We received no response from the vendor.

On the 8th November, we finally received a response stating “These have been replicated by R&D and they will fix in a later release.” No “Thanks for your help guys”, no dates that these will be patched, no responses to our other queries.

We followed this e-mail up with a response to the vendor, asking to work together on a timed release, and to agree on some reasonable dates. The vendor response was “I have asked for timescales for the fixes and will update you when these are released.”

Now just to be clear, we are not getting paid to disclose these vulnerabilities to any vendors. We are doing this to help make the Internet and networks in general a safer place for all.

We don’t ask for much, just credit for the disclosure of the vulnerability, and a timely patch to mitigate the vulnerabilities. It really doesn’t need to be this difficult to report vulnerabilities, and a little bit of thanks and courtesy never hurt anyone.

To all software and hardware vendors out there, can you please take a few moments to read the Wikipedia article on Responsible Disclosure, which can be found here. Then please try to work with your relevant teams, to make it easier to report vulnerabilities in your code, and work with you.

We understand that not all vendors can afford to hire fully fledged security teams, and most security professionals are willing to help you secure your applications and devices just for the credit of finding the vulnerability in your product. That’s got to be the cheapest application security assessment that you’ve ever had!

Little things, like an e-mail address, or a form on your website to contact your product security team, or even your developers would make the world of difference. This would also help to make sure that we as security researchers, contact the relevant teams within your organisation right off the bat (and don’t get sent around the houses, trying to do you a favour). This way, we can always deal with the same person (or team) within your organisation, and get any vulnerabilities mitigated in a timely manner.

Please guys and girls, help us to help you. We’re giving you free security advice, educating your developers and strengthening your products, all this for a one liner in your security patch disclosure notification.

Think about it…



Filed under: News,Vulnerabilities