It seems that things are coming to a head in the strange world of government surveillance for “our” protection.

Of course I see the expeditious rise in this kind of activity due to the likes of Anonymous and Lulzsec/Antisec coming to the scene and forcing the hands of those in charge.

This is not to say that the legislation and skulduggery would not have happened without the Anon’s but it may have been more of a frog in a pot of water scenario as opposed to getting zapped in a flash.

So, in a way, you can thank Anonymous for speeding up the process as well as perhaps creating the environment for really poor ideas to be floated in a hurry to “protect” us all from the bad people.

Dealers choice there I suppose…

All this aside though, we now are faced with DHS wanting to be in charge (or at least pay General Dynamics to do the work) of monitoring “Social Media” on the internet. First off, let me assure you all that DHS monitoring Social Media is akin to a severely autistic individual being assigned as a babysitter for an infant. This is one of the worst ideas I could ever conceive of as these types of things go.

Even with GD doing all of the grunt work, the actual evaluation of any product would be carried out by analysts from DHS, and boy, they are so ill-equipped to handle this. Remember, these are the same bunch of folks that brought you that classic fiasco of “Russia is hacking our water system in Illinois!”

Suffice to say, that I do not think this will go well and that the idea in and of itself, to monitor Facebook and Twitter will only lead to more of the same old false reports of doom and attacks that the Bush administration brought out every few weeks with the terror color coded chart.

In short, FEAR FEAR FEAR! All the while, they will only target people who happen to say things in a tweet that will be overblown and have them tossed out of the country (i.e. blowing up America by the Brit recently). FUD.

Just Who Will Be Monitored Really?

Aside from the lowest of low level jiahdi’s or Anonymous, just who will be really monitored by this program do you suppose? Why, you and I of course! I mean, it’s really just open source isn’t it? The real targets are the stupid and the public here really and one must face this fact and accept it.

This is no program that will actually end up with real terrorists being caught and cells disrupted you know. See it for what it is, a means to an end to have a simulacrum of control over the internet and the people using it.

But Krypt3ia... They are doing this to catch the bad men,” you say?

Sure, you can believe that if you want to, and there may be factions within the community that think this is the case, but overall you have to look at the pool being harvested from here. Since the advent of the Patriot Act, we have seen the FBI and others over-use and subvert the law to effect warrantless searches for domestic cases much more than terrorism, the thing that the Patriot was created for.

What this really is, is a drift net approach to law enforcement because technically, the government and the LEO’s are not capable of keeping up with the crime, never mind the terrorism really. So, they fall back to the idea of we can monitor everything and after the fact go back and look at data for “anyone” to make a case.

Easy as pie…

I am not inclined to believe that these measures are to be proactive either. Predictive maybe to an extent, but in prediction, we get another whiff of control do we not? After all, the predictive nature of this type of monitoring is what the CIA and other countries do to assess when there may be an outbreak of civil disobedience or perhaps insurrection might be a word for it?

Either way, this is a means of control as well as a means to detect and perhaps deter depending the use of the owner.

It’s a tool, and it is up to the user what they will do with it. In the case of other states such as Syria, well, you can see how the technology is being used. Here in the US, I am not saying that this will be 1984 all over again, but, do you really believe that you, the citizen, in the current environment will be able to know what is going on? Will you be able to FOIA the results of the testing and the monitoring to tell if its being misused?

If you think that this will be in fact the case, I think you will be sorely surprised when you find that it’s all been classified and out of reach when you have questions. Frankly, I just see this as the next iteration of “Total Information Awareness“... You know, John Poindexter’s baby? Yeah, fun fact, it never really went away, it just went into the black budgets and or changed names.

In the end, if you have a twitter account, Facebook, MySpace, blog, etc... you will be monitored... Especially if you speak your mind or use key words that trigger an analysts attention.

Kinda like the NARUS STA’s in the MAE’s out there siphoning data too.

Oh, Don’t You Worry, No Matter What They Say, YOU Will Be Monitored

In the interim though, Congress has had a meeting over the privacy concerns over this little project by DHS. The congress-critters got all up in DHS’s face about the issue and said they are not comfortable with the program/laws around this. Now, that the congress acted on this, one might think that it would stop the program... I am not so sure it will in fact do so.

I think that the case will be made and assurances given that only those who are evil doer’s will be audited and that no privacy will be breached by such measures... “We’re here to protect you”

It’s an old argument really, but in today’s digital world, the issue is that instead of say, a black chamber opening mail in a secret building by hand, you instead have machines collecting everyone’s data and sifting through it all for key words, phrases, meme’s and other data. This then spits out the alerts and an analyst then looks at it to see if it warrants being passed along to others in the food chain.

What also may occur here is that even if it’s not terrorism, they may in fact pass data on to others who may start investigations on those hits, even out of context, as you might be an agitator or show a tendency that they feel uncomfortable about.

Today, if you buy a coffee at a Starbucks with cash AND you use WIFI AND you use encryption, YOU might be marked as suspect due to the fliers recently put out by the DOJ and the FBI on how to tell if one is a terrorist. God forbid you have a missing finger(s) as well... Then SURELY you are a jihadi or a militant. *snicker*

Oh well, fear not gentle reader... Because all of what I have said above about this one program, means nothing really. Why? Because this one program is only “one” of many out there being used by the government(s) out there to trawl the internet for data. I have mentioned a few others above and you can go look up the terms and see for yourselves.

Post 9/11, we have truly become a watched commodity via the internet and all other means of communication we can buy. All of these programs have been put together with the veneer of being in place to protect us from another 9/11 and perhaps some of them were made with the best of intentions, but this idea of monitoring social media, well, it’s a little half baked really I think.

In the end, only the stupid will be caught. I mean really, look at what lengths OBL went to with cell phones and runners with messages, do you really think that much of the global jihad is being carried out over open communications lines like Twitter and Facebook?

Sure, maybe people congregate there and THAT is useful information, but, to monitor the traffic of everyone to get targeted data on “some” users is just useless if your goal is only to go after the terrorists.

Remember... Above all it’s just a drift net to make it easy…

Making Your Own Privacy Because You Soon Will Have NONE

I guess what this whole rant is boiling down to is this, and its something I have said before on many occasions: “You alone can make the privacy that you need to prevent such monitoring” Encryption is the key to all of this.

Whether that crypto be something along the lines of PGP or Vigenere is up to you but what counts is that you are taking the pains to protect the communication that will pass over the wire. You can’t trust the owner of the wire and you certainly cannot trust that the government or, hackers for that matter, aren’t watching or monitoring you either. So, it’s up to you to make the privacy happen.

With the onset of all of this, this week we also saw the first (I assume of many) solutions for encrypted tweets come along. I for one, would love to see this solution work and be used by many on Twitter to protect their privacy, but, then again, this is kind of an oxymoron huh?

As I said earlier in the post here, who would use open lines to commit crime? So, once again, we are back to the level of what privacy can one expect as well as if one wants to be private, use a means to protect that communication. *shakes head*

After that little turn, it really becomes clear that the monitoring of twitter and the like really comes down to a privacy violation by the government to feel as though they are in control. The smart people will not be talking on twitter about blowing things up and everyone else who may say such things are doing it in jest, but will end up being investigated for their poor choice of words (140 characters at a time).

It’s a sad world we live in. I hope that congress denies the DHS their wish, but, I am also certain that if they do, DHS will only hire out again to the likes of GD to do it anyway off the books so to speak…

In the interim, I will continue to encrypt love notes to DHS and others in hopes of making their day..

OOH LOOK ENCRYPTED MESSAGES! TERRORIST! WATCH EM!

K.

Sources:

• http://www.pcmag.com/article2/0,2817,2400429,00.asp

• http://www.huffingtonpost.com/2012/02/16/dhs-monitoring-of-social-media_n_1282494.html

Cross-posted from Krypt3ia

The Journal states that "the group has never listed a power blackout as a goal, but some federal officials believe Anonymous is headed in a more disruptive direction. An attack on a network would be consistent with recent public claims and threats by the group."

One of the main challenges in protecting these networks is the fact that these systems were not necessarily designed with cybersecurity in mind. Rather, the security solutions have been layered on in a piecemeal fashion after the networks were operational, leaving ample room for attackers to compromise their functionality.

In the fall of 2011, Pike Research released a report examining the state of utility cyber security. The report concluded that although a great deal of attention has shifted to protecting systems that govern infrastructure, utilities have a long way to go in protecting critical networks.

"Utility cyber security is in a state of near chaos. After years of vendors selling point solutions, utilities investing in compliance minimums rather than full security, and attackers having nearly free rein, the attackers clearly have the upper hand. Many attacks simply cannot be defended," the researchers stated.

However, the Journal goes on to report that utility officials believe the threat of a catastrophic event is in highly unlikely, and that current security precautions are effective in defeating attacks on a daily basis.

"Grid officials said their systems face regular attacks, and they devote tremendous resources to repelling invaders, whether from Anonymous or some other source. 'The industry is engaged and stepping up widely to respond to emerging cyber threats; said one electric-industry official. 'There is a recognition that there are groups out there like Anonymous, and we are concerned, as are other sectors.' Another industry official noted that the electric grid has a number of backup systems that allow utilities to restore power quickly if it is taken out by a cyberattack or other event."

While widespread vulnerabilities may persist in systems governing critical infrastructure, the government maintains that actual threat levels are not as pronounced as some would lead the public to believe.

"Intelligence officials believe that, for now, the cyber threat to the power grid is relatively limited. The countries that could most quickly develop and use cyber means to destroy part of the grid — such as China and Russia — have little incentive to do it. Those who might have more incentive, like Iran or North Korea, don't have the capability," the Journal reported.

Source:  http://content.usatoday.com/communities/ondeadline/post/2012/02/report-nsa-chief-sees-possible-anonymous-hit-on-power-grid/

For those interested, you can view this link to see that the total number of anti-virus detections was 0.

However, when I decoded the PHP backdoor, I got 17 anti-virus hits on it. It seems they locked into the c99 backdoor code remnants, which is a pretty old backdoor PHP trojan.

This leads to the question about evasion techniques and how effective anti-virus applications are at doing code de-obfuscation.

For example, if you want a currently effective AV evasion technique in PHP, it comes down to this simple line of code:

• ( g z i n f l a t e ( s t r _ r o t 1 3 ( b a s e 6 4 _ d e c o d e ( $ c o d e ) ) ) ) ;

There’s the cash money key in terms of evading most, if not all, current anti-virus tools.

However, if you have a process that runs grep against your files  looking for base64_decode and alerts you to new ones, you’ll get visibility to it and many, many others like it. Base64 encoding is still quite a popular call in PHP attack and compromise tools.

Here are some examples of this specific trivial control — here, and here. Now you have a real life example of how it pays off. So simple, yet so effective at detecting these slippery backdoors.

Finding specific nuance controls that pay off against specific threats to your assets is a key way to better security. It’s a win, all around!

Cross-posted from State of Security

The lack of proper security precautions governing the agency's websites may have been a contributing factor to the January 24 hack of the FTC's OnGuardOnline.gov site where attackers exploited vulnerabilities in the application software employed.

In addition, the PR firm subsequently failed to take action to mitigate FTC website vulnerabilities after the initial attack, allowing for the successful defacement of the agency's Consumer.ftc.gov website.

"The initial language of the FTC's solicitation for the $1.49 million contract that created the sites that were hacked on January 24 and February 17 set out very specific language about the security requirements for the site. But by the time the contract for a set of consumer and business education websites and social media was awarded to public relations firm Fleishman-Hilliard in August of 2011, those requirements were dropped from the statement of work," Arstechnica reports.

The lack of due diligence has prompted the hosting service Media Temple to ask Fleishman-Hilliard to take down any remaining websites subject to federal security guidelines.

"We have actually asked Fleishman-Hilliard to remove any [remaining] .gov sites... We aren't a FISMA-certified hosting service," said Temple Media's Kim Brubeck.

The events leading up to the security gaff provide a prime example of the risks government agencies face when outsourcing operations. In the midst of dealing with multiple contractors, security precautions seemed to have just fell to the wayside.

"In part, the security requirements were dropped because the FTC planned to host the sites with someone other than the winner of the contract. But Fleishman-Hilliard  ended up setting up the servers for the sites themselves—on Media Temple's unmanaged server-in-the-cloud service that was never intended for .gov sites. And it appears the FTC signed off on the move. As a result, the servers provisioned for a number of FTC sites, including a site providing recommendations for business and consumer information security, were configured with an outdated version of the Drupal content management system that offered up a tempting target to Anonymous "antisec" hackers looking to embarrass the government."

The events appear to be a comedy of errors, where during the long process involved in setting up and awarding federal contracts, due diligence was not maintained and critical security requirements were not enforced.

As the federal government races to outsource services to the cloud in an effort to cut costs, the risk of oversights of this nature unfortunately become more probable.

Source:  http://arstechnica.com/business/news/2012/02/recipe-for-getting-hacked-ftc-dropped-security-requirements-from-contract-for-sites-hit-by-anonymous.ars

I was speaking to a veteran the other day that has about 20 years of service and has been in more countries than I can remember.

As we talked about the war in Afghanistan, possible future war with Iran and other current military affairs, he told me, “Things are changing. They are after military websites, online accounts and even Facebook pages of active duty troops. It is a Cyber Cold War now.”

International websites are under siege by everyone from political hacktivists to cyber-crime organizations, to Nation State backed hackers. But what is the real threat?

• Political Hacktivists – The current Anonymous leak of the intercepted FBI call concerning Anonymous told me everything I needed to know about how serious a threat political hacktivism is taken. During the call, FBI agents and British agents joke around and laugh up to the point where a senior agent joins the conference call. Then it was all business. Denial of service threats and the releasing of credit card info is a nuisance, but not really a threat, especially when compared to the other heavy crime that the FBI is used to dealing with.

• Cyber Crime – This is a lot more serious than political hacktivism. International cyber-crime is booming, and recently more money was stolen through cyber-crime than was made in the illicit drug trade. But this really is an extension of organized crime and not cyber war.

• Nation State Hackers – This is where the threat really lies. From the release of counterfeit network equipment that could be backdoored to industrial sabotage to military based espionage. This is where our military level cyber forces should be focused.

In essence we are in a Cyber Cold War. Nation State hackers are very active in attacking and compromising military, government and defense contractor sites. Terrorists are using social media sites to recruit, train and spread their poison.  It is very representative of the espionage, politics and spread of communism during the Cold War.

Is our current military cyber force capable of dealing with this threat?

I think when our cyber command was created, it had in mind the threats they were facing and had the desire to be both offensive and defensive - blocking the threats and counter-attacking in the cyber realm. But before cyber command even got off the ground, it was hamstrung by the legal and political ramifications of offensive operations.

What then is needed? We need a Cyber Special Forces group.

After the failed Bay of Pigs invasion, President John F. Kennedy realized that the US was facing a new battle with the spread of communism. He made it a priority to get Special Forces groups created and active to face this threat.

Troops were selected that were intelligent, capable and willing to learn. They were put through intense training that allowed them to move undetected in enemy territory and engage the enemy on their own terms.

As Special Forces groups evolved, their peacetime missions became two fold. They were sent into countries to train allied or somewhat friendly forces, but at the same time to gather intelligence about countries that at some point in the future may not be allied with US intentions.

Right now, our Cyber Command seems more defensive oriented. Instead of just monitoring and detecting threats, a capable offensive unit is needed.

One that can not only counter-hack, assess potential targets, train friendly nations, and stop electronic threats. But also be able to put boots on the ground and physically shut down terror cells and any other physical threats that arise from intelligence gained.

Cross-posted from Cyber Arms

Researcher Kuang-Chun Hung of the Security Research and Service Institute−Information and Communication Security Technology Center (ICST) identified an uncontrolled search path element vulnerability, commonly referred to as DLL Hijacking, in the 7-Technologies (7T) TERMIS software.

ICS-CERT has coordinated this report with 7T, and 7T has created a patch that resolves this vulnerability. ICST has confirmed this patch fully resolves the reported vulnerability.

AFFECTED PRODUCTS

The following products and versions are affected:

• TERMIS V2.10 dated November 30, 2011, and any previous version.

IMPACT

A successful exploit of this vulnerability could lead to arbitrary code execution.
Impact to individual organizations depends on many factors that are unique to each organization. ICS-CERT recommends that organizations evaluate the impact of this vulnerability based on their operational environment, architecture, and product implementation.

BACKGROUND

7T, based in Denmark, creates monitoring and control systems that are primarily used in the United States, Europe, and South Asia. 7T TERMIS software is used for district energy network management.

VULNERABILITY OVERVIEW

The 7T TERMIS software is vulnerable to DLL Hijacking. An attacker may place a malicious DLL in a directory where it will be loaded before the valid DLL. An attacker must have access to the host file system to exploit this vulnerability. If exploited, this vulnerability may allow execution of arbitrary code. CVE-2012-0224 has been assigned to this vulnerability.

EXPLOITABILITY: This vulnerability may be exploitable from a remote machine.

EXISTENCE OF EXPLOIT: No known public exploits specifically target this vulnerability.

DIFFICULTY: An attacker requires a moderate skill level to exploit this vulnerability.

MITIGATION

7T has developed a patch to address this vulnerability, which can be accessed here:

• http://termis.s3.amazonaws.com/TERMIS_2.10_18-01-2012.exe

Users may need to uninstall an earlier version of the application before installing this update.

The full ICS-CERT advisory can be found here:

Source:  http://www.us-cert.gov/control_systems/pdf/ICSA-12-025-02.pdf

In this post I'm going to bring up one of the most interesting topics (at least to me) which is gathering actionable intelligence from all of your existing investments.  Since you probably have at least 100 devices across your network generating security log information - not to mention other types of useful bits - it's imperative that as you think about doing DLP you utilize this wealth of existing information available to you... or is it?

Remember - mountains of information being generated by security devices is only useful if you can transform it into actions which can increase the security posture of your organization.

What's a SIRM?

SIRM stands for Security Information and Risk Management, and it's typically served up as a platform of technologies, and can be consumed as an in-house product or service.  SIRM is the continuing evolution of the SIM platform that many years ago started as a log aggregator which of course did not one any good because no one I know had any time to actually do anything with it. 

Why the new term SIRM?  Simple - the industry needs to evolve into risk management beyond just the traditional security event management.  In short, there is more to your organization than what the firewall and IPS generates.  While lots of events may mean an influx in attack, or simply noise... it does not adequately express or correlate business risk.

You see, today's security dashboards and consoles focus on exactly that - security - and security tends to have a very myopic view of the enterprise.  Security tends to care about bad things happening, and for good reason too!  If the security team were to start looking at the totality of organizational "events" the odds of an information security team being overwhelmed in seconds is a a sure bet.

So here we have the crux of the issue with data loss prevention - too much information to process in a meaningful way without advanced insider knowledge of your specific organization.  DLP is a Catch 22, because you never know what you're looking for (or in what format) to tell the systems you have in place to look for it. 

If you knew what you were looking for, you wouldn't need the big fancy systems to look for it... so this gets complicated and SIRM technologies combined with some good 'ol fashioned brain power can actually rescue you from drowning.

Finding a needle in a stack of needles

The difficulty in DLP is that you're looking for patterns that range from obvious to downright 007-style sneaky.  What I mean by this is that sometimes you're looking for the accidental email that sends out a boat-load of social security numbers, while other times it's a trickle of events that alone don't raise suspicion but are exfiltrating data from your organization.

There are really 3 main questions when you're thinking about the mountains of information you have at your fingertips for the purposes of avoiding leaking data from your organization.  Often times, when I've seen security teams simply "dive in" to a DLP effort it turns into an exercise of trying to find the one needle they're looking for not in a haystack, but in a haystack of needles. 

Information can be our biggest asset, and our greatest adversary when we're looking at preventing data loss.  On one hand you have information being generated (in the form of events) on every single piece of hardware and software in your organization.  Starting at the badge readers at the front door, to the access terminals (PC, laptop, mobile device or terminal), to the software - every kind of software - there are billions upon billions of events being generated every day.  This mountain of information is a fantastic asset - that is until you start to think about how you're going to process those events and figure out what they mean in real-time. 

You see, with the way that business moves these days, you don't get the luxury of running a log analysis engine overnight to figure out that you've had information stolen yesterday - you need to be able to do this in real-time (or very nearly real time). 

The challenge of course is if you turn the logging knob to maximum and point it at your log aggregator (or SIRM if you've got a copy of ArcSight [or some other SIRM platform] sitting around humming) things tend to go ka-boom quickly.  So on one end you have this wealth of information and on the other is those few events when strung together which tell you something is going wrong right now.

So here we go, let's take a look at how you can find the right needle, in that haystack of needles...

What (to log & monitor)

The simpleton answer to the what question is "everything".  This doesn't scale, of course, nor does it necessarily make sense.  I would tell you that it's intelligent to err on the side of caution though, and feed your intelligence platform as much as it can take.  Let me offer you some practical advice that has worked for me and others I have first-hand knowledge of over the years.  First, don't limit yourself to security information. 

A good intelligence platform (like a SIRM) will look at everything from a badge-swipe into your data closet to the outbound access violations your firewall is generating and everything in between.  Applications are a wealth of knowledge when it comes to logging.  Sometimes developers restrict themselves artificially when it comes to logging "security events" so let the intelligence platform decide what's important while you feed it (nearly) everything. 

Everything from successful logins to your application, to things like how long a person stays on a specific area of your application, to the database queries performed is important and can be that one key piece of information that may find the bad guys.  So my main advice - don't limit yourself to 'security events' pre-defined by the application or device.

How (to analyze)

The how is part of the magic that makes one platform simply more effective than another.  Let's be clear, more effective actually means effective, and less effective actually means inadequate.  I'd crazy how often some people complain about their logging and intelligence platforms. 

Analysts complain that you have to maintain and constantly tune the platform because it doesn't just run by itself when this is actually one of the most valuable pieces of an SIRM or intelligence platform.  You can't just set it and forget it, otherwise your intelligence engine is only as effective as the last tune-up you gave it... how many months ago? 

The analysis is purely mechanical, and it has to be with the scale we're talking about here, but the rules and analytics must be at least shared with a human.  Humans can interpret events better than machines or software and therefore are required and critical when complex analysis is required. 

Until the Autonomy IDOL platform can effectively learn human patterns to detect malice (think Minority Report) we'll still need humans to tell the machines to connect two dots which seem unrelated.  I tell you what though, those PhD's over in our Autonomy group have some serious intelligence in that platform that you have to see to believe!  In the end, the key is having a well-oiled machine which can perform advanced analytics which is constantly fine-tuned by humans.

When (to respond)

Response is key.  No matter how good the logging facility is on some platform you've heard of, no matter how good its ability to show you events relevant to your situation the most important thing your logging facility can ever tell you is when to respond. 

Knowing you were compromised by SQL injection yesterday is nice from a forensic standpoint, but it doesn't actually help you stop the intrusion.  Whether it's automatic, or requires human action - the only relevant question at the end of the day is did you stop the threat? 

I can name at least a dozen times over the past couple of years when, given the right information at the right time, massive data breaches could have been minor.  I realize with attack vectors like SQL Injection it's pretty much always "too late" to react but wouldn't it be better to tell the SEC or your investors that you have 1 table from your database stolen over having to tell them your entire database was stolen? 

These are very realistic response issues.  Having actionable intelligence giving you the ability to stop an attack either before it starts (optimally) or as it's happening (next best thing) is the "Holy Grail" of information security teams.

Now you're reading this wondering - how you can possibly implement this type of system without buying one of those "solutions" that comes in 4 rack-mountable 2U boxes right?  Odds are you've got a SIM or SIEM or maybe if you're lucky one of the more advanced SIRM platforms already in-house. 

Leveraging those platforms, and building out capability is more important than probably anything else you'll do, and brings together everything else we've talked about so far.  Knowing where your critical assets are, how they traverse your business platforms, and how your users use them is the key to plugging the holes in the boat before it sinks. 

You can do this... just don't buy into the hype around DLP and understand it's like anything else - baby steps until you have a working system.

Good luck!

Cross-posted from Following the White Rabbit

Before getting into my post, I need to be clear that EMV only refers to the chip in the EMV card.  In the past I have gotten a lot of feedback from Visa when I referred to EMV as “chip and PIN” even though the world almost universally refers to EMV as “chip and PIN.”

With that disclaimer, since last August, Visa USA has been making a concerted effort to get merchants to adopt EMV.  Just a week or so ago, there was another push by Visa USA to entice merchants to support EMV.  So what is the driver behind this push?  That is the $64,000 question and the more you talk to processors and merchants, the more confusing it gets.

Merchants are just as puzzled as I am regarding Visa USA’s EMV push.  In the case of a number of large merchants I have spoken with, they do not get it as they refreshed their card terminals and POS equipment over the last three years and there is no way they are going to swap all of that new gear for EMV-capable equipment.  These merchants are not even looking at contactless terminals.  Such an equipment swap this soon would not be cost effective.

But merchants question what EMV would do for them.  EMV was developed in response to the fall of the Iron Curtain when fraud ran rampant in Europe.  Credit cards were being cloned at an obscene rate and card present fraud was huge. 

When EMV was fully implemented, card present fraud in Europe went to levels close to or a little lower than in the United States and EMV card present fraud has remained around those rates since. 

Given where card present fraud rates are currently in the United States, introducing EMV would have a limited effect on card present fraud and that would not be enough to offset the costs of implementing EMV or contactless terminals.

So if it is not card present fraud, it must be card not present fraud that Visa USA wants to address right?  Card not present fraud, particularly on eCommerce Web sites is running almost out of control.  I would like to say that this increasing fraud rate that is the reason for Visa USA’s push. 

However, EMV does nothing to address the rapidly rising rates of card not present fraud.  The reason is that in order for EMV to address card not present fraud, there would have to be some sort of interface written that would produce codes, single use transaction numbers or similar that could be used by the consumer online.  But no such solution exists, so card not present fraud cannot be the driver either.

Back in August Visa USA announced that merchants using EMV or contactless could avoid filing a PCI Report On Compliance (ROC) with Visa USA, so that must be the reason for the push.  At this year’s PCI Community Meeting in Phoenix, Arizona, PCI SSC General Manager Bob Russo made it very clear that regardless of what Visa USA was saying about filing a ROC; all merchants were still required to prove that they are in compliance with the PCI DSS. 

Other card brands also reinforced this statement by reaffirming that they still required the merchant’s ROC and/or AOC as proof of compliance.  As a result, merchants save themselves very little by not having to file a ROC/AOC with only Visa USA.

What about EMV being more secure?  While that is typically true for small and mid-sized merchants, large merchants that switch their own credit card transactions would still likely have card data in their switch systems if not elsewhere in their computer systems.  So claims by some, including at times Visa USA, that PCI compliance is easier with EMV are not totally true.  Large merchants in Europe will back this up.

So after 15 years of EMV, what is Visa USA trying to prove with this push of EMV?  Apparently only Visa USA can tell us because, for the rest of us, there are no business cases we can construct to justify the switch to EMV.  Obviously, Visa USA knows something that the rest of us do not.  Or do they?  I have consistently said that without any card not present fraud solution; EMV is just a solution looking for a problem.

But wait, maybe there is something here that we have been missing.  Is it possible that Google Wallet and similar current and future applications make Visa USA feel threatened?  There may be some factual basis in that statement.

At the PCI Community Meeting last fall, I spoke with a number of processors that seemed to have an idea of why Visa USA was finally pushing EMV.  These processors indicated that the EMV push was being driven by Visa USA to get EMV into the United States market before Google Wallet and similar applications could take the advantages of EMV away. 

After all, the United States is the largest credit card transaction market in the world and if EMV was not in the United States, there is no driver to get worldwide adoption pushed.

When I quizzed these processors about the supposed “advantages” of EMV, they said that was the real problem.  With the advent of smartphones and applications such as Google Wallet, EMV has no advantages.  As a result, merchants and banks have no incentive to implement EMV with these new technologies just on the horizon.

When I went back and talked to a couple of key merchants, they all said that they are waiting out the technology race to see what wins from a smartphone perspective.  If Google Wallet and the contactless approach win, then that is where they will head. 

However, a lot of merchants are betting on one-time use transaction codes displayed as bar codes to win out as they do not typically require any technology changes at their POS.  American Express went down the one-time use transaction code (15 digit number that appears like a credit card number) around five years ago, but only had limited success with it for online transactions.  However, maybe the time has come for another try.

In the end, it is the consensus of merchants and processors that Visa USA has missed the window for EMV in the United States.  Most organizations believe that if Visa USA wanted EMV in the United States, they should have pushed it long ago.

Cross-posted from PCI Guru

But there are still complexities under the hood of this commodity service. One of the most underestimated in complexity is data storage - it is taken for granted by everyone.

For example, I frequently talk to a high ranking manager in a software company and he constantly states that all that is needed is another disk.

At the end of the day, data storage is very far from simple. Every organization needs to provide storage service for it's requirements.

But storage is not only capacity, and one must be careful when choosing the appropriate solution for storage.

There are three basic options at the moment:

• Cloud storage services
• Open Source based storage systems
• Commercial enterprise storage systems

We will evaluate each service from the following key parameters of a storage system:

Capacity

The first (and usually only) thing we think about when we talk about storage - and the easiest to achieve. Regardless of option for data storage, capacity is upgradeable. In open source storage systems which are based on commodity hardware, upgrades are limited to the abilities of the host server/box.

The enterprise systems are much more upgradeable, but at high costs. For a cloud storage provider, capacity upgrade is nearly infinite (at least on paper). It is wise to plan ahead and consider whether future ability will support your requirements.

Input/Output Operations per Second (IOPS)

The usually forgotten and very difficult to assess parameter, but nonetheless very important. The IOPS should present the amount of operations that the system can perform on a storage within a time-frame of 1 second.

But since read and write operations on a storage can vary (sequential or random, read or write, even there are front-end and back-end IOPS when using RAID configurations).

Cloud storage services do not publish IOPS, Enterprise manufacturers always publish the IOPS number that is most beneficial to them and the open source solution mostly leaves the IOPS to the builder of the system. In any case the end result is, DO NOT TRUST THE NUMBERS.

There are some nice estimation calculators online, like wmarow's iops calculator, but use them only for reference. The smart solution is to test the storage service in a configuration as close to the one you wish to use, and assess whether performance is acceptable.

Access Bandwidth

This is not disk bandwidth, which is calculated via the IOPS. The access bandwidth is the bandwidth between the server and the storage itself. Naturally, you want this to be as high as possible. For enterprise storage systems, discussing access bandwidth is moot, since such storage is mostly connecting through Fibre Channel which has multiple links of 2, 4 or 8 Gbps.

For open source storage systems, which are mostly iSCSI based, the access bandwidth starts with 1 Gbps with Ethernet overhead. For cloud storage services, access bandwidth is a significant factor - cloud services are accessed through WAN links, where access bandwidth is limited and may be prone to congestion. When choosing a storage system, test your application with the bandwidth you are planning on using.

Redundancy and high availability

What kinds of failures and incidents can a storage system survive? Cloud services claim that they can survive a lot - short of a cataclysmic event or a nuclear bombing - but such claims should be tested. Enterprise storage systems are designed to survive nearly any hardware issue within them, and provide abilities to replicate to other systems which are at a distance of tens of kilometer (naturally, at a high high price).

Open source storage systems redundancy is dependent on actual hardware redundancy of the box the customer built, and provide some technologies for replication, which are in a different level of maturity. Always consider placing the data based on the importance to the company - can you survive without it?

Actual hardware

Storage systems are comprised of well known components - hard drives, controllers, interfaces, power supplies. For both enterprise storage systems and for cloud service the customer does not need to bother too much with the hardware - the provider constructs and combines the required hardware.

On the other hand, when preparing an open source storage, the customer usually builds the hardware which means finding appropriate hard drives, RAID controllers, redundancy in power supplies, caching mechanisms, LAN and FC interfaces.

Building a system from scratch is a great experience, but commodity devices may be prone to much more failures then specially built hardware. Testing is not very useful here, but think ahead of the very possible risk of failure of commodity components.

Reporting

Once the storage system starts working, reporting becomes an immediate issue. The customer will want to know the load on the system, on individual hard drives and logical devices, response times, utilization trends etc.

Again, enterprise storage systems shine in this area with an excellent portfolio of reporting tools, albeit usually with exorbitant prices. Cloud storage services may provide some reporting but not too in-depth, and the open source systems usually lack poorly, since the open source project is focused on functionality, not reporting.

When choosing any storage system, always ask to look at the live reports from the service/system you are planning on using.

Support

Again, once the storage system starts working, there will be problems. And I guarantee you - the problems will not be simple: either it works or it doesn't. There will be all kinds of complicated and seemingly impossible combinations of issues. And this is exactly where the customer will need support.

But there is no clear-cut answer to which type of storage system has the best support. One must tread carefully here, because good support is about having trained support personnel, but also having very dedicated support personnel. By definition, enterprise storage systems have a great advantage in this area, but this advantage can easily be ruined by a support team that juggles many projects, is used as presales or is simply not dedicated to supporting a customer.

Cloud services fall in much the same category, but it can be difficult to discuss storage issues with a cloud storage service: the engineers are impossible to reach, there is insufficient data to support an issue (reports, analysis) and the cloud service provider has usually a well crafted SLA to protect themselves from most issues.

The open source systems are an issue of support in a different way - since the systems are built with software which is written by many, there are rarely any real experts to support such a system, unless you pay someone - and even then it may be a risk.

Vendor lock-in

Cloud storage services are the strongest player in this area - if the customer chooses a cloud storage system as an important part of your infrastructure, it will adjust it's operation to the cloud system and create a 'symbiotic' bond, thus making the migration very costly.

Enterprise systems are much easier to migrate from, since they are basically just huge hard drives. If all else fails, an operating system level copy command will provide a very crude but always successful migration. Open source storage systems have no lock-in: simple hard drives, where migration is a copy-paste operation.

Conclusions

There are multiple pros and cons across our storage systems parameters, but at first glance, the enterprise storage systems have the upper hand. Bear in mind though, such systems always come with exorbitant pricing, especially on any upgrades after the initial purchase.

Therefore, such systems may be well suited for the mission critical applications, but are too price prohibitive to be used for every and any use within a company.

The cloud services are extremely flexible in expansion capacity and redundancy (at least on paper). But quality of service and support may be lacking, as well as issues in speed of access.

So cloud based storage may be only logical if you rent the full package - server plus storage in the cloud, to guarantee an overall service level. The remaining issue is lock-in: once you start using a cloud provider, leaving it may be a challenge, since you have adjusted your operation to it's service and it may be costly to shift providers.

The open source systems are an interesting project, and can provide a very cheap solution for a lower tier functions. But in order to actively use such a system would mean to dedicate an employee or a team of homegrown experts on the open source storage system, to properly support the system. Also, redundancy and high availability can become an issue in such systems.

In summary, do not choose only one storage solution: The enterprise system is well suited for the business support, but it is a huge overkill for a test or proof of concept systems. Cloud storage services are a good choice for a cloud based infrastructure, but the lock-in issue requires careful strategic approach before lock-in occurs.

So use everything, and always evaluate any solution for at least 3 months before committing to it.

Cross-posted from Information Security Short Takes

The vulnerability and technique for tracking was discussed in a paper titled “Location Leaks on the GSM Air Interface” presented at the 19th Annual Network & Distributed System Security Symposium.

“Cell phone towers have to track cell phone subscribers to provide service efficiently. For example, an incoming voice call requires the network to locate that device so it can allocate the appropriate resources to handle the call. Your cell phone network has to at least loosely track your phone within large regions in order to make it easy to find it,” researcher and PhD student Foo Kune said.

"The result is that the tower will broadcast a page to your phone, waiting for your phone to respond when you get a call, Foo Kune said. This communication is not unlike a CB radio. Further, it is possible for a hacker to force those messages to go out and hang up before the victim is able to hear their phone ring," a University of Minnesota press release explained.

The researchers warned that the information has the potential to be accessed by hackers or other third-parties with relatively inexpensive off the shelf hardware and know-how to access the Global System for Mobile Communications (GSM) network.

“It has a low entry barrier. Being attainable through open source projects running on commodity software,” Foo Kune said.

The researchers demonstrated the ability to track a target to within a ten-block radius in a proof of concept field test. The vulnerability represents a hazard on multiple levels the researchers believe.

“Agents from an oppressive regime may no longer require cooperation from reluctant service providers to determine if dissidents are at a protest location. Another example could be thieves testing if a user’s cell phone is absent from a specific area and therefore deduce the risk level associated with a physical break-in of the victim’s residence,” the researchers asserted.

The research team has indicated they are in contact with several mobile service providers and are working on disclosures for customers as well as a potential mitigation effort.

Source:  http://www1.umn.edu/news/news-releases/2012/UR_CONTENT_374462.html

Iran will be banned from the purchase of antivirus systems, a kind of technological embargo with clear implications for the Stuxnet virus attacks and the need for the country to prevent further infections to industrial control systems for critical infrastructures, namely their nuclear programs.

The international sanctions will stop the Government of Teheran to from obtaining commercial anti-virus software, according to a senior Iranian intelligence official.

The announcement was been made public by FARS news agency, and Iranian Deputy National Security Minister for technical issues Ahangaran said the country is being forced to design its own anti-virus software due to the sanctions. 

Ahangaran said that Iran is unable update antivirus programs and combat Internet viruses because of the imposed ban.

At this point it is clear in my opinion that the cyber strategy aimed against Iran by Western governments, which have consistently denied authorship of the powerful Stuxnet cyber weapon, are continuing to undermine the nuclear weapons ambitions of Teheran.

The embargo, in addition to reinforcing the belief that the dangerous virus was indeed developed by Israeli agents and / or the U.S., suggests that these countries are focusing their efforts in prelude to a conventional military offensive against Iran.

Are we also close to an escalation of cyber attacks against Iran?

Recall that in recent months it was revealed that Stuxnet was the product of an innovative design for the development of malware defined as a "tilded platform", and certainly the innovative designers behind its production are still engaged in the development of new agents.

Is the antivirus ban part of the preparation to use them? I find the penalty somewhat questionable for the following reasons:

Cyber space, as I have repeatedly said, has no boundaries,and  the potential effects of a cyber attack may have an impact far from against a specific target.

We know that half the world's critical infrastructures are still too vulnerable to a Stuxnet-type virus, and measures such as the ban under discussion could facilitate the spread of malware agents that could end up infecting systems across the world.

Are we really prepared for this?

The ban is intended to push Iran into the production of its own malware defense instruments. I personally think that this scenario was long considered by Iran. And do not forget that Iran already has strategic alliances, especially with China, and access to their technology.

It is ridiculous to think that the antivirus ban will be make the country more exposed than it already is today. And the financial earnings available to Iran resulting from the profits of the oil market gives them plenty of resources to work with.

Sanctions such as these under discussion have a symbolic value only, a provocation to which it is expected Iran will reply, and further justify a conventional military operation: this is the new Cold War.

One might expect the response from Teharan will be to limit the production oil, as the Iranian government knows full well the difficulties that west countries are facing economically and the and the weight of the future oil crisis.

While I'm writing this piece, news agencies are already reporting that Iran has decided to stop selling oil to French and British oil companies. This was announced by the spokesman of the Iranian Ministry of Petroleum, Alireza Nikzad,as  quoted by the official website of the Ministry:

"The sale of British and French oil companies is suspended," said Nikzad.

In recent days, Iranian sources had also announced the suspension of oil supplies to several European countries, including Italy. Is the decline of oil production that will break the glass?

Cross-posted from Security Affairs

The latest incarnation of the botnet is reported to be able to sniff out login credentials for several email protocols as well as files with the .dat extension related to BitCoin and FTP.

"It is the first time that we have seen it. There have been other reports of Waledac popping up that were doing similar things, but the version of Waledac that was taken down by Microsoft was not stealing passwords," Palo Alto Networks' Wade Williamson says.

The security firm identified telltale signatures of the Waledac botnet code while studying samples of the password harvesting tool.

"We were able to match specific quirks in the code based on how the bot handles specific types of communications," Williamson continued.

Microsoft had played a key role in efforts to shut down the Waledac botnet in 2010, though the operation continued functioning at a diminished capacity for a period, and some researchers believe that the infamous Kelihos botnet may have been another incarnation of the Waledac code.

"Since taking down the Waledac botnet in 2010, the botnet remains dead and Microsoft continues to control the domains once used by the botnet’s operators. We also regularly work with ISPs and CERTs around the world to help people remove the Waledac malware and regain control of their computers. Meanwhile, we constantly monitor evolving threats, including variants of botnets we have taken down as well as emerging threats ... We also follow our botnet cases wherever they lead us to hold those responsible accountable for their actions," Microsoft's Richard Boscovich said.

Palo Alto Networks believes the new variant of Waledac could potentially be an operation instigated by a new group of attackers who may have come into possession of the botnet's code and tweaked it from a spamming tool to the one now being used for harvesting login credentials.

"We don't believe this has any impact on the domains controlled by Microsoft. This looks like a restart," Williamson surmised.

Microsoft was also instrumental in the Rustock botnet takedown. In February of 2011, Microsoft provided documentation that detailed the botnet's extensive structure in a federal court filing that was part of a lawsuit against a number of John Doe defendants.

Acting on the information Microsoft provided, federal marshals raided several internet hosting providers across the U.S. in March of this year, seizing servers suspected of being used as Rustock command and control units.

Source:  http://www.darkreading.com/insider-threat/167801100/security/attacks-breaches/232600968/new-waledac-variant-goes-rogue.html

Recently, a Singapore-based iOS software developer made a startling discovery while working with the popular social-networking app Path: in the course of every new account creation, Path uploads the new user’s entire iPhone address book to their servers.

To its credit, Path responded quickly, with its CEO and co-founder Dave Morin explaining that they use the address book data for “friend-finding” and “nothing more.” He also asserted that this technique was an industry standard for social iOS apps.

That response wasn’t enough to contain the firestorm of angry user reactions. Within a day, news of the address book upload had spread, and researchers discovered evidence of similar behavior by other apps, like the photo-sharing service Hipster.

Path publicly apologized and promised to delete the address book data stored on their servers, and to begin using an opt-in system immediately. Hipster has also apologized, and plans to host an “Application Privacy Summit” at their office this month.

The strong user reaction demonstrates a fact that online privacy advocates repeat often: even as norms of sharing evolve online and in the social networking space, users still value their privacy highly.

Users want control over how their data is shared, even if they ultimately choose to share it. By collecting information about not only Path users but also all of their contacts, Path violated the trust and the privacy of their community (not to mention their own privacy policy), and witnessed the backlash.

In their apology, Path acknowledged that the way they designed the “Add Friends” feature was wrong, which is true. As they acknowledged, they could have generated a “hash” of the e-mail addresses to provide a unique identifier. This would have allowed the matches necessary for friend finding, while being incapable of being converted back into the original address.  Hopefully they will adopt this protection soon.

They also could have provided reasonable disclosure of the information they were collecting, but even that is not enough — applications on Android OS allow granular permission control, for example, but many users simply click through the installation process. Users need information present in a clear and understandable manner that allows them to make intelligent choices.

Setting aside the question of whether Apple should even allow application free access to sensitive user data like contact information, the route Path has now chosen — an affirmative opt-in process that explains what Path will collect — is certainly a good start.

Regardless of whether practices like checking addresses for friend-finding are “industry standard” in social apps, users expect and deserve respect from the providers of the services they use, and that means protecting personal data needed to use the service. Hiding behind the rationale that a certain functionality is commonplace among similar apps is not sufficient, the process must be proper whether it’s the uploading of data in the first place or its long-term storage.

In a Wired interview about the “privacy kerfuffle”, Morin assured Path users that the company stores address book data behind a firewall, and that they’re meeting with TRUSTe about their privacy policy compliance and keeping data secure. There was no mention of encrypting the data on the servers in case the firewall might fail.

Even with industry standard security practices in place, the data is still vulnerable to a breach or a subpoena. Companies collecting personal data like Path have an obligation to keep as little personally identifiable data as necessary to provide their services.

Path is taking the right steps to recover from a public relations disaster, but providers of social services should take note: these problems are avoidable. Innovative products and rapid development are great, but service providers need to respect their users or be prepared to face the fallout.

Cross-posted from Electronic Frontier Foundation

"To protest SOPA, Wallstreet, our irresponsible leaders and the beloved bankers who are starving the world for their own selfish needs out of sheer sadistic fun, On March 31, anonymous will shut the Internet down," the hacktivists threatened in a Pastebin posting.

The plan, dubbed "Operation Global Blackout", will attempt to interrupt thirteen of the Internet's Domain Name System (DNS) servers with a Reflective DNS Amplification DDoS tool developed by the collective.

While the operation will not actually crash the internet, the intention is to cause users to receive an error when attempting to access a desired URL.

"In order to shut the Internet down, one thing is to be done. Down the 13 root DNS servers of the Internet... Anybody entering 'http://www.google.com' or ANY other url, will get an error page, thus, they will think the Internet is down, which is, close enough. Remember, this is a protest, we are not trying to 'kill' the Internet, we are only temporarily shutting it down where it hurts the most," the Pastebin posting explains.

The detailed posting goes on to explain the fundamentals of the planned attack as such:

"We have compiled a Reflective DNS Amplification DDoS tool to be used for this attack. It is based on AntiSec's DHN, contains a few bugfix, a different dns list/target support and is a bit stripped down for speed."
 
"The principle is simple; a flaw that uses forged UDP packets is to be used to trigger a rush of DNS queries all redirected and reflected to those 13 IPs. The flaw is as follow; since the UDP protocol allows it, we can change the source IP of the sender to our target, thus spoofing the source of the DNS query."
 
"The DNS server will then respond to that query by sending the answer to the spoofed IP. Since the answer is always bigger than the query, the DNS answers will then flood the target ip. It is called an amplified because we can use small packets to generate large traffic. It is called reflective because we will not send the queries to the root name servers, instead, we will use a list of known vulnerable DNS servers which will attack the root servers for us."

"Since the attack will be using static IP addresses, it will not rely on name server resolution, thus enabling us to keep the attack up even while the Internet is down. The very fact that nobody will be able to make new requests to use the Internet will slow down those who will try to stop the attack. It may only lasts one hour, maybe more, maybe even a few days. No matter what, it will be global. It will be known."

Will the attack be effective in causing a denial of service for most Internet users?

Errata Security's Robert David Graham believes the attack is likely to have little to no effect, as the vulnerability anonymous is targeting has long been understood and compensated for.

"The attack is no longer practical. It's such a common idea that Wikipedia has a page devoted to it. For something so obvious, defenders have spent considerable time devising solutions. There are many reasons why such an attack won't cause a global blackout," Graham writes.

Graham believes the operation will quickly be thwarted with several techniques, the first of which would simply to block the source of the attack.

"Typical hacks work because it often takes a day for the victim to notice. Not so with critical Internet resources, like root DNS servers. Within minutes of something twitching, hundreds of Internet experts will converge to solve the problem... The easiest active response is to blackout the sources of the offending traffic. Defenders can quickly figure out where the attacks are coming from, and prevent packets from those sources from reaching the root DNS servers. Thus, people might see disruptions for a few minutes, but not likely any longer."

Graham goes on to list several other factors that make the likelihood of a successful attack against the thirteen DNS servers nearly impossible to carry out, including the diversity of the deployed server hardware, the use of anycasting routing techniques, the way caching responses are handled, and the fact that the Internet backbone is designed to handle millions of simultaneous requests.

Given Graham's analysis, it looks as though the planned Anonymous attack is good for little more than making some headlines and perhaps causing some unfounded concern from Internet users, which is probably why the operation was broadcast so far in advance.

In a nutshell, this concept means that there’s a statistical distribution of products, services, and so on, meaning most people or populations tend to gravitate to the 80% of whatever is available.

The “long tail” concept illustrates the subtle, often overlooked 20% market that tends to be more niche.

For example, using one of Anderson’s case studies, Amazon sells a number of products that are popular across all buyers.

Think hit movies, popular books, new gadgets, etc.

However, there’s a smaller subset of customers that like incredibly unusual products that most don’t consider. This doesn’t mean they’re not profitable – far from it. That group of people that love 1950′s comic strips about hilarious talking farm animals will be incredibly loyal and devoted to the company that can provide them with goods in their space.

What does this have to do with infosec? My thoughts – we are really lacking a proper “long tail”. RSA is coming up soon – what will we see that points to real innovation in the space? I always tell people that I spend the majority of my time on the show floor at RSA roaming among the smallest, least flashy booths.

The reason is that I’m always searching for that next trend or innovator that is doing something new or original. In a few cases, I’ve been rewarded – last year I saw a lot of “cloud” startups that were peddling Identity and Access Management (IAM) solutions.

This space has a lot of growth, based on what we’ve seen in the last year. More often than not, though, you see a rallying cry of buzzwords. DLP!!! Cloud !!! And we all, of course, make fun of this with our usual, lovable snark. But snark only goes so far.

At some point, we have to take a long, hard look at what we’re doing in security, and whether it’s working. Based on the breaches of the past 10 years, I think it’s safe to say that we’re not winning. Hell, I don’t even know that we’re SOLVING any problems, really.

Folks, we NEED a long tail. We need those organizations that are desperate to find unusual, different solutions that are not available at all right now. And we need small startups to provide them. Peter Kuper, a super-smart guy at In-Q-Tel who I love watching present, often gives talks about the lack of innovation and VC investment in security.

His talks are amusing… and depressing. But we need that focus. One of our fellow security wonks in the space argued to me a few years ago that he was “really innovating” now that he was working at one of the biggest vendors. Bullshit. Big vendors typically buy their way to innovation.

The question is – who are they buying? I encourage you all to pay attention to those tiny little booths in the dark corners of the Moscone Exhibit Hall at RSA 2012. And pray you see more of them.

Cross-posted from ShackF00

Researcher Kuang-Chun Hung of the Security Research and Service Institute−Information and Communication Security Technology Center (ICST) identified an uncontrolled search path element vulnerability, commonly referred to as DLL Hijacking, in the 7-Technologies (7T) AQUIS software.

ICS-CERT has coordinated this report with 7T, and 7T has created a patch that resolves this vulnerability. ICST has confirmed this patch fully resolves the reported vulnerability.

AFFECTED PRODUCTS

The following products and versions are affected:

• AQUIS V1.5 dated October 13, 2011, and any previous version.

IMPACT

A successful exploit of this vulnerability could lead to arbitrary code execution. Impact to individual organizations depends on many factors that are unique to each organization. ICS-CERT recommends that organizations evaluate the impact of this vulnerability based on their operational environment, architecture, and product implementation.

BACKGROUND

7T, based in Denmark, creates monitoring and control systems that are used primarily in the United States, Europe, Northern Africa, and Asia. 7T AQUIS software is a water network simulation platform for improving system design and operation. AQUIS may be in use in other parts of the world using a freely licensed version.

VULNERABILITY OVERVIEW

The 7T AQUIS software is vulnerable to DLL Hijacking. An attacker may place a malicious DLL in a directory where it will be loaded before the valid DLL. An attacker must have access to the host file system to exploit this vulnerability. If exploited, this vulnerability may allow execution of arbitrary code. CVE-2012-0224 has been assigned to this vulnerability.

EXPLOITABILITY: This vulnerability may be exploitable from a remote machine. If exploited, this vulnerability may allow execution of arbitrary code.

EXISTENCE OF EXPLOIT: No known public exploits specifically target this vulnerability.

DIFFICULTY: An attacker requires a moderate skill level to exploit this vulnerability.

MITIGATION

7T has developed a patch to address this vulnerability, which can be accessed here:

• http://aquis.s3.amazonaws.com/AQUIS_1.5_14-12-2011.exe

Users may need to uninstall an earlier version of the application before installing this update.

The full ICS-CERT advisory can be founde here:

Source:  http://www.us-cert.gov/control_systems/pdf/ICSA-12-025-01.pdf