Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: FIRST2011

#FIRST2011 – Round-up

Well the 23rd Annual FIRST conference has come and gone. Despite the lateness of this blog post (it’s been a tough month), it was a great conference, and as usual the attendees where what made it special. I’ve come to realise that the networking and contacts you gain from conferences like FIRST are more important than the presentations 90% of the time, and I really tried to use that opportunity this time around.

#FIRST2011 Blog posts .:

Alongside networking and seeing the odd presentation (see blog posts above) I also had the chance to work with a friend of mine and somebody I respect greatly in this industry, Martin McKeay from the netsec podcast. We actually met for the first time back at the FIRST conference in 2009 (Kyoto, Japan) and have been friends ever since. I started my journey into security listening to his podcast (amongst others) and have him to thank at least in part for my foray into podcasting in the last year. So, it was with great pleasure (and a little bit of panic) that I agreed to help out with this years FIRST podcast. I’ve learnt a lot along the way, and even started to do face-to-face audio interviews, thanks to Martin’s coaching. So I hope you’ve enjoyed them (or will enjoy them soon).

If you’ve not already heard the podcasts, please check them out and let us know what you think! Feedback is always welcomed.

#FIRST2011 Podcasts (to date) .:

The interviews are still being released (Weekly releases are planned for each Wednesday) and will continue over the coming months, so make sure to keep an eye on the FIRST podcast page to keep up to date 😉

Hope to see you next year at FIRST in Malta!

Advertisements

#FIRST2011 – Funny Pharma: Inside the Web’s leading Rogue Pharmacies

Funny Pharma: Inside the Web’s leading Rogue Pharmacies

Brian Krebs

This talk will cover the world of rogue pharmacies through the lens of 2 of the biggest out there.

When we think of pharmacies we often think of Viagra. However there are many other types on offer, and only cover a small part of the problem.

Around 65% is some form of male enhancement drugs. The rest however, are for much more serious conditions (heart conditions, etc…).

When looking through the affiliate lists of these pharmacies, you find often that they got started in the adult entertainment industry. Because of this it’s often easy to go back in time and find out a lot of information about them. After all, they probably never thought they’d be a cyber-criminal one day. 

If Marijuana is a gateway drug, then maybe the adult industry is a gateway service!

Alongside the adult content and pharma services, many of these criminals are also deeply involved in credit card fraud and in particular Rogue AV. Because of the limited resources for processing these credit cards within the underground, you often find them linked back through Chronopay (started by Pavel Vrublevsky and Igor Gusev, who himself got his start in the Adult industry).

After Igor Gusev and Pavel Vrublevsky parted ways, Igor moved into the Pharmacy industry (Glavmed). Not to be outdone, Pavel followed suit and began a competing service. It was about this time that Glavmed was shutdown by the authorities, opening up the change for Pavel to move in and become the biggest processor for this industry.

[If you want to read more about the tangled web between Pavel Vrublevsky and Igor Gusev, there are several stories on the Krebs On Security blog that cover things in detail]

At the peak of the program they were brining in $6 million a week.

Despite Chronpay moving their internal communications to a program called Megaplan and using pseudonyms… they were still hacked again and their information exposed. Due to many of the Chronopay users forwarding their pseudonyms to their real Chronopay email addresses, they could all be linked very easily.

Organization chart from ChronoPay’s MegaPlan Intranet system –> http://krebsonsecurity.com/wp-content/uploads/2011/05/CurlyRx.jpg

The Buyers

40 years worth of buyer data to mine.

After spending 100s of hours tracking and talking to buyers. Despite the rumours, many of them were happy with what they got. It looked the same, worked the same and was a quarter of the price.

In the US, people tend to pay much more for drugs. Which is one of the drivers for this entire industry. People are just trying to survive.

Geographical Differences

In the US 65% of buyers were buying male enhancement drugs

In Europe 98% of buyers were buying male enhancement or recreational drugs. Price differences for normal drugs wasn’t that much, reducing the demand.

On the record

The DEA hasn’t found a large number of foreign sites selling controlled substances, but those that do offer them, often are scams, Boggs said. “Most are scams, or you get something different than what you order,” he said. “They offer to sell you this or that, and you might get Viagra, or you might not get anything.

This comment goes against the evidence that Brian has found. Most appeared happy, and despite worries, credit card information appears to have been hidden from affiliates and very few buyers comment on CC theft.

The Problem

The credit card processing firms are the same that are dealing with fake AV… So maybe if the payment processing dried up, the industry would as well! The banks and firms that deal with Pharma CC processing however, aren’t the kind of people to get pushed around. Take AG Bank for example… just take a look at their advert!

60% of sales can be traced back to 5 issuing banks in the US. If they would set a policy not to process payments for these known pharma companies, then it would make a huge impact on the industry.

In an interview with Igor Gusev regarding pharma, he commented the following regarding the problem .:

They need to put pressure on the card processors, which are monsters which only regulate on very negative public pressure. I think it would be a very powerful strike, and online pharma would be dead within two years if they could switch off the merchants who is somehow connected to online pharma.

Note: I’m sure this is all much more elegantly written over on Brian’s blog (linked below). These are purely notes from the live presentation. I would suggest following the Krebs on security blog, if you’re not already!

Note [16/06/2011]: I have removed some of the post due to the confusing way in which it’s written. Following the complex story live and writing in real-time was a little hit and miss. So I would suggest following the story straight on the Krebs On Security blog where it was originally documented.

Links:

#FIRST2011 – Security Challenges For Future Systems

Security Challenges For Future Systems

Steve Purser (ENISA)

Although a lot of things are obvious, it doesn’t mean that we’re doing them. How many people have seen a perfectly implemented intrusion detection system that rings bells all day with nobody monitoring it!

  • Effectiveness –> Doing the right thing
  • Efficiency –> Doing the thing right

These might be close to each other, but doing the wrong thing right, still doesn’t make it right! We need more effectiveness…

Who is ENISA?

The European Network & Information Security Agency (ENISA) formed in 2004

The agency supports the commission and the EU member states in the area of information security

Facilitate the exchange of information between EU institutions, the public sector and the private sector

The Trends

You have to be very careful trying to calculate future trends from historical data… especially if the data isn’t suitable. In Infosec, the data we have isn’t good enough.

Computer architectures have changed enormously in the last 20 years. From mainframe environments through to COBRA and WebServices.

These architectures are secured according to different principles

The weak point often lies in the connection between these technologies

  • De-Centralisation
  • Globalisation
    • Most IT architectures are embedded in a global environment, even if they were never designed that way
    • Users regularly switch context from intranet to Internet sessions
    • Authentication != Trust
  • Empowerment of the end user
    • More choice to the user… more freedom, at a price
    • Move towards browser based applications
    • End Users are not ready to rise to the challenge
  • Need for Speed
    • First on the market wins… security is a second thought
    • Users are beta testers
    • Products released unfinished

Scope and Requirements

An operational system is not just technology

System = Software + People + Procedures

Secure software will not always function correctly if we make unrealistic assumptions about how people behave.

The key challenge to developing secure systems is understanding and responding to the limitations of the target environment(s)

Understanding the Threats/Risks

Risk = Threat + Probability + Impact

This process isn’t a one-off… it needs to be a cyclical model, with constant review.

Functional Requirements

We can distinguish between functional and non-functional security requirements

Traditional security functional requirements are reasonably well understood

  • Confidentiality
  • Data and session integrity
  • Availability
  • Accountability
Certain requirements are more difficult
  • Which data is considered private
  • Security vs. Privacy

Non-functional Requirements

Many real-life security issues arise out or poor definition of non-functional requirements
  • Scalability
  • Operational Constraints
  • Flexibility
    • Modularity
  • Usability
If you have the best solution in the world, but it need 50 admins to keep it running… if you don’t have 50 admins, then it’s not feasible.

Software Layers

Different software layers perform different security functions
This has led to a difference between infrastructure services and application services. It’s not often that your software service performs AV checks… this is an infrastructure issue.
In the future we should strive for a closer integration. The flaws are exposed in the connection between infrastructure and application services.
The OS is the key to everything. All security relies on your OS being secure… root is king!

Evolving security models

Different IT architectures require different security models. This isn’t just about technology, but also about associates procedures.
Established architecture can’t always be modified to meet new demands. Sometimes you need to rethink the architecture to gain security.

Example:

Mainframe Architecture
We authenticate to the OS and we stay on the ‘box’
Highly Distributed Architecture
Here we need to re-authenticate
  • Relay user authentication
  • Object-to-object
  • How easy is it to implement?
  • How easy is it to manage?

New security models

As the trend towards de-centralisation continues, we will need to consider new security models
Peer-to-peer networks have no central point of control by definition. Such networks operate on the basis of distributed trust.
cloud computing puts new demands on the scalability of applications. Predicted scalability is feasible, on-demand scalability for secure applications is hard (key-management)

Some design considerations

  • Think about non-functional requirements
  • Use defense in-depth
    • Don’t rely in a single control
    • Have fallback

Methodologies

Integration of security methodologies into development methodologies is a must

Many current methodologies are essentially linear

There is the risk of not seeing the forest for the trees… what is the problem we’re trying to mitigate?

ENISAs Contributions

  • Community building
  • Policy Alignment
  • Technical Work
    • Cloud Computing
    • Secure Software Development

Conclusions

Trends in system development include increasing decentralisation, global connectivity, more empowerment of the end users and short development cycles.

The key challenge to developing secure systems is understanding and responding to the limitations of the target environment(s)

Sufficient weight should be given to non-functional security requirements

Security design should be based on architectural principles

Traditional centralised security models are being pushed to their limits – new models are emerging

End-to-end security is more important than single system security for distributed environments

Links:

#FIRST2011 – Remediating compromised environments

Remediating compromised environments: Case Studies from large and small enterprises

Wendi Rafferty (Mandiant, US)

Commercial sector breakdown (2010 Mandiant data)

Breakdown of IR investigations preformed in 2010 by Mandiant

  1. Cryptograph and Communication – 20%
  2. Space and satellites and Imagery – 19%
  3. Energy – 18%
  4. Media / Public Relations – 10%
  5. Technology – 10%
  6. Legal – 9%
  7. Chemical – 5%
  8. Hospitality – 2%
  9. Mining – 2%
  10. Automotive – 2%

What is remediation?

Usually divided into 2 or more distinct phases. Once you’ve discovered and remediated that direct attack, the second phase involves reviewing processes, systems and controls to prevent future attacks and enable faster response in the future.
Part 1 –> Successfully removing an attacker from your network
  • Identifying their activity
  • Implementing countermeasures
Part 2 –> Developing a plan and capabilities to:
  • Successfully detect future attacker activity
  • Respond quickly to future attacks
Solutions and investments in protection are individual to an organization based on a number of factors. The goal is not to prevent a future attack, but to mature the organisations posture to better react and detect further attacks. Quicker response, prevents an attacker from spreading further into your network.

What makes remediating a targeted attack difficult?

  • Attackers have access to a wide range of malware
  • Attackers who escalate behaviour based on your response
  • You can’t stop 150,000 users from opening an email. Something will get through

Visibilty –> Detection –> Response

If you’re not tracking, logging and analysing data then you’re at a disadvantage.
Initial Leads -> IOC Creation -> Deploy IOC -> Identify Suspect Systems -> Preserve / Collect Evidence -> Analyse Data

Understanding your network

List your resources… DNS Servers, DHCP Servers, Internet Connections, VPN Concentrators, Domains, Network Diagram, …
If your data on resources isn’t centralised and easily accessible, you can lose a lot of valuable time dealing with a targeted attack.
Knowledge of who is responsible for what, where the contacts work and how to contact them is very important. A repor with other teams is a must to work through these situations smoothly.

Centralizing Logs

Monitoring on the outbound parameter is great, but a central logging location for ease of comparison between different systems. Even in cases where it’s not possible to review these logs on a daily basis, it’s better to have the logs available for review when needed. Without logs it’s hard to know where to start on large network breaches. Storage is now pretty cheap, so there’s almost no reason not to be storing logs anymore.

A Tale of two investigations

Two victim organisations
Different sizes (< 1,500 and > 150,000 hosts), strengths and capabilities
Both were advised of the breach by the FBI
Both case studies occurred in the last year in the US
Both companies cleaned their environment, only to be re-attacked multiple times

Victim X

  • <1,500 hosts
  • < 20 Compromised hosts
  • 5 compromised accounts
  • < 10 different types of malware used

Classic approach

Strong network visibility
  • 2 Network egress points
  • Full packet capture
  • DNS logging
  • Proxy logging and blocking
  • Aggregation at SIEM
  • Threat-specific network sensors
Tight host control
  • Removing internet access from all users
  • Conducted traditional remediation event and implementing security best practices
  • Reintroduced users to internet access with highly customized internet isolation application

Victim Y

  • > 150,000 hosts
  • > 30 distinct types of malware used, incl. 12 different keyloggers
  • Use of email harvesting (> 50 employees)
  • Used / Targeted Service Accounts
  • Lateral movement using net use, scheduled tasks, …
identified attack as an email harvesting attack from a known group. In total there were 5 groups identified conduction attacks against the organisation. This caused a lot of overlapping evidence and issues in remediation.
Identified Critical Infrastructure
  • Identified hosts and personnel targeted
  • Hardened critical infrastructure first from the inside out
  • Removed new credential harvesting capabilities from attackers
  • Encrypted communications and identified next victims
Comprehensive Visibility
  • Continuous threat-specific monitoring of hosts and network
  • Continued investigation until new compromises dwindled
  • Conduction traditional remediation event
  • In process of building a response team

Defining the win

The end goal can never be to be 100% immune to attack.

The end goal (or win) is to gain a good overview of your network and better detect and remediate attacks in the future.

Links:

Point Solutions (Free Tools)

  • Web Historian (browser analysis)
  • Memoryze (memory forensics)
  • Audit Viewer (memoryze front-end)
  • Highlighter (log analysis)
  • Red Curtain (malware identifier)
  • IOCe (indicator of compromise editor)
  • OpenIOC (Common language to describe IOCs)