Breaking Better Code Hub

Oops, I broke BCH

I was invited in April 2018 to join a team at the Blockchaingers Hackathon in Groningen, the Netherlands. Billed as one of the largest (if not the largest) hackathons in the world. Teams were asked to run their code through Better Code Hub (BCH) to check it for code quality.

We were told by the organizers if a team could break or find an error with the BCH system, we would get additional points for the hackathon. Game on. I like a challenge.

In looking at how BCH operates, once you log in with your GitHub credentials, it allows you to see your repositories and have them analyzed. Not going to bore you with what it looks for as you can read their site.

I logged in and used some of my pen testing scripts for tests to see what and how it would analyze. So their backend system clones my repo and then analyzes it via a new worker daemon. I wondered since it cloned the repo, how it would handle a classic Gitbomb. I cloned Kate Murphy’s repo for her bomb and ask it to analyze that repo. BCH threw an error stating it could recognize the type of code and thus couldn’t perform the analysis. Makes sense as there was no real code in that repo.

I then copied in a simple script written in bash and added a .yml file to override the defaults and state that inside the repo there is bash code. This time BCH tried to analyze the code. After about 15 mins, it errored and said just something went wrong. Bingo. Seems I broke something. So I tried to quickly run it again and upon clicking the analyze button again nothing would happen. I would need to wait about 2-3 minutes before I could try again.

We took my findings to the BCH reps on site (as they were a sponsor). They asked me to replicate what I had done and also let them manually clone the repo to check. They had the same error when they ran the analysis on the manually cloned repo. I was asked to check in later as they wanted to try and see what was happening on the backend and would need to call their tech team.

A few hours later I went back and I learned that after checking the logs, they noticed the backend checking system trying to analyze the Gitbomb and that caused it to take all the CPU/Ram for the system and it would crash the backend. The system would restart thus the delay in re-analyzing the repo I noticed.

They claimed they would look into ways to mitigate this and update the backend. As a thank you they provided me some limited edition GitHub stickers.

Upon checking today (I gave them enough time to fix the issue before making it public), the system still errors on the analysis but it doesn’t fully crash the backend.

EDIT: Saw this website discuss the Hackathon and the use of BCH by the teams, so wanted to link incase anyone wanted to see further.

CVE-2017-13127…Why security teams should care

When I was at ISC 2015, I decided to run Sensepost’s MANA. I wanted to see what connections and creds that I could get. More a learning experience as I hadn’t yet used that tool in a large public environment. I had also wanted to see if small tweaks I had made worked to run it more efficiently.

No Cert Pining or HSTS/SSL Stripping

While running it, I noticed that MANA kept giving me creds and back-end server details for a large E-commerce site in China. Seems many conference users were utilizing the mobile app and website. As I looked into it more, I was able to session hijack from the cookies and log into users accounts. I was also able to MITM the traffic and using SSLStrip, able to see API calls, purchase data and payment info.
At the time, I was sitting next to a friend and showed him my findings. He also was shocked that I was able to bypass any of their security mechanisms that should have been in place to protect the data as it was in transit. He informed me that he knew one of the heads at the Company and they were also at ISC and would contact them to meet and discuss.

Demonstration to the security team

After meeting with one of the Security team heads, he called his team that was at the conference to watch my attack and asked me to explain what I did so they could see if they could find a way to solve the problem. Most of the team couldn’t exactly follow what was occurring as they didn’t seem to understand that SSL could be stripped and that I was able to see in plain text the contents passed. There was a blanket denial, they seemed to think that it was not possible even after seeing me do it in person which one of the team members accessing the app from their phone.

Advice to remediate the problem

For a month or so after the conference, the team head and I kept in contact as he was trying to learn what was occurring and ways to remediate the issue. I spent time going over the technicals of the attack, and methods such as HSTS and cert pinning to stop the SSL Stripping, better practices to encrypt the data and not rely only on SSL which seemed to be the general practice in China then.

We will solve the problem…soon, or well maybe not

I received assurances that these would be looked into and the problem would get fixed when the next version of the mobile app and the website was updated. Versions would come and go and I would notice none where fixed. Countless messages went back and forth to the contact person asking of the status and kept getting assurances they would look into and fix. I was asked to hold off on public disclosure.

Patience young grasshopper, patience

It has been two years since this occurred. I have kept in contact with the security team head through the time. He also seemed frustrated as it was never a priority. Their company mindset was “it hasn’t affected us enough to want to make a big change“. My patience to not disclose has worn off based on their attitude to not want to fix an issue that could have effects on user data. Chinese companies rarely seem to care unless it affects their profits in a significant way.


I hope someone at’s security team or in their Security Resource Center reads this or sees the CVE details. For two years, every version of the VIP mobile application for both IOS and Android was still venerable to the attack vectors I showed the team in 2015. It is 2017, time to care for your user’s data and not just only care when it becomes a larger issue.


8/2015 Findings made at ISC 2015
8/2015 Disclosure to security team
9/2015 First follow-up to discuss methods to remediate
10/2015 Second follow-up to further discuss remediation
10/2015 Assurances from VIP team that they would fix
12/2015 Follow-up checking on status
Multiple times throughout 2016 Additional follow-up on status
8/2017 CVE applied for and public disclosure, #TrevorForget

Cons Cons Cons–2015 the year of the Cons

So this has been an interesting start of a year for my career transition into Infosec/Netsec. In March I was able to attend Black Hat Asia 2015 and Syscan 2015 (both in Singapore). On the 28th, I’m heading up to Beijing to attend ISC 2015, considered to be one of the largest China-based conferences. At the end of November I’ll be at DefCamp in Romania.
Black Hat was well too commercial or my liking. Coming from an ‘ol school underground teenage hacker past (think 2600, L0pht, cDc etc), I wasn’t so impressed. They did have an amazing buffet and one or two decent talks (Mana from Heaven–Daniel Cuthbert)  but it was really geared towards the corporate money/people/power. Did meet many security vendors from Singapore in the business hall and hopefully those contacts will be useful.
Syscan was what I really think of when I think Con. Laid back, filled with people who breathe and live security and are the practitioners who do it for fun, not just to pay the bills. The talks were very technical yet still filled with fun. All in all my type of people. I was able to meet many key people in the industry and chat with a few people I have known about from reading various hacking sites, zines, and discussions with my former hacking crew. If you had to pick a Con to go to in Asia, this is hands down my selection and advise anyone to go next year. I know I will be. Thank you Thomas Lim/Coseinc for allowing me to partake in the awesomeness of Syscan.
I will try to do more in-depth reviews soon of each.
I look forward to the two next cons I will soon be attending. If any readers happen to be attending email me at john at this domain and lets grab a drink.

Helping out–Enumeration of your target

Last week I saw a post on r/AskNetsec with a Redditor asking for help reaching out to a Hong Kong company who had all of their company data open to the internet (non-password protected directory on their server). I volunteered helping the Redditor as I understand Chinese.
The Redditor had trouble finding contact info for the company and after looking at the company name, I went on a hunt to see what data I could enumerate on the company.
Sun Zhu once said:
The general who wins the battle makes many calculations in his temple before the battle is fought. The general who loses makes but few calculations beforehand.
This holds true for pentesting or really any form of NetSec. You need to spend time learning everything you can about your target to help you strategically plan your attack. While I was doing this to be helpful, the enumeration of a company is a key first step in any pentest engagement.
I was quickly able to find an email, phone number, and a name of a contact for the company so the Redditor could contact them. I also reached out to the company contact with an email in Chinese in case they could not understand the Redditor. Hopefully this has protected a company from losing lots of corporate data and personally identifiable information of its employees and clients.