Any insight on this detected trojan inside the blobs?

Noticed Windows defender took this out. First time I’ve seen anything like this. Harmless?

It false alert, because blobs are encrypted.
Also, you can add blobs dir. to exclusion, no make any sense scan it.

2 Likes

PS: Make sure you restore that file.

5 Likes

By default… yes. There used to be an option to not use encryption. I think that’s now gone, but it’s still open source software. You can take out the encryption. Files are also split up and spread over nodes in a predictable way. It is theoretically possible to create erasure shares that end up on a single node form a working file when combined back into a piece.

It might even be possible to skip that entire process altogether and just upload a piece of code that isn’t a valid reed solomon setup if you alter the code enough, though that will not survive any repair or audit action by the satellite. This simplification isn’t needed though, the above method of having them recombine into working code through the RS process would work perfectly fine.

Edit: I should clarify, it’s unlikely that that happened here. I just don’t want to disqualify that option. It should be considered.

4 Likes

encrypted data is basically random, thus you will eventually hit some combinations that would look like malware, i would set my antivirus to disregard the entire folder… no point in scanning data you shouldn’t touch anyways…

the data is idle on your system and thus there isn’t a need to scan it, on top of that most will be encrypted, so i doubt it even can contain malware… its like scanning .txt files for viruses… utterly pointless

1 Like

I guess you didn’t read my post. Some people just want to see the world burn. You shouldn’t assume otherwise.

2 Likes

That would be a way to cause audit failures on nodes though.

1 Like


Thanks for the confirmation :smiley:

1 Like

What I meant was that this could be used to intentionally cause audit failures and get nodes disqualified.

Whether the piece survives audit or repair would not matter in that case.

1 Like

Ahh, I see. Yes, it’s a potential attack vector for the network as a whole. Though the offending customer could very easily be found and blocked if that would happen at large enough scale to do damage.
I’m not entirely sure you could get away with uploading pieces that don’t work to begin with though. There may be a check in place to prevent this that I’m not aware of.

I also do not know that, just saw what you wrote and though that the ability to upload a piece that would fail audits can be used for an attack.

Of course, maybe the piece would not fail an audit, no matter what is in it or maybe the node would reject it.

1 Like

The way audits work they rely on a property of erasure coding to check which pieces are incorrect. So if there is no erasure coding at all, it basically can’t audit any node. It’s possible, maybe even likely, this would not cause an audit failure for the responsible nodes as there is no way to determine which node is not returning the right data and it’s a bad assumption to then say none of them must have. Nodes can’t really check this as they only get one piece and you need at least 29 to be able to check whether the RS pieces are valid. But that’s as far as my knowledge on the subject goes.

It doesn’t really matter much as there is always still the option to specially craft segments to go through the erasure coding process and end up as working pieces of code on the other end. It’s a little more complicated, but definitely doable.

O.o i would just attack watchtower really… much more useful to be albe to push programming / extra containers to thousands of users and many might not even get it removed for years.

but i guess what you say could in theory be possible, but it seems like some pretty advanced shit… unless if one controls a storj satellite… i suppose…

and then again… now you got malware on the drive… you still need to node to actually execute it, and if it does that… then the antivirus will look at it, ofc we are in a level of custom code that it would most likely be written to go unnoticed by most antivirus shields.

i certainly won’t be antivirus scanning my blobs folder, just seems pointless from my understanding, but ofc exploits are created in the most novel of ways… and the impossible likely to only exist in the limitations of our imagination.

@BrightSilence i don’t assume people being benevolent, i just don’t think one can scan encrypted data without antivirus wasting time and going all bonkers chasing shadows in the encrypted data.

was just giving my 10 cents, think Odmin nailed it best tho… but only noticed that afterwards also xD

so to the point.

This is good information for people who are running windows this could cause a DQ to happen without knowing right away what caused it.

2 Likes

Yeah, I wasn’t saying that’s not the right way to go. It probably is. I was just responding to how easily this message was dismissed as a false positive, because everything is encrypted. It doesn’t have to be.

Of course your scanner would probably need to do quite a bit of work to scan everything, so it’s probably a good idea to exclude this data. But I would at least make sure it can’t be executed. These days attacks rarely stand on their own and are usually part of a bigger attack chain. Even if this doesn’t give an entrance to actually execute the data that is put on the node, putting the data there in the first place is one hurdle tackled as part of a larger attack chain. I’m not saying that is a big security thread just yet, I’m just saying it shouldn’t be ignored.

1 Like

Hmm… I remounted the storage partition with noexec parameter :slight_smile: I know it’s not foolproof, but there is nothing that should be executable there anyway.

3 Likes

I didnt think there would be a way for anything to be excuted cause the files are split so the full data wouldnt be there in the first place, right? Worst thing is if someone was able to turn our nodes into a huge botnet.

More likely exfiltration storage.

If you simply upload an executable file, no, that won’t work. But since the file is split up in a known way, you can skip encryption and craft a file in such a way that it ends up as an executable piece on someones node.

Don’t jump ahead though, this doesn’t give the uploader a way to direct where that piece goes or to execute it. It’s just one piece of the attack puzzle. So there’s no reason to talk about botnets at this point.

I don’t think this is going to be a problem… There are numerous other ways to get malware running and numerous other platforms to utilize.

One my main concerns as an SNO is the potential for personal liability for illegal information stored on my node. If everything is encrypted, then I can’t possibly be liable – since I could not have known.

There needs to be a way to ensure that all customer data is stored encrypted and that the SNO does not have the key… and can prove that the SNO does not have the key.

1 Like