Gmail updated with quick action buttons, Google Wallet integration

Amid all the hubbub of its I/O developer conference, Google has found time to teach Gmail some new tricks with the introduction of quick action buttons that will let you act on emails without even opening them. The buttons appear next to certain types of messages, so if someone sends you a calendar invite, for example, a button will show up on top of the email line that lets you RSVP or decline the invitation.
Reviewing goods, movies, restaurants and services is another common action that can be performed directly from the inbox, according to Google. Other supported actions include one-click replies for tasks like confirming registration emails, and linking to airport check-in sites when receiving flight confirmation details.

Speaking of flight confirmation emails, Google is also introducing interactive cards that display all the important information at the top of emails, so you can check whether your flight and connections are on time at a glance.

The new quick action buttons will roll out over the next few weeks to all Gmail users. The company is calling on developers and companies to create their own quick actions, with initial partners already including big names like Spotify (to play songs mentioned or linked to in emails) as well as Netflix.
In somewhat related news, Google recently announced another noteworthy addition to Gmail that taps into the company’s Wallet service to allow sending money via attachments. A dollar-sign icon will be added to the row of options in the compose window, and those who have linked Google Wallet to their bank account or who have Google Wallet balance can send money to their contacts by clicking on it.

Recipients don't have to be on Gmail, but they do need to have a Google Wallet account. Transferring money is free when the funds come from a linked bank account or a user's Google Wallet balance, but those who use a linked debit or credit card must pay a flat fee of 2.9 percent or $0.30 minimum per transaction. There’s also a $10,000 per transaction and $50,000 over a five-day period limitation for the service.

Know the 4 denial of service types that can threaten the Domain Name System

With the number of denial of service (DOS) attacks growing overall, a variety of techniques are being used to take advantage of the Domain Name System’s openness to direct attacks against DNS servers and even against targets that do not maintain a DNS server.

The asymmetrical nature of DNS queries — the response often is much greater than the query — can turn the system against itself by amplifying attack traffic. With the number of attacks on the rise, security experts have recommended that organizations change their approach to defending against DOS attacks.
Radware’s Global Application & Network Security Report for 2012 cited a 170 percent increase in DNS denial of service attacks from 2011 to 2012 and described four types of attacks targeting or using DNS.
Basic DNS flood
This is much like a brute-force DOS attack against any server, using high volumes of traffic to overpower a DNS server. This can use UDP (User Datagram Protocol) packets, which are accepted by DNS servers and do not require a connection, making it easy to spoof the IP address and hide the identity of the attacking computers.
Even though this is a brute force attack, the attack resources needed are relatively small, since just 10 PCs generating 1,000 DNS requests per second could swamp the capacity of a typical DNS server. Additional computers could be used to further distribute and hide the source of the attack.

This technique actually manipulates DNS servers into directing attack traffic at a target through the use of spoofed IP addresses. Requests are sent to a third-party DNS server or servers using the address of the intended target. Replies are sent to the target server, which can be overwhelmed by the volume of DNS traffic.
The volume of attack traffic is increased because a DNS reply typically is three to 10 times larger than the request. This amplification can be increased another tenfold by using specific DNS requests that require longer answers. The attacker remains hidden behind the DNS servers that are sending replies to the target.
Recursive DNS attack
This leverages the hierarchical nature of DNS, which Radware calls the most sophisticated and asymmetric type of DNS attack. When a recursive DNS server receives a request to resolve a domain name that it does not have cached, it sends out queries to other DNS servers, hoping to get an answer that can be returned. By sending multiple recursive requests for domain names not cached by the target server, an attacker can force the target to send out many requests of its own and wait for responses, quickly using up processing power, memory and bandwidth.
Because of the low amount of traffic needed to generate a recursive attack, it often can fly under the radar of defenses that are tuned to high volumes of traffic.
Garbage DNS attack
This is a volume-based attack using large UDP packets to overwhelm network pipes, which takes advantage of the fact that DNS is a necessity. Because availability on the Internet requires the Domain Name System, organizations will not block the targeted DNS port at the router level, giving a clear shot at the target for a distributed DOS attack.

Sometimes, the Internet just breaks

We tend to think of the Internet as part of a virtual world — cyberspace — in which battle is continuously being waged between hackers and defenders using the 1s and 0s of binary code. It’s easy to forget that the Internet relies on a physical infrastructure that can break.
As Ted Stevens, Alaska’s late Republican senator, famously pointed out, the Internet is a series of tubes. When one of them breaks, your Internet connection can go dark.
The latest State of the Internet report from Akamai noted a concerted wave of distributed denial of service attacks in the third quarter of last year, some producing traffic levels as high as 65 gigabits/sec. But it also noted four disruptions in that quarter that really did break the Internet, at least temporarily, but which probably had nothing to do with DDOS attacks.
Lebanon suffered an outage last July that took the country virtually offline for several hours and that was attributed to problems with a submarine cable in the Mediterranean between Lebanon and Cyprus on which it depends for Internet connectivity. Lebanon reportedly has plans for a second submarine cable to provide more bandwidth and back-up connectivity, but it has not yet appropriated money for it.
A month later, Jordan saw sharp drops in its Internet connectivity, the result of what reportedly was a cut in the power supply to the country’s main Internet service provider. An Internet blackout in Syria in July apparently was a denial of service attack, but that appears to have been carried out by Syria’s own government when local Internet provider networks routed through the state-affiliated Syrian Telecommunications Establishment were removed from the global routing table. This brief outage was neither the first nor the last time the government effectively pulled the plug on the nation’s Internet.
The most high-profile outage last year was at Go Daddy, the Internet registrar and Web hosting company, which in September was knocked out for five hours, leaving as many as 54 million domain names unavailable. The hacktivist collective Anonymous quickly claimed credit, but Go Daddy blamed it on internal network problems that corrupted router data tables, eventually exhausting its resources. In other words, a self-inflicted denial of service.
Not every outage is an attack. Sometimes a tube breaks.

Why do so many antivirus programs miss the same, old exploits

SAN FRANCISCO — Why do so many viruses get onto computers even when they're running updated antivirus products? The problem is two-fold, according to independent testing company NSS Labs.

Analysis of test results on popular antivirus products showed that not only do they miss known exploits, but the different products tend to miss the same exploits, opening up unexpected windows of opportunity for attackers.
"It was a major eye-opener," said Frank Artes, NSS research director and one of the authors of the report, which was released at the RSA Conference this week. "This is particularly important for government," he said, because of the large number of legacy systems agencies often maintain that are not supported by vendors or cannot be easily updated. "These machines are exponentially more at risk," because they must rely heavily on defenses such as antivirus software for protection.
NSS is demonstrating at the conference a tool, still in the early stages of development, that visualizes the gaps left by products in order to help users select the best combinations of security tools and prioritize patching and updating.
That antivirus products are porous comes as no surprise. "Many endpoint/AV vendors state that they are now processing well over 100,000 malware samples per day," NSS noted in a recent test report. "Yet NSS testing shows that the majority fail to block some of the most widely used and dangerous exploits from the past few years."

This apparently is because vendors sometimes drop older exploit signatures from their products to "make room" for new ones without impeding performance.
In a test by NSS of 13 widely used AV products in late 2012, success in blocking 144 well known exploits on machines running recent Windows operating systems ranged from a high of 92 percent to a low of 34 percent. Most products blocked less than 70 percent of the exploits.
The surprise came when researchers began looking at which exploits were successful. Conventional wisdom suggested that multiple products used in sequence would be more successful than using just one, with each catching something that the others had missed. "What we found instead is that there are large areas of correlation between products," Artes said — in some cases, they all missed the same thing.
Testers do not know why these overlaps occur. But using data modeling to see the correlations in results from NSS product tests, different combinations of products were tried to find optimal configurations. "There is not one combination of products that would result in blocking all 1,400 exploits used," he said. "We've beaten ourselves up trying to come up with a combination and we still see things being attacked."
NSS is working with vendors to help them correlate their signature defenses with commonly used exploits, but the bottom line for protecting IT systems remains the same has it has been for some time: Patch systems and keep antivirus up-to-date, but do not rely solely on signature-based defenses.

Why is Java so risky? 77 percent of agencies run unsupported versions

Only a handful of U.S. government computers are using the latest version of Java while more than three quarters of them are running unsupported versions of the software, which has been a common target for malware since 2010, according to an analysis by the Web security company Websense.

There are 52 update versions of Java in use, but as of this month, Oracle will update only versions of Java 7. That leaves a lot of unsupported versions on government and other computers.
JAVA ON THE .GOV DOMAIN
6.38 percent using latest update of Java 7.
23 percent using some version of Java 7.
77 percent using unsupported versions of Java 6 or earlier.
JAVA GLOBALLY
5.17 percent using latest update of Java 7.
21 percent using some version of Java 7.
79 percent using unsupported versions of Java 6 or earlier.
Source: Websence and Oracle

The government figures are in line with the global statistics for Java, which show a large number of versions in use. In the .gov domain there are 52 different update versions of the software being used, some of them more than five years old. This means that attackers do not have to depend on zero-day exploits to compromise these systems, but can rely on a growing number of commonly available exploit kits targeting known vulnerabilities.
“There have been an increasing number of targeted attacks aimed at government users,” said Charles Renert, vice president of research and technology at Websense. “This is a big hole in the IT infrastructure.”
Renert called the situation “a call to action to improve how Java is updated.”
But across-the-board updates to the current versions of software in an environment as complex as the government are impractical if not impossible, and to protect themselves agencies need to be able to identify and block the attacks before they can infect vulnerable software.
“The compromised content still has to hit the application, so stop the phishing and social engineering” that lure users into clicking on unsafe links and attachments, Renert said.
Java is a widely-used programming language for client-server Web applications. Vulnerabilities in it are significant concerns because Java runs on so many computers, often without users being aware of it. If users aren’t aware, it might not be updated regularly.
The large installed base of Java vulnerabilities has led to calls in recent months for abandoning the software. US-CERT in January released an advisory calling for users to disable Java in their browsers at least until a fix for the latest reported exploit was issued. Oracle, which owns Java, released the fix three days later, but the Computer Emergency Response Team of Carnegie Mellon’s Software Engineering Institute continued to advise users that “unless it is absolutely necessary to run Java in Web browsers, disable it, even after updating.”
To understand the extent of the problem of in-place vulnerabilities, Websense added Java version detection to its Advanced Classification Engine and used it to analyze tens of millions of Java endpoints on the ThreatSeeker Network.
Globally, 5.17 percent of analyzed endpoints are using the latest updated version of Java 7 (Version 1.7_17), released in March, compared with 6.38 percent in the .gov domain. At the same time update 17 was released for Java 7, Oracle released its last update, number 43, for Version 6 and announced that it no longer would update Version 6. Globally, nearly 79 percent of users still are using Version 6 or earlier. In government, about 77 percent are using the older versions.

The most commonly used version of Java in .gov is V 1.6_17 (update 17 of Version 6), at 27.41 percent. The next most common is Version 5, at 8.12 percent, which was replaced by Version 6 in 2006. Globally, the most commonly used version is V 1.6_16, at about 9 percent.
There are a number of reasons for the large installed base of outdated Java versions, Renert said. Java is a cross-platform technology, and patching it across multiple operating systems and applications is not a simple task. A lot of mobile devices use Java, and they are often outside direct enterprise management. “It’s a little harder to keep them up-to-date,” he said.
Finally, Java is updated independently of the applications using it, so an application will not necessarily be using the latest version of Java, even if the application itself has been updated. “This mix and match approach makes it difficult to keep up,” he said.
In this environment, application makers and users need to work more closely with Oracle to improve patching and updating policies and practices, Renert said.
But even at its best, updating is an incomplete solution. “The zero-days will always be a risk, and there will always be some out-of-date versions,” Renert said. “You have to assume that controls will be bypassed, that the bad guys are going to find a way around them.” Users need to understand the nature of the threats they are facing and be prepared to block them before they reach vulnerable applications, or block improper outbound traffic from compromised systems.
A full breakdown from Websense and Oracle of Java versions running on the .gov domain:
Version and update     Percentage of installed base
V 1.0 to 1.4                     1.90%
V 1.5                                8.20%
V 1.6_01                         0.04%
    _02                              0.30%
    _03                              0.33%
    _04                               0.01%
    _05                               0.47%
    _06                               0.68%
    _07                               1.30%
    _10                               0.08%
    _11                               0.05%
    _12                               0.47%
    _13                               1.37%
    _14                               0.30%
    _15                               0.51%
    _16                              0.55%
    _17                              27.41%
    _18                              0.87%
    _19                              0.21%
    _20                              2.35%
    _21                              0.84%
    _22                              1.77%
    _23                               0.92%
    _24                              2.21%
    _25                             0.28%
    _26                             3.58%
    _27                             0.65%
    _29                             1.58%
    _30                             2.76%
    _31                             4.38%
    _32                             0.73%
    _33                             1.11%
    _34                             0.87%
    _35                             4.44%
    _37                            1.20%
    _38                             0.66%
    _39                             0.93%
    _41                             0.15%
    _43                             0.55% (Final update of V 1.6; Oracle announced discontinuing support for all of V 1.6 on March 4, 2013)

Java 7 was released July 2011 fist updated in October, 2011
Version and update     Percentage of installed base
V 1.7_01                          0.11%
    _02                               0.17%
    _03                               0.07%
    _04                               0.53%
    _05                               1.63%
    _06                               0.11%
    _07                              4.79%
    _09                              2.82%
    _10                             0.47%
    _11                             1.71%
    _13                             0.85%
    _15                             3.12%
    _17                             6.38% (Current update, released March 4, 2013)



A total of 52 different versions/updates installed.



Source: Websense and Oracle

Kingston adds malware scanner to its secure drives

When key drives were first released, everyone, including public-sector workers, embraced them. Then there was a bit of a backlash in government circles, with some agencies gluing their USB ports closed to prevent unauthorized devices from connecting because the drives offer a window for malware to enter networks. In recent years removable media has been at the center of major security events, as a vehicle of infection for the infamous Stuxnet worm and as a data exfiltration vector associated with the Flame virus.
Today, flash drives are just as convenient as when they were first released, but many also contain high levels of security, which has helped bring them back into government.
Kingston Digital, the flash memory affiliate of Kingston Technology Co., is looking to fight malware on portable drives with scanning technology from ESET and ClevX.  The combination extends ClevX DriveSecurity powered by ESET’s proactive portable anti-malware technology to Kingston’s DataTraveler 4000 and DataTraveler Vault Privacy secure USB flash drives.
"Portable media is a common source of malware infection,” said Andrew Lee, CEO of ESET North America. “People often carry sensitive personal files on their USB drives, and they often don’t realize that their drive can be infected when plugged into a computer, and then that infection can be transferred to other machines. Together with Kingston and ClevX, we can offer a solution which keeps the contents of USB flash drives safe and malware-free and prevents malware from spreading via removable media."
According to Kingston, enterprise users can easily and immediately access ESET’s malware protection upon initialization of the Kingston secure USB flash drives with a strong password. There is no need for management configuration, making it easy for the end user and saving the IT department valuable setup time. Upon logging in and entering a password, the ESET engine scans for spyware, Trojans, worms, rootkits and viruses, without conflicting with the host resident anti-virus software, then notifies the user to take action if malware is detected. It also provides automatic hourly updates when an Internet connection is available. 

Hackers' new trick for slithering through sandboxes

I recently had to have my computer disinfected, which was frustrating. My firewall is up, I keep my antivirus up to date, I’m cautious about opening e-mail and don’t click indiscriminately on links. But something got through.

A new report from Lastline, a security company that focuses on advanced malware, offers some insight into a new technique used by black hat writers to escape detection by having their code do busywork in a security sandbox until it is allowed out.
It should be noted that Lastline has a dog in this fight and is offering a solution to counter this new threat. But the information is still interesting.
A sandbox is a virtual environment with its own guest operating system where intercepted incoming code can be observed. If it acts maliciously or suspiciously, it can be tossed out. Observing behavior of code in a sandbox should detect and block malware regardless of whether the code or the vulnerability it exploits is already known.
The challenge for attackers, then, is to outwit the sandbox. They do that with environmental checking; malware might check for the presence of a virtual machine or it might query well-known registry keys or files that indicate a sandbox. Other malware authors instruct their malware to sleep for a while, waiting for the sandbox to time out.
Security vendors have countered by looking for behavior such as queries for registry keys and by forcing sleeping code to wake up.
The latest trick by malware writers is what Lastline calls stalling code. It delays the execution of a malicious code inside a sandbox and instead performs a computation that appears legitimate. Sort of like an intruder avoiding notice by carrying a clipboard through an office. Once the sandbox has timed out, the evasive malware is free to execute.
This is not the ultimate malware; evasive techniques can be countered by better sandboxes. Also, these techniques are no good if the vulnerabilities being exploited have been patched or if the signature of the code is known. Although signature-based detection has been shown to be an inadequate defense by itself, it still works well when it works.  (We’ll look later at why it doesn’t always work.)
But it is a reminder that what the mind of one man can achieve, another can overcome. No attack and no defense is perfect, and the battle goes onI recently had to have my computer disinfected, which was frustrating. My firewall is up, I keep my antivirus up to date, I’m cautious about opening e-mail and don’t click indiscriminately on links. But something got through.
A new report from Lastline, a security company that focuses on advanced malware, offers some insight into a new technique used by black hat writers to escape detection by having their code do busywork in a security sandbox until it is allowed out.
It should be noted that Lastline has a dog in this fight and is offering a solution to counter this new threat. But the information is still interesting.
A sandbox is a virtual environment with its own guest operating system where intercepted incoming code can be observed. If it acts maliciously or suspiciously, it can be tossed out. Observing behavior of code in a sandbox should detect and block malware regardless of whether the code or the vulnerability it exploits is already known.
The challenge for attackers, then, is to outwit the sandbox. They do that with environmental checking; malware might check for the presence of a virtual machine or it might query well-known registry keys or files that indicate a sandbox. Other malware authors instruct their malware to sleep for a while, waiting for the sandbox to time out.
Security vendors have countered by looking for behavior such as queries for registry keys and by forcing sleeping code to wake up.
The latest trick by malware writers is what Lastline calls stalling code. It delays the execution of a malicious code inside a sandbox and instead performs a computation that appears legitimate. Sort of like an intruder avoiding notice by carrying a clipboard through an office. Once the sandbox has timed out, the evasive malware is free to execute.
This is not the ultimate malware; evasive techniques can be countered by better sandboxes. Also, these techniques are no good if the vulnerabilities being exploited have been patched or if the signature of the code is known. Although signature-based detection has been shown to be an inadequate defense by itself, it still works well when it works.  (We’ll look later at why it doesn’t always work.)
But it is a reminder that what the mind of one man can achieve, another can overcome. No attack and no defense is perfect, and the battle goes on