Boulder, Colorado, is home to the University of Colorado Boulder, which is older than the state itself. A community focus on knowledge is evident there, as it has more bookstores per capita than any other city in the US. Boulder is considered a high desert, with an altitude of 5,430 feet (1,655 meters) above sea level and very dry air, which might account for the town being thirsty enough to be the largest beer-producing triangle on the planet. This spirit of getting together, having a drink and learning made for the perfect backdrop for BSides Boulder 2024.

This year marked the fifth installment of this particular BSides and was the largest gathering so far. Over 150 people traveled to the Wolf Law Building on the UC campus, home to one of the largest law libraries in the US. Throughout the one-day event, there were multiple talks, hallway conversations, and workshops that covered making a home lab and using security tools like Corelight and CyberChef. 

Here are just a few highlights from this year's event.

Getting the right answers from AI requires telling it who to be

Jason Haddix, CEO and Founder of Arcanum Security, in his updated presentation "Red Blue Purple AI," revealed some of the secrets to getting AI to produce better answers. After an amazing intro video showing the current state of OpenAI's Generative Pre-trained Transformer (GPT), Jason took us through a high-level overview of prompt engineering based on his experience building the free-to-use Arcanum Cyber Security Bot, one of thousands of free bots released to work on top of ChatGPT. 

Without revealing all his secret sauce, he said one of the more important things for building prompts is to explain exactly who ChatGPT should impersonate and give details for what is on the line. For example, inputting "you are a 20-year veteran of cyber security and your annual bonus is on the line, please do the following" is going to yield different answers than not giving it any indication of who is answering. Academics and real-world users disagree on why this happens, but Jason's results speak for themself.

Jason also walked us through some use cases for the blue team, starting with asking the security bot to explain details about a newly encountered API to find security flaws. It is also a good tool for quickly summarizing incident response reports, helping humans get to the crux of the situation much faster. He also discussed how you can use ChatGPT to help communicate more effectively with security teams when a new CVE is discovered, drafting the public statements earlier in the conversation.

Git is hard, but it is the best we have

In her session, "Whodunnit - git repository mysteries," Natalie Somersall, Principal Federal Solutions Engineer at Chainguard, explained how Git is really good at showing what happened, but the logging is problematic when it comes to the 'who' and the 'when.' She showed us that the ".git folder is full of magic," such as the hooks folder, but that it comes with some complexity.

Part of the complexity of Git is configuration inheritance. You can configure Git at the Local, Global, or System level. System level settings, set at the operating system level, are overridden by Global settings, which live in a particular user's home directory. Local settings inside the .git folder have the final authority when executing commands. 

This inheritance means a developer can think they are signing a commit as one user but can mistakenly sign as another user due to an old local configuration. This makes logs rather unfriendly at times. Another confusing fact is that since Git is just storing history in text files, anyone can easily rewrite the timestamp of their commits, making it hard to believe all Git histories reliably.

Natalie said multiple times throughout the presentation that she wished people would "stop putting secrets in repos." In her experience, once a secret is introduced in a shared repo, the only way to really get it out is to make a new 'shallow clone' of the repo once it is fixed, meaning losing all your git history. That is a bad scenario either way. She shared points from this discussion on her blog. 

Running commands in someone else's environment

In her session "Encapsulate and Exfiltrate: Exploiting RCE via DNS." Heidi Metzler, Senior Security Engineer, walked us through a real-world remote code execution (RCE) demonstration. She said if you can execute your own code in someone else's castle, that means you control their castle. At the same time, Domain Name Servers (DNS), the phone book of the internet, makes it possible to exfiltrate encapsulated payloads by abusing the protocol. This is a common combo attackers use once they determine whether they can run their code. 

She set up a demo website without any security configuration to give us a live demo and the chance to interact with a site that allowed RCE. The site, based around her cat Jim, allowed anyone to execute bash commands by entering them in an input field. For example, running "pwd" in the field returned a page containing the output containing the path /www/html. In this very interactive session, she asked for commands from the audience to find and exfiltrate a document containing secrets, which is what most attackers immediately look for. 

Preventing RCE for many systems, such as CMS Drupal, is as easy as keeping up with security patches. If you are manually creating forms, make sure they are secured to sanitize the input to guard against these well-understood attacks. Testing your own applications for RCE can mean the difference between you or an attacker owning your castle.

A high altitude BSides

One theme that kept coming up at BSides Boulder was secrets security. Your author was fortunate enough to share a session on honeytokens and cyber deception in general. Running throughout all the sessions was a conversation about stolen secrets or exploiting applications to reveal secrets. While validating what we have been saying in our State of Secrets Sprawl reports, it also seems to indicate the community is ready to have more serious conversation about solving this fundamental issue.

The extremely dry air of Boulder makes you thirsty, but fortunately, we had a chance to refresh ourselves at the after-party at the nearby Sanitas Brewing Company. Given how many interesting turns the security conversations took at the after-party, there was also a clear thirst for knowledge, with people freely asking questions and sharing experiences. If you don't already take part in a local security community, I highly recommend finding one like theirs. I am already looking forward to next year's BSides Boulder.