3S Labs Banner

Thursday, August 28, 2014

Attack Patterns of 2013 and Lessons for the Future

Verizon DBIR 2014 is one of the most comprehensive and well researched report on various attacks and data breaches as seen by companies involved in attack & incident analysis and threat intelligence during 2013.

2013 Attack Patterns


As per the Data Breach Investigation Report (DBIR), year 2013 has seen top attacks and incidents in the following areas:
  • Point-of-Sale Systems
  • Web Applications
  • Cyber Espionage
  • Attack on Financial Services

Top attack patterns


Point of Sale (POS) Systems


It was found that majority of the attacks on POS systems were external in nature i.e. from outside the operating network. The intruders used simplistic scanning tools for identifying POS systems over the Internet. Once identified, guessed (educated) passwords and public exploits were the main tools of compromise to gain access in the systems. RAM scrapers were the primary tool of choice for these threat actors to collect decrypted payment related information including credit card details.

Web Applications


Web applications are surely the target of choice for most attackers. The amount of bug bounty earned by researchers across the world from companies like Google, Facebook, Paypal etc. for web application vulnerabilities speak for it.


However it must be considered that Bug Bounty programs should not be treated as a replacement for conventional Penetration Testing. The two approaches are complementary to each other. Any professional services engagement is usually time boxed and ideally should focus on core aspects of the security of target applications including its possible attack surfaces and issues that directly affect the business operations of the application. Given a large application, it may not be possible to identify all possible vulnerabilities within the defined time frame. This is where the Bug Bounty model comes in. The crowd sourced nature and pay per vulnerability model is effective in identifying and eliminating maximum low hanging fruits in the most cost effective manner. This is a typical case of - Given enough eyeballs, all bugs are shallow. It should also be noted that really complex and interesting vulnerabilities in popular services such as Facebook, Google, Github etc. has also been disclosed as a part of Bug Bounty initiatives. However due to the sheer volume of web applications, it is generally a better approach to consider both professional Penetration Testing and Bug Bounty programs for an effective security testing strategy.

Insider Abuse


It is relatively well known that an Information Technology infrastructure faces threat not only from outside its corporate network but also from inside. There has been multiple cases where Threat Actors were found to be insiders or assisted by insiders.

However it should be considered, due to lack of security awareness and operational security practices, insiders may end up being the pawns or pivot for launching attacks from inside the local network. The exploits of Syrian Electronic Army has highlighted the need for appropriate operational security practices. Even the strongest and most secure IT infrastructure may end up compromised due to lack of security awareness of those operating the systems. Hence it is very important to consider security in all three aspects viz. People, Process & Technology.

Shifting Motivation for Threat Actors


The DBIR also highlight an interesting pattern - The shifting motivation of Threat Actors. This is something inevitable given the rise of Bug Bounty programs and determination of important software vendors to consider defence-in-depth through exploit mitigation techniques to seriously increase the cost of practical attacks.

Threat actor motivation over time

Unlike popular perception, it turns out that random hacking incidents are relatively rare and most of the incidents so far are clearly motivated by economic gains. However over time, the data shows that the threat actors are shifting from Financial fraud to espionage related activities. This is probably an indicator of the growing importance of cyber medium for security agencies of various governments. This might also be an indicator of the growing cost of conducting practical attacks using sophisticated tools and 0day exploits.

Lessons or Inferences from the Investigation Report


  • POS System compromise could have been prevented by minimum security investments - Penetration Testing and basic Operational Security like strong passwords, use of Anti Virus etc. could have prevented a majority of the incidents.
  • Web Application vulnerabilities are still prevalent. The industry in general is very much aware of the issues and the rise of bug bounty programs might help curb misused vulnerabilities to a certain extend as long as companies do not replace conventional Penetration Testing with Bug Bounty programs - they complement each other.
  • Espionage "industry" is on the rise. The amount of leakage from relevant agencies involved in Cyber Espionage and exposure from their contractor companies provide enough evidence of its rise and prevalence. Growing investment will encourage researchers to continue innovative security research. Highly sophisticated tools and exploits will continue, but cost of entry will be very high.

General Takeaway

  • Minimum security investment is a must for any IT based business.
  • For organisations with serious security concerns - It is very important to realise that security cannot be achieved by a one-time investment. It is a practice that involves regular activities and development of individuals responsible for its operations.
  • Human Factor is an important aspect of the overall organisational IT infrastructure. Security development/maturity of the human factor must be equally considered along with the Technological aspect.
  • Vulnerabilities will exist. Most leaders in this business accept this fact and is working towards Defense-in-Depth. However you must reach a certain security maturity level in terms of your internal practices and externally exposed risks before you can start considering such strategies effectively.



Tuesday, August 19, 2014

The ActiveAdmin and Inherited Resource Mess

ActiveAdmin is a very popular library for Ruby on Rails to effortlessly implement administrative functionalities in your Rails application. You end up having Forms and Actions for CRUD operation on your models without just about any effort.

However, we recently noticed a scary scenario for a Rails application using ActiveAdmin due to a 3rd party gem (library) that is being used by ActiveAdmin - inherited_resources.

Scenario:
  • A set of resources for e.g. ResourceA, ResourceB e.t.c are internal to the application and need not be created based on user input. However information for those resources are available to the user without authentication i.e. the "read" operation is available and the corresponding "show" method is implemented in each of the respective controllers.
  • The developers implemented only the "show" method in each of the controllers assuming that the other operations such as "create", "write", "delete" e.t.c will not be possible due to the absence of the relevant methods in the controllers.

Resource creation
Exception without inherited_resource

It turns out that ActiveAdmin by default generates a Rails controller with InheritedResource::Base as the base class instead of the default ApplicationController if the corresponding controller is not already generated. This technically implies that any CRUD operation on the generated controller will be handled by InheritedResource::Base which performs the default action as requested.

This scenario resulted in unexpected authorisation issue in the application. Technically this is not a vulnerability in ActiveAdmin or InheritedResource but due to the difference in behaviour compared to Rails default, an application might end up having unexpected default actions in its controllers.

To summarise:
  • ActiveAdmin is a great utility for any Rails application.
  • If you are using ActiveAdmin, ensure you know what InheritedResource::Base is doing.
  • It is always a good idea to authorise all actions in your controller instead of depending on exception handling.