STE WILLIAMS

WPA2 Wi-Fi users – ie, almost all of us – have had a troubling Monday with the arrival of research demonstrating a critical design flaw in the technology used to secure our wireless networks. A flaw so bad, it can be exploited by nearby miscreants to potentially snoop on people’s internet connections over the air.

However, don’t stop using Wi-Fi or WPA2 completely, nor rage quit technology as a whole, no matter how simple this vulnerability is. It’s annoying, but there is light at the end of the tunnel.

The Key Reinstallation Attacks, aka KRACK, sounds scary – and it is an embarrassing oversight for the IEEE and its 802.11i protocol – but there are important caveats.

TL;DR on the KRACK WPA2 stuff – you can repeatedly resend the 3rd packet in a WPA2 handshake and it’ll reset the key state, which leads to nonce reuse, which leads to trivial decryption with known plaintext. Can be easily leveraged to dump TCP SYN traffic and hijack connections.

— Graham Spookyland 🎃 (@gsuberland) October 16, 2017

Firstly, there are some limitations. For a start, an eavesdropper has to be in wireless range of the target network, and have the time and specialized software to pull off the KRACK technique.

KRACK is only applicable in WiFi-range. If a shady hoodie is outside your house tapping on keyboard, encryption isn’t your top problem.

— Tarah M. Wheeler (@tarah) October 16, 2017

Secondly, if your network traffic is encrypted using HTTPS, a VPN, SSH, TLS, or similar, KRACK won’t get very far. All the miscreant will see, after deciphering the wireless network packets, is more encrypted data. At that point, the snooper is just like any other spy potentially sitting on the vast web of networks between you and the website or service you’re connected to – and that’s why we try to do HTTPS and other end-to-end encryption everywhere: to thwart naughty people lurking silently in the middle. Sadly, quite a lot of internet traffic is still using unencrypted and unprotected HTTP, or can be downgraded to HTTP in certain situations, which is why this KRACK issue is such a pain.

This attack does not reveal a Wi-Fi network’s password. But it can, if the base station uses WPA-TKIP or GCMP encryption, be used to inject data into your unencrypted traffic, such as malicious JavaScript and malware downloads into plain HTTP connections. That’s not great.

And while we’re on the subject of bad news, if you’re using Android 6.0 or Linux with wpa_supplicant 2.4 or later, it’s way easier to hijack the wireless connection. Due to a programming cockup, this software uses a zero key – ie, all zeroes – when under attack by the KRACK method, which makes it potentially trivial to intercept, decrypt and tamper with passing wireless packets to and from those devices.

That’s the bad news – here’s hopefully some good news

WPA2 KRACK attack smacks Wi-Fi security: Fundamental crypto crapto

READ MORE

Despite these caveats this is a serious issue, in the main because of the massive numbers of devices out there using WPA2 and the difficulty in patching them all: sure, computers and recent Android devices can grab software fixes, but wew shudder to think about all the unloved Internet-of-Things devices out there that will remain unpatched for a while or indefinitely.

On the good news front, Mathy Vanhoef and Frank Piessens of KU Leuven, the security researchers who discovered the flaw, alerted vendors in advance of going public on Monday. It appears developers and manufacturers may have got their first warning in July, around the time this unsigned paper [PDF] going over some of the KRACK techniques quietly emerged online.

Now that the news is out, some organizations have been better than others. Microsoft patched its code in its October batch of security updates, and Apple will have fixes out in public within a few days after release some updates to beta testers. Google’s still working on its stuff, however.

Cisco has some patches out, with more to come, along with more technical discussion of the issue. Intel, Netgear, Aruba, and Ubiquiti also have patches out, and the Wi-Fi Alliance is working with other vendors on the issue.

On the Unix-y front, OpenBSD has a fix available, as does Debian.

Of course, this is only half the battle: users and administrators have to obtain and install the patches, where available. Good luck telling already overstretched BOFHs and PFYs to drop everything and patch every Wi-Fi enabled bit of kit in the office, let alone expecting whoever’s handling the Wi-Fi firmware for your home security camera to get busy.

Despite many major manufacturers of Wi-Fi systems getting to work on patching, the US CERT list shows there’s a huge pool of white box builders and defunct companies that are never going to release patches. This is why it’s important to never trust the network.

KRACK is a reminder of the benefits of the BeyondCorp approach. The security perimeter should be identity, not the network border.

— SpookyTayOnSecurity (@SwiftOnSecurity) October 16, 2017

So, in summary, don’t panic, but get patching and be a lot more discerning about how you figure your network into your threat model. Assuming everything is lovely and friendly on your Wi-Fi will cause you to become unstuck at some point.

No doubt we’re going to see KRACK used in anger, but honestly it’ll take a while. There’s no easy-to-use exploit code out there, yet, but it will come, and even when it does the world isn’t ending because of today’s news.

A-IEEE-EEEE

Finally, don’t forget that the IEEE makes the whole process of evaluating and scrutinizing its standards rather difficult. You either have to pay to see the specifications, or wait months after they’ve been published and hardcoded into devices. And the specs aren’t massively clear, which is why Windows and iOS aren’t as badly affected as Linux: Microsoft and Apple’s engineers seemingly didn’t follow the specification correctly in their WPA2 implementations, thwarting part, but not all, of the KRACK technique.

“One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings,” said cryptographer and professor Matthew Green in a blog post we linked to at the top of this piece.

“More importantly, even after the fact, they’re hard for ordinary security researchers to access. Go ahead and google for the IETF TLS or IPSec specifications — you’ll find detailed protocol documentation at the top of your Google results. Now go try to Google for the 802.11i standards. I wish you luck.

“The IEEE has been making a few small steps to ease this problem, but they’re hyper-timid incrementalist bullshit. There’s an IEEE program called GET that allows researchers to access certain standards (including 802.11) for free, but only after they’ve been public for six months — coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software.

“This whole process is dumb and — in this specific case — probably just cost industry tens of millions of dollars. It should stop.”

What’s even more ugly is that WPA2’s four-way handshake at the heart of KRACK was mathematically proven as secure. Unfortunately, that verification process overlooked the fact that a secret session encryption key negotiated between the device and base station may be installed more than once. The KRACK method exploits this to reinstall the key over and over to attack the encryption protocol. ®

Sponsored:
The Joy and Pain of Buying IT – Have Your Say

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/10/17/kracken_patches/

In its ongoing effort to improve browser security, school Microsoft on security, and retain its search audience, Google is today rolling out several Chrome for Windows fortifications.

The search biz has modded Chrome for Windows to detect when extensions switch people’s Chrome settings, such as the default search engine, without authorization, a common tactic for deceptive software. The browser will now ask whether it can restore previous settings, which for the majority of Windows users will reestablish Google as Chrome’s default search engine.

The operation can also be done by visiting a reset URL:

chrome://settings/resetProfileSettings

What’s more, Google has enlisted security biz ESET to rebuild its Chrome Cleanup engine for removing deceptive code. In effect, the browser is getting built-in basic antivirus protection for your Windows computer.

“Our engine scans for and cleans potentially harmful applications, specifically the types that negatively impact or target the Chrome browsing experience,” said Juraj Malcho, chief technology officer at ESET, in an email to The Register. “It is not meant to provide full coverage against all modern threats, its capabilities are limited to detecting specific malware families and/or specific ways of tampering with Chrome or operating system.”

Chrome Cleanup began life in 2014 as Software Removal Tool, a sort of factory reset for Google’s browser. Referred to as both Chrome Cleanup Tool and Chrome Cleanup, it has evolved into a way for Windows users to undo the damage from “unwanted software,” the neutered term Google uses for malware.

“Unwanted software” emphasizes desirability, or lack thereof, rather than responsibility. The web giant takes a similar tack by referring to ad fraud as “invalid clicks.” It also uses the defanged phrase “potentially harmful apps,” or PHAs, in lieu of something stronger.

In its Android Security 2016 Year in Review report, Google said it employs the term “unwanted software” as “a way to deal with applications that are not strictly considered malware, but are generally harmful to the software ecosystem.”

For what it’s worth, Chrome, by default, automatically tries to stop software nasties from being accidentally downloaded onto a machine, by checking website URLs against lists of known dangerous and unsafe sites. If you surf to a website known for distributing malware, er, unwanted software, a big red warning will appear in the browser urging you to stop and go back the way you came.

Microsoft flips Google the bird after Windows kernel bug blurt

READ MORE

However, this kind of prevention isn’t perfect, because new evil sites pop up all the time and may not be on the blacklist immediately, and so now Chrome has its own proper builtin antivirus for catching and removing particular types of malicious code, if that code manages to run on a machine.

And here’s why Google opts for “unwanted software” rather than “malware.” To avoid any arguments or court battles over accusations of wrongdoing, rather than label a dodgy application as “malware,” Google opts for no-fault removals, without apology, blame or recompense. It’s not removing illegal or deliberately malicious software from your computer, it’s removing unwanted software.

Semantics aside, the tweaked Chrome Cleanup sports a revised interface for more clearly communicating what will be removed. It’s also, Google insisted, capable of removing “more unwanted software than ever before,” which isn’t a particularly clear metric.

Malcho said ESET’s engine doesn’t monitor the system all the time, but instead runs scans periodically with a focus on remediation – restoring the settings to a known good state.

“The speed of the scan and minimal performance impact are crucial,” Malcho said. “Hence only the most necessary parts of the scanning engine are included, resulting in a pretty tiny product. Also, only selected parts of OS are being scanned as compared to full a blown security solution.”

Nonetheless, it’s a useful expansion of Google initiatives like Safe Browsing to muck the stalls of the web. Google also stresses that it is not supposed to replace Windows Defender or whatever antivirus tools you have on your system. “Note this new sandboxed engine is not a general-purpose antivirus — it only removes software that doesn’t comply with our unwanted software policy,” the ads giant said.

A Google spokesperson told The Register via email: “All Canary and Dev Chrome for Windows users should have the new Chrome Cleanup features. Those on Beta and Stable will receive later this week. These features are not tied to our regular Chrome release schedule and users with Chrome 61 and higher will receive the new features.”

This comes after Google researchers have, over the years, pointed out various flaws in Microsoft’s programming – from bugs in the Windows kernel to cockups in the operating system’s bundled antivirus engine. ®

Sponsored:
The Joy and Pain of Buying IT – Have Your Say

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/10/16/chrome_for_windows_malware/

RSA keys produced by smartcards, security tokens, laptops, and other devices using cryptography chips made by Infineon Technologies are weak and crackable – and should be regenerated with stronger algorithms.

In short, Infineon TPMs – aka trusted platform modules – are used in countless computers and gadgets to generate RSA key pairs for securing VPNs, implementing trusted boot sequences, performing whole disk encryption, granting access to cloud accounts, producing encryption certificates, and more. The secrets at the heart of these systems can be mathematically cracked by determined adversaries, allowing them to potentially gain control of computers and decipher data secured by the TPM-built RSA keys.

We’ve previously covered the firmware bug on these pages. Now, while everyone’s distracted by the WPA2 KRACK flaw, a few more details of the Infineon screwup have emerged, and you should check them out to make sure you’re not affected or take action if so. For example, the bug causes some Yubikey 4 gadgets to generate weak authentication keys, and should be replaced as soon as possible.

Essentially, you should upgrade your TPM’s firmware, via updates from your device’s manufacturer or operating system’s maker, as soon as possible, and refresh your weak keys using the new code on the hardware or using a stronger implementation.

Crypto expert Thomas Ptáček had this to say:

The Infineon bug is a bigger deal than the WiFi bug.

— Thomas H. Ptáček (@tqbf) October 16, 2017

Meanwhile: we’ll be checking RSA keys for this stupid Infineon prime search bug for the next 10 years.

— Thomas H. Ptáček (@tqbf) October 16, 2017

The TPM vulnerability can be exploited to compute, by factorization, the private keys from public keys in TPM-generated RSA private-public key pairs. Suffice to say, this shouldn’t be possible, and the private component is supposed to remain secret.

The bug lies in the chipset’s firmware code that generates key pairs, and was discovered by a team of researchers at Masaryk University in Brno, Czech Republic; UK security firm Enigma Bridge; and Ca’ Foscari University of Venice, Italy. Infineon security chips manufactured from 2012 onwards, including the latest versions, are all vulnerable.

We’re told you’ll need somewhere in the region of $30,000 in cloud computing power to crack a 2,048-bit RSA key pair generated by the dodgy Infineon hardware. For 1,024-bit keys, which are generally crap anyway, it is trivial to factorize a vulnerable private key.

“The attack is practical, although it’s unlikely to be cost-effective for large-scale attacks,” Dan Cvrcek of Enigma Bridge told El Reg on Monday. “The current indicative processor times for 1,024 and 2,048 bit keys are 97 vCPU days ($40 to $80) and 51,400 vCPU days ($20,000 to $40,000), respectively.

“Worst hit, at the moment, seems to be … whole-disk encryption, as well as for securing access to some cloud platforms, but it extends to non-repudiation signatures, email signing, access to VPN and buildings, e-Health cards, and e-IDs.”

Cvrcek estimated that Infineon’s TPMs are “25 to 30 per cent of TPMs used globally.” The flawed Infineon chipset has been integrated into motherboards, laptops including Chromebooks, authentication systems, trusted boot mechanisms, and cryptographic tokens sold by computer and device makers worldwide.

Major vendors including HP, Lenovo and Fujitsu have released software updates and mitigation guidelines.

An idea of the stuff affected by the TPM bug … From the bug’s researchers

The vulnerability has been dubbed ROCA, aka Return of Coppersmith’s Attack aka CVE-2017-15361, and is believed to be behind recent security problems with Estonian ID cards. The code flaw was documented by Google and Microsoft last week.

Full details of the research, including the factorisation method, will be released at the ACM’s Computer and Communications Security (CCS) conference. A paper, “The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli,” will be unveiled at the confab in Dallas, Texas, on November 2.

Ahead of the talk, the researchers have produced offline and online detection tools that will allow folks to figure out whether or not their keys are affected by the issue. ®

Sponsored:
The Joy and Pain of Buying IT – Have Your Say

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/10/16/roca_crypto_vuln_infineon_chips/

The move follows a DHS review of federal government agencies’ steps to secure email and deploy authentication technologies.

The U.S. Department of Homeland Security issued a binding operational directive (BOD) requiring all federal agencies that use .gov email and website domains to secure email and deploy authentication technologies in the coming months, the DHS announced Monday.

In the next 30 days, all federal agencies are mandated to develop a plan to implement the Domain-based Message Authentication, Reporting Conformance (DMARC) security protocol, which is designed to prevent phishing and spamming attacks.

DMARC creates a whitelist of verified senders, then seeks to deliver only authenticated emails and delete fake ones before a user sees them. It also has the potential side benefit of reducing  “shadow IT” by restricting the ability for company employees to send out unauthorized email campaigns.

Three categories of filtering exist under DMARC: monitoring email for phishing and spam, quarantining emails that fall into this category, and, lastly, deleting such emails.

Within the next 90 days, all federal agencies are required to have their DMARC plans in place and, at a minimum, have begun monitoring emails.

Over the coming year, the DHS aims to have 100% of federal agencies rejecting phishing and spam emails, said Jeanette Manfra, assistant secretary for the Office of Cybersecurity and Communications at the DHS, during a joint-press conference with the Global Cyber Alliance.  

“Citizens who depend upon interaction with the government deserve a trusted relationship. So, if they see an email from the IRS or FEMA, they need to believe and trust it is an email from the IRS or FEMA,” Manfra said.

Additionally, within the next 120 days, all federal agencies will be required to use encryption on their websites via HTTPS and STARTTLS for email.

DHS has been working to implement DMARC over the past year and in the spring ramped up its efforts to encourage federal agencies to adopt the protocol. But, apparently, that was not enough.

“We felt in talking with all the agencies that we needed a little bit of a push to get people to really prioritize it and focus on it,” said Manfra, who noted the DHS has previously used a BOD in a few cases with federal civilian offices.

DMARC Industry Details
Google, Yahoo, and Microsoft email services support DMARC, providing a large leg up in migrating consumers to the security protocol. The DHS reports 4.8 billion inboxes worldwide support DMARC, accounting for 76% of global email accounts.

Federal agencies and enterprise companies are far from the 50% DMARC level, according to the DHS and industry reports.

Two-thirds of Fortune 500 companies, meanwhile, have not deployed any level of DMARC, according to an analysis of DNS records by Agari.

Agari’s report found 25% of survey respondents chose to only monitor email, 3% have a quarantine policy, and 5% have implemented a reject policy. Agari lumped the organizations that only monitor email into the category of not deploying any level of DMARC, because users would not have received the protection of having their emails quarantined or rejected.

DMARC Deployment Delays
The majority of DMARC deployments fail, according to a report last year by ValiMail. The report found 62% to 80% of DMARC efforts failed.

The protocol’s low adoption rate may be blamed, in part, on a lack of education by users, as well as a hesitation to try a new technology, industry experts say. ValiMail also pointed to a reluctance to change back-end email systems, which have complex DNS tables.

But the Global Cyber Alliance (GCA) says implementing DMARC is not difficult. Shehzad Mirza, GCA’s director of global operations, says the organization has a relatively easy DMARC setup guide on its website.

“Anyone with an email domain, small businesses, large businesses, should be using it,” Mirza says.

Enterprises Stand to Win
Enterprises will “absolutely” benefit from the mandate, says Patrick Peterson, Agari’s founder and executive chairman.

“This mandate will reduce risk for the enterprise as many phishing and malware attacks impersonate government agencies such as recent threats highlighting SEC and IRS spoofing. This leadership from DHS also sets a clear message that DMARC is valuable and should be implemented at scale which will drive enterprise awareness and adoption,” says Peterson.

Peter Goldstein, chief technology officer and co-founder of ValiMail, also agrees enterprises stand to benefit from the DHS mandate.

And although Goldstein applauds the DHS’s mandate, he cautions it is not enough to publish a DMARC record to the DNS.

“You have to get to enforcement to get real value out of DMARC,” says Goldstein. “At enforcement, receiving mail servers are instructed to quarantine (flag as spam) or delete messages that fail authentication. But getting there requires authenticating all of an organization’s legitimate senders — both internal and cloud services sending on their behalf.”

He noted that only 20% of companies succeed at reaching this point because of the complexity of modern email systems, which include dozens of cloud services a company may use to send emails on their behalf. As a result, it may prove tricky for many companies to get all of these services whitelisted, he says.

“We’re seeing progress in some areas, like the biggest financial companies,” Goldstein says. “But across the board, the rates of enforcement are still quite low.”

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Related Content:

• Phish Bait: DMARC Adoption Failures Leave Companies Exposed
• DMARC Continues To Confound Users, Report Says
• Hospital Email Security in Critical Condition as DMARC Adoption Lags
• How To Reduce Spam Phishing With DMARC

 

Dawn Kawamoto is an Associate Editor for Dark Reading, where she covers cybersecurity news and trends. She is an award-winning journalist who has written and edited technology, management, leadership, career, finance, and innovation stories for such publications as CNET’s … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/dhs-to-require-all-fed-agencies-to-use-dmarc-https-and-starttls/d/d-id/1330137?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

High court to rule on email privacy case, pitting Redmond giant against DOJ over access to its foreign-based email servers.

After four years of disputes in lesser courts, the US Supreme Court agreed Monday to hear Microsoft’s case against the Department of Justice, in which the Redmond giant is fighting to keep law enforcement from accessing its email servers in Ireland, Reuters reports.

Federal prosecutors are asking the high court to hear the case, after a federal appeals court ruled in Microsoft’s favor that the software giant did not have to provide law enforcement access to email messages that derived from a Hotmail account hosted on its Dublin, Ireland, servers, on the grounds that they are protected by Irish privacy laws. The DOJ wants to review emails stored on the servers, as part of its investigation into a drug trafficking case; the original subpoena was filed by DoJ in 2013.

Although the DOJ characterizes the lower court ruling as a threat to public safety and national security, Reuters cited a blog post by Brad Smith, Microsoft’s president and chief legal officer that a ruling against it would jeopardize the privacy not only of international citizens, but US citizens as well. “If U.S. law enforcement can obtain the emails of foreigners stored outside the United States,” wrote Smith, “what’s to stop the government of another country from getting your emails even though they are located in the United States?” 

The ultimate resolution of the case may also have repercussions for the cloud computing industry in general and for transAtlantic data transfer agreements like Privacy Shield. 

Microsoft’s case marks the first time a domestic company is fighting a US search warrant seeking to access to data the organization holds in other countries, Reuters notes.

Read more about the case here.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/us-supreme-court-to-hear-microsoft-doj-email-case/d/d-id/1330142?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

All modern WiFi access points and devices that have implemented the protocol vulnerable to attacks that allow decryption, traffic hijacking other attacks. Second, unrelated crypto vulnerability also found in RSA code library in TPM chips.

Researchers at Belgium’s University of Leuven have uncovered as many as 10 critical vulnerabilities in the Wi-Fi Protected Access II (WPA2) protocol used to secure WiFi networks.

The vulnerabilities are present on both client and access point implementations of the protocol and give attackers a way to decrypt data packets, inject malware into a data stream and hijack secure connections via so-called key reinstallation attacks (KRACKs).

(The disclosure of the WPA2 flaws is the second one in recent days involving a crypto standard.  Last week, Google, Microsoft and others warned about a bug in several Infineon trusted platform module (TPM) firmware versions that gives attackers a way to recover the private part of RSA keys generated by the TPM using only the corresponding public key. Nearly all Chrome OS devices that include an Infineon TPM chip are affected, and although large-scale attacks are not possible, a practical exploit already exists for targeted attacks.)  

The KRACK attacks work on all modern wireless networks using the WPA2 protocol and any device that supports WiFi is most likely impacted, the researchers said in a technical paper that they will present at the upcoming Black Hat Europe security conference. However the flaws are not easy to exploit and require attackers to be in close proximity to a victim, thereby making the flaws somewhat less severe of a threat despite their ubiquity.

“Vulnerabilities that focus on issues with network protocols across many devices makes the threat landscape of this vulnerability very large,” says Richard Rushing, CISO of Motorola Mobility and a speaker at Dark Reading’s upcoming INsecurity security conference in November.

[Discuss “Writing an Effective Mobile Security Policy” with Richard Rushing, CISO of Motorola Mobility, at the INsecurity Conference, for the defenders of enterprise security, Nov. 29 – 30.]

But as with all Wifi threats, physical proximity is required for the vulnerabilities to be exploitable, he says. “Most wireless IDS and IPS should be able to see this attack, and take preventative actions,” Rushing said. “In many cases there are other Wifi man-in-the-middle attacks that can be just as successful given a user WiFi configuration.” 

Meanwhile, US-CERT described the KRACK vulnerabilities as existing in the WPA2 standard itself thereby putting all correct implementations of the protocol at risk of attack. An attacker within range of a modern access point and client can use the vulnerabilities to carry out a range of malicious actions. Depending on the encryption protocols being used by the WiFi network, the “attacks may include arbitrary packet decryption and injection, TCP connection hijacking, HTTP content injection, or the replay of unicast and group-addressed frames,” US-CERT said. The advisory listed close to 150 vendors whose products are impacted by the vulnerabilities.

In the technical paper and a blog, researchers Mathy Vanhoef and Frank Piessens from the University of Leuven demonstrated a proof-of-concept key reinstallation attack that takes advantage of the WPA2 vulnerabilities to decrypt encrypted data.

The attack is targeted at the four-way handshake that takes place when a client device wants to join a protected WiFi network. The handshake is designed to ensure that both the client and the access point have the correct credentials to communicate with each other.  The manner in which the third handshake takes place essentially gives attackers an opportunity to force resets of a cryptographic nonce counter used by the encryption protocol so data packets can be decrypted, replayed or forged, according to the two researchers.

The key reinstallation attack against the 4-way handshake is the most widespread and practically impactful attack currently possible against the WPA2 vulnerabilities, Vanhoef and Piessens said in the paper. “First, during our own research we found that most clients were affected by it. Second, adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies.” The manner in which WPA-2 has been implemented on devices running Linux and Android 6.0 and above make them particularly vulnerable to key reinstallation attacks, they said.

Organizations – corporate enterprises, businesses, schools and universities, retail shops and restaurants, government agencies – that have deployed Wi-Fi networks using WPA2 encryption are affected. When mobile users connect to these Wi-Fi networks with smartphones, tablets, laptops and other devices, they are also exposed to these vulnerabilities. Both the 802.1x (EAP) and PSK (password)-based networks are affected.

Hemant Chaskar, CISO and vice president of technology, at Mojo Networks says corporate enterprises, businesses, schools and universities, retail shops restaurants, government agencies and any organization that has deployed Wi-Fi networks using WPA2 encryption are affected.  “When mobile users connect to these Wi-Fi networks with smartphones, tablets, laptops and other devices, they are also exposed to these vulnerabilities. Both the 802.1x (EAP) and PSK (password)-based networks are affected,” he says.

Nine of the 10 vulnerabilities require attackers to be relatively sophisticated, he says. In order to exploit these flaws an attacker would need to use a MAC spoofing access point as a Man-in-the-Middle to manipulate data flowing between the client device and the real access point. “For the remaining, a practical exploit can be launched using a sniffer that can listen to and replay the frames over the wireless medium. So, it requires less attacker sophistication. “The main risk from all of them is replay of packets into the client or access point,” Choskar says. “Another potential arising out of these exploits is the presence of packets in the air that are decryption-prone.”

Gaurav Banga, founder and CEO of Balbix said the newly vulnerabilities, while present in a lot of products, should not be a cause of widespread panic. For one thing, it requires a sophisticated attacker and physical proximity in order to exploit. There has also been no sign of any exploit code in the wild so far and patches are available or will soon be available. “With iOS and Windows, the attack is quite difficult to pull off. Many of the security questions are around Android, since it is rarely patched,” he says.

Users and organizations can mitigate the risk by using VPN over WiFi, avoiding websites that do not use HTTPS and updating their devices as soon as patches are released, he says.

Related content:

• Hotel Router Vulnerability A Reminder Of Untrusted WiFi Risks
• APT28 Uses EternalBlue to Spy on Hotel Wifi Networks
• Home Routers Being Targeted in DNS Hijacking Attack, Trend Micro Says

  

Join Dark Reading LIVE for two days of practical cyber defense discussions. Learn from the industry’s most knowledgeable IT security experts. Check out the INsecurity agenda here.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/secure-wifi-hijacked-by-krack-vulns-in-wpa2-/d/d-id/1330144?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

At last some good news for Microsoft’s ignored Edge browser: new tests by NSS Labs have found that it beats Chrome and Firefox hands down at blocking malware downloads and phishing attacks.

After 23 days of continuous tests between 23 August and 15 September this year, Edge version 38 blocked 96% of the socially-engineered malware (SEM) samples thrown against it in the form of malicious links and pop-ups, compared to 88% for Chrome version 60 and 70% for Firefox version 55. (The researchers describe SEM attacks as “a dynamic combination of social media, hijacked email accounts, false notification of computer problems, and other deceptions to encourage users to download malware”.)

Edge did even better when it came to phishing, blocking 92% of malicious URLs, compared to Chrome’s 75% and Firefox’s 61%.

NSS also looked at “zero hour” protection, which is how long it takes for each browser to block brand new threats once they’ve been introduced into the test.

For zero-hour SEM, Chrome started at 75% before climbing to a peak of 95% after seven days, while Firefox started at 54%, climbing to a peak rate of only 80% over the same period. Compare that to Edge which managed a steady 99.8% from hour one.

For zero-hour phishing URLs, the results weren’t quite as wide, but even here Edge started at 82% to Chrome’s 59% and Firefox’s 51%. Firefox clawed back some of the gap by day seven, scoring a peak rate of 81% to Chrome’s weakening 65%, but still ended up lagging Edge’s 89%.

These differences sound significant but how seriously should we take them?

There are only two variables here, the first of which is NSS Labs’ test methodology. We’ll ignore that, partly because assessing security testing methodologies could consume an entire article on its own but also because there’s a better candidate – the cloud-based blacklists of files and URLs these browsers use to decide what’s trustworthy and what’s not.

Edge uses Microsoft’s SmartScreen (also used by Internet Explorer), while Chrome and Firefox use Google’s Safe Browsing API (also used by Apple’s Safari, Opera and Vivaldi as well by other Google services such as Gmail).

As far as the NSS tests are concerned, we shouldn’t be surprised that SmartScreen performs better than the Safe Browsing API because that’s been the case ever since the company started testing browser SEM blocking performance some years ago.

We might speculate that Microsoft’s vast Windows base gives it an advantage over Google when it comes to gathering intelligence on malware, although that doesn’t explain why it still beats Google at spotting dodgy URLs which both should, in theory, see equally well.

The difference between Edge and Chrome seems to hold true even when they’re running on other platforms, for example when Windows 10 S (which runs only Windows Store apps) is pitted against the Chromebook, Google’s cloud-oriented computers running Chrome OS.

Here, Edge scored a 92% success rate against phishing URLs while Chrome achieved 75%, both scores identical to the same browsers running on Window 10.

Because they don’t run executables, Chromebooks are undoubtedly superior to Windows computers against SEM malware but when it comes to URL detection, these tests suggest they lag.

An interesting question is what all this means for companies using more than one browser, either for compatibility reasons (i.e. older versions of Internet Explorer) or because they fear being exposed to a specific security vulnerability affecting one.

That’s a complex judgment not assessed by NSS Labs but it shouldn’t escape our notice that Edge came last in the CanSecWest Pwn2Own contest earlier this year in terms of contestants finding exploitable software flaws.

These phishing and SEM tests are not the whole story.

In the end, focussing on browser security technology might be to miss the point that devices of all kinds come with other security layers, chief among them their users.

Which is to say that while the person using a computer can be a weakness, they could, if properly trained, also be a strength. Whatever the differences between one browser and another, performance scores should never be seen as compensation for more fundamental weaknesses.

Follow @NakedSecurity
Follow @JohnEDunn

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/tVq50YMfN9I/

The recent arrest and federal charges against a 24-year-old alleged cyberstalker brings into light the terrible fallout from unrelenting online harassment, and highlights that no one is truly anonymous online, not even criminals.

The crime

Arrested on 6 October, Ryan Lin of Newton, Massachusetts allegedly harassed and cyberstalked his former roommate for over a year in a manner so egregious and terrifying that it merited a federal investigation.

The harrowing details of his alleged activities are in a 28-page affidavit, written by FBI Agent Jeffrey Williams, provided by the U.S. Department of Justice—the crux of it is that Lin used email, SMS, social media and phone apps to make life a living hell for his victim; for over a year he harassed her, her roommates, her family and friends, her employers, her landlord and the community she lived in by sending death threats, rape threats, bomb threats and even child pornography.

Lin was a computer science graduate of Rensselaer Polytechnic Institute (RPI), and he had enough cybersecurity knowledge to effectively anonymize himself while he embarked on his campaign of harassment.

Outside of his formal computer science education, Lin had more than a passing understanding of infosec and opsec practices. A quick perusal of one of his active Twitter accounts reveals an interest in the Tor project, Tails (the privacy-centric Linux distribution), major data breaches like Yahoo and Equifax, and the nuances of VPN use.

The affidavit also mentions that Lin had harassed a number of former high school and college classmates. He either impersonated them with fake social media accounts under their names, or he tried to socially engineer his way into their Facebook profiles to harass them directly by creating fake profiles under the name of shared classmates.

The technology

According to the affidavit, Lin used a VPN to cover his tracks while he created the accounts that he used to send his harassing messages. VPNs hide your computer’s IP address and the traffic between you and your VPN provider is encrypted, making it incomprehensible to anyone intercepting it.

VPNs are an important security tool but there’s one major caveat: the encrypted tunnel between you and your VPN provider provides protection against everyone other than your VPN provider, who gets to see everything passing through your network.

There are a dime-a-dozen VPNs out there, including many free ones. Using a shoddy VPN service provided by an untrustworthy company can put your data at more risk than not using one at all. No matter who your VPN provider is though, you should expect them to cooperate with law enforcement if they are subpoenaed to do so.

As Lin himself noted on Twitter just days before he was arrested, a VPN can’t be relied upon to for anonymity:

Something that everyone should know  – VPN provides privacy. TOR provides *decent* anonymity (if you use it correctly) #vpn #tor #broadbandprivacy

It’s interesting that given this knowledge, it seems it was his own VPN traces that ended up being key in his arrest, according to the affidavit.

Another highly portentous tweet was called out in the affidavit:

For example, on June 15, 2017, Lin, using the Twitter handle @ryanlindev, re-tweeted a tweet from “IPVanish,” that read: “Your privacy is our priority. That’s why we have a strict zero log policy.” Lin criticized the tweet, saying, “There is no such thing as VPN that doesn’t keep logs. If they can limit your connections or track bandwidth usage, they keep logs.”

The affidavit details that Lin went through pains to anonymize his traffic by using a mix of proxy servers, several different VPN services and Tor.

In a number of the instances of online harassment under investigation, the user both used a VPN and used an anonymizing service to mask his true IP address. Taking this two-step approach provides the user with another layer of anonymity, and demonstrates an awareness of and concern about the exact issue that Lin highlights in his tweet-the fact that VPN’s track activity with logs.

From the affidavit, it appears that FBI Agent Williams used VPN logs to identify IP addresses that could be traced to Lin’s home and former employer. But that wasn’t a smoking gun, so to speak, just one of many data points used to build the case.

More data points in the case related to email addresses attributed to Lin, which he used to communicate openly with his victim and her roommates. It seems he accessed those emails using the same VPN-assigned IP address that he used to create the email accounts used to harass and threaten his victim.

Lin could face at least five years in prison if he’s convicted.

Courtroom sketch of Ryan Lin (center), charged with cyberstalking, his attorney Francis Doran, and Judge David Henn… twitter.com/i/web/status/9…—
Chris Villani (@ChrisVillani44) October 06, 2017

The impact

I took a special interest in this story as I live in the city that was the target of the frequent shooting and bomb threats: Waltham, a small city of just about 60,000 people.

The bomb threats started in July of this year and were sent to city schools, government offices, libraries, daycare facilities, and even a federal archive building.

In addition to the wide swath of threats, they were also increasing in frequency: there was a time where threats were sent to Waltham schools daily for days and weeks on end—in the span of just a few months the schools received dozens of bomb threats, with 24 threats in just one day.

Aside from the huge impact this made on local police (Waltham is a city of just 60,000 people), the emotional impact on the community can’t be understated.

Each school bomb threat prompted school closures or a complete student evacuation until the schools were swept and deemed safe, and with these threats coming near-daily, scaring many children from going to school, and there were more than a few parents that opted to keep their kids at home from school entirely.

There wasn’t much information that law enforcement could divulge to help calm fears as they were actively pursuing an investigation, and it seemed like there was no end in sight for these terrifying bomb threats as they continued.

Thankfully since the arrest, the bomb threats promptly stopped, and Waltham residents (myself included) are relieved, but also horrified at the nature of what was motivating these threats, unbeknownst to all of us at the time.

I’ll leave you with the words of Harold H. Shaw, Special Agent in Charge of the Federal Bureau of Investigation, Boston Field Division:

As alleged, Mr. Lin orchestrated an extensive, multi-faceted campaign of computer hacking and online harassment that caused a huge amount of angst, alarm, and unnecessary expenditure of limited law enforcement resources

This kind of behavior is not a prank, and it isn’t harmless. He allegedly scared innocent people, and disrupted their daily lives, because he was blinded by his obsession. No one should feel unsafe in their own home, school, or workplace, and the FBI and our law enforcement partners hope today’s arrest will deter others from engaging in similar criminal conduct.

Follow @mvarmazis
Follow @NakedSecurity

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/2ua8Ab8hpTQ/

News of the week – and it’s still only Monday – is a Bug With An Impressive name (and its own logo!) called the KRACK Attack.

Actually, there are several attacks of a similar sort discussed in the paper that introduced KRACK, so they’re more properly known as the KRACK Attacks.

These KRACK attacks mean that most encrypted Wi-Fi networks are not as secure as you think.

KRACK works against networks using WPA and WPA2 encryption, which these days covers most wireless access points where encryption has been turned on.

An attacker in your midst (at least, within Wi-Fi range) could, in theory, sniff out at least some of the encrypted traffic sent to some of the computers in your organisation.

Even if an attacker can only “bleed off” small amounts of traffic, in dribs and drabs, the end result could be very serious.

(If you remember the Firesheep attack of 2010, just bled a few bytes of data when you connected to Facebook or Twitter was enough to let a crook clone your connection and access your account for as long as you stayed logged in.)

KRACK in a few words

KRACK is short for Key Reinstallation Attack, which is a curious name that probably leaves you as confused as we felt when we heard about it, so here’s our extremely simplified explanation of what happens (please note this explanation covers just one of numerous flavours of similar attack).

At various times during an encrypted wireless connection, you (the client) and the access point (the AP) need to agree on security keys.

To do so, a protocol known as the “four-way handshake” is used, which goes something like this:

1. (AP to client) Let’s agree on a session key. Here’s some one-time random data to help compute it.
2. (Client to AP) OK, here’s some one-time random data from me to use as well.

At this point, both sides can mix together the Wi-Fi network password (the so-called Pre-Shared Key or PSK) and the two random blobs of data to generate a one-time key for this session.

This avoids using the PSK directly in encrypting wireless data, and ensures a unique key for each session.

3. (AP to client) I’m confirming we’ve agreed on enough data to construct a key for this session.
4. (Client to AP) You’re right, we have.

The KRACK Attacks (with numerous variations) use the fact that although this four-way protocol was shown to be mathematically sound, it could be – and in many cases, was – implemented insecurely.

In particular, an attacker with a rogue access point that pretends to have the same network number (MAC address) as the real one can divert message 4 and prevent it reaching the real AP.

During this hiatus in the handshake, the client may already have started communicating with the AP, because the two sides already have a session key they can use, albeit that they haven’t finalised the handshake.

This means that the client will already be churning out cryptographic material, known as the keystream, to encrypt the data it transmits.

To ensure a keystream that never repeats, the client uses the session key plus a nonce, or “number used once”, to encrypt each network frame; the nonce is incremented after each frame so that the keystream is different each time.

As far as we can determine, all the KRACK attacks involve reused keystream material accessed by “rewinding” crypto settings and thus encrypting different data with the same keystream. If you know one set of data you can figure out the other – that’s the best case; some cases are worse than that because you can as good as take over the connection both ways.

Back to the handshake

At some point, the real AP will send another copy of message 3, possibly several times, until the rogue AP finally lets the message get through to the client.

The mathematical certainty in the protocol now meets cryptographic sloppiness in its implementation.

The client finalises the handshake at last, and resets its keystream by “reinstalling” the session key (thus the name of the attack), and resetting the nonce to what it was immediately after stage 2 of the handshake.

This means the keystream starts repeating itself – and re-using the keystream in a network encryption cipher of this sort is a big no-no.

If you know the contents of the network frames that were encrypted the first time, you can recover the keystream used to encrypt them; if you have the keystream from the first bunch of network frames, you can use it to decrypt the frames encrypted the second time when the keystream gets re-used.

Even if attackers are only able to recover a few frames of the data in any session, they still come out ahead.

Gold dust sounds less valuable than a gold ingot – but if you collect enough gold dust, you get to the same value in the end.

What to do

Changing your Wi-Fi password won’t help: this attack doesn’t recover the password (PSK) itself, but instead allows an attacker to decrypt some of the content of some sessions.

Changing routers probably won’t help either, because there are numerous variants of the KRACK Attacks that affect most Wi-Fi software implementations in most operating systems.

Here’s what you can do:

• Until further notice, treat all Wi-Fi networks like coffee shops with open, unencrypted, wireless.
• Stick to HTTPS websites so your web browsing is encrypted even if it travels over an unencrypted connection.
• Consider using a VPN, which means that all your network traffic (not just your web browsing) is encrypted, from your laptop or mobile device to your home or work network, even if it travels over an unencrypted connection along the way.
• Apply KRACK patches for your clients (and access points) as soon as they are available.
• Sophos Customers should read knowledgebase article 127658.

The precautions that you take in those cases – why not take them all the time?

If you always encrypt everything yourself, in a way that you get to choose and can control, you never have to worry what you might have forgotten about.

Follow @NakedSecurity
Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/jSdd_bxs8IY/

An advisory from Cisco issued last Friday, October 13th gave us the heads-up on a local privilege escalation vulnerability in the Advanced Linux Sound Architecture (ALSA).

The bug is designated CVE-2017-15265, but its Mitre entry was still marked “reserved” at the time of writing. Cisco, however, had this to say about it before release:

“The vulnerability is due to a use-after-free memory error in the ALSA sequencer interface of the affected application. An attacker could exploit this vulnerability by running a crafted application on a targeted system. A successful exploit could allow the attacker to gain elevated privileges on the targeted system.”

The bug can be potentially exploited by malicious software running on a vulnerable box, or logged-in users, to gain root-level control of the system. A patch for the programming blunder was publicly merged earlier this month into the ALSA git tree, according to this discussion at SUSE’s Bugzilla.

Turned up by ADLab of Venustech, the use-after-free vulnerability is triggered by a slip-up in snd_seq_create_port().

That routine “creates a port object and returns its pointer, but it doesn’t take the refcount, thus it can be deleted immediately by another thread. Meanwhile, snd_seq_ioctl_create_port() still calls the function snd_seq_system_client_ev_port_start() with the created port object that is being deleted, and this triggers use-after-free”.

While it’s only exploitable locally, the privilege escalation is what earned the bug a “high” severity rating, and of course everybody using a downstream distribution that embeds the vulnerable ALSA will have to push patches. ®

Sponsored:
The Joy and Pain of Buying IT – Have Your Say

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2017/10/15/advanced_linux_sound_architecture_vulnerable_to_privilege_escalation/