Top risks and best practices for securely offboarding employees

Read Time:37 Second

Employees won’t work for the same organization forever and dealing with their departures is just part and parcel of business. But the security risks posed by departing staff can be significant. Without secure off-boarding processes, organizations expose themselves to a variety of cybersecurity risks ranging from the innocuously accidental to the maliciously deliberate.

High turnover rates and layoffs only add to the offboarding security pressures, with potentially large numbers of employees exiting organizations, sometimes at short notice. CISOs, security teams, and relevant businesses functions should regularly review their offboarding processes to pinpoint potential risks and vulnerabilities, addressing key factors to ensure offboarding strategies remain secure amid evolving cyberthreats and workforce patterns.

To read this article in full, please click here

Read More

USN-6026-1: Vim vulnerabilities

Read Time:4 Minute, 7 Second

It was discovered that Vim was incorrectly processing Vim buffers. An
attacker could possibly use this issue to perform illegal memory access and
expose sensitive information. This issue only affected Ubuntu 20.04 LTS.
(CVE-2021-4166)

It was discovered that Vim was using freed memory when dealing with regular
expressions inside a visual selection. If a user were tricked into opening a
specially crafted file, an attacker could crash the application, leading to a
denial of service, or possibly achieve code execution with user privileges.
This issue only affected Ubuntu 14.04 ESM, Ubuntu 18.04 LTS and Ubuntu
20.04 LTS. (CVE-2021-4192)

It was discovered that Vim was incorrectly handling virtual column position
operations, which could result in an out-of-bounds read. An attacker could
possibly use this issue to expose sensitive information. This issue only
affected Ubuntu 14.04 ESM, Ubuntu 18.04 LTS and Ubuntu 20.04 LTS.
(CVE-2021-4193)

It was discovered that Vim was not properly performing bounds checks when
updating windows present on a screen, which could result in a heap buffer
overflow. An attacker could possibly use this issue to cause a denial of
service or execute arbitrary code. (CVE-2022-0213)

It was discovered that Vim was incorrectly performing read and write
operations when in visual block mode, going beyond the end of a line and
causing a heap buffer overflow. If a user were tricked into opening a
specially crafted file, an attacker could crash the application, leading to a
denial of service, or possibly achieve code execution with user privileges.
This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS and Ubuntu
22.04 LTS. (CVE-2022-0261, CVE-2022-0318)

It was discovered that Vim was incorrectly handling window exchanging
operations when in Visual mode, which could result in an out-of-bounds read.
An attacker could possibly use this issue to expose sensitive information.
(CVE-2022-0319)

It was discovered that Vim was incorrectly handling recursion when parsing
conditional expressions. An attacker could possibly use this issue to cause
a denial of service or execute arbitrary code. (CVE-2022-0351)

It was discovered that Vim was not properly handling memory allocation when
processing data in Ex mode, which could result in a heap buffer overflow.
An attacker could possibly use this issue to cause a denial of service or
execute arbitrary code. (CVE-2022-0359)

It was discovered that Vim was not properly performing bounds checks when
executing line operations in Visual mode, which could result in a heap
buffer overflow. An attacker could possibly use this issue to cause a
denial of service or execute arbitrary code. This issue only affected
Ubuntu 18.04 LTS, Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. (CVE-2022-0361,
CVE-2022-0368)

It was discovered that Vim was not properly handling loop conditions when
looking for spell suggestions, which could result in a stack buffer
overflow. An attacker could possibly use this issue to cause a denial of
service or execute arbitrary code. (CVE-2022-0408)

It was discovered that Vim was incorrectly handling memory access when
executing buffer operations, which could result in the usage of freed
memory. An attacker could possibly use this issue to execute arbitrary
code. (CVE-2022-0443)

It was discovered that Vim was incorrectly processing Vim buffers. An
attacker could possibly use this issue to perform illegal memory access and
expose sensitive information. (CVE-2022-0554)

It was discovered that Vim was not properly performing bounds checks for
column numbers when replacing tabs with spaces or spaces with tabs, which
could cause a heap buffer overflow. An attacker could possibly use this
issue to cause a denial of service or execute arbitrary code.
(CVE-2022-0572)

It was discovered that Vim was incorrectly processing Vim buffers. An
attacker could possibly use this issue to perform illegal memory access and
expose sensitive information. This issue only affected Ubuntu 20.04 LTS and
Ubuntu 22.04 LTS. (CVE-2022-0629)

It was discovered that Vim was not properly performing validation of data
that contained special multi-byte characters, which could cause an
out-of-bounds read. An attacker could possibly use this issue to cause a
denial of service. (CVE-2022-0685)

It was discovered that Vim was incorrectly processing data used to define
indentation in a file, which could cause a heap buffer overflow. An
attacker could possibly use this issue to cause a denial of service.
(CVE-2022-0714)

It was discovered that Vim was incorrectly processing certain regular
expression patterns and strings, which could cause an out-of-bounds read.
An attacker could possibly use this issue to cause a denial of service.
(CVE-2022-0729)

It was discovered that Vim incorrectly handled memory access. An attacker
could potentially use this issue to cause the corruption of sensitive
information, a crash, or arbitrary code execution. (CVE-2022-2207)

Read More

Multiple Vulnerabilities in Google Chrome Could Allow for Arbitrary Code Execution

Read Time:32 Second

Multiple vulnerabilities have been discovered in Google Chrome, the most severe of which could allow for arbitrary code execution. Google Chrome is a web browser used to access the internet. 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-6025-1: Linux kernel vulnerabilities

Read Time:1 Minute, 57 Second

It was discovered that the Traffic-Control Index (TCINDEX) implementation
in the Linux kernel contained a use-after-free vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2023-1281)

It was discovered that the OverlayFS implementation in the Linux kernel did
not properly handle copy up operation in some conditions. A local attacker
could possibly use this to gain elevated privileges. (CVE-2023-0386)

Haowei Yan discovered that a race condition existed in the Layer 2
Tunneling Protocol (L2TP) implementation in the Linux kernel. A local
attacker could possibly use this to cause a denial of service (system
crash). (CVE-2022-4129)

It was discovered that the network queuing discipline implementation in the
Linux kernel contained a null pointer dereference in some situations. A
local attacker could use this to cause a denial of service (system crash).
(CVE-2022-47929)

It was discovered that the NTFS file system implementation in the Linux
kernel contained a null pointer dereference in some situations. A local
attacker could use this to cause a denial of service (system crash).
(CVE-2022-4842)

Kyle Zeng discovered that the IPv6 implementation in the Linux kernel
contained a NULL pointer dereference vulnerability in certain situations. A
local attacker could use this to cause a denial of service (system crash).
(CVE-2023-0394)

It was discovered that the Human Interface Device (HID) support driver in
the Linux kernel contained a type confusion vulnerability in some
situations. A local attacker could use this to cause a denial of service
(system crash). (CVE-2023-1073)

It was discovered that a memory leak existed in the SCTP protocol
implementation in the Linux kernel. A local attacker could use this to
cause a denial of service (memory exhaustion). (CVE-2023-1074)

It was discovered that the NFS implementation in the Linux kernel did not
properly handle pending tasks in some situations. A local attacker could
use this to cause a denial of service (system crash) or expose sensitive
information (kernel memory). (CVE-2023-1652)

Lianhui Tang discovered that the MPLS implementation in the Linux kernel
did not properly handle certain sysctl allocation failure conditions,
leading to a double-free vulnerability. An attacker could use this to cause
a denial of service or possibly execute arbitrary code. (CVE-2023-26545)

Read More

USN-6024-1: Linux kernel vulnerabilities

Read Time:2 Minute, 8 Second

It was discovered that the Traffic-Control Index (TCINDEX) implementation
in the Linux kernel contained a use-after-free vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
possibly execute arbitrary code. (CVE-2023-1281)

Lin Ma discovered a race condition in the io_uring subsystem in the Linux
kernel, leading to a null pointer dereference vulnerability. A local
attacker could use this to cause a denial of service (system crash).
(CVE-2023-0468)

It was discovered that a use-after-free vulnerability existed in the SGI
GRU driver in the Linux kernel. A local attacker could possibly use this to
cause a denial of service (system crash) or possibly execute arbitrary
code. (CVE-2022-3424)

Hyunwoo Kim discovered that the DVB Core driver in the Linux kernel did not
properly perform reference counting in some situations, leading to a use-
after-free vulnerability. A local attacker could use this to cause a denial
of service (system crash) or possibly execute arbitrary code.
(CVE-2022-41218)

It was discovered that the network queuing discipline implementation in the
Linux kernel contained a null pointer dereference in some situations. A
local attacker could use this to cause a denial of service (system crash).
(CVE-2022-47929)

Thadeu Cascardo discovered that the io_uring subsystem contained a double-
free vulnerability in certain memory allocation error conditions. A local
attacker could possibly use this to cause a denial of service (system
crash). (CVE-2023-1032)

It was discovered that the module decompression implementation in the Linux
kernel did not properly handle return values in certain error conditions. A
local attacker could use this to cause a denial of service (system crash).
(CVE-2023-22997)

Lianhui Tang discovered that the MPLS implementation in the Linux kernel
did not properly handle certain sysctl allocation failure conditions,
leading to a double-free vulnerability. An attacker could use this to cause
a denial of service or possibly execute arbitrary code. (CVE-2023-26545)

It was discovered that the NTFS file system implementation in the Linux
kernel did not properly handle a loop termination condition, leading to an
out-of-bounds read vulnerability. A local attacker could use this to cause
a denial of service (system crash) or possibly expose sensitive
information. (CVE-2023-26606)

Wei Chen discovered that the DVB USB AZ6027 driver in the Linux kernel
contained a null pointer dereference when handling certain messages from
user space. A local attacker could use this to cause a denial of service
(system crash). (CVE-2023-28328)

Read More

Giving a Face to the Malware Proxy Service ‘Faceless’

Read Time:10 Minute, 23 Second

For the past seven years, a malware-based proxy service known as “Faceless” has sold anonymity to countless cybercriminals. For less than a dollar per day, Faceless customers can route their malicious traffic through tens of thousands of compromised systems advertised on the service. In this post we’ll examine clues left behind over the past decade by the proprietor of Faceless, including some that may help put a face to the name.

The proxy lookup page inside the malware-based anonymity service Faceless. Image: spur.us.

Riley Kilmer is co-founder of Spur.us, a company that tracks thousands of VPN and proxy networks, and helps customers identify traffic coming through these anonymity services. Kilmer said Faceless has emerged as one of the underground’s most reliable malware-based proxy services, mainly because its proxy network has traditionally included a great many compromised “Internet of Things” devices — such as media sharing servers — that are seldom included on malware or spam block lists.

Kilmer said when Spur first started looking into Faceless, they noticed almost every Internet address that Faceless advertised for rent also showed up in the IoT search engine Shodan.io as a media sharing device on a local network that was somehow exposed to the Internet.

“We could reliably look up the [fingerprint] for these media sharing devices in Shodan and find those same systems for sale on Faceless,” Kilmer said.

In January 2023, the Faceless service website said it was willing to pay for information about previously undocumented security vulnerabilities in IoT devices. Those with IoT zero-days could expect payment if their exploit involved at least 5,000 systems that could be identified through Shodan.

Notices posted for Faceless users, advertising an email flooding service and soliciting zero-day vulnerabilities in Internet of Things devices.

Recently, Faceless has shown ambitions beyond just selling access to poorly-secured IoT devices. In February, Faceless re-launched a service that lets users drop an email bomb on someone — causing the target’s inbox to be filled with tens of thousands of junk messages.

And in March 2023, Faceless started marketing a service for looking up Social Security Numbers (SSNs) that claims to provide access to “the largest SSN database on the market with a very high hit rate.”

Kilmer said Faceless wants to become a one-stop-fraud-shop for cybercriminals who are seeking stolen or synthetic identities from which to transact online, and a temporary proxy that is geographically close to the identity being sold. Faceless currently sells this bundled product for $9 — $8 for the identity and $1 for the proxy.

“They’re trying to be this one-stop shop for anonymity and personas,” Kilmer said. “The service basically says ‘here’s an SSN and proxy connection that should correspond to that user’s location and make sense to different websites.’”

MRMURZA

Faceless is a project from MrMurza, a particularly talkative member of more than a dozen Russian-language cybercrime forums over the past decade. According to cyber intelligence firm Flashpoint, MrMurza has been active in the Russian underground since at least September 2012. Flashpoint said MrMurza appears to be extensively involved in botnet activity and “drops” — fraudulent bank accounts created using stolen identity data that are often used in money laundering and cash-out schemes.

Faceless grew out of a popular anonymity service called iSocks, which was launched in 2014 and advertised on multiple Russian crime forums as a proxy service that customers could use to route their malicious Web traffic through compromised computers.

Flashpoint says that in the months before iSocks went online, MrMurza posted on the Russian language crime forum Verified asking for a serious partner to assist in opening a proxy service, noting they had a botnet that was powered by malware that collected proxies with a 70 percent infection rate.

MrMurza’s Faceless advertised on the Russian-language cybercrime forum ProCrd. Image: Darkbeast/Ke-la.com.

In September 2016, MrMurza sent a message to all iSocks users saying the service would soon be phased out in favor of Faceless, and that existing iSocks users could register at Faceless for free if they did so quickly — before Faceless began charging new users registration fees between $50 and $100.

Verified and other Russian language crime forums where MrMurza had a presence have been hacked over the years, with contact details and private messages leaked online. In a 2014 private message to the administrator of Verified explaining his bona fides, MrMurza said he received years of positive feedback as a seller of stolen Italian credit cards and a vendor of drops services.

MrMurza told the Verified admin that he used the nickname AccessApproved on multiple other forums over the years. MrMurza also told the admin that his account number at the now-defunct virtual currency Liberty Reserve was U1018928.

According to cyber intelligence firm Intel 471, the user AccessApproved joined the Russian crime forum Zloy in Jan. 2012, from an Internet address in Magnitogorsk, RU. In a 2012 private message where AccessApproved was arguing with another cybercriminal over a deal gone bad, AccessApproved asked to be paid at the Liberty Reserve address U1018928.

In 2013, U.S. federal investigators seized Liberty Reserve and charged its founders with facilitating billions of dollars in money laundering tied to cybercrime. The Liberty Reserve case was prosecuted out of the Southern District of New York, which in 2016 published a list of account information (PDF) tied to thousands of Liberty Reserve addresses the government asserts were involved in money laundering.

That document indicates the Liberty Reserve account claimed by MrMurza/AccessApproved — U1018928 — was assigned in 2011 to a “Vadim Panov” who used the email address lesstroy@mgn.ru.

PANOV

Constella Intelligence, a threat intelligence firm that tracks breached databases, says lesstroy@mgn.ru was used for an account “Hackerok” at the accounting service klerk.ru that was created from an Internet address in Magnitogorsk. The password chosen by this user was “1232.”

In addition to selling access to hacked computers and bank accounts, both MrMurza and AccessApproved ran side hustles on the crime forums selling clothing from popular retailers that refused to ship directly to Russia.

On one cybercrime forum where AccessApproved had clothing customers, denizens of the forum created a lengthy discussion thread to help users identify incoming emails associated with various reshipping services advertised within their community. Reshippers tend to rely on a large number of people in the United States and Europe helping to forward packages overseas, but in many cases the notifications about purchases and shipping details would be forwarded to reshipping service customers from a consistent email account.

That thread said AccessApproved’s clothing reshipping service forwarded confirmation emails from the address panov-v@mail.ru. This address is associated with accounts on two Russian cybercrime forums registered from Magnitogorsk in 2010 using the handle “Omega^gg4u.”

This Omega^gg4u identity sold software that can rapidly check the validity of large batches of stolen credit cards. Interestingly, both Omega^gg4u and AccessApproved also had another niche: Reselling heavily controlled substances — such as human growth hormone and anabolic steroids — from chemical suppliers in China.

A search in Constella on the address panov-v@mail.ru and many variations on that address shows these accounts cycled through the same passwords, including 055752403k, asus666, 01091987h, and the relatively weak password 1232 (recall that 1232 was picked by whoever registered the lesstroy@mgn.ru account at Klerk.ru).

Constella says the email address asus666@yandex.ru relied on the passwords asus666 and 01091987h. The 01091987h password also was used by asus666@mail.ru, which also favored the password 24587256.

Constella further reports that whoever owned the much shorter address asus@mail.ru also used the password 24587256. In addition, it found the password 2318922479 was tied to both asus666@mail.ru and asus@mail.ru.

The email addresses asus@mail.ru, asus2504@mail.ru, and zaxar2504@rambler.ru were all used to register Vkontakte social media accounts for a Denis ***@VIP*** Pankov. There are a number of other Vkontakte accounts registered to asus@mail.ru and many variations of this address under a different name. But none of those other profiles appear tied to real-life identities.

A mind map simplifying the research detailed here.

PANKOV

Constella’s data shows the email addresses asus2504@mail.ru and zaxar2504@rambler.ru used the rather unique password denis250485, which was also used by the email address denispankov@yandex.ru and almost a dozen variations at other Russian-language email providers.

Russian vehicle registration records from 2016 show the email address denispankov@yandex.ru belongs to Denis Viktorovich Pankov, born on April 25, 1985. That explains the “250485” portion of Pankov’s favored password. The registration records further indicate that in 2016 Pankov’s vehicle was registered in a suburb of Moscow.

Russian incorporation records show that denispankov@yandex.com is tied to IP Pankov Denis Viktorovich, a now-defunct transportation company in the Volograd Oblast, a region in southern Russia that shares a long border with western Kazazkhstan.

More recent records for IP Pankov Denis Viktorovich show a microenterprise with this name in Omsk that described its main activity as “retail sale by mail or via the Internet.” Russian corporate records indicate this entity was liquidated in 2021.

A reverse password search on “denis250485” via Constella shows this password was used by more than 75 email addresses, most of which are some variation of gaihnik@mail.ru — such as gaihnik25@mail.ru, or gaihnik2504@rambler.ru.

In 2012, someone posted answers to a questionnaire on behalf of Denis Viktorovich Pankov to a Russian-language discussion forum on Chinese crested dog breeds. The message said Pankov was seeking a puppy of a specific breed and was a resident of Krasnogorsk, a city that is adjacent to the northwestern boundary of Moscow.

The message said Pankov was a then 27-year-old manager in an advertising company, and could be reached at the email address gaihnik@mail.ru.

GAIHNIK

Constella Intelligence shows gaihnik@mail.ru registered at the now-defunct email marketing service Smart Responder from an address in Gagarin, which is about 115 miles west of Moscow.

Back in 2015, the user Gaihnik25 was banned from the online game World of Tanks for violating the game’s terms that prohibit “bot farming,” or the automated use of large numbers of player accounts to win some advantage that is usually related to cashing out game accounts or inventory.

For the past few years, someone using the nickname Gaihnik25 has been posting messages to the Russian-language hacking forum Gerki[.]pw, on discussion threads regarding software designed to “brute force” or mass-check online accounts for weak or compromised passwords.

A new member of the Russian hacking forum Nohide[.]Space using the handle Gaihnik has been commenting recently about proxy services, credential checking software, and the sale of hacked mailing lists. Gaihnik’s first post on the forum concerned private software for checking World of Tanks accounts.

The address gaihnik@mail.ru shows how so many email addresses tied to Pankov were also connected to apparently misleading identities on Vkontakte and elsewhere. Constella found this address was tied to a Vkontakte account for a Dmitriy Zakarov.

Microsoft’s Bing search engine says gaihnik@mail.ru belongs to 37-year-old Denis Pankov, yet clicking the Mail.ru profile for that user brings up a profile for a much older man by the name Gavril Zakarov. However, when you log in to a Mail.ru account and view that profile, it shows that most of the account’s profile photos are of a much younger man.

Many of those same photos show up in an online dating profile at dating.ru for the user Gaihnik, a.k.a “Denchik,” who says he is a 37-year-old Taurus from Gagarin who enjoys going for walks in nature, staying up late, and being on the Internet.

Mr. Pankov did not respond to multiple requests for comment sent to all of the email addresses mentioned in this story. However, some of those addresses produced detailed error responses; Mail.ru reported that the users panov-v@mail.ru, asus666@mail.ru, and asus2504@mail.ru were terminated, and that gaihnik25@mail.ru is now disabled.

Messages sent to many other email addresses connected via passwords to Pankov and using some variation of asus####@mail.ru also returned similar account termination messages.

Read More