Security Industry Notes

Introduction to Application Security

Who is Harrison?

• Works at mnemonic, a security company with around 400 employees based in Oslo.
• Presentation focuses on working in the security industry, specifically application security.
• Discusses the ethics of application security testing.

Overview

• Harrison's background and role.
• What it's like to work in security.
• How to approach ethical hacking.
• Hacking demo with ethical considerations.

Harrison's Background

• 10 years in the security industry.
• Originally from the US, started at the University of Maryland.
• Security consultant: helps companies find and fix security issues in their applications.

Insights into the Security Industry

• Aims to provide insight into day-to-day work in security.
• Goal is to make security seem fun.

What Harrison Does

• Web application security testing.
• Mobile applications.
• IoT security (moving into hardware security).

Typical Workflow

1. Customer builds a component.
2. Customer has compliance requirements or security concerns.
3. Customer reaches out for security testing.
4. Scoping meeting to determine concerns, test scope, and time allocation.
5. Offer writing: Harrison believes in doing this personally to steer the test's direction.
6. Testing: Access to the application and vulnerability assessment.
7. Report writing: Includes executive summary and detailed findings with recommendations.
8. Remediation: Assistance provided if needed.

Working at Mnemonic

• Social zones and canteen.
• Individual desks.
• Hardware hacking lab.

Continued Learning

• Security industry requires constant learning due to rapid changes.
• Attending conferences like Black Hat for learning and swag.

Black Hat Conference

• Vendor booths with free merchandise.
• Social events and CTFs.
• Parties sponsored by security companies (e.g., Rapid7) with open bars.

Successful Web Application Testing

Areas of Focus in Security

• Application security (web, mobile, IoT).
• Networking and infrastructure (red teaming).
• Cloud security (high demand).
• Code security (static analysis).

Flexibility in Security

• Many opportunities to focus on personal interests.
• Passion and genuine interest are crucial for success.

Steps for Successful Web Application Test

1. Understand the Application: Before using tools, understand the application's context.

   • Google the application to find documentation or known vulnerabilities.
   • White box assessment: Customer provides source code.
   • Talk to people who have worked with the software before.

2. Quickly Check for Low Hanging Fruit: Use scanners and automated tools for common vulnerabilities.

   • Encryption vulnerabilities.
   • TLS/SSL issues.
   • Cross-site scripting (XSS).

3. Deep Dive: Manual testing based on initial findings.

   • This is the most important part.
   • Cheaper security tests may skip this step.

Knowing What to Look For

• Newcomers can be overwhelmed.
• OWASP Top 10 and ASVS standard.
  • OWASP Top 10: Common vulnerabilities.
  • ASVS: Standard for building secure applications.

Caution with Checklists

• Don't treat resources like OWASP as a checklist.
• Use them for inspiration, not as a rigid workflow.

The Importance of Context

Example: "All Accounts" Data

• Scenario: Application returns "all accounts" data with account identifiers and balances.
• Need more information: Whose accounts are these? What’s your access level?

Principle of Least Privilege

• Verify that users only have access to data they are supposed to access.
• Consider a customer vs. employee scenario.
• Customer access denied, employee access granted.

Additional Considerations

• What if all data is sent when the application first loads?
• Potential issue: Employees could copy data without it being logged.

Identifying Vulnerabilities

• Automated tools cannot understand the context.
• Requires human understanding of risks and industry standards.
• Need to think creatively and outside the box: "It's a bit like art."

Question on the chat

• When to stop searching if you don't have a list
• We use the list of standards to guide us, example the OWASP methodology.
• Finding SQL injection, if SQL injection is not used there is no point in continuing.
• Expertice will guide you into the right path.

The Role of Tools

How Tools Can Help

• Tools are helpful, but know what they do and don't do.
• They have limited coverage and lack context.
• Can give a false sense of security if not understood.

Evolving Application Security

• Modern frameworks provide better base security than in the past.
• Logical vulnerabilities are more common now.
  • Access control issues.
  • Circumventing steps in a specific order.

Example: Loan Application

• Steps: Login, personal information, money laundering questions, loan amount, credit check, sign document.
• Tools don't understand bank ID or money laundering.
• Method: Manually run automated scans against each step.

Developer's Limited View

• Developers often have a limited view of what the application is doing.

Abstraction of Frameworks

• Frameworks abstract away from actual processes.
• Example: Trusting a function to store passwords securely without deeper validation.

The Pen Tester's Role

• Go deep and validate that things are being done properly.
• Easier to make things work without knowing how they work due to AI and quick development demands.

Humorous Example: React Snapshot

• Open-source Google image search used to teach React coding.
• JavaScript code uses Flickr API to search for photos.
• API key and secret are visible in the code.

API Key Exposure

• Issue: API key was hardcoded into the app.
• Misunderstanding that it could be hidden; it's always exposed on the client side.

Hiding the API Key

• To hide it, requests should go through a service that stores the API key.
• Example shows that experts can have misunderstandings too.

Application Security Ethics

Getting Practice

• Don't hack things you don't have permission to hack.
• Use applications normally and observe traffic using Burp or proxies.
• Reverse engineering is allowed, but get permission for pen testing.

Scoping and Boundaries

• Don't go out of scope during testing.
• If you find something fishy, bring it up with the customer.

Demonstrating Security Risk

• Only go as far as necessary to show the risk.
• Avoid downloading entire databases.

Bug Bounty Programs

• Use platforms like HackerOne for learning.
• Companies allow testing of resources under certain terms.

Example: COVID Exposure Tracking App

• Personal project to look into the app's security and privacy.
• Two versions of the app: the first had privacy concerns and was taken down.

Reverse Engineering and Ethical Boundaries

• Reverse engineering is generally okay.
• Active attacks against servers you don't own are not okay.
• Disclosing findings: Do not go public immediately; tell the company first.

Steps to Examine App Vulnerabilities

Reconnaissance

• Look for public information on Google, GitHub, and certificate transparency logs.
• Download the app, look at the BERT traffic, and be familiar with the Apps for transparency effort.

App Functionality Examination

• Phones broadcast encrypted IDs via Bluetooth beacons.
• Phones store each other's ID. Every phone sends his Key to other phones
• Beacons contain flags, headers, and the actual key.
• Master key encrypts the key, changing regularly.
• $K_{master} \rightarrow Key$
• Users can share the master key if they get sick.

Observation of the Application

• Network traffic shows daily downloads of ZIP files containing exposure keys.
• Raw data shows various metrics, but all the downloaded zip files get processed by the application.
• Made a tool to parse the zip files.

Data Points Discovered

• Denmark listed as location (possible oversight).
• Keys of sick individuals shared.
• Transmission risk level.
• Time of infection.

None of this information was displayed in the app.

Key Security Points

• The encryption might be broken.
• Beacons might be replayed.
• Wormhole attacks may be possible.
• Spamming airwaves could cause issues.
• Privacy-related vulnerabilities could exist.
• There might be vulnerabilities on the FHI server.

Considerations for Active Testing

• Legal precedents may not exist.
• Document actions.
• Regulations vary by region.
• Terms of service are not the law.
• Reverse engineering is often allowed for security research.
• Companies can still make your life difficult.
• Not a legal expert.

Vulnerability Testing

Ethical and Legal Considerations

• Download code from GitHub and run a local server to do active attacks.
• Passively listen to traffic.
• Broadcast beacons, but don't interfere with others.

Responsible Disclosure

• Disclose findings to the appropriate organizations (Google, Apple, health organizations).
• This is called responsible disclosure.

Actions to Avoid

• Don't run Burp ActiveScan against FHI servers.
• Don't do wormhole attacks.
• Don't do denial of service attacks.
• Don't sell exploits on the dark web.

Experiment

• Sat outside with the laptop, Nordic Semiconductor dongle and python code on the microcontroller.
• Counted mobile devices and the number of beacons broadcast around him.
• Counted Android devices versus Apple devices.

Conclusion

If App Security Is Convincing

• It can be hard to get good quality material.
• Many blog posts and YouTube videos are half-baked or outdated.
• Academic write-ups may not follow through.

Recommended Resources

• No Starch Press: Security books on every area.
• Portswigger Labs: Free web testing exercises.
• Find someone with shared interests in security.
• Join a group and bounce ideas off each other.

Contact Information

• Work email and private email provided.
• Feel free to reach out with questions.

Bug Bounty Program Question

• Have you ever completed any bug bounty program?
• Yes, I have. I've done a few.