Buffer overflow in bootloader shim allows attackers to run code each time devices boot up. //

The risk of successful exploitation is mostly limited to extreme scenarios, as noted earlier. The one scenario where exploitation is most viable—when devices receive boot images over an unencrypted HTTP server—is one that should never happen in 2024 or the past decade, for that matter.

That said, the harm from successful exploitation is serious and is the reason for the severity rating of 9.8 out of a possible 10. People should install patches promptly once they become available.

A California man who lost $100,000 in a 2021 SIM-swapping attack is suing the unknown holder of a cryptocurrency wallet that harbors his stolen funds. The case is thought to be the first in which a federal court has recognized the use of information included in a bitcoin transaction — such as a link to a civil claim filed in federal court — as reasonably likely to provide notice of the lawsuit to the defendant. Experts say the development could make it easier for victims of crypto heists to recover stolen funds through the courts without having to wait years for law enforcement to take notice or help. //

On Dec. 14, 2023, a federal judge in the Eastern District of California granted Dellone permission to serve notice of his lawsuit directly to the suspected hackers’ bitcoin address — using a short message that was attached to roughly $100 worth of bitcoin Mora sent to the address.

Bitcoin transactions are public record, and each transaction can be sent along with an optional short message. The message uses what’s known as an “OP RETURN,” or an instruction of the Bitcoin scripting language that allows users to attach metadata to a transaction — and thus save it on the blockchain.

In the $100 bitcoin transaction Mora sent to the disputed bitcoin address, the OP RETURN message read: “OSERVICE – SUMMONS, COMPLAINT U.S. Dist. E.D. Cal. LINK: t.ly/123cv01408_service,” which is a short link to a copy of the lawsuit hosted on Google Drive. //

Let’s think about this for a second. We now can be served via an email that: inspires urgent action, cites consequences, is from an unknown/untrusted sender and, apparently, can use shortened links. Isn’t that EXACTLY the sort of thing we’ve all been telling our parents to be skeptical of?

Pay me or I'll tell everyone you were foolish enough to buy an internet connected broom.

Callias Ars Praetorian
10y
508
Subscriptor++
After 40 years, I still do not understand the reluctance to have one non-internet connected network for things like machinery, et al AND then the network for file shares, email, etc. that is connected to the Internet.

Now. I do understand that support vendors want remote access to the machinery, etc., but I have found remarkable success in saying (something to the effect of) “Hey no problem…it’s just…well, if the machinery or our network is hacked through your interface/accounts, you incur liability and agree to pay damages. OR, Option B, you get yourself onsite and fix it. No need to worry about liability and damages because you’d never let security lapses occur, would you?”

It has worked so, so, so many times over the decades that it just boggles the mind that such a negotiation stance is not a standard operating procedure. Of course, often I worked in high security industries where to play ball, a vendor had to have at least some semblance of their sh*t together.

If you suspect your account may have been compromised, or as a general precaution, sign out of all browser profiles to invalidate the current session tokens. Following this, reset your password and sign back in to generate new tokens. Resetting your password effectively disrupts unauthorized access by invalidating the old tokens which the infostealers rely on, thus providing a crucial barrier to the continuation of their exploit.”

Terrapin isn't likely to be mass-exploited, but there's little reason not to patch.

Passkeys are an asymmetric key pair

Each passkey is a pair of two related asymmetric cryptographic keys, which are very long, random strings of characters. While they differ from each other, they do have a special relationship - one can decrypt messages that have been encrypted by the other. This feature can be used to verify a user and authenticate them.

The key pair is made up of a private key that’s kept securely on your device, inside a password manager supporting passkeys (also called a passkey provider), and a public key that’s stored on the website you are logging into. Your private key is secure and never leaves your device, and the password manager keeps it locked by biometrics, PIN, or a password. The public key, on the other hand, could be shared with the world, such as in the case of a website data breach, and your security wouldn't be compromised so long as the private key stays safe.

Think of it as the modern form of,

“Give me six lines…”

[1] Contrary to what people think, guard labour [police] has little or no interest in either justice or correctly solving crime. As I’ve noted before their process is,

1, Build a list of suspects.
2, Prune the list down.
3, Look not for evidence but what a prosecutor can use to confound a jury thus get them to believe in nonsense to obtain a conviction.
4, Get any kind of conviction to keep politicians / funds holders happy.

That is once you are on the guard labours short list they immediately fail to carry out one of their primary requirments which is that of “impartiality”. That is they don’t look for, ignore, or hide information that might show you are innocent, so they can get the case closed quickly and most importantly as cheaply as possible.

Novel Terrapin attack uses prefix truncation to downgrade the security of SSH channels.

An unusual right-to-repair drama is disrupting railroad travel in Poland despite efforts by hackers who helped repair trains that allegedly were designed to stop functioning when serviced by anyone but Newag, the train manufacturer.

Fail2Ban uses the file /etc/fail2ban/jail.local and look for the [ssh] section, you can change the port there.

[ssh]
enabled  = true
port     = ssh

You can change the port value to any positive integer.

The facilities in Pennsylvania and Texas serve more than 2 million residents.

Easy-to-exploit flaw can give hackers passwords and cryptographic keys to vulnerable servers.

An error as small as a single flipped memory bit is all it takes to expose a private key. //

Martin Blank Ars Tribunus Militum

gromett said:
I have read it twice and am still not entirely clear.
Does this affect OpenSSH? As I read it the answer is no?

As happens often in cryptographic attacks that at least start out as implementation-specific, the likely answer is "it is not currently known to affect other implementations." Cryptographic techniques always get cheaper, never more expensive, and it is difficult to guarantee that other implementations are not vulnerable through variations of this attack. //

bobo bobo said:
A link in this article, to a Wikipedia page on Man In the Middle attacks, is labeled as a "malory in the middle" attack. But, um, the Wikipedia page does not use the term "malory". I am confused by use of the word "malory".

Typo? Or am I missing something?
It's a less common use, but it's part of the movement in the IT industry to move away from sensitive terms (e.g., master/slave becoming primary/secondary or similar). I've also heard monster-in-the-middle and monkey-in-the-middle, but really, there are no suggested terms that roll off the tongue the way man-in-the-middle does while keeping the MitM shorthand. //

FabiusCunctator Ars Scholae Palatinae

The vulnerability occurs when there are errors during the signature generation that takes place when a client and server are establishing a connection. It affects only keys using the RSA cryptographic algorithm, which the researchers found in roughly a third of the SSH signatures they examined.

A good reason to not use RSA keys if possible. I configure all of my ssh setups to use ED25519 keys by default, with a fallback to RSA if ED25519 support is not available.

You can generate an ED25519 key using the standard OpenSSH package by doing:

 ssh-keygen -t ed25519

That will generate two files in your ssh key directory ('~/.ssh/' by default): 'id_ed25519' and 'id_ed25519.pub'. The first is your private key (keep it close!), while the second is your public key. Add that to the public key file you deploy to remote servers, and (where supported *) your logins will then use the new ED25519 keypair in preference to RSA ones.

• The 'where supported' caveats are important. While many if not most ssh implementations today (including OpenSSH) support ED25519 keys, there are still a few around that don't. Hence, it's a good idea to maintain both ED25519 and RSA keys and include both in your public key lists. If an implementation does not support ED25519, it will just ignore those keys and use RSA. //

In November 2022, the password manager service LastPass disclosed a breach in which hackers stole password vaults containing both encrypted and plaintext data for more than 25 million users. Since then, a steady trickle of six-figure cryptocurrency heists targeting security-conscious people throughout the tech industry has led some security experts to conclude that crooks likely have succeeded at cracking open some of the stolen LastPass vaults. //

How hard would it be for well-resourced criminals to crack the master passwords securing LastPass user vaults? Perhaps the best answer to this question comes from Wladimir Palant, a security researcher and the original developer behind the Adblock Plus browser plugin.

In a December 2022 blog post, Palant explained that the crackability of a LastPass master password depends largely on two things: The complexity of the master password, and the default settings for LastPass users, which appear to have varied quite a bit based on when those users began patronizing the service.

LastPass says that since 2018 it has required a twelve-character minimum for master passwords, which the company said “greatly minimizes the ability for successful brute force password guessing.”

But Palant said while LastPass indeed improved its master password defaults in 2018, it did not force all existing customers who had master passwords of lesser lengths to pick new credentials that would satisfy the 12-character minimum.

“If you are a LastPass customer, chances are that you are completely unaware of this requirement,” Palant wrote. “That’s because LastPass didn’t ask existing customers to change their master password. I had my test account since 2018, and even today I can log in with my eight-character password without any warnings or prompts to change it.”

Palant believes LastPass also failed to upgrade many older, original customers to more secure encryption protections that were offered to newer customers over the years. One important setting in LastPass is the number of “iterations,” or how many times your master password is run through the company’s encryption routines. The more iterations, the longer it takes an offline attacker to crack your master password.

Palant noted last year that for many older LastPass users, the initial default setting for iterations was anywhere from “1” to “500.” By 2013, new LastPass customers were given 5,000 iterations by default. In February 2018, LastPass changed the default to 100,100 iterations. And very recently, it upped that again to 600,000.

Palant said the 2018 change was in response to a security bug report he filed about some users having dangerously low iterations in their LastPass settings.

“Worse yet, for reasons that are beyond me, LastPass didn’t complete this migration,” Palant wrote. “My test account is still at 5,000 iterations, as are the accounts of many other users who checked their LastPass settings. LastPass would know how many users are affected, but they aren’t telling that. In fact, it’s painfully obvious that LastPass never bothered updating users’ security settings. Not when they changed the default from 1 to 500 iterations. Not when they changed it from 500 to 5,000. Only my persistence made them consider it for their latest change. And they still failed implementing it consistently.”

If a transgression by a single employee breaches your network, you're doing it wrong. //

Accessing personal accounts at a company like Okta has long been known to be a huge no-no. And if that prohibition wasn’t clear to some before, it should be now. The employee almost surely violated company policy, and it wouldn’t be surprising if the offense led to the employee’s firing.

However, it would be wrong for anyone to conclude that employee misconduct was the cause of the breach. It wasn’t. The fault, instead, lies with the security people who designed the support system that was breached, specifically the way the breached service account was configured. //

First, Okta should have put access controls in place besides a simple password to limit who or what could log into the service account. One way of doing this is to put a handful of company-controlled IP addresses on an allow list and to block all others unless additional credentials are supplied. Another is to regularly rotate access tokens used to authenticate to service accounts. And, of course, it should have been impossible for employees to be logged in to personal accounts on a work machine. These and other precautions are the responsibility of senior people inside Okta.