• Security updates for Wednesday

• China slams Australia over 'double standards' in cyber security

  China has taken a swipe at Australia over the country's encryption law, saying it was "baffling" how Canberra could on the one hand claim that other countries posed security threats, while on the other hand engage in acts that endangered the cyber security of other nations.

• How to (not) fix a security flaw

  A pair of flaws in the web interface for two small-business Cisco routers make for a prime example of the wrong way to go about security fixes. These kinds of flaws are, sadly, fairly common, but the comedy of errors that resulted here is, thankfully, rather rare. Among other things, it shows that vendors may wish to await a real fix rather than to release a small, ineffective band-aid to try to close a gaping hole.

  RedTeam Pentesting GmbH found the flaws in September 2018 and notified Cisco shortly thereafter. The original disclosure date was planned for January 9, but that was postponed until January 23 at Cisco's request. On the latter date, Cisco issued advisories for CVE-2019-1652 and CVE-2019-1653; RedTeam Pentesting released its own advisories, with lots more detail, for CVE-2019-1652 and CVE-2019-1653.

  The flaws are bog standard web-application vulnerabilities. CVE-2019-1652 is a command injection that allows authenticated users (in the web interface) to execute arbitrary Linux commands as root. CVE-2019-1653 allows anyone to request the configuration page from the router, which contains all sorts of interesting information, including user names with hashed passwords, VPN and IPsec secrets, and more. In addition, password hashes are all that is needed to log into the web interface—no cracking required.

  Beyond that, an additional information disclosure flaw, related to CVE-2019-1653, was reported; it uses a debug interface to retrieve a .tgz (gzipped tar) file, encrypted with a known, hard-coded password, from the device. That file contained even more configuration and debugging information as well as etc.tgz and var.tgz with the contents of those directories from the router. In all of the RedTeam Pentesting advisories, curl was used for the proof of concept, though there are lots of other ways to perform the same actions, of course.

  The flaws were found, reported, and fixed; so far, so good—or so it would seem. But on February 7, RedTeam Pentesting found that the fixes shipped by Cisco were, at a minimum, insufficient. Once again, the problems were reported to Cisco, with a disclosure date of March 27. Despite a last-minute request to postpone the disclosure, three new advisories (command injection, configuration information disclosure, and even more configuration information disclosure) were released by RedTeam Pentesting on March 27.

• Wladimir Palant: Bogus security mechanisms: Encrypting localhost traffic

  Nowadays it is common for locally installed applications to also offer installing browser extensions that will take care of browser integration. Securing the communication between extensions and the application is not entirely trivial, something that Logitech had to discover recently for example. I’ve also found a bunch of applications with security issues in this area. In this context, one has to appreciate RememBear password manager going to great lengths to secure this communication channel. Unfortunately, while their approach isn’t strictly wrong, it seems to be based on a wrong threat assessment and ends up investing far more effort into this than necessary.

  The approach

  It is pretty typical for browser extensions and applications to communicate via WebSockets. In case of RememBear the application listens on port 8734, so the extension creates a connection to ws://localhost:8734. After that, messages can be exchanged in both directions. So far it’s all pretty typical. The untypical part is RememBear using TLS to communicate on top of an unencrypted connection.

  So the browser extension contains a complete TLS client implemented in JavaScript. It generates a client key, and on first connection the user has to confirm that this client key is allowed to connect to the application. It also remembers the server’s public key and will reject connecting to another server.

  Why use an own TLS implementation instead of letting the browser establish an encrypted connection? The browser would verify TLS certificates, whereas the scheme here is based on self-signed certificates. Also, browsers never managed to solve authentication via client keys without degrading user experience.

• You May Not Be Only Person Seeing Hotel Reservation Booking Details

  Before we go any further, we need to take a look back a few decades ago and realize how much easier the Internet has made booking travel. Remember when you had to call a travel agent to book a hotel room or a flight?

  You could book a hotel if you knew of its existence, but without the Internet, you didn’t know which hotels were located on a certain beach or close to the airport, had you never traveled to the area before. And there was no other way to book flights. Not only did the Internet make booking travel easier, but it left us with so much more control to be able to research all these choices ourselves.

  But Symantec tells us that freedom has come with a price. Hundreds of hotel websites have flaws that leak sensitive information, including your name, phone number, address, confirmation email, and even your passport number. Realize that with this information hackers know your address and when you’ll be gone for an extended period of time.

  Symantec threat researcher Candid Wueest looked at more than 1,500 hotel websites in more than 50 countries. He found two-thirds of them had security issues.

  The Marriott hotel chain has been open about their cyberattacks recently, as has Sheraton, Westin, Starwood, and Wyndham hotels. Marriott admitted last November that hackers had stolen the records of up to 383 million guests. It became one of the largest personal data breaches in history.

• Security updates for Tuesday

• Optimising IoT bandwith with delta updates [Ed: Canonical is pushing proprietary software again; using Snap. These are ads in their blogs… last week a paid press releases for Microsoft.]

• 6 Kubernetes security questions, answered

  If you’re asking questions about Kubernetes to learn more about the platform, security will be on your list. The good news: both the open source project and the commercial platforms that sit on top of it have plenty of strong security-related features baked in. Moreover, there’s a lively Kubernetes community with a shared interest in the ongoing security of the orchestration tool.

  “The Kubernetes community has had security at the forefront of their minds from the start,” says Wei Lein Dang, VP of products at StackRox.

  As with many technologies, though, the security risks tend to follow the adoption curve. So as the use of containers expands, expect Kubernetes to become an important focal point for security in containerized environments.

• The security of dependencies

  So you’ve written some software. It’s full of open source dependencies. These days all software is full of open source, there’s no way around it at this point. I explain the background in my previous post.

  Now that we have all this open source, how do we keep up with it? If you’re using a lot of open source in your code there could be one or more updated dependencies per day!

  Step one is knowing what you have. There are a ton of ways to do this, but I’m going to bucket things into 3 areas.

• Buffer Overflow Vulnerability in TP-Link Routers Can Allow Remote Attackers to Take Control

  Internet routers are among the most ubiquitous devices home and business users depend on every day to carry out communications, banking, shopping and commercial transactions. IBM Security researcher Grzegorz Wypych (aka h0rac) took a closer look at one of the most widespread internet routers in use by consumers nowadays, the TP-Link WR-940, and found that a zero-day buffer overflow vulnerability in the router could allow malicious third parties to take control of the device from a remote location.

• PoC exploit for Carpe Diem Apache bug released

• Security updates for Monday

• IPFire 2.21 - Core Update 129 released

  This is the official release announcement for IPFire 2.21 - Core Update 129 - an update that introduces routed IPsec VPNs and comes with various other changes that update the core system and fix several bugs.

• Sylvain Beucler: Debian LTS - March 2019

  In February I had requested to join the Debian LTS project, which extends the security support for past Debian releases, as a paid contributor.

  Kuddos to Freexian for pulling this project out.

• Using Multi-factor Authentication (MFA) | Roadmap to Securing Your Infrastructure

Hello,

A new snapshot, `0.0.20190406`, has been tagged in the git repository.

Please note that this snapshot is, like the rest of the project at this point
in time, experimental, and does not constitute a real release that would be
considered secure and bug-free. WireGuard is generally thought to be fairly
stable, and most likely will not crash your computer (though it may).
However, as this is a pre-release snapshot, it comes with no guarantees, and
its security is not yet to be depended on; it is not applicable for CVEs.

With all that said, if you'd like to test this snapshot out, there are a
few relevant changes.

== Changes ==

  * allowedips: initialize list head when removing intermediate nodes
  
  Fix for an important regression in removing allowed IPs from the last
  snapshot. We have new test cases to catch these in the future as well.
  
  * wg-quick: freebsd: rebreak interface loopback, while fixing localhost
  * wg-quick: freebsd: export TMPDIR when restoring and don't make empty
  
  Two fixes for FreeBSD which have already been backported into ports.
  
  * tools: genkey: account for short reads of /dev/urandom
  * tools: add support for Haiku
  
  The tools now support Haiku! Maybe somebody is working on a WireGuard
  implementation for it?
  
  * tools: warn if an AllowedIP has a nonzero host part
  
  If you try to run `wg set wg0 peer ... allowed-ips 192.168.1.82/24`, wg(8)
  will now print a warning. Even though we mask this automatically down to
  192.168.1.0/24, usually when people specify it like this, it's a mistake.
  
  * wg-quick: add 'strip' subcommand
  
  The new strip subcommand prints the config file to stdout after stripping
  it of all wg-quick-specific options. This enables tricks such as:
  `wg addconf $DEV <(wg-quick strip $DEV)`.
  
  * tools: avoid unneccessary next_peer assignments in sort_peers()
  
  Small C optimization the compiler was probably already doing.
  
  * peerlookup: rename from hashtables
  * allowedips: do not use __always_inline
  * device: use skb accessor functions where possible
  
  Suggested tweaks from Dave Miller.
  
  * qemu: set framewarn 1280 for 64bit and 1024 for 32bit
  
  These should indicate to us more clearly when we cross the most strict stack
  thresholds expected when using recent compilers with the kernel.
  
  * blake2s: simplify
  * blake2s: remove outlen parameter from final
  
  The blake2s implementation has been simplified, since we don't use any of the
  fancy tree hashing parameters or the like. We also no longer separate the
  output length at initialization time from the output length at finalization
  time.
  
  * global: the _bh variety of rcu helpers have been unified
  * compat: nf_nat_core.h was removed upstream
  * compat: backport skb_mark_not_on_list
  
  The usual assortment of compat fixes for Linux 5.1.

This snapshot contains commits from: Jason A. Donenfeld, Luis Ressel, Samuel 
Neves, Bruno Wolff III, and Alexander von Gluck IV.

As always, the source is available at https://git.zx2c4.com/WireGuard/ and
information about the project is available at https://www.wireguard.com/ .

This snapshot is available in compressed tarball form here:
  https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20190406.tar.xz
  SHA2-256: 2f06f3adf70b95e74a7736a22dcf6e9ef623b311a15b7d55b5474e57c3d0415b
  BLAKE2b-256: 787a01fa3d6a800d7376a04ff57dd16d884a7d3cb99d2f91bfc59895ab759200

A PGP signature of that file decompressed is available here:
  https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20190406.tar.asc
  Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE

If you're a snapshot package maintainer, please bump your package version. If
you're a user, the WireGuard team welcomes any and all feedback on this latest
snapshot.

Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/

Thank you,
Jason Donenfeld

Also: New WireGuard Snapshot Offers FreeBSD Fixes, Other Tweaks