Saturday, July 28, 2018

winblows update

so i'm using my computer thursday night when i get a notification that updates have been applied that require a reboot. ok, whatever, i've mostly come to terms with the fact that Windows 10 updates itself without asking me, at least it asks me when is a good time to reboot. that wasn't a good time so i said later.

well, later came in the wee hours of the morning when i was done working and ready to head to bed. i go to shut off the computer and the new options in the shutdown menu remind me that there was an update to take care of, so i choose the update and reboot option.

i chose that option rather than update and shut down because, from past experience, the update process has not actually completed by the time the system shuts down. there's a bunch of stuff it needs to do on the next restart and that takes up time i could be doing something else, so no shutdown just yet, just an update and reboot and i head off to take care of my evening oral hygiene routine thinking that the process would be done by the time i get back.

when i come back the computer is still in the process of rebooting? what the heck? oh no, i've seen this before (or at least i think i have). is the computer stuck in a reboot loop? powering off for a few moments usually breaks out of the loop, but this time i discover it wasn't a reboot loop at all. when i let it power up again i see a screen saying that it's applying updates and that several reboots will be required.

are you kidding me? this is not what i want to deal with in the wee hours of the morning when i still have to go to work the next day. this is not convenient, and frankly "several reboots" for an update is bullshit. i understand the need to perform a reboot during an update; files and other resources that need to be changed may be locked by running processes and rebooting eliminates that impediment, but several reboots? Microsoft has been at this update business for decades now, you'd think their little minions would have figured out how to coordinate their efforts so that each part of the update could make use of the same reboot, but no, apparently that kind of unified effort is beyond them and in fact they seem to be moving in the opposite direction where every bit and piece of their updates (and the operating system itself) is becoming more separate and isolated from the others.

so i did what i hate doing. i left the computer on completely unattended overnight so that hopefully by morning the update would be done. and it was, but that's not the end of the update related problems. you see, Microsoft's updates aren't just for security fixes. those are important, yes, and the fact that people were taking too long to apply them and leaving their systems to become part of massive botnets is part of the reason the user's control over updates was taken away from them. however, Microsoft has re-imagined how versioning of their operating system will work so those updates now also come with feature changes, which (due to the increasingly isolated approach units within Microsoft are taking nowadays) means new binaries with new behaviours.

how the hell is anyone supposed to develop a behavioural baseline for their system with this never ending parade of new binaries and new behaviours? this morning's culprit? BackgroundTransferHost.exe. what does it do? who the hell knows? not only does Microsoft give us less agency now that we can't control if/when updates occur, but there's also less transparency now too because the number of separate/isolated binaries they're introducing to the system has far, far outpaced anyone's efforts to document them.

maybe BackgroundTransferHost.exe isn't even Microsoft's. maybe it's malware. if i were going to make a downloader trojan, that sounds like just the sort of name i'd use - but what do i know, i'm not a malware writer. i suppose they expect me to trust it because it's signed, but that's not how that works. being signed (and passing the signature validation procedure) just means it hasn't been modified after getting signed, not that it's legitimate, not that it's safe, not that it's trustworthy. signing certificates get stolen. there's plenty of signed malware out there.

oh, and the cherry on top is now VMware is non-functional.

what the actual f#$% Microsoft. stop making alternative security approaches so much harder than they have to be. i'm regretting moving on from Window XP. at least there i could perform application and behavioural whitelisting with relative ease.

Sunday, February 04, 2018

thoughts on attack automation

axiom: there is no perfect security

because there is no perfect security we can say with certainty that systems will never be perfectly secure. if we close one vulnerability there will always be another to take it's place. we can spend an unending amount of money/time/effort on closing vulnerabilities and still remain vulnerable. in the process of doing this we would go bankrupt because no one, not even the largest companies in the world, have unlimited resources to spend on security.

therefore, eliminating all the vulnerabilities is not a viable strategy. instead a promising alternative is to approach the problem of security from an economic standpoint. while we can't eliminate all the vulnerabilities, we can eliminate some, and if we eliminate the ones that are easiest to exploit then an attacker's job becomes harder and more expensive to carry out. if we make the attacker's job hard enough then the value/benefits they derive from succeeding in their attack (success will always be possible) would no longer cover the cost of launching that attack.

attack automation doesn't make an attacker's job harder. quite the opposite in fact, it makes it easier. attack automation is carried out by attack tools. as a general rule, attack tools reduce the complexity of performing an attack. tools automate the fiddly bits to save an attacker time and effort but in so doing also save the attacker from needing to know how to do the fiddly bits themselves. this means that a larger population of attackers will become capable of carrying out a particular attack because the technical complexity of performing the attack is reduced. it also means there is a larger pool of targets to victimize because the lower cost of performing the attack makes attacking lower value targets economically viable.

additional automation to save the attacker time and effort when selecting targets and launching attacks is also possible, as the recent release of autosploit has highlighted. this lowers the cost of scaling up the attack so that a single attacker can attack a larger group of victims at a lower cost.

the argument can be made that attackers are entirely capable of making these automated attack tools themselves so it doesn't matter if security researchers do it as well. however, when researchers make the automated attack tools, not only do attackers enjoy cost savings with respect to launching attacks, they also enjoy cost savings with respect to developing the tools to launch attacks.

all of these cost savings for the attacker work against defenders. when the cost of performing an attack is reduced it means that attacks that didn't need to be defended against before (because they were too expensive to launch relative to their payoff) must now be defended against, and that increases the costs for defenders because it requires more to be done.

these cost savings are also permanent. attacks don't get harder, they only ever get easier. offensive security researchers are permanently changing the economics of mounting various attacks in the attackers' favour in an effort to incentivize defenders to do what the researchers think should be done to chase after the zero-vuln goal (a goal which we already know to be unattainable) without regard to the economic realities those defenders face.

enforcing their will, their vision of what security should be on others is misguided and damaging. there is no one-size-fits-all approach to security, and where the fit is bad there will be undue burdens with respect to cost and/or unfortunate breaches that might legitimately have been avoided if attackers had not been given a helping hand.

if attackers can build the tools that make their lives easier by themselves, then let them do it. make them pay the cost of doing it. stop subsidizing attackers in the name of security research. years ago the security research community embraced the idea that there should be no more free bugs - why then are the cybercriminals still getting bugs, and exploits, and frameworks, and more for free after all this time?