The DMZ

« first day (3959 days earlier) ← previous day next day → last day (913 days later) »

12:36 PM

and the facepalm of the day, for the lack of something stronger:
https://www.businessinsider.com/florida-school-says-vaxxed-kids-quarantine-30-days-each-dose-2021-10

vaccinated kids must quarantine, but unvaccinates ones go to the school...

1 hour later…

Anders

1:41 PM

@ThoriumBR, looks like "Florida Man" has gone into the school business. Maybe he should just go back to aligator framing or whatever he was doing before.

Question: I got an email from a bank that looks a bit fishy. Their customer support says they did not send it. However, according to Gmail both the SPF, DKIM and DMARC checks out. If this is indeed a fishing attempt, doesn't that mean that the bank somehow royaly screwed up their email configuration?

(As you can see, I know very little about these email header thingies.)

A. Hersean

Looks like a royal screw up to me.

gaazkam

2:06 PM

Difference in mindset between a dev (me) and security obsessed IT guys continues

My understanding of the purpose of signing executables: These are to make certain that we are not impersonated and malicious executables are not distributed in our name.

IT guys demand that our executables check if they are signed and refuse to start if the signature does not match.

Me: WTF?! An attacker distributes malicious executables in our name that they have full control of - they won't refuse to start because our executables have such a check? This security measure is superfluous: if our executabels are genuine then it protects against nothing, if the executables are not ours then they do not contain this check at all!

IT Guys: "An attacker compromises the account under which the executable is run. The client's account, not ours. Yes, an attacker may then modify the executable to remove the check, however this will cost them time, time that may be used to detect and stop the attack."

Another example.

IIS must not store the connection string to the SQL server in plain text, according to IT guys. This must be encrypted.

Me: "Wtf agani?! The encryption key must be accessible with the same rights as the encrypted connection string. An attacker who has compromised the system account under which IIS runs will also have access to the key. This protection, again, protects against nothing."

IT guys: "While an attacker will be able to do this, doing so will cost them time, time which may be used to detect and stop the attack".

This repeats over and over... Apparently, I am guilty of having a 0-1 approach to security. Either an attacker can do something (so putting obstacles achieves nothing except inconvenience us) or the attacker cannot do something (so putting more obstalces, again, achieves nothing except inconveniencing us).

But the correct mindset is layers. Theoretical can or cannot is not an applicable mindset here; rather, the correct mindset is how easily they can. Obstacles may and should be stacked on each other. If none of such stacked obstacle is enough to theoretically make it impossible to do something, then they all will at least buy us time, and this is a very major achievement.

If one obstacle is theoretically enough to stop the attacker, then in practice this obstacle may still be penetrated (0days and the likes) so further obstacles are not superfluous.

But I feel like I'm spending the majority of time implementing BS requirements of IT guys rather than important features...

Was signing executables ever intended to protect against them being maliciously modified on the target machine? I think that from the very beginning they were only meant to protect against impersonations and/or them being maliciously modified on the machine used to distribute them!

gaazkam

2:36 PM

... two weeks ago I was so annoyed at IT guys and their "BS" requirements that I took two weeks of vacations

I guess this helped me to gain some distance to the problem

I think I am beginning to actually understand their mindset, even though it still annoys me :/

But, grudgingly, I must admit that they may have a point

Even though this still seems to me to be an exaggeration

2 hours later…

CaffeineAddiction

4:30 PM

the point of signing an executable is to verify that the executable was not tampered with when aquiring it though non-trusted means (eg: email, ftp, http, mirror)

The attacker can modify it, however, the modified binary will have a diff checksum and the sig will no longer match. You can also host a sha256 sum on the site that is offering the binary to check against. Sig is just another layer so that you can do it locally assuming that your local machine and thus your local machines repo of trusted public keys hasnt been tampered with.

@gaazkam technically, if you want to do it right you store the password on a diff box such that its accessible via an api call ... another layer that can easly be overcome ... but it is off box, which means that the attacker has to compromise another box to remove the log message of accessing the key or figure out how to snag it from memory on the box they have control over ... which isnt impossible but would be a bit more of a head scratcher.

but then again, your using IIS ... so security isnt really your focus

gaazkam

4:47 PM

@CaffeineAddiction So the point of signing an executable is not to protect against it being modified because the machine it is meant to be run on was compromised (the paranoia of our IT guys) and therefore making the executable refuse to start if the signature does not match itself has little point?

@CaffeineAddiction Well, we still have to...

@CaffeineAddiction Assuming (as our IT constantly assumes) that the box that runs IIS is compromised will the attacker really have to make this api call? won't they be able to "just" read it from the memory of the running process?

CaffeineAddiction

kinda, signing is to verify the executable you have localy matches the version you intended to download and was not modified in xfer.

if you have something localy modifying it, all bets are off

hell, they could compromize the system used to check the sig and not even have to mess w/ the binary at that point

4 hours later…

Fire Quacker

8:39 PM

@ThoriumBR Well, you know that scanners actually have a tiny elf inside that paints a miniature version of the document that gets stored in your computer. If he doesn't have any ink, no miniature picture.

ThoriumBR

maybe the scanner scans, prints, scans again and sends to the computer...

« first day (3959 days earlier) ← previous day next day → last day (913 days later) »

all rooms