Multiple Vulnerabilities in Google Chrome Could Allow for Arbitrary Code Execution

Read Time:28 Second

Multiple vulnerabilities have been discovered in Google Chrome, the most severe of which could allow for arbitrary code execution. Successful exploitation of the most severe of these vulnerabilities could allow for arbitrary code execution in the context of the logged on user. Depending on the privileges associated with the user an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.

Read More

USN-6910-1: Apache ActiveMQ vulnerabilities

Read Time:1 Minute, 6 Second

Chess Hazlett discovered that Apache ActiveMQ incorrectly handled certain
commands. A remote attacker could possibly use this issue to terminate
the program, resulting in a denial of service. This issue only affected
Ubuntu 16.04 LTS. (CVE-2015-7559)

Peter Stöckli discovered that Apache ActiveMQ incorrectly handled
hostname verification. A remote attacker could possibly use this issue
to perform a person-in-the-middle attack. This issue only affected Ubuntu
16.04 LTS. (CVE-2018-11775)

Jonathan Gallimore and Colm Ó hÉigeartaigh discovered that Apache
ActiveMQ incorrectly handled authentication in certain functions.
A remote attacker could possibly use this issue to perform a
person-in-the-middle attack. This issue only affected Ubuntu 16.04 LTS,
Ubuntu 18.04 LTS and Ubuntu 20.04 LTS. (CVE-2020-13920)

Gregor Tudan discovered that Apache ActiveMQ incorrectly handled
LDAP authentication. A remote attacker could possibly use this issue
to acquire unauthenticated access. This issue only affected Ubuntu 16.04
LTS, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS. (CVE-2021-26117)

It was discovered that Apache ActiveMQ incorrectly handled
authentication. A remote attacker could possibly use this issue to run
arbitrary code. (CVE-2022-41678)

It was discovered that Apache ActiveMQ incorrectly handled
deserialization. A remote attacker could possibly use this issue to run
arbitrary shell commands. (CVE-2023-46604)

Read More

Phish-Friendly Domain Registry “.top” Put on Notice

Read Time:5 Minute, 32 Second

The Chinese company in charge of handing out domain names ending in “.top” has been given until mid-August 2024 to show that it has put in place systems for managing phishing reports and suspending abusive domains, or else forfeit its license to sell domains. The warning comes amid the release of new findings that .top was the most common suffix in phishing websites over the past year, second only to domains ending in “.com.”

Image: Shutterstock.

On July 16, the Internet Corporation for Assigned Names and Numbers (ICANN) sent a letter to the owners of the .top domain registry. ICANN has filed hundreds of enforcement actions against domain registrars over the years, but this is thought to be the first in which ICANN has singled out a domain registry responsible for maintaining an entire top-level domain (TLD).

Among other reasons, the missive chided the registry for failing to respond to reports about phishing attacks involving .top domains.

“Based on the information and records gathered through several weeks, it was determined that .TOP Registry does not have a process in place to promptly, comprehensively, and reasonably investigate and act on reports of DNS Abuse,” the ICANN letter reads (PDF).

ICANN’s warning redacted the name of the recipient, but records show the .top registry is operated by a Chinese entity called Jiangsu Bangning Science & Technology Co. Ltd. Representatives for the company have not responded to requests for comment.

Domains ending in .top were represented prominently in a new phishing report released today by the Interisle Consulting Group, which sources phishing data from several places, including the Anti-Phishing Working Group (APWG), OpenPhish, PhishTank, and Spamhaus.

Interisle’s newest study examined nearly two million phishing attacks in the last year, and found that phishing sites accounted for more than four percent of all new .top domains between May 2023 and April 2024. Interisle said .top has roughly 2.76 million domains in its stable, and that more than 117,000 of those were phishing sites in the past year.

Source: Interisle Consulting Group.

ICANN said its review was based on information collected and studied about .top domains over the past few weeks. But the fact that high volumes of phishing sites are being registered through Jiangsu Bangning Science & Technology Co Ltd. is hardly a new trend.

For example, more than 10 years ago the same Chinese registrar was the fourth most common source of phishing websites, as tracked by the APWG. Bear in mind that the APWG report excerpted below was published more than a year before Jiangsu Bangning received ICANN approval to introduce and administer the new .top registry.

Source: APWG phishing report from 2013, two years before .top came into being.

A fascinating new wrinkle in the phishing landscape is the growth in scam pages hosted via the InterPlanetary File System (IPFS), a decentralized data storage and delivery network that is based on peer-to-peer networking. According to Interisle, the use of IPFS to host and launch phishing attacks — which can make phishing sites more difficult to take down — increased a staggering 1,300 percent, to roughly 19,000 phishing sites reported in the last year.

Last year’s report from Interisle found that domain names ending in “.us” — the top-level domain for the United States — were among the most prevalent in phishing scams. While .us domains are not even on the Top 20 list of this year’s study, “.com” maintained its perennial #1 spot as the largest source of phishing domains overall.

A year ago, the phishiest domain registrar by far was Freenom, a now-defunct registrar that handed out free domains in several country-code TLDs, including .tk, .ml, .ga and .cf. Freenom went out of business after being sued by Meta, which alleged Freenom ignored abuse complaints while monetizing traffic to abusive domains.

Following Freenom’s demise, phishers quickly migrated to other new low-cost TLDs and to services that allow anonymous, free domain registrations — particularly subdomain services. For example, Interisle found phishing attacks involving websites created on Google’s blogspot.com skyrocketed last year more than 230 percent. Other subdomain services that saw a substantial growth in domains registered by phishers include weebly.com, github.io, wix.com, and ChangeIP, the report notes.

Source: Interisle Consulting.

Interisle Consulting partner Dave Piscitello said ICANN could easily send similar warning letters to at least a half-dozen other top-level domain registries, noting that spammers and phishers tend to cycle through the same TLDs periodically — including .xyz, .info, .support and .lol, all of which saw considerably more business from phishers after Freenom’s implosion.

Piscitello said domain registrars and registries could significantly reduce the number of phishing sites registered through their services just by flagging customers who try to register huge volumes of domains at once. Their study found that at least 27% of the domains used for phishing were registered in bulk — i.e. the same registrant paid for hundreds or thousands of domains in quick succession.

The report includes a case study in which a phisher this year registered 17,562 domains over the course of an eight-hour period — roughly 38 domains per minute — using .lol domains that were all composed of random letters.

ICANN tries to resolve contract disputes privately with the registry and registrar community, and experts say the nonprofit organization usually only publishes enforcement letters when the recipient is ignoring its private notices. Indeed, ICANN’s letter notes Jiangsu Bangning didn’t even open its emailed notifications. It also cited the registry for falling behind in its ICANN membership fees.

With that in mind, a review of ICANN’s public enforcement activity suggests two trends: One is that there have been far fewer public compliance and enforcement actions in recent years — even as the number of new TLDs has expanded dramatically.

The second is that in a majority of cases, the failure of a registry or registrar to pay its annual ICANN membership fees was cited as a reason for a warning letter. A review of nearly two dozen enforcement letters ICANN has sent to domain registrars since 2022 shows that failure to pay dues was cited as a reason (or the reason) for the violation at least 75 percent of the time.

Piscitello, a former ICANN board member, said nearly all breach notices sent out while he was at ICANN were because the registrar owed money.

“I think the rest is just lipstick to suggest that ICANN’s on top of DNS Abuse,” Piscitello said.

KrebsOnSecurity has sought comment from ICANN and will update this story if they respond.

Read More

USN-6530-2: HAProxy vulnerability

Read Time:11 Second

Seth Manesse and Paul Plasil discovered that HAProxy incorrectly handled
URI components containing the hash character (#). A remote attacker could
possibly use this issue to obtain sensitive information, or to bypass
certain path_end rules.

Read More

USN-6907-1: Squid vulnerability

Read Time:12 Second

Joshua Rogers discovered that Squid did not properly handle multi-byte
characters during Edge Side Includes (ESI) processing. A remote attacker
could possibly use this issue to cause a memory corruption error, leading
to a denial of service.

Read More

USN-6909-1: Bind vulnerabilities

Read Time:1 Minute, 3 Second

It was discovered that Bind incorrectly handled a flood of DNS messages
over TCP. A remote attacker could possibly use this issue to cause Bind to
become unstable, resulting in a denial of service. (CVE-2024-0760)

Toshifumi Sakaguchi discovered that Bind incorrectly handled having a very
large number of RRs existing at the same time. A remote attacker could
possibly use this issue to cause Bind to consume resources, leading to a
denial of service. (CVE-2024-1737)

It was discovered that Bind incorrectly handled a large number of SIG(0)
signed requests. A remote attacker could possibly use this issue to cause
Bind to consume resources, leading to a denial of service. (CVE-2024-1975)

Daniel Stränger discovered that Bind incorrectly handled serving both
stable cache data and authoritative zone content. A remote attacker could
possibly use this issue to cause Bind to crash, resulting in a denial of
service. (CVE-2024-4076)

On Ubuntu 20.04 LTS, Bind has been updated from 9.16 to 9.18. In addition
to security fixes, the updated packages contain bug fixes, new features,
and possibly incompatible changes.

Please see the following for more information:

https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-bind-916-to-918

Read More