Year: 2020

    Wireless network security has come a long way since the days of easily breakable Wired Equivalent Privacy (WEP). WiFi Protected Access (WPA) 2 has been the most commonly used standard since it was released in 2004 and has had very few vulnerabilities since the original release.

    This week however researchers from ESET released the details of a new attack called Kr00k, which affects millions of devices all over the world. This vulnerability can allow an attacker to read data between the device and access point as if there was no encryption at all.

    As detailed in a previous blog, device manufacturers rarely implement common standards like Bluetooth of WiFi into their products from scratch. They instead purchase and integrate one of
the many off the shelf solutions provided by Broadcom or others, tweaking for their specific use case.

    The two most popular chipsets for WiFi come from Broadcom and Cypress, both of which are vulnerable to the Kr00k attack. These chipsets are used in millions of devices including smartphones, laptops, IoT devices, etc. This means that the attacks spans nearly every manufacturer of electronics
that uses WiFi in their products.

    The attack itself is based on a bug in the access point disassociation logic. Disassociations happen via special control frames in a WiFi connection and happen all the time legitimately, whether from low signal or an intentional disconnect from an access point. When a disassociation request happens the vulnerable chipsets reset the transmit buffer with an encryption key of all zeros. This buffer is then finalized by being transmitted out using the all zero encryption key which makes it vulnerable to sniffing by a 3rd party. The transmit buffer is relatively small at only 32 kilobytes but using the attack sequentially via a script makes it possible to leak larger pieces of data given enough time. The same attack can also be used on the access point itself and is not limited to attacking a single client only.

    By using the attack on a vulnerable access point it would be possible to eavesdrop on any client connected to the wireless net-work, whether it has already been patched or not.

    After ESET researchers found the bug they responsibly disclosed it to the chipset makers and began a 120-day countdown for public disclosure. This gave manufacturers plenty of time to create a patch and start rolling it out to vulnerable devices. To make sure that your network is not vulnerable each device utilizing WiFi should be checked to make sure it is patched and up to date. It would also be wise to utilize VPN software when on untrusted networks as it may not be possible to verify that the access point is not vulnerable.

Sources:

• https://threatpost.com/billions-of-devices-wifi-encryption-hack/153267/

• https://www.zdnet.com/article/new-kr00k-vulnerability-lets-attackers-decrypt-wifi-packets/

    The popular free Certificate Authority (CA), Let’s Encrypt, will be revoking mil-lions of certificates that enable Transport Layer Security (TLS), the subsequent protection of data between machines, and the positive identification of services for their customers. Digital certificates bind a public cryptographic key to a name. It binds it to a domain name in the case of web traffic utilizing the HTTPS protocol. This binding happens when a CA, also known as an issuer, certifies that the entity claiming ownership over the domain has control over the do-main in question.

    The CA announced this revocation just 24 hours prior and sent notifications out to the users affected informing them that on Wednesday 03/04/20 the digital certificates would be revoked. Let’s Encrypt explained in its announcement that the revocation was due to an error in its domain validation checking software.

    Let’s Encrypt is a free certificate issuance organization that has become wildly popular and accepted for issuing certificates. It can do this because it auto-mates and simplifies the issuance and renewal process for certificates. The automation code used by Let’s Encrypt to validate a domain is essential to the integrity of certificates that it issues. Unfortunately, a bug in this code was dis-covered, casting doubt on the legitimacy of millions of TLS certificates. Let’s Encrypt claims to secure 190 million websites. This bug affects 3 million certificates which, according to Let’s Encrypt, equates to around 12 million server names.

    The bug was found in Certificate Authority Authorization (CAA) code which checks for CAA records at the same time it validates a subscriber’s control of a domain name. A problem in the CAA domain validation code allowed subscribers to submit N domains for validation and the CAA software, instead of validating each domain, would pick one domain and validate it N times. The bug could have potentially been exploited and looks like it has been exploited numerous times as Let’s Encrypt began analyzing the highest priority certificates and immediately revoked 445 certificates that had forbidden CAA records.

    The issue for those using a revoked certificate, particularly businesses, is that users will see security warnings claiming that the site is not valid which could lead to lost sales and a damaged reputation. You can check for affected sites by downloading the list Let’s Encrypt provides on their website showing the affected domains.

Sources:

• https://threatpost.com/lets-encrypt-revoke-millions-tls-certs/153413/

• https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591/3

• https://nakedsecurity.sophos.com/2020/03/04/why-3-million-lets-encrypt-certificates-are-being-killed-off-today/

     Apache Tomcat has been a popular Java servlet hosting application for over 20 years. It is used to host hundreds of thousands of websites and web applications. However, a high–risk vulnerability has recently been discovered that has remained unnoticed for 13 years.


    Researchers at Chaitin Tech, a Chinese cybersecurity firm, discovered the vulnerability and dubbed it GhostCat. The vulnerability lies in a flaw with the Tomcat Apache JServ Protocol (AJP). This protocol is similar to HTTP but runs on port 8009 and is used to communicate with Apache HTTPD web servers or oth-er Tomcat instances. Until recently, the AJP connector was enabled by default on all Tomcat servers and bound to IP address 0.0.0.0.


    This AJP flaw can be used to read and write files to a Tomcat server that the user shouldn’t be able to do. This could lead to an attacker stealing configuration files, passwords, or putting scripts on the server for backdoor access. If the web server allows file uploads, it could also be abused to allow remote code execution. There are already multiple proof–of–concept code examples on GitHub that have popped up since the vulnerability was made public, so it is likely that attacks are already happening in the wild.


    The GhostCat vulnerability was found in versions all the way back to Tomcat version 6.x, which was released in February of 2007. All version since then, in-cluding 7.x, 8.x, and 9.x are also affected. Chaitin researchers found the bug in early January of this year and properly informed Apache to develop patches before releasing the vulnerability information to the public. Apache has re-leased patches for supported branches (7.0.100, 8.5.51, and 9.0.31) but Tomcat 6.x was end–of–life back in 2016 and has not been updated. Chaitin also updated their XRAY network scanning tool to help identify vulnerable Tomcat servers.


    There is also a mitigation for GhostCat if updating the server is not possible for some reason. The AJP connector can be disabled in the server configuration if it is not needed at all, or the listening address and/or port can be modified as well. It is highly encouraged that all server owners upgrade to the latest version as soon as possible.

 Sources

 • https://thehackernews.com/2020/02/ghostcat–new–high–risk–vulnerability.html#comment–box

• https://lists.apache.org/thread.html/ r7c6f492fbd39af34a68681dbbba0468490ff1a97a1bd79c6a53610ef%40% 3Cannounce.tomcat.apache.org%3E




• https://www.zdnet.com/article/ghostcat–bug–impacts–all–apache–tomcat–versions–released–in–the–last–13–years/

For you security professions this is a great site to get guidance and software.

 The
software listed here developed within the National Security Agency
and is available to the public for use. I encourage you to check it
out!

I would also tell you to check out  this site as well code.gov

    The National Security Agency released the source code of Ghidra, its reverse engineering tool.

    This source code repository includes instructions to build on all
supported platforms (macOS, Linux, and Windows). With this release,
developers will be able to collaborate by creating patches, and
extending the tool to fit their cybersecurity needs.

    The source code is available for download at ghidra-sre.org along with the 9.1.1 patch.
Ghidra is a software reverse engineering (SRE) framework developed by NSA’s Research Directorate for NSA’s cybersecurity mission.
It helps analyze malicious code and malware like viruses, and can give
cybersecurity professionals a better understanding of potential
vulnerabilities in their networks and systems.

   For more NSA releases, check out CODE.NSA.GOV for open source, and NSA’s Technology Transfer Program for other technology.

SmokeLoader Malware Found Spreading via Fake
Meltdown/Spectre Patches


New KillDisk Variant Hits Financial Organizations in
Latin America


GhostTeam Adware Can Steal Facebook Credentials


‘Hacking Incident’ Impacts Nearly 280,000 Medicaid
Patients


Hackers Hijack DNS Server of BlackWallet to Steal
$400,000


U.S. Cyber Command Operation Disrupted Internet
Access of Russian Troll Factory on Day of 2018 
Midterms

UPnP-enabled Connected Devices in the Home and
Unpatched Known Vulnerabilities

    We expect services to protect themselves from fraudulent activity. Automated
services tend to be particularly tempting to unscrupulous individuals that seem to think that they can pull one over
on an unmanned operation. So it makes plenty of sense
for Google AdSense to be constantly vigilant for any bot activity trying to
extract artificial ad views to collect on the bounty of ad revenue. But what if
our fences become cages?

    Security
researcher Brian Krebs details a new extortion scheme that recently targeted
one of his readers involving a Denial of Service attack on the victim’s source
of ad revenue, Google AdSense. The attacker threatens the victim with the loss of
revenue by flooding the victim’s website with traffic that is indicative of
fraudulent activity. It seems obvious how a criminal mind would use fraudu-

Sources:

Sources

    Emotet banking Trojan has been around since 2014 as banking malware. As the software was changed, the developers added additional spamming and malware delivery services found in other
banking malware. Key to Emotet is how it incorporates functionality allowing the software to evade detection by antimalware products.

    Emotet also uses  Worm-like capabilities to help spread to other connected computers. Because of
this, the Department of Homeland Security (DHS) concludes that Emotet malware is one of the most costly and destructive pieces of malware out there. Emotet spreads on a connected network using a list of common passwords in a brute-force attack. The primary off network propagation mechanism used by Emotet is spam laced with malware. By 2018 newer versions included stealth, new targets, and the ability to install other malware such as ransomware onto infected machines. This was the cause of the July 2019 Lake City, Florida ransomware attack.

    Malwarebytes Labs reported a botnet-driven spam campaign in September of 2019 where opening the infected attached Microsoft Word document initiates a macro which downloaded Emotet. A key functionality to Emotet is the ability to deliver custom modules or plugins suited for specific tasks such as stealing Outlook contacts or spreading over a LAN.

    Binary Defense has identified a new functionality that uses the wlanAPI interface to enumerate all Wifi networks in the area, and then attempts to spread to these networks and infect all devices that
it can access. With this new propagation method, if a nearby Wi-Fi-capable host is infected, it can attack another Wifi using the same brute-force weak password attacks used on a local network. Zdnet summarized the Wifi spreader’s modus operandi nicely as follows: Once a host is infected Emotet downloads and runs the Wi-Fi spreader module. The Wi-Fi spread-er module lists all Wi-Fi devices enabled on the host and extracts a list of all the locally reachable Wi-Fi networks. The module then performs a brute-force attack on each Wi-Fi network by using two internal lists of easy-to-guess passwords. If the brute-force attack succeeds, the Emotet Wifi spreader now has direct access to another network and moves into a second brute-force attack attempting to guess the usernames and passwords of servers and computers connected to this Wifi network much like a connected network attack. If this second brute-force attack succeeds, Emotet begins its infection cycle again widening its reach.

    The Cybersecurity and Infrastructure Security Agency (CISA) has issued a warning on the increased activity related to targeted Emotet attacks roughly two weeks ago, advising admins and users to review the Emotet Malware alert for guidance. Fortunately, all it takes to stop the malware’s spread is having effective passwords on your infrastructure, hosts, and accounts. Emotet will thrive on users who don’t use such good passwords, or who never changed the factory-default access pass-words when they set up their routers.

Sources:

• https://www.binarydefense.com/emotet-evolves-with-new-wi-fi-spreader/

• https://www.zdnet.com/article/emotet-trojan-evolves-to-spread-via-a-wifi-connection/

• https://www.tomsguide.com/news/emotet-wifi-worm

    Bluetooth technology seems to be nearly everywhere now. It is an extremely convenient method to make all sorts of different devices speak the same language and perform greater functions. As we already know though, when computing devices can communicate trouble soon follows in one form or another. This week the details of 12 different security vulnerabilities, collectively called SweynTooth, targeting Bluetooth low energy devices became public. 11 of the 12 vulnerabilities are just denial of service vulnerabilities. The twelfth however allows a complete security bypass on affected devices.

    The group releasing the vulnerabilities is comprised of 3 researchers from the Singapore University of Technology and Design, Matheus E. Garbelini, Sudipta Chattopadhyay, and Chundong Wang.
Most devices that implement Bluetooth connectivity do not implement it from the ground up. They instead rely on a specialized system on a chip (SoC) from a larger manufacturer to handle the inner Bluetooth workings and interface with it via a software development kit (SDK). The SDK can allow them to configure specific parameters for connectivity as well as receiving/sending information over the link. Due to most devices sharing SoCs with other devices it is no surprise that a vulnerability in a specific SoC may affect hundreds or thousands of otherwise unrelated devices.

    The vulnerabilities released this week affect SoCs from Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics, and Telink Semiconductor. The devices using these SoCs range from smart watches, smart locks, and even medical devices.

    As stated the majority of these vulnerabilities are able to trigger denial of service. They trigger a denial of service by sending specially crafted packets to the target device to put it into a deadlocked state where it can no longer process incoming or outgoing data.

    To make the device functional again a reboot is required. Most of these attacks require only 1 or 2 packets to be transmitted to exploit successfully. The most dangerous vulnerability of the set is CVE-2019-19194, which can allow an attacker to completely bypass secure communication protections. An attacker using this vulnerability may be able to access functions on the affected device as if they were an authorized user. This could lead to information leakage or even code execution in certain cases.

    This specific vulnerability only appears to affect the Telink SMP family of SoCs.
Before releasing the vulnerability details to the public the researchers followed responsible disclosure guidelines and notified the affected vendors. After 90 days the research went public, with 6 of the 12 vulnerabilities still without patches. When updates become available affected devices should be upgraded to prevent these attacks.

Sources:

• https://www.theregister.co.uk/2020/02/13/dozen_bluetooth_bugs/

• https://www.bleepingcomputer.com/news/security/sweyntooth-bug-collection-affects-hundreds-of-bluetooth-products/