New years resolution: Don’t show my security tokens when hacking my demo application on stage
Traditionally, we start the new year with resolutions. We want to do more good things, like working, other things we try to eliminate. Considering the latter, my 2022 resolution is to stop accidentally exposing confidential information while I hack my application during demos on stage or similar.
Yes, this new years resolution sounds very specific, and it has an excellent security horror story behind it…
Hacking my demo application at J-Fall 2021
November 4, 2021 was J-Fall, the largest Java conference in the Netherlands. It is an annual event by the Netherlands Java User Group (NLJUG), and as a fellow board member, I was proud to have an in-person event again since the start of the pandemic. I was also selected to speak at this conference about a Java Security related topic. In this case, about deserialization security issues in Java.
As part of this presentation, I was hacking my application using a deserialization gadget chain. I used the well-known attack chain in the Commons Collections 3.1 library created to show how to hack my application with an arbitrary code execution (ACE). The setup was easy as I used ysoserial to set up the gadget chain, and the demo application that I was about to hack had the library included. So far, so good, but now the tricky part…
Exposing secret API tokens on stage
The ACE I was going to perform was calling the
env command on my machine and showing the output in my console. For those of you who are unfamiliar with this command, it shows the environment variables on the host machine. I often use a specific user on my demo laptop when I demo some application hacking. Alternatively, I sometimes use a Docker container, however, I did not this time.
This time, I performed the hack using my primary environment. This is the environment on my laptop I also use for regular development. As a result, my environment variables then also included some API tokens like my GitHub token! All of this was shown on the big screen in the large cinema room. 🤦🤦🤦
At first, I was unaware of this and entirely focused on delivering my presentation and demos on stage. However, afterward, one of the participants in the room, Nils Breunese (@breun), came up to me and said: “Hey, I hope you can appreciate this as a security guy,” and showed me the following picture on his phone.
At first, I didn’t fully understand what was possible. However, he explained the situation and used my GitHub access token to commit some code to my website. After realizing what happened, I was both embarrassed and relieved at the same time. This could have been so much worse than the simple prank he took on me. I immediately invalidated all tokens declared in my environment variables and fixed my website. I decided not to revert the commit by Nils but fix it in a new commit, so it is still visible as a reminder of my J-Fail.
Don’t hack yourself, just your demo application
Thankfully this turned out to be a nice story I can tell to other people. I want to thank Nils for being a good person with a sense of humor. For myself, this is a reminder that I need to practice what I preach. It is incredibly painful to be speaking about security on stage and hacking applications while getting breached in the process. So I want to conclude with that we should be careful about what we do and what is visible to others. Although tooling for your application, like the tools that Snyk provides, are helpful, it does not help against silly mistakes. You see, even security professionals mess this stuff up. Just try to be conscious about this and check what your output is before you publish your application to production or demo it on stage.
So my new year’s resolution for 2022 is: Don’t expose confidential information while I hack my applications during demos or presentations! I am grateful that Nils was so kind to remind me of this. Happy 2022 y’all!