WeHackPurple Podcast

This podcast interview from WeHackPurple features Anant Shrivastava discussing supply chain security, DevSecOps, Android security, and his open source projects.

Guest Background

• Anant Shrivastava: Close to 15 years corporate experience, about 17 years as trainer
• Linux involvement: About 20 years
• Career path: Server administrator → Development work → Information security (2010)
• Roles: SOC → Pen testing → Managing team of 50-60 pen testers
• Current: Building small niche research-based firm that converts research into training programs

Key Topics Discussed

Supply Chain Security:

Definition:

• Software supply chain security: The entire pipeline from developer’s laptop to production
• Code level: You write ~20% of code, 80% is imports/dependencies
• Full pipeline includes: Developer’s laptop → IDE with plugins → Source code repository (Git/SVN) → CI/CD tools → Test environment → Production environment → Monitoring software
• Every piece: From every software on developer’s machine to every software on servers is part of supply chain
• Compromise at any level: Can lead to compromise of your product

Real-World Examples:

• CircleCI, LastPass, Slack hacks: Third-party SaaS vendors are crucial ingredients of your process
• 2015-2016 pen test story: Found exposed .SVN directory, downloaded entire content, got source code URL and username (username = password), pushed one PHP file to 50 regional servers in 10 minutes due to automated deployment
• SolarWinds: Example of why attackers target CI/CD - can release code themselves into production

Package Sources and Dependencies:

The Package Problem:

• Long-term stable releases: Red Hat, Debian (every 3 years), Ubuntu (every 2 years, .04 releases)
• Stability means: Packages stay same version - doesn’t sit well with developers who want latest versions
• Result: Developers install from different sources (pip, npm, RubyGems) not distro-maintained
• Accountability: If installed from pip/npm/gems, keeping packages updated is on you
• Version freezing: Developers freeze versions for confidence, but can’t update when security patches come out
• Frankenstein monster: Combination of multiple sources with no clear update path

Container Complexity:

• Docker containers: Isolate things, but containers themselves need updates
• Problem: Can’t track 10 things, now have to track 20 things
• Cycle keeps going: People keep looking for more variety

Trust and Zero Trust:

• Oxymoron: Security people talk about not trusting others, but recommend relying on SaaS vendors
• Reality: Everyone dependent on 50-100-200 SaaS vendors, all have to keep business functional for us to be secure
• Code audit challenge: Decent-sized org using Node might depend on 200-500 modules - can 10 security people audit all 500 modules when new versions come out?
• Factor of: Manpower, cost, rapid development pace

Dependency Hell:

• npm example: is-even module depends on is-odd module (both by same person) - cascading dependencies
• Technical debt: Every time you use something not vetted by you, technical debt increases
• Mobile app example: Decompiled Android app had 4 different root detection packages, but author never called any function from them - code rot
• People miss: Reducing dependencies where you don’t actually need to depend

Software Composition Analysis (SCA):

• SCA tools: Super helpful, but supply chain security is not just SCA
• Also need: Teaching developers to remove unused dependencies, work with technical debt
• Problem: Can’t sell that - companies have to figure it out themselves
• No direct impact: Hours spent on technical debt don’t add new features (makes things easier long-term)

Asset Inventory:

• Asset definition: Not just IP addresses or domain names
• Also includes: Git repositories, cloud accounts, S3 buckets, random subdomains for test environments
• Test box from 2014: Still floating around - that’s also your asset
• SBOM + Asset Inventory: Everyone talks about it, no one knows how deep rabbit hole goes
• You can’t protect: What you don’t know you have

Asset Inventory Story (2010-2012):

• Organization had: 5,000 assets in inventory
• Cleaned up: To 95-96% using log correlation
• Correlation techniques: If Symantec AV installed → Windows machine; Port 22 open → not Windows
• Found discrepancies: Machine supposed to have Symantec AV (Windows) doesn’t have it because marked as Linux box
• CircleCI hack: Credentials stored in CircleCI used to access buckets - no visibility of what’s there

Dev vs Ops:

Traditional Waterfall Model:

• Business people: Bring idea/requirements
• Development team: Do coding, get software working
• QA team: Do testing, find problems (infosec is part of QA)
• Operations team: Take software and make it available for customers
• Difference: Software working for developer (on laptop) vs. available in production for all customers

Operations Aspect:

• Creating environment: Optimized for your application
• Scaling: 10-20 customers = single box; 50,000 customers = load balancer, multiple servers, database optimization
• Putting software: Into environment where it can function and serve large number of people

Dev vs Ops Disagreements:

• Packages: Devs want latest, Ops want stable versions
• Solution: Developers given freedom to automate manual effort → Infrastructure as Code → DevOps
• DevSecOps: Security wants name of their own - term that should never have existed but exists

Startup vs Corporate:

• Startup: Very beneficial - one person doing end-to-end work
• Corporate (20,000 people): Not beneficial - want 10 people doing checks and balances, cross-referencing
• Startup: Want one person to do everything (mop floors, bring sales)
• Corporate: Want separation of concerns

Android Security:

Key Mental Shift:

• Web apps: Have trusted end (web server) - harden and protect it, do everything server-side
• Mobile apps: No trusted end - can’t rely on server (slow, bandwidth, cost), can’t trust device

Hostile Environment:

• Can’t trust: User running app, app running in secure environment (might be rooted), headers from server (could be faked)
• Every in and out: Has to be validated
• In-app purchase hacks: Most common hacks around 2014-2015 (before Pokemon Go)
• Pokemon Go: Made it hard for everyone - root detection, SSL pinning, in-app blocking came up

Infosec Community Problem:

• Handful of people: Actually doing anything around mobile apps themselves
• Everyone figured out: Most apps have web server in backend
• Approach: Start app, start Burp/ZAP, check traffic, focus on just APIs
• Lots of problems: In app itself, in device itself that no one touches
• Example: Samsung TTS bug - one intent call gets high-privileged system shell

Mobile Device Security Model:

• By default: Applications run as low-level privileged user (non-admin mode)
• Recommendation on Windows: Use non-administrative user - mobile devices do this by default
• If user becomes root: Can access a lot of things
• Google Authenticator: For very long time relied on Android’s native capability to protect - SQLite file with tokens in clear text, not encrypted
• Assumption: Protected vs. everything is compromised

Complexity:

• Cryptocurrency wallets, banking apps, UPI apps: All in device
• More checks and balances: More complex app gets
• Balancing act: Between security and usability

Middleware Frameworks:

• People relying on: Frameworks that work on iOS and Android
• Another layer: Application built in framework → translation to native code → native code runs
• Middleware adds: Own layer of complexity

Advice:

• For security researchers: Mobile app space is more complex, but understanding everything is compromisable gives freedom to let threat model fly
• For developers: More complexity you add, more difficult to protect
• Key principle: If you don’t keep the data, you don’t have to worry about it
• Revisit: Do you really need to do that? Only do what you really need - reduces threat model

Open Source Projects:

Tamer Platform:

• Started: Around 2010, working with Android
• Problem: Software installation too complex (Java 6 vs Java 8, etc.)
• Solution: Created basic virtual machine with tools rightly configured
• Made available: Publicly
• Current version: About to be released in couple of months
• Components: Virtual machine environment, Debian package environment, emulator for Android devices, package repository for emulator (vulnerable apps, hacking tools pre-baked in), minimal tools knowledge base
• Website: tamer-platform.com (T-A-M-E-R, like lion tamer)

Code Vigilant:

• Started: Around 2014
• Problem: Knew how to write applications, do deployment, pen test, but trying to figure out code reviews
• Approach: Took WordPress ecosystem as base
• Logic: Not going to find bug looking at code line by line
• Downloaded: About 30,000 WordPress plugins at that point
• Method: Simple logic - echo and dollar underscore GET = XSS
• Wrote regex for grep: Ran over entire repository, manually analyzed
• Found: About 300 odd bugs in 2014 (first iteration)
• Second iteration: Started 2021 when Semgrep came out with PHP support
• 2021: Disclosed about 50-60 odd SQL injections in WordPress plugins
• Current: Running Semgrep, finding bugs, piping into vulnerability management system, doing triage and validation, then reporting
• Website: codevigilant.com (C-O-D-E-V-I-G-I-L-A-N-T)

Hacking Archives of India:

• Started: Around 2015-2016
• Problem: People not aware who is from India but representing outside, people in India idolizing people outside, saying no one does things in India
• Goal: Find good people in India, create place where people can see what they’ve been doing
• Method: Went into all big conference listings, identified who all identify themselves as Indians
• Added details: Name, social media handles (if public), all talks they’ve done
• Top person: Active in infosec space since 1997
• Not updated: 2021 and 2022 data (as of interview)
• Purpose: When someone says “do people in India do this?” - go to website, see whole list

Cultural Aspect:

• People don’t glorify themselves: Don’t keep bragging about what they’ve done
• Good thing vs. bad thing: Should at least tell people what you do
• Cultural modesty: Lots of women told to be modest, humble
• Difference: Bragging vs. informing - “I’m going to speak at this conference, come on out”
• Personal hurdle: More of “I’d not jinx it by saying I’m going there” - would talk about what done, not what about to do

Key Insights:

• Supply chain security: Entire pipeline from developer’s laptop to production
• Real-world examples: CircleCI, LastPass, Slack hacks; .SVN exposure leading to 50 server compromise
• Package sources: Long-term stable releases vs. developers wanting latest versions
• Dependency hell: Cascading dependencies, technical debt, code rot
• Asset inventory: Not just IPs/domains - also Git repos, cloud accounts, S3 buckets, test environments
• Dev vs Ops: Traditional waterfall → DevOps → DevSecOps
• Android security: No trusted end, hostile environment, can’t trust anything
• Mobile security model: Applications run as low-privileged user by default
• Open source projects: Tamer Platform, Code Vigilant, Hacking Archives of India

Actionable Takeaways:

1. Don’t store data you don’t want to protect
2. Supply chain includes everything - every software, every environment
3. Package sources are varied - accountability is on you
4. Reduce dependencies where you don’t actually need to depend
5. Asset inventory is crucial - you can’t protect what you don’t know
6. DevSecOps: Term that should never have existed but exists
7. Mobile apps: No trusted end, hostile environment, validate everything
8. If you don’t keep the data, you don’t have to worry about it
9. Don’t idolize people - everyone is doing their own journey
10. It’s okay to say you don’t know - what’s not okay is still saying you don’t know after 6 months