Friday, January 28, 2011

Is serving up malware drivers?

Hi guys,

D-Link have firmware drivers on their website, specifically the DSL-502T and DSL-504T that are showing as malware when I upload them to Virus Total to confirm.

Here is the 502T:

Here is the 504T:

(Be sure to download the  EXE and extract it).

I freely admit I have not tested these drivers out in a test environment (e.g. VM running procmon, or tried reversing them). But the reports from Virus Total are not thrilling:

502T driver report from Virus Total (17/43 vendors):

504T driver also reported infected with 20/43 known A/V products this time:

The 504T sample was also reported on Virus Total back in August 2010 (I have no idea if it made its way back to D-Link though):

Not just tiny vendors either: McAfee, Fortinet, Avast, AVG, VIPRE. Email from the technical support team has referred to them as "no name brands" as well. Very professional guys.

Why I am posting this here? Because I'd like independent testing (ok, I'll be honest - I lack a Windows VM to test).

I've also tried emailing and phoning D-Link technical support since Australia Day. I've been told on three occasions that the Anti Virus software attempting to stop me from installing is "normal" and I should "disable my A/V". I gave them all the steps needed to replicate the fault, asked what processes/checks they made to ensure that the drivers on the site have not been compromised. D-Link told me that this has been raised with their "Technical Support Manager". Despite a full business day... no response.

Funny, I would have thought someone reporting that your website might well be owned would be serious and warrant a more thorough investigation.

Oh well, I'll just put this out in the public eye and see what other people find.

Please note, I am not saying that the drivers on the site have been compromised as I cannot say that for certain.

What I am saying however is two files are reporting as malware with a SIGNIFICANT number of anti virus vendors and bears further investigation. When it has been raised with D-Link they seem highly disinterested in pursuing it further.

If anyone wants to take a further look, please post your findings here as I'd be very interested.


- J.

* Double thanks to Julio Canto & @Uglypackets for actually doing the real digging that I should have done. Julio has confirmed with several  AV vendors that this isn't malware. I guess its safe to call this a day. All the same the whole situation has certainly raised a lot more questions in my mind about how D-Link manage their security:

  • Why would you not escalate potential security quesitons? 
  • Why would you not answer questions about checking that the hash values on the fileserver repository haven't changed? 
  • Why would you tell your clients to disable A/V?
  • Why would they not want to work with well known A/V vendors to eliminate false positives on their products?
Anyway, thanks guys. I freely admit reversing is not my forte and as much as I want to get into it (got Eldad Elam's book in my bedroom right now sadly enough) there is no time for me these days.

* Props to GPLama for his suggestion that I run this through Their analysis can be found here and they confirm both samples as malware as well:

Publish Post


Wednesday, January 26, 2011

Architect vs Consultant vs Penetration Tester

Now there seems to be a bit of twitter rage at the moment around pentesting and consulting and what it should be or even what it should represent. I made a bit of an off the cuff comment that pentesting is a conversation opener and Twitter only supporting a 140 character limit, I didn't bother to clarify my stance.

See below a copy of the Open Software Assurance Maturity Model. I just picked this out to illustrate this discussion because I was reading it yesterday and I thought it would help make the point.

I have commented in the past that penetration testing should be used as either a validation piece as I call it (or 'Verification' under OSAMM) or a discovery exercise (to find out what is unknown - e.g. a legacy application in your environment). Now far too much hate has been circling on what some people are saying about penetration testing and from my perspective I think its because none of us is really trying to see the other side of the argument and perhaps I've added fuel to the fire (sorry).

We all know that the skills of a penetration tester is incredibly deep as well as broad. This is so indisputable it requires little mention. 

However, the skillset required to break a network, or a system, or an application is a very, very different skill than fixing it and maintaining it. If you have ever worked in an enterprise environment for an extended period, you’ll know what I mean.

To help make the point, I want to break down the roles of an architect, consultant and pentester into conceptual terms that in reality are grossly simplified (and kind of do an injustice) but for purposes of illustration will do for now (in at least as far as I see it):

Architect thinks first and foremost conceptually. They focus on business requirements and how to align security to meet those objectives. This typically manifests in changes to IT (infrastructure, applications) but can just as easily be a process change if it is the simplest solution. Architects are able to dive town in depth on a technical level but generally speaking, not to the same degree as the other two.

Is the middle man between an architect and pentester. A consultant thinks in terms of risk. Usually a technical person who has moved into to consulting based on broader exposure to other areas of security or business and/or excellent communication skills to be able to articulate risk and translate architectural terms and concepts or low levels of detail that a penetration tester may unravel. The posess a moderate degree of technical skill generally, typically higher than an architect.

Highest degree of technical skill. Engineers often fall within this category too. They possess the deepest degree of knowledge and in many cases, the broadest. Their ability to focus on the microlevel of detail is the single greatest strength and in many cases their weakness.
Now if we look at the different phases within OSAMM, let us see where each role can fulfil:

CONSTRUCTION: Architect/Consultant
VERIFICATION: Consultant/Penetration Tester
DEPLOYMENT: Penetration Tester

In a general sense, all three work in harmony to provide the coverage needed. I don't really know of a pentester that enjoys drawing up security policies  but the truth is that the pentester's detail focus is what enables him to pick out an error in a line of code, or the desire to test a single form field for umpteen different ways to break weak validation. He has no interest to delve into the business processes required to secure the enterprise. That's what architects are good for. Conversely, Architects generally lack that sort of attention to detail to do the work of a pentester. They are conceptual thinkers ("big picture"). Consultants are good at going to all the design review meetings, arguing with the business over a security requirement they want to cut and explaining the consequences for that decision. A lot of pentesters really lack the articulation to be able to do this. Likewise, too many architects are accused of sitting in their "ivory towers" ignoring the realities of the world around them when difficult technical discussions need to be made.

Back to reality, the world is full of individuals and everyone brings a unique blend of skills to the table. Very few people can "do it all" really well. Some people can wear multiple hats. Some can do all three. In my experience those people have a depth of experience that only comes with time in this field. You cannot compete with raw experience.

However because we all wear multiple hats, building a strong consulting practise relies on understanding the hats that everyone in your team has. When recruiting this often means looking beyond what you see before you and also seeing a bit of what can be. As a team, we are all more than the sum of our parts and our true value to our clients is leveraging our diversive skillsets to help uplift our client's security posture. 

Being able to successfully implement a framework like OSAMM can only be achieved when all the members of a security team (or consultancy) work collaboratively. It takes time to build and maintain trust, understanding the client's business and making sure the work we deliver is truly strategic. Even if you're an in-house team it is every bit as important to take the time to understand the business rather than attempt to dictate terms. If you aren't having those discussions with your consultants (or with the business if you work in-house) and if there is no understanding of the business then something is wrong with the approach. Certainly it takes a certain level of degree of maturity to reach this point however, our roles as security professionals is to push to have these discussions and play in this space.

A penetration test in and by itself is pointless if we are not having discussions with our client about their remediation activity, understanding their internal testing process, their security requirements and how they are being provided to developers, how is the architecture reviewed and ultimately, what is the level of engagement between the business and the in-house security teams. Having said that, a penetration test can also prove that all the strategic work you’ve done is still not up to scratch and needs improvement. In that respect, it might be used as an 'opener' or a 'finisher'. 

But there are three other business functions under OSAMM and multiple security practises that need to be achieved. Open frameworks like OSAMM prove that the skillsets used during each phase are specialist and require an entirely different focus. It is truly rare person to possess all the skills necessary to deliver each phase. It takes a certain level of self awareness to recognise what you can do and what you can't. Building a security practise around those skillsets requires embracing that diversity and ensuring people are given the opportunity to develop skills they might not otherwise have done as well as run with their strengths. 

However, ensuring the diversity of skills within a security practise and offering a wide variety of services that encompass all the business functions under frameworks like OSAMM requires that these other perspectives be acknowledged and developed. It is the only way to maintain our currency and relevance as our field evolves and develops. To quote Charles Darwin:

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.

- J

Saturday, January 22, 2011

What did we learn from the floods and fires?

Years ago, I was lucky enough to be invited to closed session at Deloitte where Adele Melek (Global Leader of Information & Technology Risk Service) talked about one of their annual global security reports.

One of the points in the report was about Business Contuinity Planning and Disaster Recovery. What was interesting was he made the very poignant observation that there was not a significant uptake of these consulting services when compared to other regions globally. I can't remember the exact numbers but he made a point that in late 2000/early 2001 a marginal percentage, lets say around 10% (I am throwing up arbitrary numbers which sound right from memory). Post 9/11, 12 months after, that figure skyrocketed to somewhere well above 90%. Watching those two towers go down and the number of businesses and lives affected, made a significant impact for businesses. He made a point - as have many others - it will take a 9/11 (or equivalent there of) for US before we start thinking of BCP/DR a little more.

Well three years since I attended that session we've seen not one but TWO MAJOR tragedies I would argue would be our equivalent - the Victorian Bushfires of 2009 (aka. Black Saturday) and the Queensland Floods.

Before anyone dismisses the impact of these in relation to 9/11, let me through up some numbers/stats:

Victorian Bushfires
  • Destroyed 2,030 houses, 3,500+ structures in total and damaged thousands more.
  • The following townships utterly destroyed: Kinglake, Marysville, Narbethong, Strathewen and Flowerdale.
  • The fires affected 78 individual townships in total and displaced an
  • Displaced an estimated 7,562 people.
  • Total death toll: 178
  • The Black Saturday bushfires were the 8th deadliest singular bushfire/wildfire event in recorded history.

Queensland Floods
  • At least 70 towns affected to date.
  • Over 200,000 people were affected.
  • Damage initially was estimated at around A$1 billion.
  • The estimate of lost revenue from Australia's GDP is about A$30 billion.
  • Many state that the factual losses cannot be calculated but can be readily counted in the billions of dollars.
  • (These numbers could increase as of this time of posting btw).
Even if your business or livelihood was not directly impacted by these events, chances are you had a business interruption as a result if you did business with anyone in these areas - or had friends and family who did.

These incidents teach us that the Availability in information security goes beyond having data recovery and backup. It's about an understanding of your true assets - your buildings, your equipment, phones, desks, software, hardware and of course, your people. Sound business continuity planning relies on thinking in terms of business processes and functions (not just IT infrastructure) and absolutely defining what is critical and what isn't. What can you afford to run at a reduced capacity? Who are the key staff in your business and what happens if you lose them? How is knowledge transferred to prevent loss of critical corporate intellectual property? This isn't just useful in a crisis either. A lot of it just good corporate governance.

Also, sound strategy here goes beyond thinking in terms of fires and floods. What is a real disaster for YOUR business? What are the likely risks you could face? Have you done a threat and risk assessment for your business? Few people could have anticipated the planes hitting the towers in 9/11. But some did predict the possibility of losing access to a building and developed strategies to ensure that the loss of their sites (and in some csaes their staff) to ensured they had a measure of redundancy continue operation - even if it was at a reduced capacity - in the case of such an event.

Real contigency plans can be constructed around a number of scenarios. For example:
  • Loss of buildings,
  • Loss of people,
  • Loss of critical services (gas, water, power, telecommunications).
These could be trigged by anything (fire, flood, even acts of violence such as shootings, etc).

While it is impossible to have a scenario for everything, developing even a single strategy is simply the beginning to a wider strategy. Having a process (even an imperfect one) means that you have something which can tested annually and improved it over time. This already puts you ahead of the pack.

I've personally worked with businesses that have fully accepted the risk of not having a DR or BCP strategy based on their estimation of likelihood. I think these incidents have well highlighted that such short sightedness can be damning.It doesn't have to be a fully redundant cutover. You just need to be realistic. Your BCP/DR strategy may only allow for limited or even reduced capacity based on cost constraints. But hey, something is better than nothing.

I don't want people to think that I am trying to milk these tragedies for chalking up posts ont his blog. My intention is the opposite infact. My point is that there is a greater tragedy here - that these incidents have occured and yet, we still don't seem to be learning.

- J.

Tuesday, January 11, 2011

Vodafone Privacy Scandal

Happy New Year to everyone.

Interesting that I get to kick off my first post of 2011 on what could be considered the largest privacy breach in Australian history.

In away, I think we need to be greatful that the Vodafone privacy scandal has drawn so much attention. We (Australia) never had our Heartland or TJX or anything like that. Our complacency and lack of strict privacy regulation means that we don't get to see the notifications of privacy breaches. Some companies, such as Telstra have "voluntary notification policy" concerning privacy breaches but perhaps I'm one of those skeptics who wonder just how much they would "volunteer" if they were put to the test.

Potentially, this incident has the chance to bring about change on the legal landscape. In reality, it is no doubt being lost in the deluge (no pun intended) of news concerning the Queensland floods.

There is a lot of blogging going on about the basic security controls that Vodafone could have/should have implemented but didn't. I'd love to wag my finger at them and say how naughty they are but the reality is that this is FAR MORE COMMON than most people are aware of and what security professionals can tell.

The best thing security conscious folk can recommend is that if consumers give a shred about their personal information in any respect (including SMS messages and call usage btw) then I suggest you push anyone and everyone you know who is using Vodafone to another carrier. I am already telling immediate friends and family who use them to make the switch. I urge you to do the same.

The only thing companies understand  are dollars and cents. So make the message strong and clear - tell these businesses we will not accept poor security. Personal information does have a value and its high time companies recognise the cost of failing to protect it.

- J.