Adobe Launch script hacking | Community

Level 4

Solved

Adobe Launch script hacking

Forum|Forum|3 years ago
December 13, 2022
1 reply
1928 views

Our devs have question on Adobe Launch Tag Management script as to what are the chances of bad actor hijacking the script and what kind of skills/tools which hackers can use to hack the script?

How can we detect hijacking so we can disable a user's access?..

Analytics

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by Jennifer_Dungan

Your Adobe Launch access should already be restricted to just people who need to be in there... not everyone with Analytics access should be added to Launch.

I suppose the risk of someone gaining access to the Launch Property would be the same as any system... if someone's credentials are hacked, someone could in theory have access to make malicious updates.

I don't know if the script itself could be hijacked.. but again, that risk would be the same as any other third party script I suppose...

If someone unauthorized did get access to someone's password, the same steps would be taken as any other site... go into the admin panel, remove access to launch (and any other Adobe products on the account), check the user's machine for malware or try to identify how their credentials were obtained, seal that up, change the password, re-grant them access.

Luckily there are logs and revision histories on the rules and data elements etc... if you are using the Adobe Servers to host the files and have , there is an option to turn on archives, which allow you to republish (up to 3) I think deployments back...

If you are self-hosting, I think you just have to create a build with your previous rule and element revisions and re-deploy. (archive doesn't seem to work for self-hosted.. at least not for us).

I don't know how you would detect issues or malicious changes... I think you would just have to monitor the deployments.

Or you could create a "deployment landing zone". Have the Launch deployments go to a separate server, then have a job that needs to be manually run to copy those files into your production site... this would require your devops team to have some manual steps for the process, but then, only properly requested changes would make it to your production site.

Jennifer_Dungan

Community Advisor and Adobe Champion

Accepted solution

Community Advisor and Adobe Champion

Your Adobe Launch access should already be restricted to just people who need to be in there... not everyone with Analytics access should be added to Launch.

I suppose the risk of someone gaining access to the Launch Property would be the same as any system... if someone's credentials are hacked, someone could in theory have access to make malicious updates.

I don't know if the script itself could be hijacked.. but again, that risk would be the same as any other third party script I suppose...

If someone unauthorized did get access to someone's password, the same steps would be taken as any other site... go into the admin panel, remove access to launch (and any other Adobe products on the account), check the user's machine for malware or try to identify how their credentials were obtained, seal that up, change the password, re-grant them access.

Luckily there are logs and revision histories on the rules and data elements etc... if you are using the Adobe Servers to host the files and have , there is an option to turn on archives, which allow you to republish (up to 3) I think deployments back...

If you are self-hosting, I think you just have to create a build with your previous rule and element revisions and re-deploy. (archive doesn't seem to work for self-hosted.. at least not for us).

I don't know how you would detect issues or malicious changes... I think you would just have to monitor the deployments.

Or you could create a "deployment landing zone". Have the Launch deployments go to a separate server, then have a job that needs to be manually run to copy those files into your production site... this would require your devops team to have some manual steps for the process, but then, only properly requested changes would make it to your production site.

xcode2295Author

Level 4

Thank you for the detailed response! Appreciate it. I will pass it along to our devs.

Level 10

As mentioned above Adobe Launch access is restricted so this should fix/solveany security issues regarding access. Having said this there are several other security aspect that your team needs to be aware of:

Extensions

When you install an extension you might thing that they are "safe" meaning that Adobe done all the necessary check to validate no malicious code will be injected. Well this is not true.

The "public" extensions are being reviewed by Adobe when they are submitted for public use but when I queried with Adobe they confirmed that they will check it that it does not break Adobe Launch when installed and that all of the settings are correct but in terms of the views code and the javascript bundled in Adobe Launch main library or delivered via adobe launch are not vetted.

This opens to several kind of issues:

if the code injected in Adobe Launch view contains malicious code it might be loaded to your Adobe Launch end users, so even if they are meant to use Adobe Launch they might be affected or some sort of machine compromise could happen. Adobe did say that even if malicious code is present in the view it would be unlikely that it would affect the user machine as it is loaded in an iframe.
if the extension bundles malicious code in the adobe launch library then it will compromise your website platform and might either affect your site performance and security but also your sit users.
- this could be as simple as injecting another library when the actions/data element/condition from this extension runs or when the core library loads.

SOLUTION:

Never trust third party public extensions! We opted to only trust extensions developed by Adobe itself AND hosted on the official Adobe github account. Be aware that some extensions that are labelled as adobe or adobe consulting are actually not developer by Adobe as they are not hosted on Adobe Main github account
Always review extension code, load your main adobe launch library without the ".min", so replace ".min.js" by ".js". This will display the source of the library in an unobfuscated way. Review all code related to the public extension and vet it.
Never trust that an update of an extension will not include malicious code. It can be intended (someone compromised their github repo and committed malicious code) or unintended they added some code that works for the intended feature but how they coded it will compromise your platform. Same as above review source code with .min

Custom Code

In most tagging implementation your tagging team will use custom javascript code to achieve specific tagging requirements. It can be that the tagger is not knowledgeable enough with JavaScript and will seek the code to achieve the functionality on the internet and will just copy paste this. So the rule is that any custom code should follow your coding standards, should be refactored and not copy pasted and should be peer reviewed prior being released.