Thursday, January 18, 2018
Home Tags IPV4

Tag: IPV4

Even CHARGEN services are hosed, daily, says CAIDA study One-third of Internet hosts with IPv4 addresses were subject to denial of service attacks in the last two years.…
A vulnerability in the implementation of the direct authentication feature in Cisco Adaptive Security Appliance (ASA) Software could allow an unauthenticated, remote attacker to cause an affected device to unexpectedly reload, resulting in a denial...
The Simple Network Management Protocolnbsp;(SNMP) subsystem of Cisconbsp;IOS and IOS XE Software contains multiple vulnerabilities that could allow an authenticated, remote attacker to remotely execute code on an affected system or cause an affec...
A vulnerability in the ICMP ingress packet processing of Cisco TelePresence Collaboration Endpoint (CE) Software could allow an unauthenticated, remote attacker to cause the TelePresence endpoint to reload unexpectedly, resulting i...
A vulnerability in Common Internet Filesystem (CIFS) code in the Clientless SSL VPN functionality of Cisco ASA Software could allow an authenticated, remote attacker to cause a heap overflow. The vulnerability is due to insufficie...
It uses antiquated code, possibly to decrease chances of detection. A rare strain of malware known as "Fruitfly" appears to have been lurking in the dusty corners of macOS for years, taking advantage of vulnerabilities in code that hasn't been update...

SHA-1 End Times Have Arrived

For the past couple of years, browser makers have raced to migrate from SHA-1 to SHA-2 as researchers have intensified warnings about collision attacks moving from theoretical to practical. In just weeks, a transition deadline set by Google, Mozilla and Microsoft for the deprecation of SHA-1 is up. Starting on Jan. 24, Mozilla’s Firefox browser will be the first major browser to display a warning to its users who run into a site that doesn’t support TLS certificates signed by the SHA-2 hashing algorithm. The move protects users from collision attacks, where two or more inputs generate the same hash value. In 2012, Bruce Schneier projected a collision attack SHA-1 would cost $700,000 to perform by 2015 and $143,000 by 2018. In 2015, researchers said tweaks to existing attacks and new understanding of the algorithm could accelerate attacks and make a full-on collision attack feasible for somewhere between $75,000 to $125,000. Bocek and other experts warn the move SHA-2 comes with a wide range of side effects; from unsupported applications, new hardware headaches tied to misconfigured equipment and cases of crippled credit card processing gear unable to communicate with backend servers. They say the entire process has been confusing and unwieldy to businesses dependent on a growing number of digital certificates used for not only their websites, but data centers, cloud services, and mobile apps. “SHA-1 deprecation in the context of the browser has been an unmitigated success. But it’s just the tip of the SHA-2 migration iceberg. Most people are not seeing the whole problem,” said Kevin Bocek, VP of security strategy and threat intelligence for Venafi. “SHA-1 isn’t just a problem to solve by February, there are thousands more private certificates that will also need migrating.” Nevertheless, it’s browsers that have been at the front lines of the SHA-1 to SHA-2 migration. And starting next month, public websites not supporting SHA-2 will generate various versions of ominous warnings cautioning users the site they are visiting is insecure. According to Venafi Labs research team, 35 percent of the IPv4 websites it analyzed in November are still using insecure SHA-1 certificates. However, when researchers scanned Alexa’s top 1 million most popular websites for SHA-2 compliance it found only 536 sites were not compliant. Exceptions to Every Rule But still there are companies concerned about disruption to their business after the deadline asking for exceptions and exploring alternatives to full SHA-2 support. “What you are seeing is various companies, for one reason or another, unable to complete the migration” said Patrick Donahue, security engineering product lead at Cloudflare. “The browser makers have created an exception process that allows companies to make appeals for exceptions that allow CAs (certificate authorities) to issue them.” For example, last year Mozilla allowed a security firm to issue nine new SHA-1 certificates to payment processor Worldpay to use in 10,000 of its payment terminals worldwide. Worldpay argued because it missed a Dec. 31, 2015 cutoff for obtaining SHA-1 certificates, and said it needed SHA-1 certificates to buy more time to make the transition to SHA-2 or risk having thousands of its terminals go dark. After considerable debate, Mozilla granted the exception and issued SHA-1 certificates after the cutoff date. According to Cloudflare, as many as 10 percent of credit card payment systems may also face problems as browsers reject SHA-1 certificates used in terminals similar to Worldpay’s. “For credit card processing, it’s not as simple as a software update. It will require sending out new credit card processing machines that support SHA-2,” Donahue said. For social networking behemoth Facebook, it wasn’t so much about the company looking for an exception, rather a solution that could allow it to keep users stuck on older computers and aging handhelds connected to its service. In late 2015, Facebook estimated up to 7 percent of browsers used by its customers, particularly in developing countries, would not able to use the newer SHA-2 standard. At the time, Facebook chief security officer Alex Stamos said, “We don’t think it’s right to cut tens of millions of people off from the benefits of the encrypted Internet, particularly because of the continued usage of devices that are known to be incompatible with SHA-256.” The solution for Facebook is similar to what a number of companies have sought, a stopgap fix until SHA-2 adoption is ubiquitous. Facebook said it has found success running a large TLS termination edge with certificate switching, where it intelligently chooses which certificates a person sees based upon Facebook’s guess as to the capabilities of user’s browser. “This allows us to provide HTTPS to older browsers using SHA-1 while giving newer browsers the security benefits of SHA-256,” Stamos explained. Cloudflare and Mozilla have both developed a similar techniques for customers concerned that line-of-business websites will stop working after the deprecation deadline. “The biggest excuse among web server operators was the need to support Internet Explorer on Windows XP (pre-SP3), which does not support SHA-2.  However, websites with this requirement (including have developed techniques that allow them to serve SHA-2 certificate to modern browsers while still providing a SHA-1 certificate to IE/XP clients,” said J.C. Jones, cryptographic engineering manager at Mozilla. Workarounds work for browsers, but different SHA-2 transition challenges persist within the mobile app space. Apps Must Catch Up on SHA-2 Support When a browser rejects a SHA-1 certificate, the warning message is easy to spot. That’s not the case with apps. While Google’s Android and Apple’s iOS operating systems have supported SHA-2 for more than a year, most apps still do not. “With apps, you don’t get to see what the actual trusted connections are. It requires blind faith,” Venafi’s Bocek said. Alternatively, it should be a matter of trust and verify, he said. He reminds how bad things got in 2014 when Fandango and Credit Karma assured users that their data was secure and being sent over encrypted SSL connections when in fact they disabled their apps’ SSL certificate validation. SHA-1 used by apps is a far cry from no protection. But still, the absence of SHA-2 introduces risk that someone could mint a forged SHA-1 certificate to connect with an app using a SHA-1 certificate. An attacker spoofing the DNS of a public Wi-Fi connection could launch a man-in-the-middle attack, and unlike with a browser, the use of untrusted TLS certificates would go unnoticed, Bocek said. App developers don’t have to worry about pressure from browser makers. More often, it’s about what individual platforms and app makers decide to enforce. In December, Apple backtracked on its plan to enforce a year-end deadline that would have required developers to adopt App Transport Security, which included SHA-2 support. It did not set a new deadline. As with Apple, it’s unclear when Google might force app developers to use SHA-2 or if it will reject SHA-1 certificates used to sign apps. Salesforce warned its developer community and users if they wanted to continue to have error-free access to Salesforce, they needed to ensure their operating systems, browsers, and middleware were capable of accepting HTTPS certificates with the SHA-2 hashing algorithm or risk being blocked. For Facebook, unlike its stance on SHA-1 deprecation for its website, it set a firm sunset date of Jan. 1, 2016 for SHA-1 for developers using its SDKs. After that date, Facebook required apps that connect to it to support SHA-2 connections. “If your app relies on SHA-1 based certificate verification, then people may encounter broken experiences in your app if you fail to update it,” said Adam Gross, a production engineer at Facebook. Internal PKIs Aren’t Immune Enterprises are also not under the same immediate pressure to update their internal PKI used for internal hardware, software and cloud applications. But security experts warn that doesn’t make them immune to major certificate headaches. One of those hassles is the fact the number of certificates has ballooned to an average of more than 10,000 per company, which makes the switch from SHA-1 to SHA-2 a logistical nightmare, according to Venafi. The growth of SSL and TLS traffic has been a mixed blessing, Bocek said. “More security is always better, but one blind spot in a sea of thousands of certificates used within the enterprise could be disastrous for the security of a business.” That’s prompted Microsoft to take a hardline approach to SHA-1 deprecation. It announced an ultimate kill date for SHA-1 for its operating system in 2014: “CAs must stop issuing new SHA-1 SSL and Code Signing end-entity certificates by 1 January 2016 … For SSL certificates, Windows will stop accepting SHA-1 end-entity certificates by 1 January 2017. This means any time valid SHA-1 SSL certificates must be replaced with a SHA-2 equivalent by 1 January 2017 … For code signing certificates, Windows will stop accepting SHA-1 code signing certificates without time stamps after 1 January 2016.  SHA-1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.” “This is an operational issue. It isn’t as simple as patching or upgrading systems,” Bocek said. The migration requires a certificate inventory assessment, a review of policies, application and system testing and automation, he said. But he warns of the perils of procrastination. “This is a non-trivial migration,” Bocek said. Think of 2017 not as the end of the race, rather when SHA-2 migrations begin to hit their stride, he said.
The Nmap Project just released the Holiday Edition of its open source cross-platform security scanner and network mapper, with several important improvements and bug fixes. New features in Nmap 7.40 include Npcap 0.78r5, for adding driver signing updates to work with Windows 10 Anniversary Update; faster brute-force authentication cracking; and new scripts for Nmap Script Engine, the project’s maintainer Fyodor wrote on the Nmap mailing list. The de facto standard network mapping and port scanning tool, Nmap (Network Mapper) Security Scanner is widely used by IT and security administrators for network mapping, port-scanning, and network vulnerability testing. Administrators can run Nmap against the network to find open ports, determine what hosts are available on the network, identify what services those hosts are offering, and detect any network information leaked, such as the type of packet filters and firewalls in use. With a network map, administrators can spot unauthorized devices, ports that shouldn’t be open, or users running unauthorized services. The Nmap Scripting Engine (NSE) built into Nmap runs scripts to scan for well-known vulnerabilities in the network infrastructure. Nmap 7.40 includes 12 new NSE scripts, bringing the total to 552 scripts, and makes several changes to existing scripts and libraries. The ssl-google-cert-catalog script has also been removed from NSE, since Google is no longer supporting the service. Known Diffie-Hellman parameters for haproxy, postfix, and IronPort have been added to ssl-dh-params script in NSE. A bug in mysql.lua that caused authentication failures in mysql-brute and other scripts (affecting Nmap 7.52Beta2 and later) have been fixed, along with a crash issue in smb.lua when using smb-ls. The http.lua script now allows processing HTTP responses with malformed header names. The script http-default-accounts, which tests default credentials used by a variety of web applications and devices against a target, adds 21 new fingerprints and changes the way output is displayed. The script http-form-brute adds content management system Drupal to the set of web applications it can brute force. The brute.lua script has been improved to use resources more efficiently. New scripts added to NSE include fingerprint-strings, to print the ASCII strings found in service fingerprints for unidentified services; ssl-cert-intaddr, to search for private addresses in TLS certificate fields and extensions; tso-enum, to enumerate usernames for TN3270 Telnet emulators; and tso-brute, which brute-forces passwords for TN3270 Telnet services. Nmap 7.40 adds 149 IPv4 operating system fingerprints, bringing the current total to 5,336 OS fingerprints. These fingerprints let Nmap identify the operating system installed on the machine being scanned, and the list includes a wide range of hardware from various vendors. The latest additions are Linux 4.6, macOS 10.12 Sierra, and NetBSD 7.0. The Amazon Fire OS was removed from the list of OS fingerprints because “it was basically indistinguishable from Android.” Nmap also maintains a list of service fingerprints so that it can easily detect different types of services running on the machine. Nmap now detects 1,161 protocols, including airserv-ng, domaintime, rhpp, and usher. The fingerprints help speed up overall scan times. Nmap 7.40 also adds service probe and UDP payload for Quick UDP Internet Connection, a secure transport developed by Google that is used with HTTP/2. A common issue when running a network scan is the time it takes to complete when some of the ports are unresponsive. A new option—defeat-icmp-ratelimit—will label unresponsive ports as “closed|filtered” in order to reduce overall UDP scan times. Those unresponsive ports may be open, but by marking the port this way, administrators know those ports require additional investigation. Source code and binary packages for Linux, Windows, and MacOS are available from the Nmap Project page.
Enlarge / Georgia politician Brian Kemp reads at a Holocaust remembrance ceremony in the reader comments 31 Share this story Accusations that the US Department of Homeland security tried to hack Georgia's voter registration database are running rampant.

But until officials from that state's Secretary of State office provide basic details, people should remain highly skeptical. The controversy erupted after Georgia Secretary of State Brian Kemp sent and publicly released a letter addressed to DHS Secretary Jeh Johnson.
In it, Kemp made a series of statements so vague in their technical detail that it's impossible to conclude any kind of hacking or breach—at least as those terms are used by security professionals—took place. "On November 15, 2016, an IP address associated with the Department of Homeland Security made an unsuccessful attempt to penetrate the Georgia Secretary of State's firewall," Kemp wrote. "I am writing you to ask whether DHS was aware of this attempt and, if so, why DHS was attempting to breach our firewall." Kemp continued: The private-sector security provider that monitors the agency's firewall detected a large unblocked scan event on November 15 at 8:43 AM.

The event was an IP address ( attempting to scan certain aspects of the Georgia Secretary of State's infrastructure.

The attempt to breach our system was unsuccessful. At no time has my office agreed to or permitted DHS to conduct penetration testing or security scans of our network. Moreover, your Department has not contacted my office since this unsuccessful incident to alert us of any security event that would require testing or scanning of our network.

This is especially odd and concerning since I serve on the Election Cyber Security Working Group that your office created. As you may know, the Georgia Secretary of State's office maintains the statewide voter registration database containing the personal information of over 6.5 million Georgians.
In addition, we hold the information for over 800,000 corporate entities and over 500,000 licensed or registered professionals. As Georgia's Secretary of State, I take cyber security very seriously.

That is why I have contracted with a global leader in monitored security services to provide immediate responses to these types of threats.

This firm analyzes more than 180 billion events a day globally across a 5,000+ customer base which includes many Fortune 500 companies.

Clearly, this type of resource and service is necessary to protect Georgians' data against the type of event that occurred on November 15. The letter uses some scary language, including an "attempt to penetrate" and "breach" the agency's firewall and system plus "security event." However, nowhere does it say what gives rise to such claims.

The phrases "large blocked scan event" and "attempting to scan certain aspects of the Georgia Secretary of State's infrastructure" are vague to the point of being almost meaningless. Many security professionals on social media are interpreting them to mean a computer with an IP address belonging to the DHS sent a request to one or more Internet ports on a Georgia Secretary of State network to see if they provided some sort of response. Such scans allow someone to know if network ports reserved for e-mail, Web traffic, and all sorts of other Internet services are responding to queries from outside services.
Security professionals and blackhat hackers alike use such scans all the time to identify vulnerable networks.

For instance, in the weeks following the 2014 discovery of the Heartbleed vulnerability—arguably one of the most severe security bugs ever to hit the Internet—it was network scans that allowed the public to learn that huge swaths of the Internet remained vulnerable and to identify the 300,000 specific sites that had yet to install a patch. It was the same sort of scan in 2013 that identified more than 81 million IP addresses that were exposing a networking feature known as Universal Plug and Play to the Internet at large.

The setting, which was in violation of guidelines that say UPnP isn't supposed to communicate with devices that are outside a local network, put them at risk of being remotely hijacked by people halfway around the world.

The discovery was only possible by performing a scan on every routable IPv4 address about once a week over a six-month period. As a security researcher and CEO of penetration testing firm Errata Security, Rob Graham regularly scans the entire Internet for insights about vulnerabilities. "I get these letters all the time," he told Ars, referring to the type of letter Kemp sent. While some people argue the practice is unethical or even illegal, Graham has never been sued or prosecuted for it, and Ars isn't aware of any practicing attorneys who say such scans are unlawful. (Graham does agree to stop sending IP addresses upon request by the owners of those addresses.) Playing devil's advocate In fairness, there's no way to be certain Kemp's letter is complaining of a network scan.

The references to penetration testing and attempts to breach the agency's system and to penetrate or breach its firewall raise the possibility of something that went beyond passive scans.
If, for example, the DHS computer attempted to exploit a SQL injection vulnerability that divulged protected data or accounts, such a move could very well run afoul of criminal hacking statutes.

Trying to exploit specific vulnerabilities in the agency's firewall might also be unlawful. Meanwhile, the phrase "large unblocked scan event" is so technically clumsy that security practitioners say it could mean just about anything. The problem with Kemp's letter is that readers have no way of knowing what gave rise to his exceptional claims. Yet despite the vagueness, the Internet is now awash with reports that the DHS tried and failed to hack Georgia's Secretary of State office, an event that if true, would amount to an extremely serious offense.

Georgia Secretary of State officials didn't respond to Ars' request for an interview.
In the absence of crucial details left out of Thursday's letter, there's little that's odd or concerning about the reported November 15 complaint, and there's certainly no evidence of an attempted breach by the DHS at this time. ntpd prior to 4.2.8p9 contains multiple denial of service vulnerabilities.
DHCP has to be trusted, so this isn't trivial to block How do you get a sniff of a locked computer? Tell it you're its gateway to the entire Internet IPv4 routing space. That's the basic principle behind a demo from brainiac cracker Samy Kamkar. Plugged into a victim, his Raspberry Pi Zero-based "PoisonTap" isn't just a network sniffer, it's a backdoor-digger. MacOS users can breathe a sigh of relief: Kamkar's attack currently only works on Windows and Linux boxen. The basic bit of trust he exploits is this: operating systems trust DHCP (Dynamic Host Control Protocol) information that routers use to tell them how to get to the Internet. They must, after all. If a computer – even a locked one – detects the PoisonTap Ethernet emulator plugged into its USB port, it loads it and runs a DHCP request across it. Instead of providing a legitimate router's response, that the local network covers, for example, PoisonTap says it's the whole IPv4 address space (from to That tricks the OS into treating what should be a “low priority” network interface as more important than the native Ethernet port of the target. Kamkar writes “if traffic is destined to, while normally this traffic would hit the default route/gateway of the primary (non-PoisonTap) network device, PoisonTap actually gets the traffic because the PoisonTap “local” network/subnet supposedly contains, and every other IP address in existence”. Ho hum, a local exploit ... “So what?” you ask. “It's plugged into the USB port – someone's bound to notice”. That's where Kamkar's extra code work comes in: while the device is plugged in, with all that traffic crossing PoisonTap it's a cinch to capture cookies and the like. In the video below, he explains: “As long as a browser is running on the machine and an HTTP request is made automatically – such as through an ad, AJAX request, or other dynamic web content, which happens on most sites, even when the browser is entirely in the background, PoisonTap intercepts the request and responds with attack code that’s interpreted by the browser”. And some of that's quite nasty: a 2FA session cookie lets an attacker pretend to be opening an already logged-in session. Kamkar also wrote Web backdoor code so it would produce thousands of iFrames that are “HTML+Javascript backdoors that are cached indefinitely”. That gives an attacker a persistent backdoor through the user's legitimate router – “a persistent WebSocket out to the attacker’s web server (over the Internet, not on the PoisonTap device)”. That can be exploited, again with new iFrames, so that having a backdoor associated with, the attacker can then redirect their exploit to “Any 'X-Frame-Options', Cross-Origin Resource Sharing, and Same-Origin Policy security on the domain is entirely bypassed as the request will hit the cache that PoisonTap left rather than the true domain”. Fooling around with what's cached on the victim's host also means PoisonTap can drop a remote access backdoor to any router that's got default or weak credentials. Protection? If you're running a server, use HTTPS – at the very least for authentication and authenticated content, make sure cookies are marked with the secure flag, add the subresource integrity flag to any remote JavaScript, and use HSTS. As a desktop user, you can either abandon Thunderbird or USB ports entirely, close all browser tabs when leaving your machine, or – the most practical suggestion – use an encrypted sleep mode (FileVault2 with “deep sleep”). If you're interested in Kamkar's previous exploits, you can check out his browser location stalking, which got a reprise in Android; a handy chip-and-pin bypass, or a demo that car-hacking was child's play. ® Youtube Video Sponsored: Customer Identity and Access Management
EnlargeSamy Kamkar reader comments 48 Share this story The perils of leaving computers unattended just got worse, thanks to a newly released exploit tool that takes only 30 seconds to install a privacy-invading backdoor, even when the machine is locked with a strong password. PoisonTap, as the tool has been dubbed, runs freely available software on a $5/£4 Raspberry Pi Zero device. Once the payment card-sized computer is plugged into a computer's USB slot, it intercepts all unencrypted Web traffic, including any authentication cookies used to log in to private accounts. PoisonTap then sends that data to a server under the attacker's control.

The hack also installs a backdoor that makes the owner's Web browser and local network remotely controllable by the attacker. Enlarge Samy Kamkar PoisonTap is the latest creation of Samy Kamkar, the engineer behind a long line of low-cost hacks, including a password-pilfering keylogger disguised as a USB charger, a key-sized dongle that jimmies open electronically locked cars and garages, and a DIY stalker app that mined Google Streetview. While inspiring for their creativity and elegance, Kamkar's inventions also underscore the security and privacy tradeoffs that arise from an increasingly computerized world. PoisonTap continues this cautionary theme by challenging the practice of password-protecting an unattended computer rather than shutting it off or, a safer bet still, toting it to the restroom or lunch room. Kamkar told Ars: The primary motivation is to demonstrate that even on a password-protected computer running off of a WPA2 Wi-Fi, your system and network can still be attacked quickly and easily.

Existing non-HTTPS website credentials can be stolen, and, in fact, cookies from HTTPS sites that did not properly set the 'secure' flag on the cookie can also be siphoned. Unsecured home or office routers are similarly at risk. Kamkar has published the PoisonTap source code and additional technical details here and has also released the following video demonstration:
PoisonTap - exploiting locked machines w/ Raspberry Pi Zero. Once the device is inserted in a locked Mac or PC (Kamkar said he hasn't tested PoisonTap on a Linux machine), it surreptitiously poisons the browser cache with malicious code that lives on well after the tool is removed.

That makes the hack ideal for infecting computers while they are only briefly unattended. Here's how it works. Once the PoisonTap software is installed, the Raspberry Pi device becomes a miniature Linux computer that presents itself as an Ethernet network. Like a router, it's responsible for allocating IP addresses for the local network through the dynamic host configuration protocol.
In the process, the device becomes the gateway for sending and receiving traffic flowing over the local network.
In this sense, PoisonTap is similar to a USB exploit tool demonstrated in September that stole login credentials from locked PCs and Macs. Through a clever hack, however, PoisonTap is able to become the gateway for all Internet traffic as well.
It does this by defining the local network to include the entire IPv4 address space. With that, the device has the ability to monitor and control all unencrypted traffic the locked computer sends or receives over its network connection. PoisonTap then searches the locked computer for a Web browser running in the background with an open page. When it finds one, the device injects HTML iframe tags into the page that connect to the top 1 million sites ranked by Alexa.

Because PoisonTap masquerades as the HTTP server for each site, the hack is able to receive, store, and upload any non-encrypted authentication cookies the computer uses to log in to any of those sites. Given its highly privileged man-in-the-middle position, PoisonTap can also install backdoors that make both the Web browser and connected router remotely accessible to the attacker.

To expose the browser, the hack leaves a combination of HTML and JavaScript in the browser cache that produces a persistent WebSocket. PoisonTap uses what's known as a DNS rebinding attack to give remote access to a router. That means attackers can use PoisonTap to remotely access a browser as it connects to a website or to gain administrative control over the connected router.

Attackers still must overcome any password protections safeguarding an exposed router.

But given the large number of unpatched authentication bypass vulnerabilities or default credentials that are never changed, such protections often don't pose much of an obstacle. PoisonTap challenges a tradition that can be found in almost any home or office—the age-old practice of briefly leaving a locked computer unattended.

And for that reason, the ease and thoroughness of the hack may be understandably unsettling for some people.
Still, several safeguards can significantly lower the threat posed by the hack.

The first is to, whenever possible, use sites that are protected by HTTPS encryption and the transmission of secure cookies to prevent log-in credentials from being intercepted.

A measure known as HTTP Strict Transport Security is better still, because it prevents attack techniques that attempt to downgrade HTTPS connections to unsecured HTTP. As a result, neither Google nor Facebook pages can be triggered by computers infected by PoisonTap.
Sadly, multi-factor authentication isn't likely to provide much protection because it generally isn't triggered by credentials provided in authentication cookies. End users, meanwhile, should at a minimum close their browsers before locking their computer or, if they're on a Mac, be sure to enable FileVault2 and put their machine to sleep before walking away, since browsers are unable to make requests in such cases. Regularly flushing browser caches is also a sound, albeit imperfect, measure.

For the truly paranoid, it may make more sense to simply bring laptops along or to turn off machines altogether.