It’s almost Halloween — the one night of the year when witches, ghosts, and vampires roam the streets. And if you thought those were scary, think again. In our connected world, cyber threats and attacks are lurking all around us, ready to spook people and companies every day.

Whether it’s data breaches, password phishing or mobile device hacks, cyber threats are among our biggest fears. The best way to combat these fears, is to look at the biggest hacks straight on and better understand how they happen.

Therefore, in the spirit of Halloween and Cyber Security Awareness Month, here are the top Halloween Hacks and how to avoid them. We hope that by sharing these stories (and tips on how to best handle similar situations) we will make the Internet a little less scary this Halloween.

Dangerous Assumptions Client-Side.

We’ve all seen issues with sensitive credentials stored in page source or exposed configuration files server-side. For traditional client-side applications this remains a dangerous assumption as depending on the architecture of the application, they may be reversed in various ways. For .NET and Java applications, review of bytecode or decompilation to close source allows attackers to discover sensitive information including, backend hosts, credentials, certificates. In addition to this, a direct understanding of the application’s code allows rapid discovery of business logic flaws and API to exacerbate known issues, e.g. poor input validation, overly-broad trust of connected systems, or assuming you can trust “your” client-side application. If it runs on someone else’s machine it’s not your code anymore – input validation and properly-implemented code signing notwithstanding, they help.

Like with the web, do not count on compilation as a defense to discovery or understanding, be it to assembly or intermediary languages. Obfuscation can slow an attacker nevertheless via annotation and invested effort these may be reversed and understood for the same purposes. For these reasons do not trust client-side input or client-side protection of sensitive information. Instead, separate responsibilities and validate expected input server-side for sensitive actions.

Spoofing and Account Takeover.

Take care with what information is considered user input. For parameters from a form or user interface elements this is widely understood. What if you trust a “from” email from certain accounts? Be aware that unless you’re properly validating the email is from the corresponding domain this is spoofable like spam, user-controlled, and the trick can be on you (or your administrative users as we’ve seen in the wild).

Like direct user input only trust hosts you can control, properly identify, and validate expected input from.

Ghost Integrations

You’re only as strong as the weakest link in your armor. Are you controlling sensitive secrets across your development team? What if one of your developers commits credentials to GitHub?

In our connected world this can be both to your applications directly but also trusted third parties such as Slack. Be mindful of the integrations we support for collaboration and convenience which may expose your users and infrastructure to attackers. It’s a treat for hackers to search GitHub for Slack user tokens of which there are plenty, e.g. (xoxp-.* xoxb-.*). Don’t be tricked by a small mistake that opens what might be your organization’s central collaboration tool, including: sensitive attachments, related integrations, more recon like team/usernames.

How do you fix this? Education of your internal staff, auditing from an adversarial mindset, least privilege, and rotating secrets.  

There are a lot of scary bugs out there – and I’m not just referring to the creepy, crawly kind — but with the right precautions you can mitigate the threat and sleep like the dead.