Avatar
Dr. Hax
d30ea98ea65e953f91ab93f6b30ea51eb33c506f87d49f600a139aef00aa9511
Cypherpunk. Infosec veteran of about 15 years (vulnerability research, exploit development and cryptography). Cypherpunks write code. :-) Signet maintainer. Self-custody your passwords... in hardware! https://hax0rbana.org/signet Want to see wider adoption so Bitcoin can be used as digital cash and not just an investment vehicle. XMR: 44RDkTFmTeSetwAprJXnfpRBNEJWKvA5dBH5ZVXA4DofgoZ9AgjyZdSa2fo7pMD3Qe3pdKga8X22y3Lyn1xYde5kPQPzVUu

TIL: RFK Jr was arrested in 2013 for protesting the Keystone XL pipeline.

https://www.huffpost.com/entry/robert-f-kennedy-jr-arrested_n_2679609

#ClimateChange #environmentalism #CivilDisobedience

For any defenders out there who want some unsolicited advice about #exploit #detection. I got you. πŸ˜„

You might want to use auditd to log all invocations of the fork() and clone() syscalls. All successful calls to system() will result in one of these being called.

If you only monitor calls system() (which is a libc function), it's possible for a payload to just invoke the syscalls directly and you will miss new processes spawning.

The documentation for auditd is decent, but using it effectively does require a bit of knowledge about the #kernel and specifically #syscalls.

In addition to looking for processes, you can also look for files being opened, read, written, and tons of other things of interest.

None of this will stop any attacks, but it can help you know when you've been pwned and do some #forensics after the fact. Of course, to be of any practical value, you'll also need to detect the anomolous behavior via the log messages and ship an alert to another machine as quickly as possible.

The fastest way to do this is usually to ship the logs directly to a syslog server (or two) and do the analysis there.

As you may have guessed by now, I've personally done this. On some machines, it's extremely expensive (in terms of CPU & I/O) because a lot of these so-called cloud native apps want to do SO MANY SYSCALLS! Oh mein Gott! It's complete madness. Those systems take a lot of resources and a lot of work to deal with. If they are mission critical, that sucks.

But if compromising those services only gets the attacker a launchpad, and doesn't compromise anything that is really critical, you can sometimes cheat by lowering the amount of syscall monitoring on that box and focus on #network traffic from/to there.

Hopefully that critical machine doesn't need to talk to tons of arbitrary servers or if it does that is confined to one, untrusted network interface. If not, again, that sucks. Try to split some things up if you can. If not, you'll be in for a lot of work to do a reasonable job at exploit detection.

Remember: When formulating your detection routines don't ask the question of "how could I detect this payload?" Ask the question "How can I detect all payloads?"

You probably won't get to "all" payloads, but that framing helps avoid the problem of keying in on #exploit / #payload specific things that are trivial for the attacker to change. Detecting when the web server tries to access some file outside of the ones it normally messes with, on the other hand... that's harder to bypass (unless your web server can access /dev/sda or something similar, but if that's the case, you have bigger problems!).

I have plenty of suggestions for also thwarting the #attacks too, but this post has gotten long enough. As a teaser: a lot of the protection revolves around locking down permissions and limiting the syscalls that users or processes have access to. Maybe I'll post about that in the future.

#security #infosec #cybersecurity #cyber #cybersec #hacking #BlueTeam πŸ’ͺ

nostr:nevent1qqswwywsvu3ufcy9syvs9k26a3un970gdgldc3s8fp6445nr9ewz2kgpz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzp5cw4x82vh5487g6hylkkv82284n83gxlp75nasq5yu6auq249g3qvzqqqqqqyah7gv6

Now to take a break from talking about backdoors and vulnerabilities to post a picture of our #oregano.

The bottom layer is store bought, the top is home grown. It's all oregano. Same genius and species.

I think I'm winning on the oregano front, but I admit the factory producers have me beat on volume and efficiency. I'm cool with that. 😀

#spices #homegrown #gardening #homesteading #prepper

I really need to find a Nostr client for Android that doesn't disable the built in spell checker.

Wow, right after I posted that, I found out that the same account that introduced the xz backdoor also introduced a vulnerability into libarchive in 2021!

It wasn't caught until two days ago, and only because the xz backdoor happened to get caught.

So yeah, more evidence that this happens more frequently than people realize.

Source: https://boehs.org/node/everything-i-know-about-the-xz-backdoor

nostr:nevent1qqsrfpv29tlkx370wgd0ax8qm38k6kt5433q3a9l6gyxuhhhrzn6awspz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzp5cw4x82vh5487g6hylkkv82284n83gxlp75nasq5yu6auq249g3qvzqqqqqqyymdqcv

As I said before, there are a lot of lessons for payload authors here.

- Don't include the real payload (stage 2) in everyone infected, only in those who are exploited. Infection (stage 1) should just enable delivery.

- Always encrypt and sign your payloads, both for confidentiallity and to make sure others can't use your backdoor.

- Make sure captured payloads can not be replayed against everyone

- Don't phone home

- Make sure your stack is aligned!

- Stash your stage 1 in files that evade scrutiny (a unit test case file was good, but now that's been burned and people will be looking closer at those, at least for a while)

- If you do put a payload in a unit test, be sure to write a test that uses said file, and add some chaff so it's not immediately obvious that it's an obfuscated shell script

nostr:nevent1qqswwywsvu3ufcy9syvs9k26a3un970gdgldc3s8fp6445nr9ewz2kgpz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzp5cw4x82vh5487g6hylkkv82284n83gxlp75nasq5yu6auq249g3qvzqqqqqqyah7gv6

Replying to Avatar Alex

I was also very surprised/confused by that. But searching salsa.debian.org for liblzma doesn't turn anything up. I'm not sure why that one isn't built from source. πŸ€”πŸ€·β€β™‚οΈ

Here are dome ways non-developers can help:

Give issues that affect you a thumbs up on the issue tracker (GitHub in this case). Same for feature requests on the issue tracker. This shows the developers what things people want them to work on. They may not do so, but it enables them to make an informed decision.

On a related note, don't post comments like "this affects me too" on the issue tracker. A thumbs up indicates this and having a long list of comments like that risks people missing something important.

Help with testing and add any details that are missing. Steps to reproduce the issue are critical. Other examples: "this bug doesn't affect Android 13 and below" or "introduced in version xyz".

Be concise with your comments.

Link related issues together. Often it's helpful to know about other issues when a developer is already in that section of the code working on something else. Plus, it can help avoid making one problem worse when fixing another.

Creating a bounty is a good one, if you can afford it.

Spread the word about the project. I know this one sounds cheesy, but the more users a project has, the more likely it is that additional people will help with all of the things above (or people you share it with might be developers who can help with the code).

It's been a known issue for months, but fixing it doesn't seem like a priority.

https://github.com/vitorpamplona/amethyst/issues/757

In fairness, I also am one of those people who has not been fixing it. But I just made a comment on that ticket to try to help find the bug in the code.

If anyone else can jump in with helpful comments on that ticket, please do. Or even just give the reporter a thumbs up to show how many people are affected (and also have a github account, and are willing to tie that account to being an Amethyst user).

I like how the beave reacted to that poat with a party icon. 🀣

Also, I'm not tagging them because #Amethyst still crashes when I try to tag someone. And before someone tells me that the crash is my fault because I use the "wrong" keyboard, sod off pal. I should have the #freedom to use whatever keyboard I want and not have tagging someone break, and also, it happens with the stock Android keyboard so I assure you, it's an Amethyst problem, not a me problem. v0.85.3-fdroid

My #signet Saturday update this week is super boring. I'm abstaining from using my desktop while everything gets backed up and all backups are integrity checked.

Then, some hardware switches, and then I can install #Qubes 4.1 and 4.2 in parallel on two different machines, restore my #backups to the Qubes 4.1 machine (where Signet works) and use that for a few months until it hits EOL on 2024-06-18.

More importantly, I'll be doing side by side experiments to figure out what's going on in Qubes 4.2!

Since it's not going to have my data, I could even set it up without a USB qube, which is basically unthinkable for my desktop. I've been using a #USB #qube for so long, I kinda forgot that it was even optional. It is just "how Qubes works" in my head, but in reality it's "how I've configured my Qubes installation to work".

There are plenty of lessons for attackers herr in this case study, but not much new for defenders. It just reenforces things security professionals have been saying for a long time.

1. Building from source is safer than downloading binaries

2. Reproducable builds can help spot differences between the source and binaries

3. Don't run services that you don't actually need (like SSH)

4. Make your systems as stripped down as possible (complexity is the enemy)

5. Compartmentalizatiton

6. Set up automated detection and response

7. Network segmentation (e.g. only allow SSH from an admin network)

8. It's better to build software that doesn't require constant updates (so there's more time to give scrutiny to the changes that are made)

9. Source code scanners and manual audits are good but not sufficient on their own

10. Many backdoors will have side channels (like performance issues) that can give them away. However, because of constant updates and complexity of most software nowadays, there are tons of other opportunities of performance issues to crop up. Also, some backdoors don't have a noticable performance impact

It's all pretty standard stuff here.

nostr:nevent1qqsppca5hst8f6ew34l8qzsnr654m0cc7cd04xmgzpad2gyaxfd4qcqpz9mhxue69uhkummnw3e82efwvdhk6q3q6v82nr4xt62nlydtj0mtxr49r6enc5r0sl2f7cq2zwdw7q92j5gsxpqqqqqqz9ankwg

Hi. πŸ‘‹ I have a vegetable garden and while we do not intend to grow 100% of our food, I post under the #homesteading hashtag and enjoy others posts on the topic.

I can't speak for others, but I can say why I personally spend my time on gardening.

1. Fresh vegetables from the garden taste better

2. We've seen supply line problems in the past and expect them to continue in the future

3. It's more convienent to get vegetables from our yard than from the store (they don't go bad as fast when they're still growing)

4. We have concerns about effects of climate change, political unrest, and other societal problems causing trouble and want to be at least somewhat self reliant

5. It's far less stressful than a day job

Those are all just off the top of my head, so perhaps not articulated well, but none of them are addressed by transacting in #bitcoin or buying food.

You're absolutely right that it's hard work and that I would be financially better off if I went back to a job in infosec. And we've been doing this for a few years now and we would be unable to survive on what we produce.

And yet, here I am, choosing to not have a job and instead spending my time making open source hardware and software, gardening, and walking or riding my bicycle places when I could afford to take the car instead. I don't think that many people who are on the homesteading bandwagon are doing this because it's cheaper than earning a salary and paying for food. If they are, I agree they'll go back to a day job sooner rather than later.

Also, we are getting better at preserving our harvest too. Some of it is dehydrated, other crops are frozen. We'll eventually get around to canning. So one huge crop failure would suck, but it'll be tolerable once we build up some more stock.

One of the reasons we never plan on producing all our own food is that we like dairy products, but we don't have room for (or desire to have) cows or goats. We also don't have the land for grains, but we're happy to get those from local farmers. Relying on ourselves and our neighbors seems much more reliable than relying on international trade and food that is shipped/trucked/flown in from thousands of miles away.

The xz package was backdoored, and the payload appears to be targeting SSH on x86_64 Fedora and Debian.

What you need to know:

- The backdoored version did not make it into any stable distros

- It was caught about a month after it was introduced

- It did make it into some bleeding edge distros (e.g. Debian's unstable branch: sid)

- It only affected the binary releases, so if you build from source, you were safe from this one

- It was only caught because the backdoor caused some tests to take a half second longer, someone noticed this and decided to investigate why

Get the technical details directly from the person who discovered it: https://www.openwall.com/lists/oss-security/2024/03/29/4

I found the Yubikey very difficult to use with a PIN. It worked okay without one but:

A.) That's not what I want, and

B.) Some systems won't accept devices that are not PIN protected

So I'd disrecommend them unless you extra money and want to play around with it to see if it'd work for your use case.

I haven't personally used a NitroKey, but I did verify that they really do publish their hardware schematics and code. I'd build one of my own, but they're so reasonably priced, I can't really justify that amount of time and effort for something I'm only moderately passionate about.

And if you like The Crystal Method, you should check out The Chemical Brothers.

And I don't know about all of the songs by the Lo Fidelity Allstars, but I'll πŸ’― vouch for Battle Flag. It's from the album with my favorite title: How to Operate With a Blown Mind

"Every facet, every department of your mind, is to be programmed by you. And unless you assume your rightful responsibility, and begin to program your own mind, the world will program it for you."

--The Crystal Method, from the song Cake Hole

That entire album (Community Service) is amazing. I think you should be listening to it right now. I am.

(Yes, I know it was a sample and the quote comes from someone else, but it'll always be a crystal method quote yo me) ❀️

#music #lyrics #GrowNostr