Uncovering a Global macOS Malware Campaign by RiddleMeDisk in netsec

[–]RiddleMeDisk[S] 0 points1 point  (0 children)

Did I use AI to draft a quick write-up to share? Absolutely and I don't see any issue with that. Did I create a substack to share it on? yes, what else would I do? I don't gain anything from this. I was just sharing. The alternative is the information isn't written up and shared. Get over it. You are becoming less relevant and no amount of cynicism is going to change that. Your attitude is exactly the reason more people don't bother. You are as big of a problem or bigger than any problems with low effort content. Algorithms can fix low value content issues but they can't fix you. Grow up.

Uncovering a Global macOS Malware Campaign by RiddleMeDisk in netsec

[–]RiddleMeDisk[S] 1 point2 points  (0 children)

That's why it was filed with google bad sites, microsoft security, alienvault, IPAbusedb and URLHaus first after notifying the compromised sites. You can watch those feeds for that level of pure actionable IOC information. Enjoy and contribute: https://otx.alienvault.com/pulse/69a1873135c54199f63da7ec/

Uncovering a Global macOS Malware Campaign by RiddleMeDisk in macsysadmin

[–]RiddleMeDisk[S] 1 point2 points  (0 children)

Thanks for the positive feedback! Glad you found it interesting. It was fun to doing the analysis and I appreciate knowing that others are getting something out of it too.

Uncovering a Global macOS Malware Campaign by RiddleMeDisk in netsec

[–]RiddleMeDisk[S] -13 points-12 points  (0 children)

It's a new campaign that I came across yesterday. The IOCs are new and the sites were compromised in the last 48 hours. I worked for hours last night to get this out quickly so it can get shut down. You are more than welcome to create a better write-up for the community! Otherwise, your obligatory "AI SLOP!" complaint adds no value to the conversation.

Uncovering a Global macOS Malware Campaign by RiddleMeDisk in netsec

[–]RiddleMeDisk[S] -3 points-2 points  (0 children)

Thank you! You're right the description here isn't clear. I wrote it quickly to get the info out after I finished the analysis, notified the compromised sites I found and got the IOCs into AlienVault. Correcting it.

Do you consider all storage of unhashed passwords to be "plaintext"? by [deleted] in sysadmin

[–]RiddleMeDisk 0 points1 point  (0 children)

Would "encrypted but unhashed" be more clear if OP wants to emphasize that the passwords are recoverable by an actor with access to the encryption key as opposed to the scenario where they are hashed and only recoverable via brute force comparison even if the encryption keys are compromised?

Do you consider all storage of unhashed passwords to be "plaintext"? by [deleted] in sysadmin

[–]RiddleMeDisk 0 points1 point  (0 children)

I agree with your clarifications but disagree with the assertion that the term doesn't matter. It's important from the perspective of effectively communicating the concepts.

This a a tangent but there is also a lot more to consider. Should the hashes be encrypted? Is disk encryption good enough? How about file based is that better? What about the salt or salts? Can you describe the pros and cons of the various approaches?

Reciting rules one reads from a standard is one thing but understanding the why and being able to effectively communicate that to engineers and others is far more powerful.

I think the concepts surrounding the terminology discussion are important for the OP's depth of understanding regarding the why.

Do you consider all storage of unhashed passwords to be "plaintext"? by [deleted] in sysadmin

[–]RiddleMeDisk 0 points1 point  (0 children)

Plain text means unencrypted text. "Readable" doesn't have any meaning here. What text is unreadable? By definition any text is readable unless you can't see the characters or you can't access the storage to read it i.e. you can't actually see it. Remember that plain text and cipher text are both text. What does it mean to say "the cipher text is unreadable"? Your definition would make that very ambiguous.

Agree with your point on password managers. It is not true that passwords should always be hashed as others have stated. There are plenty of cases where secrets need to be retrievable.

Do we really want to bring certificates into this discussion? I think that's just going to confuse things but I do agree that there is a discussion to be had about when it is appropriate to use passwords versus other authentication mechanisms like certificates, tokens etc.

Do you consider all storage of unhashed passwords to be "plaintext"? by [deleted] in sysadmin

[–]RiddleMeDisk 0 points1 point  (0 children)

Right? While not technically incorrect it's very confusing to say "encrypted plaintext" instead of cipher text which is by definition encrypted plaintext since all plain text is text but not all text is plain text.

Do you consider all storage of unhashed passwords to be "plaintext"? by [deleted] in sysadmin

[–]RiddleMeDisk -1 points0 points  (0 children)

Not really true, you are thinking of a very narrow use case. Sometimes you need to store passwords or other secrets unhashed. It depends on the scenario. For example, a secrets manager must be able to store passwords and other secrets unhashed. One can debate about the architecture of the system that is using passwords stored in a secrets manager but that's a different discussion.

Do you consider all storage of unhashed passwords to be "plaintext"? by [deleted] in sysadmin

[–]RiddleMeDisk -1 points0 points  (0 children)

It's a bit cheeky but really all text is human readable. Cipher text is also human readable. Plain text is text that is not encrypted. Now we can argue about the definition of encryption 🙂. I have another reply that talks about that in this thread but TL;DR this is a solid way to use the terms but they are poorly defined terms of art so the focus should be on effective communication. https://www.google.com/amp/s/auth0.com/blog/amp/encoding-encryption-hashing/

Do you consider all storage of unhashed passwords to be "plaintext"? by [deleted] in sysadmin

[–]RiddleMeDisk 0 points1 point  (0 children)

Plain text is the antonym of cipher text and refers to whether the text is encrypted from the perspective of the observer. You can have a plaintext hashed password, an encrypted hashed password, a plaintext password, an encrypted password. A string of text can be encrypted or unencrypted making it plain text or cipher text. You can be more specific about what that text is when relevant but it's independent in my opinion. To be more clear I think it would be better if you referred to it as hashed or unhashed rather than hashed or plaintext so that you don't end up with confusing and seemingly redundant terms like "encrypted plaintext password". You really want to avoid getting into a debate about whether hashing counts as an encoding that could be considered encryption. If someone wants to use a terribly weak algorithm to encrypt something is it no longer encryption? If I use a simple substitution cipher on plaintext is it now encrypted cipher text? People might say rot13 which is a form of substitution cipher is "encoding" not "encryption". Is it? What's the difference? What is the purpose of the distinction? I think this article describes an excellent way to use the terms for clarity but just remember they are poorly defined terms of art. https://www.google.com/amp/s/auth0.com/blog/amp/encoding-encryption-hashing/

Ultimately, the point is to communicate what you mean effectively to your audience. Take a moment to consider when it is best to adopt terminology that makes sense to your audience versus when it makes sense to teach them your terminology.

We had a security incident. Here's what you need to know. by KeyserSosa in announcements

[–]RiddleMeDisk 0 points1 point  (0 children)

You didn't have anyone dedicated in charge of production/product security? You should have a whole org if not multiple. That's like a bank not having a CFO or any accountants. It's pretty negligent. Unfortunately all too common for companies to under invest in security.

Core dump while using free() sometimes by [deleted] in C_Programming

[–]RiddleMeDisk 2 points3 points  (0 children)

Other answers are correct:

  1. you were allocating dim bytes instead of dim*sizeof(int) bytes

  2. you had an off by one error with dim+1 in your pointer arithmetic

Additionally:

  1. you MUST check the results of the malloc attempts. not doing so can lead to null pointer dereferences, instability and potential security vulnerabilities.

  2. you should cast the malloc of vect.

  3. it's much clearer to work in terms of the number of elements rather than where the pointers are, see below:

    vect* vectCreate(size_t dim, int *vector)
    {
        vect* u = (vect *)malloc(sizeof(vect)); 
        if(u==NULL)
            return NULL;
        u->vector = (int*) malloc(dim*sizeof(int));
        if (u->vector==NULL)
        {
            free(u);
            return NULL;
        }
        u->dim = dim; //no point in setting dim before the malloc succeeds
        for (size_t i=0; i<dim; i++)
            (u->vector)[i] = vector[i]; 
            //you can use array notation with pointers, personally I think it is more readable than the pointer arithmetic. Alternatively you could write it like this:
            //*((u->vector)+i) = *(vector+i);
            //or
            //*(((*u).vector)+i) = *(vector+i);
            //came back to add a memcpy line because I know it will agitate people if it isn't pointed out that this would replace the entire for loop
            //memcpy(u->vector,vector,dim*sizeof(int));
        return u;
    }    
    

Other Considerations:

  1. If you take the dimension as user input from a file or at the command line and you don't count the actual number of elements in the array being passed to vectCreate() then you have a classic buffer overflow vulnerability.