Notes from OWASP Helsinki chapter meeting 35: Bug Bounty programs

Have you ever wondered how to become a bug bounty hunter or wanted to organize a bug bounty program? OWASP Helsinki chapter meeting number 35 told all about bug bounty programs from hacker and organizer point of views. The event was held 6.11.2018 at Second Nature Security (2NS) premises in Keilaniemi. Here’s my short notes.

Notes from OWASP Helsinki chapter meeting #35

“Hunting for bounties in a web browser” by Juho Nurminen from 2NS started the event talks and told about how to approach the issue and showed some findings in details. For the usual of understanding the technology and focusing on what you know, it’s beneficial to read up prior art. Is it repeatable bug? Reproduce it in other context. The talk presented cve-2018-6033 (extension code can execute downloaded files), cve-2018-6039 (XSS in DevTools, privileged API can be overwritten) and cve-2011-2800 (data leak across origins). tl;dr; pwn things, submit crbug.com, profit.

“#OWASPHelsinki 35 started by @jupenur hunting bounties in web browsers. Understand the tech (web, js, extensions, plugin API, devtools, NaCI, WebAssembly, etc.). Focus on what you know. Read up prior art. Nice examples of bugs found. @OWASPHelsinki meetup hosted by @2NS_fi.” – @walokra

Why web browsers?
Why web browsers?

CVE-2018-6033
CVE-2018-6033

In “How to become a bug bounty hunter” Iiro Uusitalo from Solita talked about bug bounty platforms and tips to be succesful. In short: POC or GTFO, recon, stay on scope, automate all the things, focus, report, wait, profit, join the community.

“How to become a bug bounty hunter, told by @iiuusit at @OWASPHelsinki meetup. Tips: poc or gtfo, recon, stay on scope, automate all the things, focus, report, wait, profit, join the community. #OWASPHelsinki” – @walokra

Bug bounty programs in Finland
Bug bounty programs in Finland

Tips for recon
Tips for recon
How to report
How to report

tl;dr;
tl;dr;

“Running a successful bug bounty program” by Thomas Malmberg from Hackrfi bug bounty program covered the topic from the “random dude from the other side of the table” point of view. “What really matters is finding bugs” but there’s a lot of things to manage. It comes to managing expectations of hackers and program owners. And remembering that hackers work for you (program owners) but they are not your employees.

Expectation management
Expectation management

“What really matters is finding bugs.” @tsmalmbe from @hackrfi told how to run a successful bug bounty program at @OWASPHelsinki meetup. Managing expectations of hackers and program owners. Remember: hackers work for you; hackers are not your employees. #OWASPHelsinki” – @walokra

The evening ended with a panel & discussion about bug bounty with Juho, Iiro and Thomas. There was lots of interesting questions asked and here’s some of them in short.

  • Hardware bug bounties, how to do if device not publicly available?
    • On premises hack days -> not so successful, too little time, concentrate on low hanging fruits.
  • How to choose [bug bounty] program?
    • Wide scope -> low hanging fruits.
  • What kind of reports of findings
    • OWASP Top 10 covers almost everything.
    • Everyone is scared of finding remote code execution.
    • Business impact findings.
    • Recon: who we are, what we do -> what has big business impact. Also where’s the legacy code?
  • Impact of how hacker and product owner sees findings? Owner will set the impact, how it should happen at both ends? how to define the final impact corresponding the value?
    • Always estimate, run some CVSS estimator.
    • Use Google’s approach.
    • Fairness and trust. Programs task is to create trust.
  • Awfraid of reporting found bugs when there’s no bug bounty program?
    • Program has rules which covers legal matters. Read the rules, ask.
  • Top 3 negative things?
    • Program runner went public, lots of bugs, hackers pwned whole system.
    • Communication issues.
    • Program runner: call on Friday night, database lost. bug bounty program to blame.
  • Bug bounty programs role, client and customer: public programs. -> ncss, cert-fi.
  • Pentesting vs. bug bounty?
    • Not competing.
    • You shouldn’t do bug bounty if you don’t have enough security maturity. Too many reports at start (duplicates, cost much, etc.), then nothing if you don’t pay.
    • Low hanging fruits are not interesting for good hackers
    • Pentesting last 30 days and result is report covering certain things.
    • Bug bounty concentrates on specific aspect.
  • Bug bounty and threat model? When program open, easier for black market to find vulnerabilities?
    • Threat model for users? Depends on product / service you are providing.
    • 0-day on some Finnish site selling on USA black market -> not much interest.
    • Pentesting should be done first.
  • How to improve process?
    • Educating the bottom of the pyramid. Hammer and nails.
    • Public programs generate lots of noice vs. private
  • Bug bounty in 5 years?
    • More automated things, scripts to detectivive things, AI
    • Bug hunter side: more professional all around the pyramid, more spam

Notes from Red Hat Forum Finland 2018: Ideas worth exploring

Red Hat Forum Finland 2018 was held 11.9.2018 at Finlandia-talo and it’s mainline was “Ideas worth exploring. Come with questions. Leave with ideas.” The event was divided to keynote and to four breakout sessions. The four breakout sessions were: 1. Automation – Ansible 2. Journey to Cloud-Native Applications with OpenShift 3. Business & Solution track 4. Half day Executive discussions and round tables. I chose to get hands-on with OpenShift but also Ansible would’ve been interesting. Here’s my notes from the event.

Red Hat Forum Finland 2018: Ideas worth exploring

Red Hat Forum 2018 Helsinki started with keynote session by Michel Isnard from Red Hat and in “Digital transformation & the open organization” he talked about open source and how Red Hat embraces it. “Open source is collaborative curiosity, a culture with a desire to connect and the technologies to do it. Yet what draws our attention isn’t the technology alone; it’s what we can do with it. It gives us the platform for imagination, a focal point to collectively push for new possibilities.”

Be courageous, be open and innovate in the open.

Keynote: Ideas worth exploring
Keynote: Ideas worth exploring (@walokra)

Next there was customer reference by Markku Reinikainen from SOS International. He told us about their open innovation platform and how they have modernized their applications and moved to the mobile world.

SOS International: Open innovation platform
SOS International: Open innovation platform

Journey to Cloud-Native Applications with OpenShift

The main content of the Red Hat Forum event were the breakout sessions. I chose the full day hands-on workshop which showed how to modernize an existing legacy monolithic application by applying microservice architecture principles, using modern lightweight runtimes like WildFly Swarm (Thorntail.io) and Spring Boot, and deploying to container-based infrastructure using OpenShift Container Platform. The material and slides are available on GitHub.

Hands-on OpenShift
Hands-on OpenShift

The lab was split into four scenarios, going through the process of understanding how a developer can most effectively use Red Hat technologies in deploying a monolith to OpenShift, wrapping it with a CI/CD pipeline, developing microservices to start replacing functionality in the monolith, and integrating it all together to form the beginnings of a complete modernization of an existing app. The last scenario was about using Istio to prevent and detect issues in a distributed system.

The session started with Red Hat Application Migration Toolkit (RHAMT) and migrating (lift & shift) Java EE monolith app on WebLogic to run on JBoss EAP and OpenShift in the cloud. Crafty tool which fixed poor and non-standard choices done in legacy app.

Hands-on: Red Hat Application Migration Tool
Hands-on: Red Hat Application Migration Tool (@walokra)

The breakout session had also a talk from Red Hat partner. “Shift to a Cloud-First Core” talk by Capgemini told how they are approaching OpenShift projects. Different options, some are easier depending of legacy technologies. Retain, retire, migrate: lift & shift, new layers, new apps.

Shift to the Cloud-First core
Shift to the Cloud-First core (@walokra)

OpenShift hands-on session continued with developer introduction which was about live synchronization and changes, deploying to different environments, Jenkins Pipeline, Continuous Delivery and approval steps.

Hands-on: introduction to OpenShift
Hands-on: introduction to OpenShift (@walokra)

Third and fourth scenarios were about strangling the monolith with transforming it to microservices architecture with and without Spring Boot. Splitting up monolith to domain specific applications and connecting them. Lots of things that goes over the hill and seems magic if you’re not familiar with them. You just click click click, done, profit. Some technologies used were Spring Boot and Spring Cloud, Snowdrop, Feign and Hystrix.

Strangling the monolith
Strangling the monolith

The last and most interesting part of the hands-on session was Istio and resilient apps and due time schedule Red Hat guy clicked and talked it through. It gave good overview to visualization, monitoring, metrics, fault injection, traffic shifting, circuit breaking, rate limiting and tracing. Time was limited so much things left to be read.

Hands-on: Istio, resilient apps
Hands-on: Istio, resilient apps (@walokra

All the OpenShift scenarios used Katacoda which made the hands-on experience with just a few clicks. Crafty tool for this kind of sessions and although you just clicked through with relative fast pace. For example “Developer Introduction to OpenShift” estimated time 45-60 minutes and the lab had 23 minutes. The limited time made the hands-on experience somewhat superficial but you got the point what the possibilities are and how OpenShift works.

And last Red Hat talked about OpenShift and their services regarding application modernization. Modernization of legacy applications is in high demand and there are different paths to achieve that.

One point regarding monoliths vs. microservices was that as Martin Fowler wrotes in Monolith First.: “you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile.”

Monolith first
Martin Fowler: Monolith first

Red Hat OpenShift Application Runtimes product architecture showed the blocks in the OpenShift context.

Red Hat OpenShift Application Runtimes
Red Hat OpenShift Application Runtimes

Red Hat Application Migration and Modernization Program
Red Hat Application Migration and Modernization Program

Summary

Red Hat Forum Finland 2018 was nice event and the content was interesting. The hands-on session was fast paced but you got the point and ideas worth exploring. Will look into Istio. The WiFi network had some problems but got better when more access points were added. After the official program there was some networking and drinks. Some food other than hemp snacks and vegetable chips would’ve been nice but Woolshed provided in that regard. Thanks for Red Hat for organizing the event and good talks.

To continue with OpenShift topics you can check learn.openshift.com which has similar material as in hands-on and use Katacoda but different topics. The hands-on material can be read from GitHub and for listening there’s DevNation Podcasts.

Red Hat OpenShift Pale Ale
Red Hat OpenShift Pale Ale

Notes from React Helsinki August 2018 meetup

React Helsinki August 2018 meetup was hosted by Smartly.io at their office in Postitalo next to the Central Railway Station. Here’s my short notes from the event. To follow the community, React Helsinki has also a Facebook group.

The meetup started with Splitting React codebases for increased development speed by Hugo Kiiski from Smartly.io. He told how their Video Editor component is separated from main frontend. Code is in monorepo managed by Lerna. More tools going to be splitted. The recording of the presentation can be seen on Vimeo. (Twitter)

Splitting React codebases for increased development speed

Second topic was live coding and Making your own Ignite generator – for React Native by Toni Ristola from Gofore. It’s useful e.g. if you do many projects in a year. The recording of the presentation can be seen on Vimeo. (Twitter)

When to use generator
When to use generator

Why build your own
Why build your own

Use GraphQL! by Mikhail Novikov showed a quick intro to GraphQL, covered the current state of its adoption and described several ways of how to move to GraphQL. GraphQL “fills the gap between client and server developer needs and values. Matching server capabilities with client requirements.” GraphQL clients to use are i.a. Apollo and Relay. See the slides for more information. The recording of the presentation can be seen on Vimeo. (Twitter)

GraphQL parts
GraphQL parts

GraphQL adoption
GraphQL adoption

As I mentioned the event has hosted by Smartly.io and their office in Postitalo was cosy and had nice demo room for the meetup. Also the food and beverages were nice althought the hamburger patty was a bit too raw.

Some food & drinks
Some food & drinks

Smartly.io entrance with swings
Smartly.io entrance with swings

OWASP Helsinki chapter meeting 34: Secure API

OWASP Helsinki Chapter held a meeting number 34 last week at Eficode with topics of
“Perfectly secure API” and “Best friends: API security & API management”. The event gave good overview to the topics covered and was quite packed with people. Eficode’s premises were modern and there was snacks and beverages. And also a sauna. Here is a short recap of the talks.

OWASP Helsinki Chapter Meeting 34

Perfectly secure API

Matti Suominen from Nixu talked about perfectly secure API and things related to get there. Can API be secure? On gut feeling APIs seems to be rubbish and have problems. He covered the topic from three view points: security, risks and defense. Good starting point is to read OWASP resources like ASVS, Top 10 and Security cheat sheet. Also implement security centrally, involve business in design and DIY never works out.

Best friends: API security & API management

Antti Virtanen from Solita talked about API security and API management and how we’ve traveled from dark ages to modern times. You can do API security with tools like Amazon AWS API Gateway but the main point was to step further with API management. Use some already made products like Apigee and open source alternative Tyk.io. Slides are available in Slideshare.

Snacks and beverages

Refreshments were basic and different

Notes from OWASP Helsinki chapter meeting #31

What is DevSec, how to use Docker securely, why developers leak credentials? All those questions were answered at OWASP Helsinki chapter meeting #31 which was held 13.6.2017 at Solita premises. Here’s my short notes from the event. I’ll add links to presentations when they’re available.

DevSec – Developers are the key to security

DevSec is a emerging trend to move developers closer to security experts, akin to DevOps. Antti Virtanen from Solita talked about DevSec and how they do it (slides, pdf). As talk’s title tells us developers are the key but often buying one cybersolution is easier (giving out money) than peoples’ time. But if we look at the return of investment, passive defense is more effective.

Value for life?
Challenges in DevSec
Issues with DevSec
Recipe works!

Docker Security

Docker is currently experiencing very high adoption rate and people are deploying on Docker without considering the security landscape. Mika Vatanen from Digia told us about Docker Security (slides, pdf), possible attack vectors, how Docker handles security and what recommendations we should use when using it.

Possible attack vectors
How Docker handle security

Docker image tech recommendations
Docker image: tech recommendations
Docker image: policy recommandations
Docker runtime
Host and engine recommendations
AppArmor and seccomp
Seccomp
Seccomp

Leaking credentials – a security malpractice more common than expected

Bogdan Mihaila from Synopsys talked about Protecode and research of leaked credentials (slides, pdf).

Why credentials are leaked
Keys that got public
Mitigation
Conclusion: raise awareness

Upcoming: DevSecOps “mini-hackathon”

Last topic was introduction to upcoming “mini-hackathon” by Pekka Sillanpää from OWASP Helsinki. They are planning a hands-on event in August for familiarizing and investigating some nice open source tools, including: OWASP Dependency-Check, ZAP Proxy, OWASP DefectDojo, DevSec hardening framework and Clair. See more info from OWASP Helsinki page.

Nebula Tech Thursday – Beer & DevOps 2.3.2017

Agile software development to the cloud can be nowadays seen more as a rule than exception and that’s also what this year’s first Nebula Tech Thursday’s topics were about. The event was held 2.3.2017 at Woolshed Bar & Kitchen alongside good food and beer.

The event consisted of talks about “Building a Full Devops Pipeline with Open Source Tools” by Oleg Mironov from Eficode and “Cloud Analytics – Providing Insight on Application Health and Performance” by Markus Vuorinen & Jarkko Stråhle from Nebula. The presentations were a bit high level and directed more to the business level people than developers but there was some new information how different tools were used in practice.

Overall it was nice event to hear how things can be done and to talk with people. Here’s my short notes from the event.

Nebula Tech Day

Cloud Analytics – Providing Insight on Application Health and Performance

Markus Vuorinen & Jarkko Stråhle from Nebula talked about how to gather data to Elasticsearch, make it accessible and visualize it with Kibana and make actions based on that. The ELK-stack (Elasticsearch – Logstash – Kibana) is commonly used and the presentation showed nicely how to utilize it with cloud.

Technical setup
Technical setup
Data flow to Elastic
Data flow to Elastic
To visualization and alerts
To visualization and alerts
Kibana main view
Kibana main view
Kibana and response times
Kibana and response times

Building a Full Devops Pipeline with Open Source Tools

Oleg Mironov from Eficode showed the building blocks of how to build a Devops pipeline with Open Source Tools and demoed it. Nothing really special if you don’t count Rancher and Cattle. Just put your code to Git, use Ansible, run Jenkins jobs, build docker images, use RobotFramework for testing, push artifacts to Artifactory and deploy with Rancher.

Rancher overview
Rancher overview
DevOps Pipeline
DevOps Pipeline

DevOps Finland Meetup goes Mobile at Zalando

Development and operations, DevOps, is in my opinion essential for getting things done with timely manner and it’s always good to hear how others are doing it by attending meetups. This time DevOps Finland went Mobile and we heard nice presentations about continuous delivery for mobile applications, mobile testing with Appium and the Robot Framework and efficient mobile development cycle. Compared to developing Web applications mobile brings some extra hurdles to jump but nothing that’s not solvable. Here are my short notes about the meetup.

The meetup was hosted by Zalando Technology at their new office here in Helsinki. Zalando is known to many as that online store that sells shoes, clothing and other fashion items but things don’t sell themselves and behind the scenes they have lots of technologies to keep things running. For the record I think they said that the meetup had 65 attendees of the 100.

Also if mobile is your thing there’s a new Meetup group for mobile developers in Finland which was announced at the meetup. They’re also on Twitter and Facebook.

Continuous Delivery for Mobile Applications

Rami Rantala from Zalando talked about “Continuous Delivery for Mobile Applications” and how they’re managing releases of their Fleek app which is available for Android and iOS in German markets.

They didn’t arrive to the final setup straightforward and it was iterative approach with how Git is used, code merged and releases done. Using Fastlane for all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application made automating things easier. Interesting note was that their build server slaves are ansible managed Mac Minis on Rami’s desk. They had solved the problems nicely but testing is still difficult.

DevOps and rollbacks don’t work together, you roll forward.

Mobile testing with Appium and the Robot Framework

Mobile testing can be done with different tools and one option is to use Robot Framework just like for Web applications. Elmeri Poikolainen from Eficode demoed how to use Appium and run Robot Framework tests on real device. It has some limitations and I think with native applications it could be better to use native test tools like what Xcode has to offer.

Efficient Mobile Development Cycle

The last and most fast-paced talk was by Jerry Jalava from Qvik about “Efficient Mobile Development Cycle“. He talked about different practices and tools in the development cycle and it was nice overview to the complexity of the process from design to done. You can for example run remote preview with 27 devices.

Container orchestration with CoreOS at Devops Finland meetup

Development and Operations, DevOps, is one of the important things when going beyond agile. It’s boosting the agile way of working and can be seen as an incremental way to improve our development practices. And what couldn’t be a good place to improve than learning at meetups how others are doing things. This time DevOps Finland meetup was about container orchestration with CoreOS and it was held at Oppex’s lounge in central Helsinki. The talks gave a nice dive into CoreOS, covering both beginner and seasoned expert points of view. Here’s my short notes about the presentations.

CoreOS intro for beginners, by beginners

The first talk was practically an interactive Core OS tutorial by Antti Vähäkotamäki and Frans Ojala. Their 99 slides showed how to get started with CoreOS on Vagrant step by step and what difficulties they experienced. Nothing special.

CoreOS in production, lessons learned

The more interesting talk about CoreOS was “CoreOS in production, lessons learned” by Vlad Bondarenko from Oppex where he told about their software stack and how they’re running it. In short, they’re running on baremetal with CoreOS Nginx for reverse proxy, Node.js for UI and API and RethinkDB and SolrCloud clusters. Deployment is made with Ansible and makefiles and Ship.it is used for Node.js. Service discovery is DNS based with docker-etcd-registrator component and they’ve also written their own DNS server. For Node.js config management with etcd they’ve made etcd-simple-config component. With Docker they use standard images with volumes and inject own data to the container.

CoreOS seemed to work quite well for them with easy cluster management, running multiple versions of 3rd party and own software and having zero downtime updates or rollbacks. But there were some cons also like maturity (bugs) and scripting systemd.

Kontena, CoreOS war stories

The last talk was about CoreOS war stories in Kontena by Jari Kolehmainen. The slides tell the story of how they use CoreOS on Kontena and what are the pain points. In story short it comes to configuration management and issues related to etcd.

For bootstrapping they use CloudInit which is de-facto way to initialize cloud instances and Integrated to CoreOS. The hard parts with etcd are discovery, security (tls certificates), using central services vs. workers and maintenance (you don’t do it). Now they run etcd inside a container, bind it only to localhost and overlay network (Weave Net) and master coordinates etcd discovery. With automatic updates they use the best-effort strategy: If etcd is running, locksmith coordinates the reboots; Otherwise just reboot when update is available.

Presentation’s summary was that the “OS” part is currently best option for containers and etcd is a must, but a little hard to handle. For the orchestrator they suggest that pick one which hides all the complexities. And automate all the things.