Are You Primed?

The Prime Information Security Blog

Power of the People

Published: December 8th, 2010 Permalink

If you’ve tuned into any major news outlet lately, you can’t help but have noticed the ongoing drama concerning the release of US cables by Wikileaks. Since Wikileaks began releasing snippets from their cache of secret communiques on-line activist group, Anonymous, have taken it upon themselves to enact a form of online ‘payback’.

Throughout the day, Anonymous have been directing it’s legion of constituents to conduct a distributed denial of service (DDoS) attack against MasterCard, Visa and others. Whilst I certainly don’t condone the actions of Anonymous in conducting illegal DDoS attacks, they have helped bring attention to an important issue.

When dealing with security, you’ll often hear mention of Confidentiality, Integrity and Availability — the three tenets of information security. All three of these are absolutely critical to protecting information. However, look at what most companies are doing and you’ll notice far less investment in protecting Availability, versus the other two domains.

I wanted to get a better perspective on the Anonymous actions, so I joined their IRC channel to listen in on what was being discussed. Whilst I was there, an announcement was made that the DDoS target was changing from MasterCard to This was scheduled to start at 4:00pm EST. I waited, and watched.

Within a matter of mere seconds, Visa’s web site was completely inaccessible. The DDoS attack was stunningly effective! In fact, it only took roughly 2,000 computers on the Internet to completely disrupt Visa’s site.

So what can we take away from this? We should be ensuring our security objectives include protecting the availability of our information systems. Sure, it’s critical to protect confidentiality and integrity… but your business may very well depend upon availability.

Binary Archaeology

Published: November 2nd, 2010 Permalink

I recently attended the SecTor security education conference in Toronto. It’s a great annual event that brings together security professionals from across North America and beyond. Top of the agenda is learning from the super-talented people you bump into at these events!

One of the areas frequently getting discussed was incident response and some of the techniques we, as security professionals, should employ to understand and learn from incidents. A side-project of mine for some time has been a tool I’ve affectionately referred to as ‘FRuiT’. It was conceived as a tool for the non-security-savvy first responder to collect valuable information that can be analyzed by a security incident handler to determine if a security incident had occurred and to plot a remedial course of action. If you were wondering about the name ‘FRuiT’, it started off as the First Responder Toolkit (FRT) and then gained a User-Interface (UI), so became FRuiT, the First Responder Toolkit with a UI ๐Ÿ™‚

Back to the story. Using FRuiT, I captured a physical memory image of a corporate laptop system I had access to; this dumps the entire contents of physical memory to a file, for later analysis. Using the tools provided by the Volatility Framework, it’s possible to analyze this memory image to determine (amongst other things) what processes were running on the system, open network connections, files and registry keys, etc. It also allows you to extract an executable from the memory image.

I selected a random executable that was running on the system and extracted it from the memory image, saving it back to an executable file on disk. Out of curiosity, I decided to run ‘strings’ against the binary file and see if there was anything exciting inside. By sheer chance, there was.

It turns out that inside the extracted executable, there was an IP address that stood out. It stood out because it was not part of the corporate address space where the subject laptop system was running. So the obvious questions arise: where is this IP address pointing to, and what purpose is it serving in the process? A quick trip along to DomainTools indicated that the IP address belonged to an ISP in the UK that provides residential Internet access. Curious… now why would a residential ISP IP address be in a binary running on a corporate system?

The next step was to discover what the code was doing with this IP address. For that, I turned to OllyDbg — a Windows debugger that disassembles code back to assembly language and allows us to peer inside the binary to uncover what it’s doing. Here’s a snapshot of OllyDbg looking at the code section that uses this IP address:

OllyDbg disassembly of a target executable

(as you can see, I’ve redacted the actual IP address)

I’m no Windows assembly language guru, but the code is essentially trying to connect to the IP address we have found (the function call being addresses at 00411C22 is to the connect() function in WinSock32).

Going back to the corporate laptop where we found this executable in the first place, we use Wireshark to capture traffic between the laptop system and the IP address we discovered. Sure enough, after some time, the processes attempted an outbound TCP connection, on port 80, to the IP address we identified. It turns out that there isn’t anything listening on that IP address at port 80, so the traffic capture consisted only of the laptop attempting to set-up the TCP connection… and ultimately failing.

So the question remains, what is the code trying to do. Like I said, I’m no assembly language guru so I’ll rely on some empirical evidence to try and formulate an idea. Since I don’t control the network within which the corporate laptop is running, I’m unable to play routing tricks to direct traffic for the suspect IP address to a system under my control. So, next up, we try to patch the running binary and change the IP address to point to a system we do control. In this case, it’s a server system I maintain on the Internet. Again, OllyDbg allows us to connect to the running process on the laptop and manually patch the binary to change the IP address.

On the Internet-connected system we control, I’ve placed a simple netcat listener on TCP port 80, so that when the executable attempts the TCP connection, it should succeed and we can perhaps divine a little more about what the process is trying to do and the information it’s sharing. We’re also running a tcpdump packet capture to collect the packets being received by the outbound connection from our process. Back on the laptop system, a Wireshark packet capture is running to detect any activity from the process to the (newly patched) IP address we control. This enables us to get as much information about the connection as possible, in case any HTTP filtering is tampering with the outbound connection on TCP port 80.

So what do we find? Well… at the moment, nothing!

It seems that the executable only attempts the connection infrequently and as I write this, it hasn’t tried to ‘reach out’. However, when it does, we should be prepared to capture some useful data for analysis.

I know what you’re thinking: what executable is this? Since it’s an ongoing investigation, I’m not going to share the name of the executable, or it’s publisher. Safe to say that it’s from a trusted large software vendor and one could expect to find it in many large corporate settings. The vendor has been notified and we’re working together to try and shed some light on things.

What are my thoughts on what’s going on? Honestly, I believe that this just might be some debugging code left behind by the developer. I’m not assuming anything nefarious… but staying open-minded. It raises the question though: what is YOUR software doing?

We Can Haz Credit Card Numberz?

Published: May 19th, 2010 Permalink

I’ve spoken to many small business owners about the Payment Card Industry Data Security Standard (PCI-DSS). In an entirely unscientific study, I’d say that of those people I’ve spoken with, 99% of them had never heard of PCI. What’s more interesting is that the majority of them were certainly interested after we had chatted about the importance of keeping payment card data secure.

Of course, it’s difficult to have the discussion without touching on the scale of the problem. I’m talking of course about the relative ease by which credit card numbers can be obtained for fraudulent purposes. This was reinforced today, when, a trusted security professional happened to share a simple Google search. In this case, a simple 56-character URL that brought up a surprising bounty of credit card and identity information…

You’ll notice that I’ve blanked out any sensitive information… but think about this. Each black mark you see in the screenshot, that’s credit card numbers, expiry dates, CVV2 codes, addresses, card names, telephone numbers, e-mail addresses and even things like mother’s maiden name! With just a quick Google search, we’re able to find a raft of sensitive data.

Through awareness and education, we can help influence businesses to take protection of critical data (such as payment card information) seriously.

Security for the Remote Worker

Published: May 18th, 2010 Permalink

I attended a press conference today, where details of a TELUS-commissioned Harris/Decima survey on “Flexible Work” were discussed. The survey contains some interesting data from Canadian companies.

The stand out finding is that 89% of employees consider a flexible working program (one that includes some remote / mobile working option) makes a company more attractive. An expert panel backed-up this conclusion with supporting data showing how many job-seekers entering the market consider flexible working to just be table-stakes.

There’s no doubt that the small business sector is especially embracing of flexible work programs. Small businesses enjoy a type of agility and readiness to embrace more cutting-edge concepts that larger businesses are slow to adopt. One area that is of particular interest for me, is how we can continue to ensure good information security practices, even though our workforce is increasing mobile–working at home, in coffee shops, airports, etc.

Small businesses often don’t have the extensive IT infrastructure that larger companies are able to leverage to maintain an acceptable level of security. What type of infrastructure are we talking about? Here are just a few:

  • Remote network access, such as a Virtual Private Network (VPN) connection back to the ‘office’ network.
  • Remote voice communication: mobile phones, VoIP telephony, etc.
  • Data backup.
  • Update mechanisms for anti-virus software, operating systems and applications.

For some businesses, this means investing and building out the necessary infrastructure, which can be costly and brings with it management overhead that previously may not have existed. For others, outsourcing is a more viable option. I have seen several businesses, for example, make the transition to Google Applications as a way of ensuring their remote workforce can collaborate effectively, regardless of their location. Once these hurdles can be overcome, we must not forget to think about how these changes have impacted our information security.

There may be some concrete benefits to providing a flexible working program in your business, but it also brings some security considerations to the forefront. Maybe now is a good time to think about your flexible working strategy and review your security practices to see if they are still effective.

Microsoft: the world’s #1 Security Tools provider?

Published: March 30th, 2010 Permalink

I should preface this post with the fact that this is to be read with tongue firm planted in cheek. I think.

Some number of years ago I worked for Nortel. One particular morning, I recall attending a ‘town hall’ meeting being held with the CEO at the time. We won’t use his name, but suffice to say it was during a period of ‘initial decline’ at the company. During this town hall session, we heard about the usual suspects: new product introductions, R&D innovations, customer success stories and financial performance. The last point was of keen interest for many; despite not being accountants, everyone had learned a little something to better understand the situation Nortel found themselves in. Even a graphic designer could tell you DSO was Days Sales Outstanding, and why that was bad if it got too big.

As the session progressed, it was explained that the Optical portfolio was seeing some decline in growth. It was pretty clear for us all to see that ‘some decline in growth’ was secret accounting-speak for ‘the bottom has fell out of the market’. What followed was a great demonstration of the difference between Generally Accepted Accounting Priciples (GAAP) and Nortel Accepted Accounting Principles (NAAP). Under NAAP, correcting this minor decline in growth was simple: just reclassify your portfolio so that almost everything becomes an ‘Opto’ product. How to achieve that? Why, if a product contains any kind of optoelectronic component, then rack up it’s revenue under the optical portfolio. Of course, almost everything had an LED power light… so we were in business! Optical revenue had never been stronger.

This redefinition hit me again today. As security professionals, we often work with a number of tools to help secure our networks, systems and information. Sure, security folks will all recognize tools like Nessus, Snort, WebInspect, nmap and so on. There’s even a nice list of the Top 100 Network Security Tools — people love lists.

But it’s flawed. The real number one security tool vendor is Microsoft.

I’ve asked a few security professionals what tools they use the most in the field. The most popular isn’t Nessus or nmap; it’s not Snort, Metasploit or Core Impact. It’s Microsoft PowerPoint.

That’s right, in my extremely unscientific survey, and re-classifying PowerPoint as a security tool (under the rules of NAAP)–I confirm that Microsoft is the #1 provider of security tools. We spend buckets of time creating presentations to pitch security, presentations to position how it will be improved, presentations to get funding, presentations to measure progress. It’s a wonder we don’t create presentations about creating presentations. Oh–maybe we do.

So congratulations Microsoft, on your great achievement in the field of information security! I do have one small suggestion… and judging from the ‘Windows 7 was my idea’ advertisements on TV right now, I think you are listening. Could we please have one of those lovely security seals, something like ‘Protected by PowerPoint’, that we could put on our web sites, or stick to our servers?

That’ll keep the bad guys out.

Ada Lovelace Day

Published: March 27th, 2010 Permalink

Ada Lovelace Day was celebrated on March 24th–a day in recognition of the contribution of women in science and technology. If you haven’t heard of Ada Lovelace, I’d certainly recommend you find out more about her short, but fascinating life, over at Wikipedia.

Ada was one of the world’s first programmers, developing a process of calculating Bernoulli numbers using Charles Babbage’s Analytical Engine. This, despite the fact that Babbage’s machine had never been built.

If you’ve ever written a computer program, give a few moments pause to consider Ada’s contribution that kick-started the discipline.

Who are your favourite women in science and technology?

Secure Application Development on Facebook

Published: March 24th, 2010 Permalink

Are you dabbling in building applications for Facebook? Maybe you have engaged the services of a development company that is constructing some marketing application to add to your Facebook Fan Page?

Some excellent material has just been released through the Open Web Application Security Project (OWASP)–giving specific security guidance for web developers building Facebook applications. I encourage you, or your web developers, to take a look and help prevent some common security pitfalls.

Head on over to the Facebook page at OWASP for more information.

Firewall != Security

Published: March 23rd, 2010 Permalink

If you know me, you know I’m not a fan of firewalls.

Well, that’s not strictly true. Maybe I should say I’m not a fan of people who equate firewalls with security.

Firewalls are perfectly good devices for performing the function they were designed to do: make a broad-based decision to allow certain packets in or out of a network. The trouble is these days, that our networks are a lot like your local shop… and the firewall is like the shop door.

Let me explain.

You see, down at your local shop, the door (remember door == firewall) is open during business hours allowing a constant stream of customers in who just can’t wait to part with their money. However, when the shop is closed, so is the door. It keeps those customers out, no doubt upset at their inability to spend money at the local shop.

Aha… but it’s not just customers that come into the shop through that door. Unfortunately there are also thieves, spies (well, let’s call them ‘competitors’ doing a little ‘market research’), delivery people, suppliers, etc. The door doesn’t do anything but let everyone in, or let nobody in.

Today, I was once again reminded of the shop door. After reviewing a specific architecture design for a web-based application I was promptly shown that there was a firewall in place in front of the web server, to make sure the only traffic getting through was on good old TCP port 80, which new-fangled kids these days sometimes call HTTP [I’ll refrain from having one of my ‘get off my lawn’ moments about the difference between ports and protocols].ย Sure, the firewall serves a purpose–like the shop door–but it’s also letting all those would-be web hacker types have a crack at your shiny new web site.

So, following the analogy, I extended it a bit further… telling the architect that he needed a ‘bouncer’.

You see a bouncer (or ‘doorman’ to use the correct term) is often found outside a nightclub. They work hand-in-hand with the door, performing additional checks to see that only ‘acceptable’ customers are permitted entry. And so in looking at this weird and wonderful analogy, the architect concluded that additional protections might be warranted. Good call.

So ask yourself… is your business running out of a local shop, or a nightclub? It just might be time to hire a bouncer ๐Ÿ™‚

Security Brainstorming

Published: March 23rd, 2010 Permalink

I was recently invited to take part in a session being run by a project team looking to determine security-related Non-Functional Requirements (or NFRs) for their project. In essence, the project team were wanting to identify a number of security considerations ahead of designing the system. These considerations would be structured to become the security requirements, and the system design would be such that these requirements be met, or risks mitigated.

In my experience, it is rare to find this level of planning early-on in projects; certainly it is something more often found in large established companies, than in small businesses. What made this exercise so worthwhile was the planning that had gone into the session beforehand. Before we even came together, the chairperson had organized a mind-map with some of the thought-avenues we’d be taking. In this particular exercise, we started with the Horror Story–what is the worst scenario we could picture that could arise as a result of some security failure?

That is where the fun starts. The people in the meeting have to shift their mindset, and begin thinking like an attacker. This comes more naturally for some; with others it takes time–but universally it is a source of fun! The Horror Story starts with a scenario, with the team floating ideas of how that horror story could be a reality. These are expressed and recorded as anti-requirements: e.g. Passwords will not be complex, making it easy for attackers to guess.

After the session, the team regroups and looks at each of the anti-requirements. They are then ‘flipped’ to form a positive, security-related requirement for the project.

This brainstorming approach is a good first step. At the very least, it means the project team is thinking about security from the outset–and as any security practitioner will tell you, “building security in” is the best approach. However, it doesn’t mean it’s the end of the journey. Teams, such as the one I worked with recently, should consider extending this practice to incorporate structured Threat Modeling techniques.

Threat Modeling can be accomplished in several ways, but at it’s most basic, it is the exercise of looking at a Horror Story and working back to the preconditions that would make the Horror Story realizable. These preconditions can be arranged into trees–showing how they must be combined to make a specific outcome possible. What we are left with is a simple graph of conditions that must hold true, in order for the Horror Story to become a reality. Thinking about this a different way: we have a graph showing what conditions we need to take care of to prevent the Horror Story coming true!

Threat Modeling can be a very powerful technique for quickly identifying the major causes of security failures. More importantly, it can help your team invest wisely in addressing those conditions that present the most risk.


Published: March 21st, 2010 Permalink

Welcome to Prime Information Security’s new blog: Are You Primed?

Through our blog, we’ll be making sense of information security by looking at the hottest issues and exploring what they mean for your business. We welcome you to get involved: ask questions, share your thoughts and opinions.

If there is a topic you’d like us to explore, drop us a line and we’ll see what we can do!