How does an internal event dedicated to security make a difference? Why keeping your security team in one place is a bad idea?

No matter if you’re a senior developer, team leader, project manager, scrum master or architect — If you have trouble implementing the appropriate security quality then this article is for you.

During the security awareness workshops I ran I had quite a few chats over the coffee with developers and they gave me unique insights into application security from their perspective — both problems they face and solutions they either think about or have implemented. …

This is a story about one of my most interesting findings without a happy ending. Spoiler alert — the bug was closed as duplicace. Duplicate is still a valid bug and in this case it’s yet another reason to improve my automation. Moreover I also learned a bit finding it.

It was interesting from the beginning. First I routinely ran a dictionary against a host, which resulted in one interesting thing. I ommited the boring parts of HTTP requests and responses to keep this short.

GET /sendmail HTTP/1.1
Host: host:exoticport
HTTP/1.1 405 Method Not Allowed
content-length: 0

So POST it…

Long time no see. I will improve I promise. Maybe. NVM.

Staying in application development area as in previous post.
Some time ago I was interested in applications created in Ruby. I did some review of trending GitHub repositories and I noticed that some of them contain a Rakefile file. To quote the docs:

Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax. Rake has the following features: * Rakefiles (rake’s version of Makefiles) are completely defined in standard Ruby syntax. No XML files to edit. No quirky Makefile syntax to worry…

I observed that some application deployment’s automation is done by the use of shell scripts, mostly files with .sh extensions.

Based on the popular filenames found on GitHub (search for ext:sh) I routinely check for such files during bug bounty hunting in my spare time.

Once it ended up quite unexpected.

I found a file, let’s say it was on one site which was WordPress based blog.

[--CUT--]echo "Setting up blog"echo "- Admin URL: ${local_url}/wp-admin"echo "- Wp User: c[--EDITED--]"echo "- Wp Pass: [--EDITED--][--CUT--]

What? WordPress admin credentials in plaintext?!

When I saw this… file is meant to be helpful. It is the first file to check when you look into a new project on GitHub, see here. That’s perfectly fine from developer’s perspective.

Sometimes this file stays as a development leftover all the way from the test environment to production. If it does not contain anything sensitive it is still fine.

Some time ago I’ve found file which was way too helpful. Definitely it should not have ended up in the production environment.

The case

So, the first lines of the file I found were:

The first thing you need is to install…

I love sensitive information exposure bugs. They are getting more attention at last. Below a short story about leaked Node.js code and OAuth client id and client secret which I found in there.


One of my bug bounty recon tools discovered a package.json file which looked interesing. The package.json file is a description of a Node.js module. This particular one looked like below:

"name": "[…redacted…]",
"description": "[…redacted…]",
"version": "[…redacted…]",
"private": true,
"engines": {
"node": ">=6.9.1"
"scripts": {
"start": "node server/[…redacted…].js"

Setting scripts contained a path to some Node.js code to execute. I was curious what’s…

Mateusz Olejarka

Pentester @ SecuRing

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store