Rootconf Delhi edition

As security analysts, we are often on the offensive side of things; trying to find out the universal contraints under which a system will say nothing by “Sorry” (not sponsored by Justin Beiber). However, as a software engineer, we are on the other side of Select City Walk, oftentimes confused as to how we landed there: the defence. It’s a constant battle of the fittest and the losing side loses (pardon the pun) more than their business.

In this conversation, I will be discussing some really bad ways of writing code and how they are really exploitable. Easily.

A section has also been included to give researchers, development operations’ engineers’ and nerds some insight as to how we discover, disclose and patch these vulnerabilities. We’ll also look at some good vs. bad practices in all realms of the software development live-cycle.

Outline

• Introduction
• I write code. Really.
• Node.js
  • Everyone’s favvvvvv
  • Common misconceptions
  • Don’t evaluate the evil.
  • Prototypes’ AQI is horrible: a tale on pollution;
  • Sharing is caring - how a simple error resulted in a DDoS;
• Golang
  • A tale of two ellipses: Incorrect EC params (~1.0x);
  • 3 errors of a classic DDoS;
  • 1 configuration parameter;
• DevOps
  • Your cloud infra’s house: the hardware - forgotten considerations of hardware security;
  • I am who He claims - server-side request forgery;
  • Make me a sandwich - sudo: how we fooled IAM;
  • Peekaboo - don’t leave your security credentials in your VCS;
  • Can you take some REST? No.
  • Containers? Users? Please?
• Conclusion
• QA

Requirements

Some knowledge of systems under heavy load/attack. Or:
Some knowledge of systems (what a lovely anaphora).

Speaker bio

I have worked with startups and corporates of all sizes; now, I know that sounds flamboyant but listen to me. I have seen systems on all scales: from mere ideas on a piece of paper to live 350+ nodes serving 10+ mil. people every month. In this short span, I have seen some horrible programming and deployment and with this talk I intend to collate all of those experiences into one 40 minute session detailing the problems as well as their - quite easy, I may say - fixes which may skip the mind of someone starting out into the playing field.

There is a quote by Dalai Lama which comes to my mind - “Know the rules so well, you can break them efficiently” and as someone who taught themselves most of their knowledge base, I am trying to ease the process of saying “Hello, DevOps!” for new engineers and/or students by providing information which I wish was available when I started to “traverse” this mysterious tree of unknowns.