Monthly Archives: February 2019

Security Researcher Creates Remote WiFi USB Charging Cable

Early last week; a security researcher has demonstrated a new means of social engineering which could be used to compromise the security of a computer network:

TL DR: This cable poses a threat from a social engineering perspective. Should these cables become widespread: I would recommend being more careful of the cables you use to charge devices and consider using power outlets for charging.

What kind of threat does this pose?
The researcher created a custom USB cable that looks just like a standard cable. This cable could obviously be used to charge a smartphone. This cable however contains a custom printed circuit board (PCB) that allows an attacker to send commands to it via WiFi. The cable “appears” and acts as a keyboard and mouse when connected to a system and allows the attacker to control as if they had physical access to it and allows the opening of a reverse shell to execute commands:

The researcher demonstrated how the “mouse” feature of the cable could be used to prevent a system from locking after the real user has left the system by continually moving the mouse; just as a real person would.

Worse than this the cable has the potential to conduct WiFi deuthentication (de-auth) attacks which will disconnect devices in the vicinity from the WiFi networks they have connected with. This would constitute a denial of service attack and the inconvenience of having to keep re-connecting your wireless devices to the WiFi network again. Whether such an attack could be used to sniff/capture WiFi authentication credentials or to be used to exploit the KRACK vulnerability is not clear:

How could an adversary use this cable in a practical way?
The adversary simply need to wait for you to plug this cable into one of your systems. They don’t need to be nearby in order for them to access the system the cable is connected to (since the cable appears to be accessible over the internet connection in your office). Consider if an adversary left some of these cables on the desks in your organisation. How many people connect the cables to their systems to charge their phone? This would be even more common in older offices were USB charging ports aren’t readily available.

An adversary could also send some cables to your office via postal mail while pretending they came from the marketing department or another office of the same organisation. Cables aren’t considered malicious (like an unknown USB thumb drive should be) and will be used by those who receive them. Employees might also take them home or give these “free” cables to friends and family.

How can I protect myself from this type of threat?
This is not an easy question to answer. While you can educate your employees to not use cables that arrive in the postal mail (or even from your marketing department); what is to prevent them from doing so? Do you then treat every cable as a possible threat? You would need to place your office in a Faraday cage to truly mitigate this! Should you split every cable open to check if it has a WiFi PCB added to it (even if you did; could you tell what you are looking at)?

Given how common and widespread they are; is that even possible? You could ask that charging cables are only connected to power (electrical) outlets (requiring employees to bring the charging adapters for their devices (which almost nobody does)) or ask them to use portable battery packs. But again; what is to stop an employee from not doing this especially if they are travelling and need to charge their mobile devices? It’s already difficult to educate your employees about the dangers of BadUSB or juice-jacking (my previous post on that topic) but this is even harder to defend against:

It’s very likely that this cable would have a MAC address and while you can use MAC address authentication to protect your network; that can be bypassed. An adversary can spoof a MAC address (to use a legitimate MAC address from your own network). So, if you deny that MAC access to your network you could block the legitimate device too.

Note: The adversary would need to use some form of software to spoof the MAC address. The cable may not currently accommodate that capability. I assume the adversary can’t manufacture the silicon needed for a WiFi adapter and doesn’t have the ability to “burn” a MAC address of their choice into it.

It’s important to remember this cable is only a proof of concept at this time but the researcher does plan to sell them. They could be used by pen testers in much the same way as Wi-Fi Pineapples or RubberDuckies currently are. Given that the cable looks exactly like a standard USB smartphone charger (for an Apple device); from the photos included you can’t tell the difference between a genuine cable and this pen testing cable.

Can an upcoming standard for USB help with this issue?
Possibly.

Unfortunately, while the new USB Type-C Authentication Program appears to be more of a Digital Rights Management (DRM) feature that may raise charger and cable prices and potentially creating vendor lock-in. While it would help with detecting a malicious cable or a cable that was tampered with; it remains to be seen if the standard in reality increases security. It’s also unclear how the cables will authenticate since we have seen digital signatures being stolen in the past to bypass this form of authentication:

Thank you.

Adobe Flash Player 2019 Update Tracker

In a similar manner to previous years this post will track the number of vulnerabilities patched within Adobe Flash for 2019. This will be the penultimate year of tracking these numbers since Flash Player is due to be decommissioned in 2020.

As always this post will be updated throughout the year with the details of vulnerabilities being patched and if they are being exploited in the wild. Apologies for not making this 2019 tracker available sooner.

Thank you.

=======================

=======================
8th  January 2019: Adobe releases Flash Player v32.0.0.114 This update is a non-security update addressing only feature and performance bugs.

12th February: Adobe releases Flash Player v32.0.0.142 resolving 1x priority 2 CVE.

12th March: Adobe have not released any Flash Player updates this month.

12th March 2019: Adobe makes available Flash Player v32.0.0.156 to resolve non-security bugs only.

9th April 2019: Adobe releases Flash Player v32.0.0.171  resolving 2x priority 2 vulnerabilities (CVEs) (1x Critical and 1x Important severity).

14th May 2019: Adobe releases  Flash Player v32.0.0.192 to resolve a single critical CVE.

11th June 2019: Adobe releases Flash Player v32.0.0.207 just like last month to resolve a single critical CVE.

9th July 2019: Adobe has not released any Flash Player updates this month.

13th August 2019: Just like last month; Adobe has not released any Flash Player updates this month.

=======================
Update: 19th February 2019: The timeline was created to include the Adobe Flash Player updates for January and February 2019. At the time of writing no exploits for the issue fixed by the February update are known to be taking place.

Update 12th March 2019: The timeline was updated to reflect that Adobe did not issue Flash Player updates this month.

Update: 21st March 2019: The timeline was updated to reflect that Adobe did publish a Flash Player update for March 2019 but it is a non-security update.

Update: 10th April 2019: The timeline was created to include the Adobe Flash Player updates for April 2019. At the time of writing no exploits for the issues resolved fixed by the April update are known to be taking place.

Update: 12th June 2019: The timeline was created to include the Adobe Flash Player updates for May and June 2019. At this time no exploits for the issues resolved in either month are known to be currently taking place.

Update: 9th July 2019: The timeline was created to state Adobe did not release Flash Player update for July 2019.

Update: 13th August 2019: The timeline was created to state Adobe did not release Flash Player update for August 2019.
=======================

February 2019 Update Summary

Earlier today Microsoft made available 13 bulletins and 3 advisories resolving 74 vulnerabilities (more formally known as CVEs (defined)) respectively. As always more details are available from Microsoft’s monthly summary page.

Also today Adobe released scheduled updates for the products listed below addressing 75 CVEs in total:

Adobe Acrobat and Reader: 71x priority 2 CVEs resolved (43 of the 75 are Critical, the remainder are Important severity)

Adobe ColdFusion: 2x priority 2 CVEs resolved

Adobe Creative Cloud Desktop Application: 1x priority 3 CVE resolved

Adobe Flash Player: 1x priority 2 CVE resolved

If you use the affected Adobe products; due to the public disclosure (defined) of CVE-2019-7089 as a zero day (defined) vulnerability, please install the Adobe Acrobat and Reader updates first followed by Flash Player and the remaining updates. I provide more detail on the zero day vulnerability in a separate post.

As we are accustomed to Microsoft’s updates come with a long list of Known Issues that will be resolved in future updates or for which workarounds are provided. They are listed below for your reference:

4345836
4471391
4471392
4483452
4486996
4487017
4487020
4487026
4487044
4487052

You can monitor the availability of security updates for most your software from the following websites (among others) or use one of the utilities presented on this page:

====================
US Computer Emergency Readiness Team (CERT) (please see the “Information on Security Updates” heading of the “Protecting Your PC” page):

https://www.us-cert.gov/

A further useful source of update related information is the Calendar of Updates.

News/announcements of updates in the categories of General SoftwareSecurity Software and Utilities are available on their website. The news/announcements are very timely and (almost always) contain useful direct download links as well as the changes/improvements made by those updates (where possible).

If you like and use it, please also consider supporting that entirely volunteer run website by donating.

====================
For this month’s Microsoft updates, I will prioritize the order of installation below:
====================
Microsoft Edge and Internet Explorer (multiple versions of Edge and IE affected)

Microsoft GDI+

Scripting Engine (CVE-2019-0590 , CVE-2019-0591 , CVE-2019-0593 , CVE-2019-0640  ,
CVE-2019-0642
, CVE-2019-0648 , CVE-2019-0649  , CVE-2019-0651 , CVE-2019-0652 , CVE-2019-0655 , CVE-2019-0658)

Windows DHCP

Microsoft Exchange

Microsoft SharePoint and CVE-2019-0604

====================
Please install the remaining updates at your earliest convenience.

As usual; I would recommend backing up the data on any device for which you are installing updates to prevent data loss in the rare event that any update causes unexpected issues. I have provided further details of updates available for other commonly used applications below.

Thank you.

=======================
Nvidia Graphics Drivers:
=======================
8 security vulnerabilities with the most severe having a CVSS V3 (defined) base score of 8.8 have been resolved within Nvidia’s graphics card drivers (defined) in February. These vulnerabilities affect Linux FreeBSD, Solaris and Windows. The steps to install the drivers are detailed here (and here) for Ubuntu and here for Linux Mint. Windows install steps are located here. If you use affected Nvidia graphics card, please consider updating your drivers to the most recent available.

=======================
7-Zip:
=======================
In the 3rd week of February; 7-Zip version 19.00 was released. While it is not designated as a security update; the changes it contains appear to be security related. While 7-Zip is extremely popular as a standalone application; other software such as Malwarebytes Anti-Malware, VMware Workstation and Directory Opus (among many others) all make use of 7-Zip. Directory Opus version 12.2.2 Beta includes version 19.00 of the 7-Zip DLL.

If you use these software applications or 7-Zip by itself, please update these installed applications to benefit from these improvements.

=======================
Changes:
=======================
– Encryption strength for 7z archives was increased:
the size of random initialization vector was increased from 64-bit to 128-bit, and the pseudo-random number generator was improved.
– Some bugs were fixed.
=======================

If you are using the standalone version and it’s older than version 19, please consider updating it.

=======================
Mozilla Firefox
=======================
In mid-February Mozilla issued updates for Firefox 65 and Firefox ESR (Extended Support Release) 60.5:

Firefox 65.0.1: Resolves 3x high CVEs (defined)

Firefox 60.5.1: Resolves 3x high CVEs

As always; details of how to install updates for Firefox are here. If Firefox is your web browser of choice, if you have not already done so, please update it as soon as possible to benefit from changes such as improvements to Netflix playback, color management on Apple macOS and resolving audio/video delays during WebRTC calls etc.

=======================
Wireshark 3.0.0, 2.6.7 and 2.4.13
=======================
v3.0.0: 0 security advisories (new features and benefits discussed here and here)

v2.6.7: 3 security advisories

v2.4.13: 3 security advisories

As per standard process Linux distributions can obtain this update using the operating systems standard package manager (if the latest version is not installed automatically using the package manager you can instead compile the source code (v3.0.0, v2.6.6 or v2.4.12). This forum thread and this forum thread may also be helpful to you with installing Wireshark on your Linux based system.

For Mac OS X and Windows, the update is available within the downloads section of the Wireshark website. In addition, a detailed FAQ for Wireshark is available here.

Note: from this post onwards, I will only report on the most recent (v3.0) and previous branches (v2.6) of Wireshark.

Thank you.

Adobe Reader Vulnerability Disclosed

====================
Updated: 26th February 2019
====================
After the update was issued by Adobe; the original researcher who disclosed it found a bypass and again reported it to Adobe. The bypass was assigned another CVE number; CVE-2019-7815

It has now been addressed by a further update made available by Adobe last Thursday. If you use Adobe Acrobat or Reader, please ensure it is up to date:

Thank you.

====================
Original Post
====================
Yesterday; the security firm 0patch released a micropatch for a vulnerability that was publicly disclosed (defined) in late January.

Why should this vulnerability be considered important?
The vulnerability allows for the extraction/disclosure of the NTLMv2 hashes (defined) associated with your Windows login account to be sent to an attacker when you open a specifically modified PDF document, The information is sent via the SMB protocol (defined) to the attacker essentially allowing the document “to phone home” to them.

Adobe Reader DC (2019.010.20069 and earlier) are affected. This vulnerability is similar to a now patched vulnerability from last year namely; CVE-2018-4993, The new vulnerability is caused by the fact that while a user is warned via a dialog box when opening an XML style sheet via the HTTP protocol; when using the SMB protocol and while following a UNC (defined) link; no such warning appears.

How can you protect your organisation and yourself from this vulnerability?
Please apply the update made available by Adobe earlier today. If for any  reason you cannot update right now, please consider the micropatch from 0patch. A YouTube video of the micropatch in action is available from the following link:

The micropatch does not require a reboot. The patch does not need to be uninstalled once you later install the update from Adobe.

Thank you.

Security of Selected IoT Devices Tested

The current level of security present in Internet of Things (IoT)(defined) devices continues to be low and is in need of further maturity and consideration given to security and best practices.

A recent study carried out by researchers from Brazil’s Federal University of Pernambuco and the University of Michigan found that 31% of the apps (equating 37 out of 96 devices tested) used to control the IoT devices used no encryption while a further 19% used hard coded encryption keys (which can’t be changed). An attacker may be able to reverse engineer these.

The researcher then developed proof of concept attacks against five devices which are controlled by four apps:

Belkin’s WeMo for IoT
Broadlink’s e-Control app
TP-Link’s Kasa app
LIFX app used with that company’s Wi-Fi enabled light bulbs

From these 3 used no encryption while three apps communicated via broadcast messages that can provide an attacker a means of monitoring the nature/contents of the app to device communication. The researchers elaborated “A remote attacker simply has to find a way of getting the exploit either on the user’s smartphone in the form of an unprivileged app or a script on the local network”.

For the TP-Link Smart Plug which was reviewed more than 10k times on Amazon shares an encryption key across a given product line while the initial set up is performed using the app without strict authentication.

How to secure your IoT devices:
The researchers pointed out that Google’s Nest thermostat app was a better example of how security should be done. Its configuration can be carried out over TLS to the cloud or via Wi-Fi with WPA. This app also offers 2 factor authentication (defined) (albeit only via SMS messages which are themselves not best practice).

However, the Nest and any IoT rely on you to practice good security e.g. not re-using passwords for researching how best to secure that device. This story linked to is an example of what can happen if you don’t:

Further tips on securing IoT devices are listed provided below with a further tip of “Track and assess devices” from CSO Online. Devices such as Amazon Echo, Apple HomePod and Google Home require even more steps (final link below):

7 tips for securing the Internet of Things by Chester Wisniewski (Sophos Security)

8 tips to secure those IoT devices by Michelle Drolet (CSO Online)]

Securing the Internet of Things (US-CERT)

9 things to check after installing wireless access points by Eric Geier (Computerworld)

Securing Your Smart TV

Increasing the privacy and security of virtual assistants

Thank you.

Apple KeyChain Vulnerability Disclosed

Last week a security researcher publicly disclosed a vulnerability within Apple macOS’ Keychain (Apple’s password management system). The exact proof of concept code has not been released.

TL DR:  This vulnerability is currently unpatched by Apple. Be cautious of the links you click on, email attachments and applications you download/open. Keep your system current with already released updates. Watch for updates from Apple in the near future.

Why should this vulnerability be considered important?
This vulnerability affects all versions of Apple macOS up to the most recent 10.14.3 (Mojave). Apple Keychain is used to store passwords for application, websites and servers. This information is encrypted by default blocking access via other means without your permission.

However; the exploit allows an attacker to access this information from a standard user account (thus not requiring root (defined)(privileged) access) without generating a password prompt. The keychain must first be unlocked but it is when you are logged into the system. The System keychain which contains (among other items) is not affected. Thus, if the attacker can persuade you to run an application of their choice (e.g. substituting an app that looks like an app you regularly download manually); they could obtain your passwords/sensitive information. A YouTube video demonstrating the custom application designed to exploit this is provided below:

https://youtu.be/nYTBZ9iPqsU

How can I protect myself?
Please see the TL DR above. You should also consider manually locking your keychain or setting a keychain specific password (further details below).

===========

Lock your Keychain:
Open Keychain Access in the Applications: Utilities folder. Select your keychain (usually your user name) in the drawer (click on Show Keychains in the toolbar if it’s not visible). Then choose Edit: Change Settings For Keychain keychain name. Select Lock After 5 Minutes Of Inactivity (or lower according to your preference).

Password Protect Your Keychain:
Open the Keychain Access application, and select your keychain in the drawer. Select Edit: Change Password For Keychain keychain name, and then enter a new password.

With thanks to MacWorld:

===========

Why did the researcher not disclose this to Apple privately?
The researcher, Linus Henze chose not to privately disclose this to Apple since while Apple have a bug bounty for iOS which is by invite only; they don’t have such a program for macOS. The researcher wishes to highlight this omission. A quote from the researcher is included below (my thanks to Sergiu Gatlan of BleepingComputer.com) for this:

“Please note that even if it looks like I’m doing this just for the money, this is not my motivation at all in this case. My motivation is to get Apple to create a bug bounty program. I think that this is the best for both Apple and Researchers. I really love Apple products and I want to make them more secure. And the best way to make them more secure would be, in my opinion, if Apple creates a bug bounty program (like other big companies already have)”

Separately he is not the only researcher to be criticising Apple’s approach to vulnerability remediation. Ian Beer of Google Project Zero publicly criticised Apple last August for simply fixing vulnerabilities rather than thinking of them in an exploit context namely “Why is this bug here? How is it being used? How did we miss it earlier? What process problems need to be addressed so we could have found [the bug] earlier? Who had access to this code and reviewed it and why, for whatever reason, didn’t they report it?”

Thank you.

DNS Flag Day Aims to Make DDoS Attacks Harder

Since the 1st of February multiple major DNS (defined) resolvers removed resolver workarounds. The resolvers involved in the initiative include ISC, Cloudflare, Facebook, Cisco, Google (among others).

The workarounds were removed to stop DNS queries not compliant with the following official Requests for Comments (RFC) 1035 and 2671 from being completed(resolved). In more depth; the DNS Flag day page explains these workarounds are being removed due to:

==============
The current DNS is unnecessarily slow and inefficient because of efforts to accommodate a few DNS systems that are not in compliance with DNS standards established two decades ago.

To ensure further sustainability of the system it is time to end these accommodations and remediate the non-compliant systems. This change will make most DNS operations slightly more efficient, and also allow operators to deploy new functionality, including new mechanisms to protect against DDoS attacks.
==============

It appears that DNS amplification and DNS flood attacks are the threats attempting to be mitigated with these changes. A full list of the types of DDoS (defined) attacks is available from the following Cloudflare page (at the end of that page):

It will be interesting to see the effect of these changes on the DNS infrastructure when it is again targeted by botnets (defined) (e.g. made up of Internet of Things (IoT)(defined) or compromised systems or by other means. Such botnets can make use a command and control (C2) (defined) infrastructure.

Thank you.