Monthly Archive November 2015

Security Awareness

WHAT DOES GOOGLE KNOW ABOUT YOU?

“Knowledge is Power” – well Google have taken this phrase to a whole new level. Google is one of the biggest driving forces of the information age. Remember when Google used to be just a search engine? Well, their sophisticated approach to data collection is allowing them to do way more cool stuff. Every other day I come across articles and reports alleging one of the big media companies is intruding on my personal information. Well something dropped the other day which made me think, “what does Google know about me”?

The simple answer is a lot.

The processes I am going to take you through rely on you being logged on to a Google Account (which you probably have). If you have ever logged into an Android phone or tablet, used Gmail, or used YouTube as a registered user then you have a Google account.

What does Google think about you?

I was curious to see what Google thought it knew about me. Below are some of my ‘interests’. To my surprise they were right with a lot. In fact, out of 85 listed interests, google only got 2 wrong.

 

1st

Every time you make a search, go to a website or click an add, Google is watching. In order to serve relevant ads, Google collects data about you and creates a profile.

Find out what Google thinks about you using this link >> http://www.google.com/settings/ads/

Where does Google think I have been?

In existence of my google account, this is spot on. However, this is not all!

2nd

In addition to this, Google can tell you:

  • What is your most visited place (With the full address and postcode).
  • The exact dates and times when you visited that place.
  • What route you took to get to this place.
  • How long it took you to get to that place.
  • The full address and postcode of a stop, if you stop.
  • How long you stayed at the place after you arrived.
  • The full address and postcode of where you went after you visited this place.
  • How long it took you to get to this place (With an exact date and time).

If you want to find out your travel habits, you can do so
by going here >> https://maps.google.com/locationhistory

When do I use the internet the most?

3rd

Google knows this down to the hour! They know I search more at mid-day on a Tuesday. They know search less in the months of July, August and September (Probably because I’m enjoying the sun).

What does Google do with this information?

So you maybe wondering, “why does Google want to know all of this about me”?. This is because your habit are a big deal…in the world of marketing atleast. The more Google knows about you, the better they can target you with products and services. Ever wondered why you kept getting adverts of “cars” weeks after you looking for cars online? Yes, Google is paying attention! By using direct marketing, you are more likely to engage with their adverts. Think of it as tailor-made advertising.

What if I don’t want Google to know this about me?

If this article has made you a bit uncomfortable about how much information Google is collecting about you, then you will be happy to know that there is an option to opt out by clicking the link below.

https://tools.google.com/dlpage/gaoptout.

This will stop the Google Analytics from following you.

Extra Security for Black Friday and Cyber Monday

As major retailers across the country announce the recruitment of additional security staff to safeguard shoppers on Black Friday, it is also time for online businesses to ramp up their security in anticipation of escalated sales around 28th November including Cyber Monday on 30th November.

Last year an estimated £810 million was spent on Black Friday, a date when stores offer massive discounts to kick start a Christmas shopping frenzy. Originating in the United States the phenomenon has been gaining popularity in the UK since 2010 and many businesses are already predicting that Black Friday 2015 will be the busiest shopping day in UK history.

It is not just competitive fellow shoppers that present a danger, however. Those shopping online will also be in need of additional protection. In recent weeks there have been multiple warnings about large spam and phishing campaigns where goods that are paid for will never be delivered.

Mobile phones are now also particularly vulnerable as cyber criminals have shifted their focus. American statistics show that 1.3 per cent of all phone-based sales are fraudulent, which is twice the 0.8 per cent on PCs and nearly three times the 0.5 per cent on tablets. Companies wishing to make the mobile shopping experience as frictionless as possible are, it is claimed, putting fewer checks in place and criminals are exploiting this loophole.

Unfortunately, cyber security breaches tend not to be instantly visible, particularly where client side injected malware (CSIM) is concerned. CSIM presents a significant threat to sales, profit and brand reputation by injecting unwanted advertising and malware directly onto the consumer’s browser or device. Once installed the attackers can use it to lure customers to alternative sites, sometimes persuading them to give away personal data and payment information.

It is estimated that currently one in three devices in the UK is infected with CSIM. IOS (Apple) devices are particularly at risk, with infection numbers having risen from five percent to 20 per cent over the last year.
Responsible retailers should consider a number of precautionary tactics. In anticipation of higher transaction volumes they must be vigilant, and prepare for a potential attack. Testing and patching should therefore be a priority at this time of year, although of course it is an ongoing process made more effective by a scheduled programme of activity. Those following PCI DSS and ISO 27001 guidelines will be in the strongest position to defend their customers’ data.

In the event of a breach, however, an incident response plan will ameliorate some of the impact of criminal activity. Early action with the help of specialist support will help to mitigate damage. Effective safeguarding is best undertaken with expert input in a measured a prescribed manner but it is not too late to put in place some effective defences before the biggest day in retail spending arrives.

Magento Exploits – a technical review

By Mustafa El-Jarrah Information Security Consultant, Security Risk Management Ltd

Exploits appear in trends with the magnitude and duration of these trends exacerbated by the community edition download zip not being updated with the latest patches, often requiring the end user to run patches immediately after installation. This combined with sluggish patching practices in live deployments (often out of fear of breaking something) lead to exploits still being prevalent in the wild several months after their public disclosure date.

The most common type of evidence left is usually Access Log data from the server software, less commonly, there can also be execution and error log data for the PHP preparser software.

Unfortunately, these PHP logs are uncommon and often disabled by default but when present, can be instrumental in definitively distinguishing legitimate code and access from malicious ones.

MAGMI Plugin

In the first 2 quarters of the year, the prevalent exploit within the Magento ecosystem was a vulnerability within the Magento Mass Import (MAGMI) plugin that allowed file uploads to bypass the Magento authentication steps.

Artefacts associated with this type of exploit were often located within the /plugins/ or /magmi/ directories of the compromised site.

Magento version 1.8 and older is affected.

Magmi version 0.7.17a and older is affected.

Key Identifiers

Proof of concept:

http://www. magentosite.com/magmi/web/magmi.php
Under upload new plugins:
Click on “choose file”

Magento plugins are zipped php files; create or obtain a php shell and zip the file.

File: evil_plugin.zip. Once the file has been uploaded, it will say: Plugin packaged installed.

Your malicious example.php file is extracted. You can access it by navigating to your file from: http://www.examplesite.com/magmi/plugins/example.php
Artefacts associated with this type of exploit were often located within the /plugins/ or /magmi/ directories of the compromised site.

Shoplift

Towards the second quarter of the year, an exploit that leveraged a vulnerability in the visual (what you see is what you get, or “wysiwyg”) page editor build into the Magento administrator tools.

This allowed an attack to run code or commands, retrieve security tokens and inject data into the database.

This attack was most visible in the server access logs where abnormally large numbers of ‘POST’ requests were being directed towards the WYSIWYG system, often with requests to either uploaded shells or pages requiring a security token in the URL.

Magento version 1.9.0.1 and prior is vulnerable.

Key Identifiers

The attack in this example is written in Python and is implemented through a ‘POST’ method. Typical exploit attempts would look like the following within logs.

62.76.177.179 – – [23/Apr/2015:00:45:44 -0400] “POST /index.php/admin/Cms_Wysiwyg/[HIDDEN] HTTP/1.1″ 403 1880 “-”

185.22.232.218 – – [22/Apr/2015:00:42:38 -0400] “POST /index.php/admin/Cms_Wysiwyg/[HIDDEN] HTTP/1.1″ 200 2211 “-”

Code

Lines 1-3 create an account and sets the target for exploit. The target consists of the target’s domain and a static vulnerable URL which is exploited for this attack.
Lines 5-14 is a SQL statement that is executed by the target servers. It inserts a new admin user inside the database.
Lines 19-22 is the ‘POST’ process with the encoded form of the ‘getCsvFile’ function which was identified to be exploitable and acts as the entry point for the SQL injection.
Lines 24-27 contain a condition statement to verify whether the exploit was successful – if it was, it prints out “SUCCESSFUL” along with the username and password. If it wasn’t successful, it prints out “UNSUCCESSFUL”.

Mage.JPG

Although the method of entry was not identified on this attack, once the attacker gains access to the site. They inject app/mage.php with code that captures ‘POST’ data being sent to the server. The code encrypts the captured data which includes credit card and billing details and places inside a fake image file entitled ‘mage.jpg’; hence the name of the attack. The image name can be different however this is the most common one that we have come across and the same name reported by other people that have seen the compromise.

The encrypted image can only be opened by the attacker as he would have the private key corresponding to the public key incorporated within the exploit code.

Key Identifiers

Open the file app/Mage.php.
The first part of the file should contain ‘Notice of License’ as follows
?php

/**

* Magento

*

* NOTICE OF LICENSE

*

* This source file is subject to the Open Software License (OSL 3.0)

* that is bundled with this package in the file LICENSE.txt.
If there is other code present prior to the code above then this most likely indicates an issue. There could be a legitimate reason as to why there is other code present however, in the majority of cases this would likely be of a malicious nature.

Web Shells

Common Web Shell capabilities that we’ve encountered:

File Browser/Editor
File Uploader
Permissions Editor
Database UI and SQL interface
Basic Bruteforcing tools
Basic Hash Cracking for passwords (3 providers)
Live PHP execution
Encypted POST variable back door (this is unusual, it’s often either/or with the GUI or POST vars execution)
Encrypting functionality (also unusual, looks like it was used for hiding what data was extracted)
Reverse Shell functionality (when supplied with an IP and port, the shell can be made to run a Perl script to Dial Home)
Functionality to hide from search engines (checks requests for known search engine UserAgent IDs and returns a HTTP 404 response)
Ajax enabled Web console
Cookie handling
Hex Dumping file data
Scraping of ExploitDB for known vulnerabilities matching the installed system
Self-Deletion
Important to note that web shells have generically been base64 encoded in the past and it was relatively easy decoding them to analyse their functionality/capability. However, as of recent times, we are seeing a new approach to web shells where they are obfuscated with base64 encoding and also encrypted with a password.

This means traditional means of decoding are failing and after doing some research, there doesn’t seem to be a viable way of decrypting them which leaves us with very little when it comes to describing their capabilities in the PFI reports.

SRM Blog

SRM Blog