Hacked by Design: How Bad Design and Weak Upgrades Compromise Security and Privacy

I am a person with a unique interdisciplinary background with a unique perspective that grants me the ability to spot attack vectors and bypassing techniques on a multitude of systems. I carry real world experience in physical security bypassing, circumventing and surreptitious attacks, such as lockpicking, high level intrusion alarm bypassing, and am also recognized as an entry specialist. One of my most interesting skills is using policy and governance against itself to guide my attacks when testing application hardness for security vulnerabilities. I look at the requirements as a roadmap and reverse engineer the application standards against the compliance architecture, which tends to be the most satisfying part of the process. I can equip these reverse engineering skills on anything from government applications for ID to digital infrastructures. One of my favorite finds is how I reverse engineered most or North America's birth certificate application processes in most of the 52 states as the majority of the Canadian provinces. I found ways that would allow fraudsters to apply for and be granted birth certificates with no physical presence and simply all done remotely. "This experience dealing with vulnerabilities in identity systems highlights how easily certain governance gaps can be exploited. Whether it’s physical processes like birth certificate applications or more complex digital systems, the principles remain the same." I also deploy these skills in the information and security side of things for example the cyber world when I am interacting with the front end of systems with input validations and the manipulation on government or financial databases.

I recently found a fun vulnerability when interacting with a provincial MTO 'Ministry of Transportation' website that validates drivers licenses and provides driver abstracts. Let’s break down this vulnerability and see how it ties into real-world, hands-on practical learning for ISO 27001, which is all about securing information systems through effective controls like input validation. If the MTO site employs AI in its processes, we can also relate this to ISO 42001, especially regarding governance and the trustworthiness of AI-driven decisions. This intersection of security and governance principles is where things get interesting!

What you see is an input filed on a government website where people can check the status of a drivers license number either for employment or other purposes. The purpose of this service is to pull a drivers abstract in the end and view any history. I began playing with the input fields since I am familiar with the construction of DL numbers. I used my own for testing purposes and changed a few characters and quickly saw it was no longer validated with in stand user feedback.

The legacy system they had back in 2023 allowed me to input a DL number, and before moving along to the payment fields, it would actually validate the DL number and alert me if it was found on the back end. The error in their system was to provide instant user validation on the DL number rather then making it standard to send and API call. Many are familiar with this where the field goes red or shows a red asterisk to indicate incorrect data in the fields. We know this as input validation or client-side validation. This can be incredibly useful for those who want to use may tools on the market to data dump and test the validity of DL numbers keeping rate limiting in mind to find active DL numbers. This has now been corrected and they are no longer validating the DL number with client side feedback by confirming an license does not exist or is not valid.. They have also started using an API to call each DL number and not give immediate client feedback to the user.

I also completed this attack vector SSN and SIN numbers using loan/credit application websites and for the thinkers out there this is already a corrected issue. don't go thinking and taking my breadcrumbs for the bad actors.

Let's now unpack this slightly with respect to how principles affect situations like this as well as how they could have prevented this vulnerability in the first place. This was a legacy system but we know AI is becoming big thing so I want to address this as if we were to now integrate this system into a AI based platform. Let's take a look at how implementing standards like ISO and using them in conjunction with local laws can help to mitigate this.

Assessing AI system impact on individuals or groups of individuals

Control

The organization should assess and document the potential impacts of legacy and AI systems to individuals or groups of individuals throughout the system’s life cycle. Implementation guidance When assessing the impacts on individuals or groups of individuals, or both, and societies, the organization should consider its governance principles, AI policies and objectives. Individuals using the AI system or whose PII are processed by the AI system, can have expectations related to the trustworthiness of the AI system. Specific protection needs of groups such as children, impaired persons, elderly persons and workers should be taken into account. The organization should evaluate these expectations and consider the means to address them as part of the system impact assessment.

Depending on the scope of AI system purpose and use, areas of impact to consider as part of the assessment can include, but are not limited to

1. Transparency:

• Principle: Ensuring that users and stakeholders understand how input data is validated and processed is critical. If the validation mechanisms are opaque or poorly documented, it can lead to misunderstandings or exploitation.
• Implementation: Organizations should implement clear logging and reporting mechanisms to document how inputs are handled, providing transparency into the validation processes.

2. Accountability:

• Principle: Establishing accountability for data handling and validation processes is vital. This involves knowing who is responsible for maintaining secure APIs and input validation.
• Implementation: Regular audits and reviews of API endpoints can ensure that proper validation is in place and that responsible parties are identified and held accountable for vulnerabilities.

3. Trustworthiness:

• Principle: Users need to trust that their data will be handled securely and that input validation is effective against potential attacks.
• Implementation: Implementing robust validation mechanisms and regularly testing them against known vulnerabilities (like those described in your API vulnerability scenario) can enhance the trustworthiness of the system.

4. Safety and Security:

• Principle: Ensuring that systems are safe from vulnerabilities that could be exploited, such as inadequate input validation.
• Implementation: Regular security assessments, including penetration testing, can help identify weaknesses in the API and ensure that proper validation is enforced to prevent attacks.

5. Continuous Improvement:

• Principle: The principles of governance in ISO 42001 emphasize the need for continuous monitoring and improvement of systems.
• Implementation: Organizations should implement a feedback loop for the validation processes, using findings from vulnerability assessments to refine and improve input validation methods continuously.

When we understand who the system is designed for, who is intended to use it and what the intended purpose is we can better understand what the principles should be when designing, deploying and continuously improving it. This is not only useful for GRC folks, auditors and pentesters but for hackers and malicious people who want to reverse engineer systems. Coming back full circle from the top of the article this is how I assess, analyze, plan, and deploy tactics in some instances when it comes to breaking systems. Sometimes learning the language and internal rules, laws and procedures can be super dry but it can pay off in the end. Where as other times playing with a front end and tinkering around can reveal a serious input validation flaw that can allow us to smash a system with test creds and some rate limiting adjustments to find some great valuable data in this case authentic SSN/SIN numbers and drivers license numbers. A person may find this vuln but not know what is actually happening on the back end or that this is even related to principles and this is the key to today's newsletter. I wanted to emphasize the importance of principles in security as they are so often overlooked especially by the laymen or new people breaking into the industry. If we can train and educate organization on the basics of principles and why we have them we can harden targets and secure systems that much more.

If you are really into law and policy I highly suggest looking at your local, state, and federal policies, or those from other provinces. This document will even make my eyes water in the end the tear will be good ones. It is a great feeling when you crack the code on an in depth framework like a government system.

I hope you enjoyed this edition and it helped to clarify or more importantly inspire you to delve deeper into the world of language, law and policy.

This was a free fall writing off the top no AI here today. Have a good one!