* Posts by KalF

11 publicly visible posts • joined 8 Apr 2020

Bug hunter tricked SSL.com into issuing cert for Alibaba Cloud domain in 5 steps

KalF
Flame

Email DCV can die in a fire

With Whois based DCV killed off at the start of this year, I think it's time the CA/Browser forum got serious with removing the other flaky forms of DCV. There's still a couple of email based DCV methods, including the one in this article. The most ridiculous IMO is emails to a 'well known' address which may not be that well known by most ppl and thus vulnerable to abuse.

CAs arent obliged to support these dodgy DCV methods, but they do, because if someone wants to pay, who are they to say no? After all it might delay a customer migrating to an automated DCV method. down that path lies Let's Encrypt and damnation (also known as zero cash).

nevertheless this particular issue appears to be just plain sloppiness on the part of SSL.com.

Abandoned AWS S3 buckets can be reused in supply-chain attacks that would make SolarWinds look 'insignificant'

KalF

Turns out blindly trusting downloaded resources is dumb. who knew

Just like the whois issue, this class of attacks relies on clients using a hardcoded or statically configured path forever. In the case of whois, it was exacerbated because the protocol has no legit delegation path, meaning every client had to do this and some just forgot to ever update. that protocol also has no inherent validation for received data.

With any client that relies on fetching a resource via FQDN, the process should always use signatures to validate that the resource was actually generated by the author you trust. That way, even if you forget to update the clients, at least a malicious actor wont be able to send you files that you blindly trust. This really has nothing to do specifically with S3. Blocking out a name for eternity the first time it is used would be really dumb. This won't happen in the DNS world, so a validated supply chain practice that works well for FQDNs will work just fine for S3 also.

Bluesky keeps growing, and so do its problems

KalF
Thumb Up

better ui and feed

I left twitter as soon as the UI started to degrade and the feed turned to junk. I think those that stayed have generally become used to the worse experience and there's a trepidation that all their hard won social media points will be lost if they move. But when I occasionally log in now, I can't believe how poor the UX has become. I personally prefer Mastodon's architecture and UX - validating your github and web content is useful. but Bluesky has way more ppl and doesnt feel too far behind Mastodon, it even has a primitive form of validation by domain.

AWS Cloud Development Kit flaw exposed accounts to full takeover

KalF

Re: Pre-load??

The crims create a bucket in their own account with the predicted name/s. They upload some dodgy code into that bucket. presumably obfuscated. You bootstrap your CDK. you don't supply a custom bucket name, because many ppl don't. CDK either creates _or_ uses the default bucket. CDK didnt crash out if the bucket already existed and was owned by someone else. <- this seems like an obvious risk to me, but what do I know?

since buckets names are global, it turns out you are now using a bucket you don't own, with code present that you are likely to accidentally execute.

The fix is to require CDK bootstrapping to only use buckets within the user's account. And in future to also not use a predictable name.

Australian techie jailed for accessing museum's accounting system and buying himself stuff

KalF

Re: Circular reasoning

yes, they do differ. but Australian govt rules apply for australian security clearance. which was the topic of the study. Although it's relevance to their findings seems limited to amplifying clicky headlines only. They could have reported that 100% of fish n chip shop employees on linkedin appear on HIBP, so you'll get malware with your minimum chips.

in some nation's cases it isnt clearance for a purpose, but rather a general access level. Which is madness IMO, but they seem to make it work.

AGSVA does retain your data so submitting and the initial screening will be faster if you've had it recently. However it is illegal to prefer a candidate on this basis, they must simply be eligible for clearance. But we all know what happens in the real world.

KalF

Circular reasoning

Checking a known breached service (linkedin, pick your recent data breach occurrence) to see if users have had their data breached seems a bit redundant. It's the kind of lazy analysis companies do in order to come up with a headline reason why their staff are better than the randoms on a social network. Anyone using linkedin for longer than a few moments has had their profile exfil'd. Whether that is an actual problem depends on whether they are vulnerable to cred stuffing. Just saying someone appears on HIBP is weak research.

However putting clearance on your profile is a bit off. Clearance is for a specific purpose/role and does not carry to a new role. Hiring only those with current clearance is illegal (AGSVA site explains this quite clearly). And yet recruiters and employers do it all the time anyway. Which is why some are motivated to put their clearance in their profiles. Since what really matters to an employer should be whether clearance is attainable, perhaps candidates should put their citizenship and whether or not they have been to the big house?

It's completely unsupportable. Yes, we mean your brand new system

KalF

I may not have made the 'focus on what is core' part clear. The skills you prioritise should be for your core money making systems. If you allow your back office tech stack to dictate tech choices for your core products you'll have a company that can't compete or evolve.

Your back office is not unimportant and ppl shouldnt draw that conclusion simply because I say it shouldnt drive your tech choices. But efficiency gains should drive the cost and focus down over time for those support systems.

As for deciding what your core systems are, if the CIO and CTO can't decide that, then tech stack choices are the least of your challenges.

KalF

organisations should specialise on what is core to their business. That part should never be outsourced, but everything else either should be completely outsourced or operated in a manner that prioritises a stable and efficient service to the broader organisation. Effectively replicating the benefits of outsourcing, while mitigating the downsides we've all suffered.

Therefore if you innovate within your core business, but prioritise the capabilities within the support arm of the organisation, as appears to be the moral of the story, then you are holding the stick wrong. I think many CTOs and CIOs feel connected to their enterprise backoffice support backgrounds, to the detriment of business value.

There's clearly a balance that must be found, skills and control within your supporting services are important, but its the core business that should drive innovation. In the story in the article, I would have refocused the team on the product platform (assuming those skills werent there to begin with) and thought long and hard about my dependence on skills for 'mainstream' systems that didnt make me any money. They had effectively invested in skills and capabilities that didnt offer a competitive advantage. The good staff will adapt and thrive.

Linux laptop biz System76 makes its first foray into the mechanical keyboard world with dinky, hackable Launch

KalF

ur choice of firmware, but not keycaps?

I can hack the firmware, great, but I will probably never do it.

Can I use custom keycaps with that split space bar tho? There's a community of ppl who do like to change up the hardware of their keyboards, from the switches to the key caps. This appears to service some other non existent community that likes to modify firmware but not much else.

and it isnt quite what most ppl would expect in a TKL keyboard which is 87/88 keys. They have borrowed a key from the bottom right hand cluster you normally have on a TKL for the second space bar. No big deal since that rarely does anything other than RGB profile control. They have also taken 4 keys from the top right cluster where you'd expect PRT, SCR, INS etc.. the reason for that is less clear. if TKL is too wide, use the compact form factor other keyboard providers use.

This is node joke. Tor battles to fend off swarm of Bitcoin-stealing evil exit relays making up about 25% of outgoing capacity at its height

KalF
Unhappy

Re: I continue to be surprised

Plain HTTP can be manipulated to inject exploits. This is why you always need HTTPS regardless of the content on your site. A lot of shopping cart attacks start this way, using unencrypted parts of a site to compromise subsequent encrypted activities.

As others have said, its 2020, certs are free, the software is simple. There's no good excuses anymore for using plain text http, although the bad ones remain.

Something something DANE cook: Microsoft pledges to wrap its email systems in secure anti-snooping protocol

KalF

Not quite right

@bige TLSA doesnt remove PKI to replace it with DNSSEC and root level authority. It uses your proven control of your own domain to tell the client mail server what to expect from the certificate the remote mail server will present _after a secure connection is established_. Bear in mind that all public certificates already rely on proof of domain control in order to issue you that cert. So this is not weaker or stronger, its simply more practical for SMTP. RFC7672 does contain a good intro into why SMTP secure connections dont match the HTTPS paradigms. go check it out if you want to dive into the details.

There is a DNS record that can help with email encryption, but client tools are probably lagging (OPENPGPKEY). The MS announcement doesnt make this easier or harder.

@DrFlay, you may have conflated adoption of mail security with adoption of all possible DANE records. Until browsers come to the party web TLSA records are a novelty. This has no impact on smtp TLSA adoption.