Month: March 2020

COVID-19 and SPYMax on Android APPs

    Cyber criminals are taking full
advantage of the COVID-19 pandemic and increased
communications surrounding it by installing spyware via apps to end-users’
mobile devices. The spyware being utilized is a commercial version called SpyMax, which can be acquired by anyone
with an internet connection and a credit
card.

    Kristin Del Rosso, a researcher with mobile cybersecurity firm Lookout,
has associated the malware with over 30 rogue Android applications to date.
The re- searchers have not yet
associated the various corrupt apps with any
nationstate backed
actors but do note that the “use of these commercial surveillance- ware
families has been observed in the past as part of the tooling used by nationstates in the Middle East.”

    One of the
latest apps taking advantage of the COVID-19 crisis is titled “corona live 1.1”
which is a trojanized version of the legitimate “corona live” application that provides
an interface to the data at the Johns Hopkins
Corona Virus tracker such as infection rates and deaths
caused by the virus. Under the hood, the malicious app is utilizing the
commercial SpyMax application which
has typical spyware capabilities. The SpyMax
tool is capable of accessing files, call logs, SMS messages, contact lists,
location tracking, opening up a shell for the execution of further commands,
listening through the microphone, and watching through the camera.

    Researchers at
Lookout tracked down the command and control server for the app and pivoted
from there to find 30 other unique apps that all share the same infrastructure,
suggesting a much larger surveillance campaign has been in progress for some
time. The command and control domain appears to be hosted through the dynamic
DNS provider No-IP and resolves several different addresses within the same
range. The address space is operated by the Libyan Telecom and Technology
internet service provider. The researchers at Lookout also noted that these
apps were never available from the Google Playstore and that most instances are
being downloaded from third-party sites.

    Kristin Del Rosso also noted,
“This surveillance campaign highlights how in times of crisis, our innate need
to seek out information can be used against us for malicious ends. Furthermore,
the commercialization of ‘off-the-shelf’ spyware kits makes it fairly easy for
these malicious actors to spin up these bespoke campaigns almost as quickly
as a crisis like COVID-19 takes hold.”

Sources:

       
https://blog.lookout.com/commercial-surveillanceware-operators-latest-to-take-advantage-of-covid-19
 

Warning About Coronavirus themed health advisories

    Threat actors are currently spreading malicious
Coronavirus themed health advisories via email which, when opened, deploy a
Remote Administration Tool (RAT) onto the systems of targets. This phishing
campaign has been traced back to APT36, a Pakistan-based group notable for
targeting Indian defense and government entities. Researchers at Malwarebytes
Labs’ Threat Intelligence Team note that the emails attempt to impersonate
Indian government officials and target residents of India. Once the payload is on the
target’s system, the threat actors have full control of that machine. However,
this is not the only group attempting to exploit COVID-19 to infect potential
targets.

    Researchers
have observed nation-state actors from China, North Korea, and Russia attempting to exploit the coronavirus to spread their malware. In February, Russian hackers carried out a phishing campaign in which they hid a backdoor trojan in a document containing news on COVID-19. They then sent these
malicious documents to Ukrainian officials, claiming to be from the Ukraine
Center for Public Health. Toward the end of February, researchers have ob-
served North Korea using similar tactics to other nation states. Researchers
found that a group of North Korean hackers was sending South Korean officials
malware-infested documents disguised as COVID-19 response information. Re-
searchers also found that Chinese hackers were targeting both the Vietnamese and
Mongolian governments using malicious attachments. However, not all COVID-19
themed attacks are happening outside of the United States. Researchers at
Cofense discovered a phishing campaign targeting U.S. citizens, which claimed
to be an email from the Center for Disease Control. 
    The email differs from the attacks previously mentioned in that it
does not contain a document attached to it. Instead, the email tells the
recipient that a high-risk person is being monitored in their city. The email
then provides a fake link to the CDC’s website with more information. The user
is redirected to a fake Microsoft login page where, if entered, the user’s
credentials are harvested.
    Staying safe during this time not only includes
practicing proper hygiene and social distancing measures but employing proper
cybersecurity awareness. Epidemics and natural disasters are, unfortunately,
frequently capitalized on by bad actors. When people are desperate for news, an
email claiming to be from your government’s health department can be quite
convincing. As always, be wary of unsolicited emails containing documents and
links. When in doubt of an email’s authenticity, it is best to exercise caution
and not to click links or download documents contained within the email.

Sources:

·  https://www.bleepingcomputer.com/news/security/nation-backed-hackers-spread-crimson-rat-via-coronavirus-phishing/

 
https://cofense.com/threat-actors-capitalize-global-concern-coronavirus-new-phishing-campaigns/

 

Cryptographic Key Generation: NIST Releases Draft SP 800-133 Rev. 2 for Comment

NIST requests your comments on Draft Special Publication (SP) 800-133 Revision 2, Recommendation for
Cryptographic Key Generation, which discusses the
generation of the keys to be managed and used by
the approved cryptographic algorithms. This revision provides a
method for determining a symmetric key by combining multiple keys and other
data.

The public comment period closes on April 17, 2020. See the publication details for a copy of the
draft and instructions for submitting comments.
NOTE: A call for patent claims is included
on page iii of this draft. For additional information, see the Information Technology Laboratory (ITL) Patent
Policy–Inclusion of Patents in ITL Publications.

Defending Against COVID-19 Cyber Scams

The Cybersecurity and Infrastructure Security Agency (CISA) warns
individuals to remain vigilant for scams related to Coronavirus Disease 2019
(COVID-19). Cyber actors may send emails with malicious attachments or links to
fraudulent websites to trick victims into revealing sensitive information or
donating to fraudulent charities or causes. Exercise caution in handling any
email with a COVID-19-related subject line, attachment, or hyperlink, and be
wary of social media pleas, texts, or calls related to COVID-19.

CISA encourages individuals to remain vigilant and take the following
precautions.

Discovery of Cloud Snooper this week

    Cloud security is as important as ever as more and more services are moved to the cloud. Unfortunately misconfigured servers still exist, regardless of where they are located. A simple Google search (no Shodan required) is all it takes to find unsecured S3 buckets, which can be treasure troves of information. Let’s be real though, that type of find is low-hanging fruit that any script kiddie or automated tool can find. There’s something far more sophisticated lurking in the cloud and there’s a good chance a nation state is behind it.

    Researchers over at SophosLabs announced the discovery of Cloud Snooper this week. They were looking into infected cloud servers hosted by Amazon Web Services (AWS) when they noticed unusual traffic on a Linux server. The security groups (SGs), which are firewall rules designed to limit traffic to the server, were properly configured. But a rootkit and a backdoor were found on the system that allowed the adversary to bypass the firewall altogether.

    It all works by piggybacking malicious packets on legitimate traffic allowed by the SGs. The attacker sends these “disguised” requests to the rootkit, where they are intercepted. The malware sends the command to the backdoor. The outbound traffic is then obfuscated in the same way, giving the adversary the ability to siphon data and execute commands. The researchers noted that because
of this technique “the C2 traffic stays largely indistinguishable from the legitimate web traffic.”

    Linux servers aren’t the only ones vulnerable to Cloud Snooper – there’s also a Windows version based on the notorious Gh0st RAT. What’s worse is that it isn’t limited to cloud services either. The researchers pointed out that the technique could potentially bypass nearly any firewall. Security best practices will help to mitigate the threat, which includes keeping all security services and patches up to date, proper configuration management, and two-factor authentication.

Sources:

Wifi attack called Kr00k, which affects millions of devices

    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/

Revoking Over 3 Million Digital Certificates Due To Bug

    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/

Vulnerability Affects Tomcat Versions for Over a Decade

     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/