Hacking News
-
Roku switches on 2FA for all following latest security snafu
Streamer says access came via credential stuffing
At least they didn’t say sofiscated nation-state actor.
-
-
@HardwareGeek linked an article in Hacking News that said:
There are instances where this vulnerability can be exploited without the need to compromise a server in advance.
One such case is the use of SSH keys for signing Git commits. A common setup involves using Pageant, the ssh-agent of PuTTY, locally and forwarding the agent to a development host.
Here, you configure Git to use OpenSSH to sign Git commits with the SSH key provided by Pageant. The signature is then generated by Pageant, making it susceptible to private key recovery.
Who in their right mind does that‽Git commits should be signed by keys that are part of some public key infrastructure, but SSH doesn't have any method of signing certificates or even certificates at all. And while it uses the same algorithms as PGP/GPG or X.509, there is no sane reason to actually use the same key with it.
On the other hand
Collecting signatures from an SSH server is not as critical as it would mean the server itself is already compromised, and thus, the threat actor has broad access to the operating system.
Yes, it is, because the normal use-case is that the user has one key and uses it to access all systems they administer, so if one server is compromised, stealing the keys allows getting to those other systems.
Either way, the attack affects
NIST P-521 curve
Has anybody already started using that? I've been using the smaller ed25519 curve for over a decade, but still have to have an RSA key for quite a few systems that don't support it.
Also it is funny that the exploit affects the longer key while the shorter ones remain safe.
-
@Bulb Git on Windows is a generally unmitigated shitshow.
-
@Arantor said in Hacking News:
@Bulb
Git onWindows is a generally unmitigated shitshow.But that's a different thread.
-
@HardwareGeek More than only one.
-
@Arantor said in Hacking News:
@Bulb Git on Windows is a generally unmitigated shitshow.
Which has exactly nothing to do with the issue at hand, because the standard install of git uses openssh, not putty, for transport, and does not even offer an option to sign anything with ssh (only with gpg).
-
@Bulb said in Hacking News:
@Arantor said in Hacking News:
@Bulb Git on Windows is a generally unmitigated shitshow.
Which has exactly nothing to do with the issue at hand, because the standard install of git uses openssh, not putty, for transport, and does not even offer an option to sign anything with ssh (only with gpg).
Using HTTPS for transport is also pretty common.
-
@dkf It is completely irrelevant that it can also be using a non-ssh transport, the point is it is using a different implementation of ssh transport than the one affected by the security advisory.
-
@Bulb said in Hacking News:
SSH doesn't have any method of signing certificates or even certificates at all.
it is (or at least openssh does). The first duck hit for signing ssh key gave me this hashicorp link, but we are using it also in our environment (without hashicorp)
-
@robo2 Hm, TIL, never seen anybody actually use that.
-
@Bulb said in Hacking News:
@HardwareGeek linked an [article] in Hacking News that said:
There are instances where this vulnerability can be exploited without the need to compromise a server in advance.
One such case is the use of SSH keys for signing Git commits. A common setup involves using Pageant, the ssh-agent of PuTTY, locally and forwarding the agent to a development host.
Here, you configure Git to use OpenSSH to sign Git commits with the SSH key provided by Pageant. The signature is then generated by Pageant, making it susceptible to private key recovery.
Who in their right mind does that‽Git commits should be signed by keys that are part of some public key infrastructure, but SSH doesn't have any method of signing certificates or even certificates at all.
It does. SSH certs are little known although they have existed for a decade or so. (Ed 
)
Although it doesn't sound like they were being used in this scenario.NIST P-521 curve
Has anybody already started using that? I've been using the smaller ed25519 curve for over a decade, but still have to have an RSA key for quite a few systems that don't support it.
I see no reason to switch. Supposedly the algorithm is faster (which doesn't matter at all in SSH), but DJB & Tanja Lange say it's crap and quite a few things coming out of NIST turned out to be smelly so I would prefer not to.
-
@LaoC said in Hacking News:
I see no reason to switch. Supposedly the algorithm is faster (which doesn't matter at all in SSH), but DJB & Tanja Lange say it's crap and quite a few things coming out of NIST turned out to be smelly so I would prefer not to.
The https://safecurves.cr.yp.to/ (by DJB & Lange) lists the NIST P-256 and P-384 as manipulatable, because they include an unexplained pseudo-random constant, but it does not list the P-521. It does list “E-521”, which someone said is the same curve here, but https://neuromancer.sk/ doesn't seem to agree (P-521, E-521).
-
By "using" the Github comments feature, you can deposit malware which looks like "official" packages of trusted companies...
https://www.bleepingcomputer.com/news/security/gitlab-affected-by-github-style-cdn-flaw-allowing-malware-hosting/
-
Effing brillant: exploiting a software bug with paper coupons, to the tune of a couple M$.
Nobody cared enough to check why audits were out of whack
{{ .Terminator.EasyMoneyMeme }}
-
@LaoC's article said in Hacking News:
Known abusers of the TICO machines have been charged, and one of those set to face the courts is accused of association with a criminal group.
I know this is the other side of the "You can't '
Ackchyually' your way out of court" coin, but it seems kind of ridiculous. How is it their fault that the machines give out too much money? What if instead the slot machines had a bug so that you could actually win instead of "the house always wins". Would it then be criminal to play them?
-
@topspin said in Hacking News:
How is it their fault that the machines give out too much money?
They could redeem the same ticket twice. It must have been rather obvious to them that they were not supposed to do that, and that they were not entitled to that money, but they still took it. That's stealing, just like it's stealing to walk through someone's wide open front door and take the money lying on the kitchen counter.
-
@ixvedeusi said in Hacking News:
That's stealing, just like it's stealing to walk through someone's wide open front door and take the money lying on the kitchen counter.
Yeah, kinda.
It's more like I bring you a cake, you give me money in return but it's twice as much as you said you'd give me. The difference is that the machine / you hand me the money, so there's an argument to be made for you agreeing on the thing you are doing.It must have been rather obvious to them that they were not supposed to do that.
And if it's obvious that you're not supposed to win at slot machines, but (consistently, due to a bug) still do? Is that stealing?
-
@topspin said in Hacking News:
And if it's obvious that you're not supposed to win at slot machines, but (consistently, due to a bug) still do? Is that stealing?
You lose on average, at any snapshot in time you can be winning. So no as a user of the slot machine I would have no idea if I was in a winning streak or the slot machine was broken.
-
@topspin said in Hacking News:
@ixvedeusi said in Hacking News:
That's stealing, just like it's stealing to walk through someone's wide open front door and take the money lying on the kitchen counter.
Yeah, kinda.
It's more like I bring you a cake, you give me money in return but it's twice as much as you said you'd give me. The difference is that the machine / you hand me the money, so there's an argument to be made for you agreeing on the thing you are doing.It must have been rather obvious to them that they were not supposed to do that.
And if it's obvious that you're not supposed to win at slot machines, but (consistently, due to a bug) still do? Is that stealing?
The better analogy here would be:
- You brought me a cake last week, and I gave you a promise to pay for the cake.
- You redeemed the promise to pay the day after, and I didn't take the promise to pay slip but gave you the money
- You forgot you had redeemed the promise to pay two days after, so when you found the slip again, you came and redeemed the promise to pay, and I didn't take the promise to pay slip or otherwise question whether I'd paid it before
- After you got the money again, you realized I'd paid you twice and wasn't monitoring whether I've paid you at all, so now you started re-redeeming the promise to pay on a daily basis
Edit because I hit enter before completing my thought: the point of criminality is step 4.
-
Found a gem in Microsoft documentation:Azure Storage relies on Windows implementation of SSL that is not based on OpenSSL and therefore is not exposed to OpenSSL related vulnerabilities.
-
Yes, you don't want all those open-source vulnerabilities in your crypto stack. Serious companies insist on only closed-source, proprietary vulnerabilities that have been designed by actual proper intelligence agencies.
-
-
@Zerosquare Anyways, Microsoft is technically correct
!
-
Millions of IPs remain infected by USB worm years after its creators left it for dead
Ability of PlugX worm to live on presents a vexing dilemma: Delete it or leave it be.
-
-
@Dragoon said in Hacking News:
@topspin said in Hacking News:
And if it's obvious that you're not supposed to win at slot machines, but (consistently, due to a bug) still do? Is that stealing?
You lose on average, at any snapshot in time you can be winning. So no as a user of the slot machine I would have no idea if I was in a winning streak or the slot machine was broken.
And they are generally programmed to work this way. Even to a point of periodically letting you win so you keep putting money in the machine.
-
Depends where you are. In some jurisdictions, the machines are programmed/manufactured such that each spin is (for all practical purposes) independent of previous ones, so there’s no such thing as a streak. If a streak happens, technically you’re either very lucky or the machine is faulty and should be removed from service and corrected.
Others, on the other hand (especially here in the UK) have thresholds for taking in and paying out, such that several marks can put money in and at some point the machine will go “shit I haven’t paid out in too long” and will pay out quite a bit in a hurry to get back to its current thresholds.
-
UnitedHealthcare CEO says 'maybe a third' of US citizens were affected by recent hack | TechCrunch
Two months after hackers broke into Change Healthcare systems stealing and then encrypting company data, it’s still unclear how many Americans were UnitedHealth Group CEO Andrew Witty finally gave an estimate of how many Americans were impacted by the hack on the company's subsidiary Change...
-
Ah, just the usual "very limited number of users", then
-
@boomzilla Yet another way in which United Healthcare sucks even more than other American health insurance companies. I suppose it's too much to hope that it affects only current
victimscustomers and not historical data.
-
@HardwareGeek said in Hacking News:
Yet another way in which United Healthcare sucks even more than other American health insurance companies.
Would you say they're the United Airlines of healthcare?
-
@Zerosquare I wouldn't have said that, but now that you've mentioned it, it's probably not a bad comparison.
-
@Zerosquare said in Hacking News:
@HardwareGeek said in Hacking News:
Yet another way in which United Healthcare sucks even more than other American health insurance companies.
Would you say they're the United Airlines of healthcare?
Hmm. So "United <something>" sucks? "United States" - yup, until we get someone sensible in office.
-
-
@HardwareGeek said in Hacking News:
@dcon said in Hacking News:
we get someone sensible in office
When was the last time that happened?
I think I covered that in my
<abbr>...
-
Maximum-severity GitLab flaw allowing account hijacking under active exploitation
The threat is potentially grave because it could be used in supply-chain attacks.
-
@boomzilla That gets a 10
out of 10 
from me! Absolute top 
territory. 
Makes me glad that we've been institutionally trying to move away from GitLab... though I don't know the politicking behind why that decision was taken.
-
@dkf Why the eF does anybody host their own gitlab instance while keeping it accessible from the infernet and using the built-in authentication‽
I mean we use gitlab at $work, but we have it in the intranet only and we have it connected to the LDAP for authentication, so the vulnerable feature can't be used anyway. Those two things are the reason to bother with having own instance. If you don't want to do either, just use some hosted offer—that will hopefully be patched more rapidly.
-
@Bulb my old employer did this.
So, consider the following. Company is a hosting company, with the various sources to be deployed hosted on said GitLab instance. Originally this was internal only.
Now consider allowing a customer you trust (
) to have access from outside the internal network, and not handle this by some form of tunnelling.All your internal users ca be tied to your internal auth but the external ones, um, weren’t.
They may have changed this since I left but it was changed to this vulnerable state while I was there and I raised concerns. But the client in question was paying enough bucks to make this happen. (Most other clients just paid for “do this thing, deploy it” and not have direct full access to the code on demand)
-
@Bulb said in Hacking News:
Those two things are the reason to bother with having own instance. If you don't want to do either, just use some hosted offer—that will hopefully be patched more rapidly.
When the instance needs access to special hardware yet has to support external collaboration (old-man-shakes-fist-at-active-directory) you end up with the tricky case. The hardware can be special for various reasons; being something genuinely weird and custom is only one possible scenario; you see this more in hardware development where the custom stuff is a group of large FPGAs for the testbed.
-
@dkf but wouldn't that only be relevant for the build/test agents/runners? You can still have those on premise while "the rest" of gitlab is hosted. We do this with github and azure devops.
-
@robo2 said in Hacking News:
@dkf but wouldn't that only be relevant for the build/test agents/runners? You can still have those on premise while "the rest" of gitlab is hosted. We do this with github and azure devops.
With much of the higher end of hardware development, keeping the SCM repos on premises as well is common, as part of risk management (especially relating to corporate espionage). It's very different to software, where the main defense is typically just making the whole system so difficult to build and deploy that everything is quite safe even if the source code is out in the open...
-
@dkf said in Hacking News:
It's very different to software, ... making the whole system so difficult to build and deploy
That much, at least, isn't all that different. Yes, we tend to be very protective of our source code. Some companies are utterly paranoid about it, to the point that employees aren't even allowed to know some projects exist, unless they are directly involved in them. But hw is often just as difficult to build and deploy as any sw.
-
@Arantor said in Hacking News:
@Bulb my old employer did this.
So, consider the following. Company is a hosting company, with the various sources to be deployed hosted on said GitLab instance. Originally this was internal only.
Now consider allowing a customer you trust (
) to have access from outside the internal network, and not handle this by some form of tunnelling.All your internal users ca be tied to your internal auth but the external ones, um, weren’t.
… so a wrong reason, I see. In all the subcontracts I did, I always got a customer account for accessing their systems. Not doing it is … a
.They may have changed this since I left but it was changed to this vulnerable state while I was there and I raised concerns. But the client in question was paying enough bucks to make this happen. (Most other clients just paid for “do this thing, deploy it” and not have direct full access to the code on demand)
You correctly raised concerns. It should have been connected to some central auth.
@dkf said in Hacking News:
@robo2 said in Hacking News:
@dkf but wouldn't that only be relevant for the build/test agents/runners? You can still have those on premise while "the rest" of gitlab is hosted. We do this with github and azure devops.
With much of the higher end of hardware development, keeping the SCM repos on premises as well is common, as part of risk management (especially relating to corporate espionage). It's very different to software, where the main defense is typically just making the whole system so difficult to build and deploy that everything is quite safe even if the source code is out in the open...
When it's for risk management, sure the first thing you want to do is connect it to a central identity management, so you can centrally audit who has access where.
-
I didn’t really read / understand that article too well
. What’s going on, something about outsiders getting access by triggering password reset emails? How does that work?And why is everybody now arguing against hosting your shit on premises instead of
somebody-else’s-computerThe Cloud all of a sudden, as if on-prem wasn’t the much more reasonable option?
-
@topspin said in Hacking News:
And why is everybody now arguing against hosting your shit on premises instead of somebody-else’s-computerThe Cloud all of a sudden, as if on-prem wasn’t the much more reasonable option?
Kickbacks from Microsoft et al..
Also, IT doesn't want to take responsibility. If you let somebody else host your shit, it's their fault if things go wrong. Or your users. Either way, IT get to point fingers at somebody.
-
@cvi said in Hacking News:
@topspin said in Hacking News:
And why is everybody now arguing against hosting your shit on premises instead of somebody-else’s-computerThe Cloud all of a sudden, as if on-prem wasn’t the much more reasonable option?
Kickbacks from Microsoft et al..
Also, IT doesn't want to take responsibility. If you let somebody else host your shit, it's their fault if things go wrong. Or your users. Either way, IT get to point fingers at somebody.
It's mildly amusing, but a lot of bean counters seem to think that it's cheaper as well. Dunno how it could be cheaper to let someone else hire staff to do the exact same thing and then also turn a profit from the job. If you can't do it cheaper inhouse you probably suck at IT.
Though I do see the point for companies that don't really do IT because it's either not what they do, or they are too small to have a real need for it yet. A fixed rate cloud thingymabob works perfectly fine for them, and they don't have to hire IT staff.
-
: 
