Tag Archives: man-in-the-middle

Some notes on eFail

Post Syndicated from Robert Graham original https://blog.erratasec.com/2018/05/some-notes-on-efail.html

I’ve been busy trying to replicate the “eFail” PGP/SMIME bug. I thought I’d write up some notes.

PGP and S/MIME encrypt emails, so that eavesdroppers can’t read them. The bugs potentially allow eavesdroppers to take the encrypted emails they’ve captured and resend them to you, reformatted in a way that allows them to decrypt the messages.

Disable remote/external content in email

The most important defense is to disable “external” or “remote” content from being automatically loaded. This is when HTML-formatted emails attempt to load images from remote websites. This happens legitimately when they want to display images, but not fill up the email with them. But most of the time this is illegitimate, they hide images on the webpage in order to track you with unique IDs and cookies. For example, this is the code at the end of an email from politician Bernie Sanders to his supporters. Notice the long random number assigned to track me, and the width/height of this image is set to one pixel, so you don’t even see it:

Such trackers are so pernicious they are disabled by default in most email clients. This is an example of the settings in Thunderbird:

The problem is that as you read email messages, you often get frustrated by the fact the error messages and missing content, so you keep adding exceptions:

The correct defense against this eFail bug is to make sure such remote content is disabled and that you have no exceptions, or at least, no HTTP exceptions. HTTPS exceptions (those using SSL) are okay as long as they aren’t to a website the attacker controls. Unencrypted exceptions, though, the hacker can eavesdrop on, so it doesn’t matter if they control the website the requests go to. If the attacker can eavesdrop on your emails, they can probably eavesdrop on your HTTP sessions as well.

Some have recommended disabling PGP and S/MIME completely. That’s probably overkill. As long as the attacker can’t use the “remote content” in emails, you are fine. Likewise, some have recommend disabling HTML completely. That’s not even an option in any email client I’ve used — you can disable sending HTML emails, but not receiving them. It’s sufficient to just disable grabbing remote content, not the rest of HTML email rendering.

I couldn’t replicate the direct exfiltration

There rare two related bugs. One allows direct exfiltration, which appends the decrypted PGP email onto the end of an IMG tag (like one of those tracking tags), allowing the entire message to be decrypted.

An example of this is the following email. This is a standard HTML email message consisting of multiple parts. The trick is that the IMG tag in the first part starts the URL (blog.robertgraham.com/…) but doesn’t end it. It has the starting quotes in front of the URL but no ending quotes. The ending will in the next chunk.

The next chunk isn’t HTML, though, it’s PGP. The PGP extension (in my case, Enignmail) will detect this and automatically decrypt it. In this case, it’s some previous email message I’ve received the attacker captured by eavesdropping, who then pastes the contents into this email message in order to get it decrypted.

What should happen at this point is that Thunderbird will generate a request (if “remote content” is enabled) to the blog.robertgraham.com server with the decrypted contents of the PGP email appended to it. But that’s not what happens. Instead, I get this:

I am indeed getting weird stuff in the URL (the bit after the GET /), but it’s not the PGP decrypted message. Instead what’s going on is that when Thunderbird puts together a “multipart/mixed” message, it adds it’s own HTML tags consisting of lines between each part. In the email client it looks like this:

The HTML code it adds looks like:

That’s what you see in the above URL, all this code up to the first quotes. Those quotes terminate the quotes in the URL from the first multipart section, causing the rest of the content to be ignored (as far as being sent as part of the URL).

So at least for the latest version of Thunderbird, you are accidentally safe, even if you have “remote content” enabled. Though, this is only according to my tests, there may be a work around to this that hackers could exploit.


In the old days, email was sent plaintext over the wire so that it could be passively eavesdropped on. Nowadays, most providers send it via “STARTTLS”, which sorta encrypts it. Attackers can still intercept such email, but they have to do so actively, using man-in-the-middle. Such active techniques can be detected if you are careful and look for them.
Some organizations don’t care. Apparently, some nation states are just blocking all STARTTLS and forcing email to be sent unencrypted. Others do care. The NSA will passively sniff all the email they can in nations like Iraq, but they won’t actively intercept STARTTLS messages, for fear of getting caught.
The consequence is that it’s much less likely that somebody has been eavesdropping on you, passively grabbing all your PGP/SMIME emails. If you fear they have been, you should look (e.g. send emails from GMail and see if they are intercepted by sniffing the wire).

You’ll know if you are getting hacked

If somebody attacks you using eFail, you’ll know. You’ll get an email message formatted this way, with multipart/mixed components, some with corrupt HTML, some encrypted via PGP. This means that for the most part, your risk is that you’ll be attacked only once — the hacker will only be able to get one message through and decrypt it before you notice that something is amiss. Though to be fair, they can probably include all the emails they want decrypted as attachments to the single email they sent you, so the risk isn’t necessarily that you’ll only get one decrypted.
As mentioned above, a lot of attackers (e.g. the NSA) won’t attack you if its so easy to get caught. Other attackers, though, like anonymous hackers, don’t care.
Somebody ought to write a plugin to Thunderbird to detect this.


It only works if attackers have already captured your emails (though, that’s why you use PGP/SMIME in the first place, to guard against that).
It only works if you’ve enabled your email client to automatically grab external/remote content.
It seems to not be easily reproducible in all cases.
Instead of disabling PGP/SMIME, you should make sure your email client hast remote/external content disabled — that’s a huge privacy violation even without this bug.

Notes: The default email client on the Mac enables remote content by default, which is bad:

Security Vulnerabilities in Certificate Pinning

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/12/security_vulner_10.html

New research found that many banks offer certificate pinning as a security feature, but fail to authenticate the hostname. This leaves the systems open to man-in-the-middle attacks.

From the paper:

Abstract: Certificate verification is a crucial stage in the establishment of a TLS connection. A common security flaw in TLS implementations is the lack of certificate hostname verification but, in general, this is easy to detect. In security-sensitive applications, the usage of certificate pinning is on the rise. This paper shows that certificate pinning can (and often does) hide the lack of proper hostname verification, enabling MITM attacks. Dynamic (black-box) detection of this vulnerability would typically require the tester to own a high security certificate from the same issuer (and often same intermediate CA) as the one used by the app. We present Spinner, a new tool for black-box testing for this vulnerability at scale that does not require purchasing any certificates. By redirecting traffic to websites which use the relevant certificates and then analysing the (encrypted) network traffic we are able to determine whether the hostname check is correctly done, even in the presence of certificate pinning. We use Spinner to analyse 400 security-sensitive Android and iPhone apps. We found that 9 apps had this flaw, including two of the largest banks in the world: Bank of America and HSBC. We also found that TunnelBear, one of the most popular VPN apps was also vulnerable. These apps have a joint user base of tens of millions of users.

News article.

Man-in-the-Middle Attack against Electronic Car-Door Openers

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/11/man-in-the-midd_8.html

This is an interesting tactic, and there’s a video of it being used:

The theft took just one minute and the Mercedes car, stolen from the Elmdon area of Solihull on 24 September, has not been recovered.

In the footage, one of the men can be seen waving a box in front of the victim’s house.

The device receives a signal from the key inside and transmits it to the second box next to the car.

The car’s systems are then tricked into thinking the key is present and it unlocks, before the ignition can be started.

SNIFFlab – Create Your Own MITM Test Environment

Post Syndicated from Darknet original https://www.darknet.org.uk/2017/11/snifflab-create-mitm-test-environment/?utm_source=rss&utm_medium=social&utm_campaign=darknetfeed

SNIFFlab – Create Your Own MITM Test Environment

SNIFFlab is a set of scripts in Python that enable you to create your own MITM test environment for packet sniffing through a WiFi access point.

Essentially it’s a WiFi hotspot that is continually collecting all the packets transmitted across it. All connected clients’ HTTPS communications are subjected to a “Man-in-the-middle” attack, whereby they can later be decrypted for analysis

What is SNIFFLab MITM Test Environment

In our environment, dubbed Snifflab, a researcher simply connects to the Snifflab WiFi network, is prompted to install a custom certificate authority on the device, and then can use their device as needed for the test.

Read the rest of SNIFFlab – Create Your Own MITM Test Environment now! Only available at Darknet.

Some notes on the KRACK attack

Post Syndicated from Robert Graham original http://blog.erratasec.com/2017/10/some-notes-on-krack-attack.html

This is my interpretation of the KRACK attacks paper that describes a way of decrypting encrypted WiFi traffic with an active attack.

tl;dr: Wow. Everyone needs to be afraid. (Well, worried — not panicked.) It means in practice, attackers can decrypt a lot of wifi traffic, with varying levels of difficulty depending on your precise network setup. My post last July about the DEF CON network being safe was in error.


This is not a crypto bug but a protocol bug (a pretty obvious and trivial protocol bug).
When a client connects to the network, the access-point will at some point send a random “key” data to use for encryption. Because this packet may be lost in transmission, it can be repeated many times.
What the hacker does is just repeatedly sends this packet, potentially hours later. Each time it does so, it resets the “keystream” back to the starting conditions. The obvious patch that device vendors will make is to only accept the first such packet it receives, ignore all the duplicates.
At this point, the protocol bug becomes a crypto bug. We know how to break crypto when we have two keystreams from the same starting position. It’s not always reliable, but reliable enough that people need to be afraid.
Android, though, is the biggest danger. Rather than simply replaying the packet, a packet with key data of all zeroes can be sent. This allows attackers to setup a fake WiFi access-point and man-in-the-middle all traffic.
In a related case, the access-point/base-station can sometimes also be attacked, affecting the stream sent to the client.
Not only is sniffing possible, but in some limited cases, injection. This allows the traditional attack of adding bad code to the end of HTML pages in order to trick users into installing a virus.

This is an active attack, not a passive attack, so in theory, it’s detectable.

Who is vulnerable?

Everyone, pretty much.
The hacker only needs to be within range of your WiFi. Your neighbor’s teenage kid is going to be downloading and running the tool in order to eavesdrop on your packets.
The hacker doesn’t need to be logged into your network.
It affects all WPA1/WPA2, the personal one with passwords that we use in home, and the enterprise version with certificates we use in enterprises.
It can’t defeat SSL/TLS or VPNs. Thus, if you feel your laptop is safe surfing the public WiFi at airports, then your laptop is still safe from this attack. With Android, it does allow running tools like sslstrip, which can fool many users.
Your home network is vulnerable. Many devices will be using SSL/TLS, so are fine, like your Amazon echo, which you can continue to use without worrying about this attack. Other devices, like your Phillips lightbulbs, may not be so protected.

How can I defend myself?

More to the point, measure your current vendors by how long it takes them to patch. Throw away gear by those vendors that took a long time to patch and replace it with vendors that took a short time.
High-end access-points that contains “WIPS” (WiFi Intrusion Prevention Systems) features should be able to detect this and block vulnerable clients from connecting to the network (once the vendor upgrades the systems, of course). Even low-end access-points, like the $30 ones you get for home, can easily be updated to prevent packet sequence numbers from going back to the start (i.e. from the keystream resetting back to the start).
At some point, you’ll need to run the attack against yourself, to make sure all your devices are secure. Since you’ll be constantly allowing random phones to connect to your network, you’ll need to check their vulnerability status before connecting them. You’ll need to continue doing this for several years.
Of course, if you are using SSL/TLS for everything, then your danger is mitigated. This is yet another reason why you should be using SSL/TLS for internal communications.
Most security vendors will add things to their products/services to defend you. While valuable in some cases, it’s not a defense. The defense is patching the devices you know about, and preventing vulnerable devices from attaching to your network.
If I remember correctly, DEF CON uses Aruba. Aruba contains WIPS functionality, which means by the time DEF CON roles around again next year, they should have the feature to deny vulnerable devices from connecting, and specifically to detect an attack in progress and prevent further communication.
However, for an attacker near an Android device using a low-powered WiFi, it’s likely they will be able to conduct man-in-the-middle without any WIPS preventing them.

Self-Driving Cars Should Be Open Source

Post Syndicated from Bozho original https://techblog.bozho.net/self-driving-cars-open-source/

Self-driving cars are (will be) the pinnacle of consumer products automation – robot vacuum cleaners, smart fridges and TVs are just toys compared to self-driving cars. Both in terms of technology and in terms of impact. We aren’t yet on level 5 self driving cars , but they are behind the corner.

But as software engineers we know how fragile software is. And self-driving cars are basically software, so we can see all the risks involved with putting our lives in the hands anonymous (from our point of view) developers and unknown (to us) processes and quality standards. One may argue that this has been the case for every consumer product ever, but with software is different – software is way more complex than anything else.

So I have an outrageous proposal – self-driving cars should be open source. We have to be able to verify and trust the code that’s navigating our helpless bodies around the highways. Not only that, but we have to be able to verify if it is indeed that code that is currently running in our car, and not something else.

In fact, let me extend that – all cars should be open source. Before you say “but that will ruin the competitive advantage of manufacturers and will be deadly for business”, I don’t actually care how they trained their neural networks, or what their datasets are. That’s actually the secret sauce of the self-driving car and in my view it can remain proprietary and closed. What I’d like to see open-sourced is everything else. (Under what license – I’d be fine to even have it copyrighted and so not “real” open source, but that’s a separate discussion).

Why? This story about remote carjacking using the entertainment system of a Jeep is a scary example. Attackers that reverse engineer the car software can remotely control everything in the car. Why did that happen? Well, I guess it’s complicated and we have to watch the DEFCON talk.

And also read the paper, but a paragraph in wikipedia about the CAN bus used in most cars gives us a hint:

CAN is a low-level protocol and does not support any security features intrinsically. There is also no encryption in standard CAN implementations, which leaves these networks open to man-in-the-middle packet interception. In most implementations, applications are expected to deploy their own security mechanisms; e.g., to authenticate incoming commands or the presence of certain devices on the network. Failure to implement adequate security measures may result in various sorts of attacks if the opponent manages to insert messages on the bus. While passwords exist for some safety-critical functions, such as modifying firmware, programming keys, or controlling antilock brake actuators, these systems are not implemented universally and have a limited number of seed/key pair

I don’t know in what world it makes sense to even have a link between the entertainment system and the low-level network that operates the physical controls. As apparent from the talk, the two systems are supposed to be air-gapped, but in reality they aren’t.

Rookie mistakes were abound – unauthenticated “execute” method, running as root, firmware is not signed, hard-coded passwords, etc. How do we know that there aren’t tons of those in all cars out there right now, and in the self-driving cars of the future (which will likely use the same legacy technologies of the current cars)? Recently I heard a negative comment about the source code of one of the self-driving cars “players”, and I’m pretty sure there are many of those rookie mistakes.

Why this is this even more risky for self-driving cars? I’m not an expert in car programming, but it seems like the attack surface is bigger. I might be completely off target here, but on a typical car you’d have to “just” properly isolate the CAN bus. With self-driving cars the autonomous system that watches the surrounding and makes decisions on what to do next has to be connected to the CAN bus. With Tesla being able to send updates over the wire, the attack surface is even bigger (although that’s actually a good feature – to be able to patch all cars immediately once a vulnerability is discovered).

Of course, one approach would be to introduce legislation that regulates car software. It might work, but it would rely on governments to to proper testing, which won’t always be the case.

The alternative is to open-source it and let all the white-hats find your issues, so that you can close them before the car hits the road. Not only that, but consumers like me will feel safer, and geeks would be able to verify whether the car is really running the software it claims to run by verifying the fingerprints.

Richard Stallman might be seen as a fanatic when he advocates against closed source software, but in cases like … cars, his concerns seem less extreme.

“But the Jeep vulnerability was fixed”, you may say. And that might be seen as being the way things are – vulnerabilities appear, they get fixed, life goes on. No person was injured because of the bug, right? Well, not yet. And “gaining control” is the extreme scenario – there are still pretty bad scenarios, like being able to track a car through its GPS, or cause panic by controlling the entertainment system. It might be over wifi, or over GPRS, or even by physically messing with the car by inserting a flash drive. Is open source immune to those issues? No, but it has proven to be more resilient.

One industry where the problem of proprietary software on a product that the customer bought is … tractors. It turns out farmers are hacking their tractors, because of multiple issues and the inability of the vendor to resolve them in a timely manner. This is likely to happen to cars soon, when only authorized repair shops are allowed to touch anything on the car. And with unauthorized repair shops the attack surface becomes even bigger.

In fact, I’d prefer open source not just for cars, but for all consumer products. The source code of a smart fridge or a security camera is trivial, it would rarely mean sacrificing competitive advantage. But refrigerators get hacked, security cameras are active part of botnets, the “internet of shit” is getting ubiquitous. A huge amount of these issues are dumb, beginner mistakes. We have the right to know what shit we are running – in our frdges, DVRs and ultimatey – cars.

Your fridge may soon by spying on you, your vacuum cleaner may threaten your pet in demand of “ransom”. The terrorists of the future may crash planes without being armed, can crash vans into crowds without being in the van, and can “explode” home equipment without being in the particular home. And that’s not just a hypothetical.

Will open source magically solve the issue? No. But it will definitely make things better and safer, as it has done with operating systems and web servers.

The post Self-Driving Cars Should Be Open Source appeared first on Bozho's tech blog.

Top Ten Ways to Protect Yourself Against Phishing Attacks

Post Syndicated from Roderick Bauer original https://www.backblaze.com/blog/top-ten-ways-protect-phishing-attacks/

It’s hard to miss the increasing frequency of phishing attacks in the news. Earlier this year, a major phishing attack targeted Google Docs users, and attempted to compromise at least one million Google Docs accounts. Experts say the “phish” was convincing and sophisticated, and even people who thought they would never be fooled by a phishing attack were caught in its net.

What is phishing?

Phishing attacks use seemingly trustworthy but malicious emails and websites to obtain your personal account or banking information. The attacks are cunning and highly effective because they often appear to come from an organization or business you actually use. The scam comes into play by tricking you into visiting a website you believe belongs to the trustworthy organization, but in fact is under the control of the phisher attempting to extract your private information.

Phishing attacks are once again in the news due to a handful of high profile ransomware incidents. Ransomware invades a user’s computer, encrypts their data files, and demands payment to decrypt the files. Ransomware most often makes its way onto a user’s computer through a phishing exploit, which gives the ransomware access to the user’s computer.

The best strategy against phishing is to scrutinize every email and message you receive and never to get caught. Easier said than done—even smart people sometimes fall victim to a phishing attack. To minimize the damage in an event of a phishing attack, backing up your data is the best ultimate defense and should be part of your anti-phishing and overall anti-malware strategy.

How do you recognize a phishing attack?

A phishing attacker may send an email seemingly from a reputable credit card company or financial institution that requests account information, often suggesting that there is a problem with your account. When users respond with the requested information, attackers can use it to gain access to the accounts.

The image below is a mockup of how a phishing attempt might appear. In this example, courtesy of Wikipedia, the bank is fictional, but in a real attempt the sender would use an actual bank, perhaps even the bank where the targeted victim does business. The sender is attempting to trick the recipient into revealing confidential information by getting the victim to visit the phisher’s website. Note the misspelling of the words “received” and “discrepancy” as recieved and discrepency. Misspellings sometimes are indications of a phishing attack. Also note that although the URL of the bank’s webpage appears to be legitimate, the hyperlink would actually take you to the phisher’s webpage, which would be altogether different from the URL displayed in the message.

By Andrew Levine – en:Image:PhishingTrustedBank.png, Public Domain, https://commons.wikimedia.org/w/index.php?curid=549747

Top ten ways to protect yourself against phishing attacks

  1. Always think twice when presented with a link in any kind of email or message before you click on it. Ask yourself whether the sender would ask you to do what it is requesting. Most banks and reputable service providers won’t ask you to reveal your account information or password via email. If in doubt, don’t use the link in the message and instead open a new webpage and go directly to the known website of the organization. Sign in to the site in the normal manner to verify that the request is legitimate.
  2. A good precaution is to always hover over a link before clicking on it and observe the status line in your browser to verify that the link in the text and the destination link are in fact the same.
  3. Phishers are clever, and they’re getting better all the time, and you might be fooled by a simple ruse to make you think the link is one you recognize. Links can have hard-to-detect misspellings that would result in visiting a site very different than what you expected.
  4. Be wary even of emails and message from people you know. It’s very easy to spoof an email so it appears to come from someone you know, or to create a URL that appears to be legitimate, but isn’t.

For example, let’s say that you work for roughmedia.com and you get an email from Chuck in accounting ([email protected]) that has an attachment for you, perhaps a company form you need to fill out. You likely wouldn’t notice in the sender address that the phisher has replaced the “m” in media with an “r” and an “n” that look very much like an “m.” You think it’s good old Chuck in finance and it’s actually someone “phishing” for you to open the attachment and infect your computer. This type of attack is known as “spear phishing” because it’s targeted at a specific individual and is using social engineering—specifically familiarity with the sender—as part of the scheme to fool you into trusting the attachment. This technique is by far the most successful on the internet today. (This example is based on Gimlet Media’s Reply All Podcast Episode, “What Kind of Idiot Gets Phished?“)

  1. Use anti-malware software, but don’t rely on it to catch all attacks. Phishers change their approach often to keep ahead of the software attack detectors.
  2. If you are asked to enter any valuable information, only do so if you’re on a secure connection. Look for the “https” prefix before the site URL, indicating the site is employing SSL (Secure Socket Layer). If there is no “s” after “http,” it’s best not to enter any confidential information.
By Fabio Lanari – Internet1.jpg by Rock1997 modified., GFDL, https://commons.wikimedia.org/w/index.php?curid=20995390
  1. Avoid logging in to online banks and similar services via public Wi-Fi networks. Criminals can compromise open networks with man-in-the-middle attacks that capture your information or spoof website addresses over the connection and redirect you to a fake page they control.
  2. Email, instant messaging, and gaming social channels are all possible vehicles to deliver phishing attacks, so be vigilant!
  3. Lay the foundation for a good defense by choosing reputable tech vendors and service providers that respect your privacy and take steps to protect your data. At Backblaze, we have full-time security teams constantly looking for ways to improve our security.
  4. When it is available, always take advantage of multi-factor verification to protect your accounts. The standard categories used for authentication are 1) something you know (e.g. your username and password), 2) something you are (e.g. your fingerprint or retina pattern), and 3) something you have (e.g. an authenticator app on your smartphone). An account that allows only a single factor for authentication is more susceptible to hacking than one that supports multiple factors. Backblaze supports multi-factor authentication to protect customer accounts.

Be a good internet citizen, and help reduce phishing and other malware attacks by notifying the organization being impersonated in the phishing attempt, or by forwarding suspicious messages to the Federal Trade Commission at [email protected]. Some email clients and services, such as Microsoft Outlook and Google Gmail, give you the ability to easily report suspicious emails. Phishing emails misrepresenting Apple can be reported to [email protected].

Backing up your data is an important part of a strong defense against phishing and other malware

The best way to avoid becoming a victim is to be vigilant against suspicious messages and emails, but also to assume that no matter what you do, it is very possible that your system will be compromised. Even the most sophisticated and tech-savvy of us can be ensnared if we are tired, in a rush, or just unfamiliar with the latest methods hackers are using. Remember that hackers are working full-time on ways to fool us, so it’s very difficult to keep ahead of them.

The best defense is to make sure that any data that could compromised by hackers—basically all of the data that is reachable via your computer—is not your only copy. You do that by maintaining an active and reliable backup strategy.

Files that are backed up to cloud storage, such as with Backblaze, are not vulnerable to attacks on your local computer in the way that local files, attached drives, network drives, or sync services like Dropbox that have local directories on your computer are.

In the event that your computer is compromised and your files are lost or encrypted, you can recover your files if you have a cloud backup that is beyond the reach of attacks on your computer.

The post Top Ten Ways to Protect Yourself Against Phishing Attacks appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

A Man-in-the-Middle Attack against a Password Reset System

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/07/a_man-in-the-mi.html

This is nice work: “The Password Reset MitM Attack,” by Nethanel Gelerntor, Senia Kalma, Bar Magnezi, and Hen Porcilan:

Abstract: We present the password reset MitM (PRMitM) attack and show how it can be used to take over user accounts. The PRMitM attack exploits the similarity of the registration and password reset processes to launch a man in the middle (MitM) attack at the application level. The attacker initiates a password reset process with a website and forwards every challenge to the victim who either wishes to register in the attacking site or to access a particular resource on it.

The attack has several variants, including exploitation of a password reset process that relies on the victim’s mobile phone, using either SMS or phone call. We evaluated the PRMitM attacks on Google and Facebook users in several experiments, and found that their password reset process is vulnerable to the PRMitM attack. Other websites and some popular mobile applications are vulnerable as well.

Although solutions seem trivial in some cases, our experiments show that the straightforward solutions are not as effective as expected. We designed and evaluated two secure password reset processes and evaluated them on users of Google and Facebook. Our results indicate a significant improvement in the security. Since millions of accounts are currently vulnerable to the PRMitM attack, we also present a list of recommendations for implementing and auditing the password reset process.

Password resets have long been a weak security link.

BoingBoing Post.

Separating the Paranoid from the Hacked

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/06/separating_the_.html

Sad story of someone whose computer became owned by a griefer:

The trouble began last year when he noticed strange things happening: files went missing from his computer; his Facebook picture was changed; and texts from his daughter didn’t reach him or arrived changed.

“Nobody believed me,” says Gary. “My wife and my brother thought I had lost my mind. They scheduled an appointment with a psychiatrist for me.”

But he built up a body of evidence and called in a professional cybersecurity firm. It found that his email addresses had been compromised, his phone records hacked and altered, and an entire virtual internet interface created.

“All my communications were going through a man-in-the-middle unauthorised server,” he explains.

It’s the “psychiatrist” quote that got me. I regularly get e-mails from people explaining in graphic detail how their whole lives have been hacked. Most of them are just paranoid. But a few of them are probably legitimate. And I have no way of telling them apart.

This problem isn’t going away. As computers permeate even more aspects of our lives, it’s going to get even more debilitating. And we don’t have any way, other than hiring a “professional cybersecurity firm,” of telling the paranoids from the victims.

Surveillance and our Insecure Infrastructure

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2017/04/surveillance_an_2.html

Since Edward Snowden revealed to the world the extent of the NSA’s global surveillance network, there has been a vigorous debate in the technological community about what its limits should be.

Less discussed is how many of these same surveillance techniques are used by other — smaller and poorer — more totalitarian countries to spy on political opponents, dissidents, human rights defenders; the press in Toronto has documented some of the many abuses, by countries like Ethiopia , the UAE, Iran, Syria, Kazakhstan , Sudan, Ecuador, Malaysia, and China.

That these countries can use network surveillance technologies to violate human rights is a shame on the world, and there’s a lot of blame to go around.

We can point to the governments that are using surveillance against their own citizens.

We can certainly blame the cyberweapons arms manufacturers that are selling those systems, and the countries — mostly European — that allow those arms manufacturers to sell those systems.

There’s a lot more the global Internet community could do to limit the availability of sophisticated Internet and telephony surveillance equipment to totalitarian governments. But I want to focus on another contributing cause to this problem: the fundamental insecurity of our digital systems that makes this a problem in the first place.

IMSI catchers are fake mobile phone towers. They allow someone to impersonate a cell network and collect information about phones in the vicinity of the device and they’re used to create lists of people who were at a particular event or near a particular location.

Fundamentally, the technology works because the phone in your pocket automatically trusts any cell tower to which it connects. There’s no security in the connection protocols between the phones and the towers.

IP intercept systems are used to eavesdrop on what people do on the Internet. Unlike the surveillance that happens at the sites you visit, by companies like Facebook and Google, this surveillance happens at the point where your computer connects to the Internet. Here, someone can eavesdrop on everything you do.

This system also exploits existing vulnerabilities in the underlying Internet communications protocols. Most of the traffic between your computer and the Internet is unencrypted, and what is encrypted is often vulnerable to man-in-the-middle attacks because of insecurities in both the Internet protocols and the encryption protocols that protect it.

There are many other examples. What they all have in common is that they are vulnerabilities in our underlying digital communications systems that allow someone — whether it’s a country’s secret police, a rival national intelligence organization, or criminal group — to break or bypass what security there is and spy on the users of these systems.

These insecurities exist for two reasons. First, they were designed in an era where computer hardware was expensive and inaccessibility was a reasonable proxy for security. When the mobile phone network was designed, faking a cell tower was an incredibly difficult technical exercise, and it was reasonable to assume that only legitimate cell providers would go to the effort of creating such towers.

At the same time, computers were less powerful and software was much slower, so adding security into the system seemed like a waste of resources. Fast forward to today: computers are cheap and software is fast, and what was impossible only a few decades ago is now easy.

The second reason is that governments use these surveillance capabilities for their own purposes. The FBI has used IMSI-catchers for years to investigate crimes. The NSA uses IP interception systems to collect foreign intelligence. Both of these agencies, as well as their counterparts in other countries, have put pressure on the standards bodies that create these systems to not implement strong security.

Of course, technology isn’t static. With time, things become cheaper and easier. What was once a secret NSA interception program or a secret FBI investigative tool becomes usable by less-capable governments and cybercriminals.

Man-in-the-middle attacks against Internet connections are a common criminal tool to steal credentials from users and hack their accounts.

IMSI-catchers are used by criminals, too. Right now, you can go onto Alibaba.com and buy your own IMSI catcher for under $2,000.

Despite their uses by democratic governments for legitimate purposes, our security would be much better served by fixing these vulnerabilities in our infrastructures.

These systems are not only used by dissidents in totalitarian countries, they’re also used by legislators, corporate executives, critical infrastructure providers, and many others in the US and elsewhere.

That we allow people to remain insecure and vulnerable is both wrongheaded and dangerous.

Earlier this month, two American legislators — Senator Ron Wyden and Rep Ted Lieu — sent a letter to the chairman of the Federal Communications Commission, demanding that he do something about the country’s insecure telecommunications infrastructure.

They pointed out that not only are insecurities rampant in the underlying protocols and systems of the telecommunications infrastructure, but also that the FCC knows about these vulnerabilities and isn’t doing anything to force the telcos to fix them.

Wyden and Lieu make the point that fixing these vulnerabilities is a matter of US national security, but it’s also a matter of international human rights. All modern communications technologies are global, and anything the US does to improve its own security will also improve security worldwide.

Yes, it means that the FBI and the NSA will have a harder job spying, but it also means that the world will be a safer and more secure place.

This essay previously appeared on AlJazeera.com.

Thursday’s security advisories

Post Syndicated from jake original https://lwn.net/Articles/713405/rss

Debian has updated ntfs-3g
(privilege escalation).

Debian-LTS has updated openssl
(three vulnerabilities).

Fedora has updated jasper (F25:
code execution), moodle (F24: multiple vulnerabilities), and
percona-xtrabackup (F25; F24: information disclosure).

Mageia has updated libxpm (code
execution), pdns (multiple vulnerabilities), python-pycrypto (denial of service from 2013),
and wireshark (two denial of service flaws).

openSUSE has updated bzrtp (42.2,
42.1: man-in-the-middle vulnerability), firefox (42.2, 42.1: multiple vulnerabilities), nginx (42.2, 42.1; SPH
for SLE12
: denial of service), seamonkey (42.2, 42.1: code execution), and
thunderbird (42.2, 42.1; SPH for SLE12: multiple vulnerabilities).

Red Hat has updated rabbitmq-server (OSP8.0: denial of service
from 2015) and thunderbird (multiple vulnerabilities).

Ubuntu has updated gnutls26,
(multiple vulnerabilities), irssi (multiple vulnerabilities), iucode-tool (16.10, 16.04: code execution), libxpm (code execution), and ntfs-3g (16.10, 16.04: privilege escalation).

Fluxion – Automated EvilAP Attack Tool

Post Syndicated from Darknet original http://feedproxy.google.com/~r/darknethackers/~3/9T4e6Vl_EoI/

Fluxion is an automated EvilAP attack tool for carrying out MiTM attacks on WPA Wireless networks written in a mix of Bash and Python. Fluxion is heavily based off Linset the Evil Twin Attack Bash Script, with some improvements and bug-fixes. How it Works Scan the networks. Capture a handshake (can’t be used without a […]

The post Fluxion…

Read the full post at darknet.org.uk

Security advisories for Monday

Post Syndicated from ris original http://lwn.net/Articles/710472/rss

Arch Linux has updated curl (two vulnerabilities) and libwmf (multiple vulnerabilities).

Debian has updated libgd2 (denial
of service) and libphp-phpmailer (code execution).

Debian-LTS has updated hdf5
(multiple vulnerabilities), hplip
(man-in-the-middle attack from 2015), kernel (multiple vulnerabilities), libphp-phpmailer (code execution), pgpdump (denial of service), postgresql-common (file overwrites), python-crypto (denial of service), and shutter (code execution from 2015).

Fedora has updated curl (F24:
buffer overflow), cxf (F25: two
vulnerabilities), game-music-emu (F24:
multiple vulnerabilities), libbsd (F25; F24:
denial of service), libpng (F25: NULL
dereference bug), mingw-openjpeg2 (F25; F24:
multiple vulnerabilities), openjpeg2 (F24:
two vulnerabilities), php-zendframework-zend-mail (F25; F24:
parameter injection), springframework (F25:
directory traversal), tor (F25; F24: denial of service), xen (F24: three vulnerabilities), and
zookeeper (F25; F24: buffer overflow).

Gentoo has updated bash (code
execution), busybox (denial of service), chicken (multiple vulnerabilities going back
to 2013), cyassl (multiple vulnerabilities
from 2014), e2fsprogs (code execution from
2015), hdf5 (multiple vulnerabilities), icinga (privilege escalation), libarchive (multiple vulnerabilities, some
from 2015), libjpeg-turbo (code execution),
libotr (code execution), lzo (code execution from 2014), mariadb (multiple unspecified
vulnerabilities), memcached (code
execution), musl (code execution), mutt (denial of service from 2014), openfire (multiple vulnerabilities from 2015),
openvswitch (code execution), pillow (multiple vulnerabilities, two from
2014), w3m (multiple vulnerabilities), xdg-utils (command execution from 2014), and
xen (multiple vulnerabilities).

Mageia has updated mcabber (roster push attack) and tracker (denial of service).

openSUSE has updated firefox
(13.1: multiple vulnerabilities), gd (42.2,
42.1: stack overflow), GNU Health (42.2:
two vulnerabilities), roundcubemail (13.1:
cross-site scripting), kernel (42.1:
information leak), thunderbird (42.2,
42.1, 13.2
; SPH for SLE12:
multiple vulnerabilities), and xen (42.2; 42.1; 13.2: multiple vulnerabilities).

Red Hat has updated ipa (RHEL7:
two vulnerabilities) and rh-nodejs4-nodejs and
(RHSCL: multiple vulnerabilities).

Slackware has updated libpng (NULL dereference bug), thunderbird (code execution), and seamonkey (multiple vulnerabilities).

SUSE has updated gstreamer-plugins-good (SLE12-SP2: multiple
vulnerabilities) and kernel (SLERTE12-SP1: multiple vulnerabilities).

Ettercap – A Suite For Man-In-The-Middle Attacks

Post Syndicated from Darknet original http://feedproxy.google.com/~r/darknethackers/~3/Y51Scv7c-Tg/

Ettercap is a comprehensive suite for man-in-the-middle attacks (MiTM). It features sniffing of live connections, content filtering on the fly and many other interesting tricks. It also supports active and passive dissection of many protocols and includes many features for network and host analysis. Ettercap works by putting the network interface…

Read the full post at darknet.org.uk

Security advisories for Monday

Post Syndicated from ris original http://lwn.net/Articles/707487/rss

Arch Linux has updated lib32-libtiff (multiple vulnerabilities), libtiff (multiple vulnerabilities), and ntp (multiple vulnerabilities).

Debian has updated icu (multiple vulnerabilities) and imagemagick (three vulnerabilities).

Debian-LTS has updated irssi (information disclosure), libsoap-lite-perl (XML expansion), and mcabber (roster push attack).

Fedora has updated bind (F23:
denial of service) and python-tornado (F25:
XSRF protection bypass).

Mageia has updated bzip2 (denial
of service), chromium-browser-stable
(multiple vulnerabilities), clamav (three
vulnerabilities), giflib (denial of
service), icu (two vulnerabilities), kernel-4.4.32 (code execution), libtiff (two vulnerabilities), lighttpd (man-in-the-middle attacks), and perl-Email-Address (denial of service).

openSUSE has updated wireshark
(Leap42.2: multiple vulnerabilities).

SUSE has updated kernel
(SLE12-SP1: multiple vulnerabilities).

Ubuntu has updated gst-plugins-good0.10, gst-plugins-good1.0
(incomplete fix in previous update).

Is WhatsApp Hacked?

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2016/10/is_whatsapp_hac.html

Forbes is reporting that the Israeli cyberweapons arms manufacturer Wintego has a man-in-the-middle exploit against WhatsApp.

It’s a weird story. I’m not sure how they do it, but something doesn’t sound right.

Another possibility is that CatchApp is malware thrust onto a device over Wi-Fi that specifically targets WhatsApp. But it’s almost certain the product cannot crack the latest standard of WhatsApp cryptography, said Matthew Green, a cryptography expert and assistant professor at the Johns Hopkins Information Security Institute. Green, who has been impressed by the quality of the Signal code, added: “They would have to defeat both the encryption to and from the server and the end-to-end Signal encryption. That does not seem feasible at all, even with a Wi-Fi access point.

“I would bet mundanely the password stuff is just plain phishing. You go to some site, it asks for your Google account, you type it in without looking closely at the address bar.

“But the WhatsApp stuff manifestly should not be vulnerable like that. Interesting.”

Neither WhatsApp nor the crypto whizz behind Signal, Moxie Marlinspike, were happy to comment unless more specific details were revealed about the tool’s capability. Either Wintego is embellishing what its real capability is, or it has a set of exploits that the rest of the world doesn’t yet know about.

Leaked Product Demo from RCS Labs

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2016/09/leaked_product_.html

We have leak from yet another cyberweapons arms manufacturer: the Italian company RCS Labs. Vice Motherboard reports on a surveillance video demo:

The video shows an RCS Lab employee performing a live demo of the company’s spyware to an unidentified man, including a tutorial on how to use the spyware’s control software to perform a man-in-the-middle attack and infect a target computer who wanted to visit a specific website.

RCS Lab’s spyware, called Mito3, allows agents to easily set up these kind of attacks just by applying a rule in the software settings. An agent can choose whatever site he or she wants to use as a vector, click on a dropdown menu and select “inject HTML” to force the malicious popup to appear, according to the video.

Mito3 allows customers to listen in on the target, intercept voice calls, text messages, video calls, social media activities, and chats, apparently both on computer and mobile platforms. It also allows police to track the target and geo-locate it thanks to the GPS. It even offers automatic transcription of the recordings, according to a confidential brochure obtained by Motherboard.

Slashdot thread

Notes on the Apple/NSO Trident 0days

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/08/notes-on-applenso-trident-0days.html

I thought I’d write up some comments on today’s news of the NSO malware using 0days to infect human rights activist phones. For full reference, you want to read the Citizen’s Lab report and the Lookout report.

Press: it’s news to you, it’s not news to us

I’m seeing breathless news articles appear. I dread the next time that I talk to my mom that she’s going to ask about it (including “were you involved”). I suppose it is new to those outside the cybersec community, but for those of us insiders, it’s not particularly newsworthy. It’s just more government malware going after activists. It’s just one more set of 0days.

I point this out in case press wants to contact for some awesome sounding quote about how exciting/important this is. I’ll have the opposite quote.

Don’t panic: all patches fix 0days

We should pay attention to context: all patches (for iPhone, Windows, etc.) fix 0days that hackers can use to break into devices. Normally these 0days are discovered by the company itself or by outside researchers intending to fix (and not exploit) the problem. What’s different here is that where most 0days are just a theoretical danger, these 0days are an actual danger — currently being exploited by the NSO Group’s products. Thus, there’s maybe a bit more urgency in this patch compared to other patches.

Don’t panic: NSA/Chinese/Russians using secret 0days anyway

It’s almost certain the NSA, the Chinese, and the Russian have similar 0days. That means applying this patch makes you safe from the NSO Group (for a while, until they find new 0days), but it’s unlikely this patch makes you safe from the others.

Of course it’s multiple 0days

Some people are marveling how the attack includes three 0days. That’s been the norm for browser exploits for a decade now. There’s sandboxes and ASLR protections to get through. There’s privilege escalation to get into the kernel. And then there’s persistence. How far you get in solving one or more of these problems with a single 0day depends upon luck.

It’s actually four 0days

While it wasn’t given a CVE number, there was a fourth 0day: the persistence using the JavaScriptCore binary to run a JavaScript text file. The JavaScriptCore program appears to be only a tool for developers and not needed the functioning of the phone. It appears that the iOS 9.3.5 patch disables. While technically, it’s not a coding “bug”, it’s still a design bug. 0days solving the persistence problem (where the malware/implant runs when phone is rebooted) are worth over a hundred thousand dollars all on their own.

That about wraps it up for VEP

VEP is Vulnerability Equities Process that’s supposed to, but doesn’t, manage how the government uses 0days it acquires.

Agitators like the EFF have been fighting against the NSA’s acquisition and use of 0days, as if this makes us all less secure. What today’s incident shows is that acquisition/use of 0days will be widespread around the world, regardless what the NSA does. It’s be nice to get more transparency about what they NSA is doing through the VEP process, but the reality is the EFF is never going to get anything close to what it’s agitating for.

That about wraps is up for Wassenaar

Wassenaar is an internal arms control “treaty”. Left-wing agitators convinced the Wassenaar folks to add 0days and malware to the treaty — with horrific results. There is essentially no difference between bad code and good code, only how it’s used, so the the Wassenaar extensions have essentially outlawed all good code and security research.

Some agitators are convinced Wassenaar can be still be fixed (it can’t). Israel, where NSO Group is based, is not a member of Wassenaar, and thus whatever limitations Wassenaar could come up with would not stop the NSO.

Some have pointed out that Israel frequently adopts Wassenaar rules anyway, but they would then simply transfer the company somewhere else, such as Singapore.

The point is that 0day development is intensely international. There are great 0day researchers throughout the non-Wassenaar countries. It’s not like precision tooling for aluminum cylinders (for nuclear enrichment) that can only be made in an industrialized country. Some of the best 0day researchers come from backwards countries, growing up with only an Internet connection.


The victim in this case, Ahmed Mansoor, has apparently been hacked many time, including with HackingTeam’s malware and Finfisher malware — notorious commercial products used by evil government’s to hack into dissident’s computers.

Obviously, he’ll be hacked again. He’s a gold mine for researchers in this area. The NSA, anti-virus companies, Apple jailbreak companies, and the like should be jumping over themselves offering this guy a phone. One way this would work is giving him a new phone every 6 months in exchange for the previous phone to analyze.

Apple, of course, should head the list of companies doing this, proving “activist phones” to activists with their own secret monitoring tools installed so that they can regularly check if some new malware/implant has been installed.

iPhones are still better, suck it Android

Despite the fact that everybody and their mother is buying iPhone 0days to hack phones, it’s still the most secure phone. Androids are open to any old hacker — iPhone are open only to nation state hackers.

Use signal, use Tor

I didn’t see Signal on the list of apps the malware tapped into. There’s no particular reason for this, other than NSO haven’t gotten around to it yet. But I thought I’d point how yet again, Signal wins.

SMS vs. MitM

Some have pointed to SMS as the exploit vector, which gave Citizen’s Lab the evidence that the phone had been hacked.

It’s a Safari exploit, so getting the user to visit a web page is required. This can be done over SMS, over email, over Twitter, or over any other messaging service the user uses. Presumably, SMS was chosen because users are more paranoid of links in phishing emails than they are SMS messages.

However, the way it should be doing is with man-in-the-middle (MitM) tools in the infrastructure. Such a tool would wait until the victim visited any webpage via Safari, then magically append the exploit to the page. As Snowden showed, this is apparently how the NSA does it, which is probably why they haven’t gotten caught yet after exploiting iPhones for years.

The UAE (the government who is almost certainly trying to hack Mansoor’s phone) has the control over their infrastructure in theory to conduct a hack. We’ve already caught other governments doing similar things (like Tunisia). My guess is they were just lazy, and wanted to do it the easiest way for them.

National interest is exploitation, not disclosure

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/08/national-interest-is-exploitation-not.html

Most of us agree that more accountability/transparency is needed in how the government/NSA/FBI exploits 0days. However, the EFF’s positions on the topic are often absurd, which prevent our voices from being heard.

One of the EFF’s long time planks is that the government should be disclosing/fixing 0days rather than exploiting them (through the NSA or FBI). As they phrase it in a recent blog post:

as described by White House Cybersecurity Coordinator, Michael Daniel: “[I]n the majority of cases, responsibly disclosing a newly discovered vulnerability is clearly in the national interest.” Other knowledgeable insiders—from former National Security Council Cybersecurity Directors Ari Schwartz and Rob Knake to President Obama’s hand-picked Review Group on Intelligence and Communications Technologies—have also endorsed clear, public rules favoring disclosure.

The EFF isn’t even paying attention to what the government said. The majority of vulnerabilities are useless to the NSA/FBI. Even powerful bugs like Heartbleed or Shellshock are useless, because they can’t easily be weaponized. They can’t easily be put into a point-and-shoot tool and given to cyberwarriors.

Thus, it’s a tautology saying “majority of cases vulns should be disclosed”. It has no bearing on the minority of bugs the NSA is interested in — the cases where we want more transparency and accountability.

These minority of bugs are not discovered accidentally. Accidental bugs have value to the NSA, so the NSA spends considerable amount of money hunting down different bugs that would be of use, and in many cases, buying useful vulns from 0day sellers. The EFF pretends the political issue is about 0days the NSA happens to come across accidentally — the real political issue is about the ones the NSA spent a lot of money on.

For these bugs, the minority of bugs the NSA sees, we need to ask whether it’s in the national interest to exploit them, or to disclose/fix them. And the answer to this question is clearly in favor of exploitation, not fixing. It’s basic math.

An end-to-end Apple iOS 0day (with sandbox escape and persistance) is worth around $1 million, according to recent bounties from Zerodium and Exodus Intel.

There are two competing national interests with such a bug. The first is whether such a bug should be purchased and used against terrorist iPhones in order to disrupt ISIS. The second is whether such a bug should be purchased and disclosed/fixed, to protect American citizens using iPhones.

Well, for one thing, the threat is asymmetric. As Snowden showed, the NSA has widespread control over network infrastructure, and can therefore insert exploits as part of a man-in-the-middle attack. That makes any browser-bugs, such as the iOS bug above, much more valuable to the NSA. No other intelligence organization, no hacker group, has that level of control over networks, especially within the United States. Non-NSA actors have to instead rely upon the much less reliable “watering hole” and “phishing” methods to hack targets. Thus, this makes the bug of extreme value for exploitation by the NSA, but of little value in fixing to protect Americans.

The NSA buys one bug per version of iOS. It only needs one to hack into terrorist phones. But there are many more bugs. If it were in the national interest to buy iOS 0days, buying just one will have little impact, since many more bugs still lurk waiting to be found. The government would have to buy many bugs to make a significant dent in the risk.

And why is the government helping Apple at the expense of competitors anyway? Why is it securing iOS with its bug-bounty program and not Android? And not Windows? And not Adobe PDF? And not the million other products people use?

The point is that no sane person can argue that it’s worth it for the government to spend $1 million per iOS 0day in order to disclose/fix. If it were in the national interest, we’d already have federal bug bounties of that order, for all sorts of products. Long before the EFF argues that it’s in the national interest that purchased bugs should be disclosed rather than exploited, the EFF needs to first show that it’s in the national interest to have a federal bug bounty program at all.

Conversely, it’s insane to argue it’s not worth $1 million to hack into terrorist iPhones. Assuming the rumors are true, the NSA has been incredibly effective at disrupting terrorist networks, reducing the collateral damage of drone strikes and such. Seriously, I know lots of people in government, and they have stories. Even if you discount the value of taking out terrorists, 0days have been hugely effective at preventing “collateral damage” — i.e. the deaths of innocents.

The NSA/DoD/FBI buying and using 0days is here to stay. Nothing the EFF does or says will ever change that. Given this constant, the only question is how We The People get more visibility into what’s going on, that our representative get more oversight, that the courts have clearer and more consistent rules. I’m the first to stand up and express my worry that the NSA might unleash a worm that takes down the Internet, or the FBI secretly hacks into my home devices. Policy makers need to address these issues, not the nonsense issues promoted by the EFF.

Security advisories for Wednesday

Post Syndicated from ris original http://lwn.net/Articles/696930/rss

CentOS has updated qemu-kvm (C6:
denial of service).

Debian-LTS has updated fontconfig
(privilege escalation) and mongodb (problem
in previous update).

Fedora has updated lighttpd (F24; F23:
man-in-the-middle attacks) and openssh
(F24: denial of service).

Oracle has updated qemu-kvm (OL6:
multiple vulnerabilities).

Red Hat has updated qemu-kvm
(RHEL6: denial of service).

SUSE has updated java-1_7_0-openjdk (SLE12-SP1: multiple
vulnerabilities), java-1_8_0-openjdk
(SLE12-SP1: multiple vulnerabilities), php53 (SLE11-SP4: multiple vulnerabilities),
squid3 (SLE11-SP4: multiple
vulnerabilities), and kernel (SLE11-SP4: three vulnerabilities).

Ubuntu has updated kernel (16.04; 14.04;
12.04: multiple vulnerabilities), linux-lts-trusty (12.04: two vulnerabilities),
linux-lts-vivid (14.04: multiple
vulnerabilities), linux-lts-xenial (14.04:
multiple vulnerabilities), linux-raspi2
(16.04: multiple vulnerabilities), linux-snapdragon (16.04: multiple
vulnerabilities), and linux-ti-omap4
(12.04: multiple vulnerabilities).