News Report: (September, 2022) Uber hack made possible through MFA and hardcoded credentials in Powershell script

Well, before we judge the system administrator in this case, let us examine the possible reasons he might have had to justify putting credentials in a plain text script.

The first obvious reason would be for convenience. Yes, there are options available that can be utilized to protect credentials in a script

1. Generally, these options will require that your script initiate a network connection to retrieve the encrypted credentials

• While this might seem straight forward to some, there are some drawbacks.

• This method introduces an extra layer of complication into a process that was originally simple.

• What happens if that extra layer goes offline?

• Your script won't work.
• You would be at the mercy of the connection between your host and that external layer

2. Other methods include downloading and installing packages that aren't native to the language your script is written in (powershell in this case)

• Again, while this may not seem like a big deal to the uninitiated, it does have its problems.

• If you were to upgrade your operating system, there is the real possibility that the new OS version will be incompatible with your custom packages.

• And if you try to download **new or updated versions** of the packages, you may find out the original links no longer exists.

• And the rabbit holes that can result from this are painfully numerous.

So I ask again, what are the likeliest reasons the administrator at Uber hardcoded passwords in their script?

1. Because it was simply the easiest thing to do.

• So is he lazy? No. I wouldn't make such an accusation. Neither should you.
• It is likely that, when he (the administrator) considered the totality of the day to day work he was responsible for, taking that extra 30 minutes to an hour (probably longer) to find and implement a reliable solution was just too much.

2. Can we blame him?

• You can. But that would be unfair....considering what happened to him can happen to most of us in similar scenarios. Let's be frank.

• If you think it could never happen to you, that's probably because you dont write enough number of scripts for it to be an issue.

So how does atshai.com solve this problem?

1. First, we do the obvious. We convert your plain text code into an unreadable text

2. We provide various types of restrictions to apply to your script.

• Aggressive protection - Cause the protected powershell script to self destruct when it detects suspicious behavior

• Time ranges - Specify what time period your script is allowed or expected to run in.

• Host list - Specify a list of hosts on which your powershell script is allowed to run

• User list - Specify the usernames/accounts that are authorized to execute the powershell script

• Tamper Resistance - The first thing hackers will attempt to do when in possession of an obfuscated script, is try to alter it

• When that happens, you can be sure the protected powershell code will self-abort.
• There was a time they said it is not possible for a script to validate itself against unauthorized modifications

  • We clearly defeated that hurdle. We incarnated an inspiration and materialized it in the world of reality.

• Remote code monitoring - Enable remote monitoring during obfuscation of the powershell script

• This essentially means your obfuscated powershell script will be mandated to:

• Remotely validate itself with either us (enscrypt.io/atshai.com) OR
• An internal webserver in your environment

• If your protected powershell script is unable to validate itself at all, for any reason, it will abort and notifications will be sent out.

• Additionally, all associated dashboards will light up RED and will stay RED!

3. When all or some of the aforementioned restrictions are applied to a powershell script, you can rest assured your .ps1 code is safer than the alternative options.
4. We provide barriers and fortifications between the sensitive data in your powershell code and the outside world.

Some may ask, what happens if our powershell obfuscation can be easily broken?

First, it is not easily broken. But let us assume just for the sake of argument, that it is easily broken. Then what?

• Well, an attacker would first need to read through the obfuscated powershell script to understand what it does.

• A process that will NOT be completed within a few minutes.

• OK, Another scenario. Let's assume the attacker does manage to get a general idea of what our obfuscation does. What then?

• If he is arrogant and thinks he knows all, he will make the mistake of actually running the script on his own machine. and when he does this, a signal will be sent to us and it will be registered on a dashboard and alerts sent out to whoever needs to know about the incident.

• Note however, this particular protection is activated ONLY if the powershell script was obfuscated with remote monitoring enabled.

• Well, what happens if the hacker runs the code on a standalone system that isn't connected to the web?

• If the powershell script was obfuscated with remote monitoring enabled...the script will NOT function.

• It can even self destruct, if you really wish to make things as difficult as possible for a hacker.

When it comes to protecting powershell scripts, one thing is for certain, hackers will never be able to modify an atshai.com protected code, and expect it to behave normally with their foreign changes.

• In contrast, if a hacker gets a hold of an unprotected plain text powershell script (as was the case at Uber), all he has to do is read through it, make some changes to it, remove or add custom lines of code. And thats it.

• He will be able get the script to operate how he wants.

• BUT, if that same hacker gets a hold of an atshai.com obfuscated code, modifying it will only render the script unusable, corrupted...And can self destruct when confronted with unexpected conditions.

• NOTE, self destruction of a protected powershell script activates only IF 'aggresive protection' was enabled during the obfuscation process

So how is the atshai obfuscation better than existing methods of code protection?

• We take your plain text powershell scripts and obfuscate them AS THEY ARE

• We do NOT require you to do anything to your scripts. Only submit them and that's it. You can go with your life.

• We do not require 3rd party packages (packages that arent native to powershell or windows)

• We give you the option to choose between remote monitoring or local monitoring, or no monitoring.

• We provide dashboards to help you keep tabs on the health of your scripts

• Health meaning; the visualization of all records of attempts to execute, modify or tamper with your code - know when your code is executed in conditions outside of the ones you defined.

The most common discouraging comment often lunged at those of us who dare to endeavor to protect code is..."whatever you do can be undone by a determined hacker".

Our response to that is this:

• Case scenario:

• Suppose a hacker gets a hold of an atshai.com protected powershell script and manages to crack it.

• We find out about this, and decide to accost the hacker with a question: Hey Mr./Mrs. GeniusHacker, can you tell us precisely what you did to crack it?

• The response given to this humble question is often eye-opening.

• The hacker can only respond to it in 2 or 3 ways:

• 1) Sure, this is what I did. **proceeds to list the steps he/she followed**

• 2) Nope, not going to tell you !

• 3) **Reveals only partial information, not the full steps performed**

• A hacker who leans towards #2 and #3, is unwittingly making a statement and admission, which essentially boils down to...I AM WORRIED IF I SHOWED YOU HOW I HACKED YOUR OBFUSCATION, YOU WILL BLOCK THE LOOPHOLE

• And my friends, that statement would be correct!

• But then, one has to wonder...why is Mr./Mrs. GeniusHacker worried? Any obfuscation can be undone by a determined professional? Right??

• See, the reality is, we are not going to run out of ideas on how to protect code nor are we going to get tired of it. But, we know those who are convinced of the impossibility of code protection will eventually deplete their arsenal of tricks.

• We are certain, if there are ways to crack our obfuscation, they will become useless the day we find out about them. Counter measures will always be rapidly developed to null all loopholes.

Finally, we believe when the cynics and critics go as far as to publicly deprecate (put down) the impact of obfuscation as a useful technique in protecting code, it is important you understand they have their own agenda. A bonafide way of protecting code spells disaster for them.

• They need code to be in plain text, under the guise of open source...because they glean a lot of their ideas for commercial products from those open source plain text scripts

• You can often get a whiff of their intent by examining the arguments they put up in opposition to code protection. Their argument is that any obfuscation can be undone by a determined, seasoned professional, therefore, dont even bother with it.

• By that shockingly superficial logic, it is absolutely unnecessary to roll up the windows in your car when you park it on the street.

• You should leave the doors to your house unlocked. After all, doors can be easily broken into, right? Windows can be easily shattered, right?

• Conveniently, they ignore the fact that obfuscation of code, by definition, buys you a lot of time...more time than the alternative plain text option.

Above all else, there was a time developers relied only on system privileges, settings and file permissions to help manage or restrict access to their scripts. That is no longer the case today, in the year 2023. AtShai.com has invented a code protection mechanism capable of barricading plain text code from public view so that any random person who gets a hold of it will be unable to reverse engineer it to make it behave in a way it wasn't intended to.