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.
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.
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.
Every now and then one of our readers will send in a link to an article that we just have to share.
A really special thank you to Brandi from all of us here at ITSG for sending this one through.
To Heather over at Backgroundchecks.org, really nice article!
So for everyone who wants to get a better understanding of what Social Engineering (S.E) is, go and have a read of the following article.
“Working With People An Introduction To Social Engineering.“
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.
There is a really good article over on Secmaniac.com that describes where a lot of penetration testing companies are going wrong lately.
We encourage all our customers to take 5 minutes out of their day and have a read.
You can find the full article here.