Re:After 36 years as a paid product, the Micro-Cap Circuit S...
by labawi on Sunday January 12, 2020 @08:09AM
(#22026123)
So.. you haven't heard of automated MITM executable-patching (infecting) solutions? I believe I read about them a couple of years ago.
Once implemented, it's much easier than hacking servers and more convenient to do targeted, semi-targeted, local network/cafe script-kiddie attacks, without it being easily detected. Unfortunately for attackers, these days people don't download and run unverified executables as often, especially over http, so you may need lots of patience if you want do infect a specific person.
Re:After 36 years as a paid product, the Micro-Cap Circuit S...
by someguydave on Sunday January 12, 2020 @06:44PM
(#22030587)
I covered that in the portion of the comment where I mentioned http/tcp
Re:After 36 years as a paid product, the Micro-Cap Circuit S...
by labawi on Monday January 13, 2020 @06:21PM
(#22039892)
I would really love some data (or good reasoning) on how server attacks are overwhelmingly more likely, so much so that the false security impression increases risk.
MITM executable patching attacks are not theoretical. AFAIU, the first hit on "mitm executable infection" [1] and an interceptor (ARP/wifi/whatever) is all a script kiddie needs.
Re:After 36 years as a paid product, the Micro-Cap Circuit S...
by someguydave on Saturday January 25, 2020 @01:23PM
(#22147700)
To me, the fact that the server being exploited to deliver bad binaries is a possibility is reason enough to be cautious, and to therefore not regard them with any more credibility than if they were delivered over unencrypted http.
Therefore, an unsigned binary is an unsigned binary, no matter the transport mechanism. I agree that distributing unsigned binaries is poor security practice, but I also think that it is dangerous to think that the transport of an unsigned binary over an SSL connection gives it any credibility.