Dear PenTest Readers,
This month’s main topic is Threat Modeling. We have decided to continue focusing on it after our last issue, as a follow-up and response to the popular demand. Threat Modeling is undoubtedly one of the key aspects in a white hat’s day-to-day life. Having a mindset of profiling possible attack vectors is crucial in any infosecurity job. Recognition of potential threats, categorization and prioritizing, ability to look at the matters from a hypothetical attacking point of view is the essence of effective cyber protection. Our contributors provide you with general knowledge about this topic, as well as the most innovative projects and insights, presenting from various perspectives.
Inside, you will find an article presenting the meaning of Threat Modeling process in the context of Supply Chain Risks, written by Cecilia Clark. There is also an article by Marcelo Castro, presenting the exercise of Threat Modeling in the context of Google Tag Manager. Fraser Scott presents a very interesting open-source project, ThreatSpec, which is supposed to close the gap between development and security, by bringing Threat Modeling further in the development process. Vanshindar Singh presents how modeling of threats should be done. Suin Kang, Hye Min Kim, and Huy Kang Kim, academics from Korea University, share their article on security requirement analysis and Threat Modeling for smart bands.
Furthermore, we would like to point out the article written by Fred van den Langenberg, which follows up on our previous month’s main topic - SAP Security. It presents how the reverse engineering of SAP Security Notes can lead to producing working exploits. If you are responsible for SAP Security, this is a must-read.
Robert Fling presents the case study of Spear Phishing and website attack vectors, using various tools - this is a great article if you feel like you need some practice.
Moreover, there are two articles covering the AWS Security. Prashant BS presents the introduction to this environment, and Ben de Haan reviews open-source tools for scaling security of AWS. Mr de Haan stresses the importance of scalability, the role of open-source community, and categorizes the tools as defensive and offensive. If you want to enhance your AWS Security knowledge, this article will help a lot.
Last but not least, Dinesh Sharma, our regular contributor, present a practical tutorial of thick client penetration testing, which is also a useful skill for every white hat.
Special thanks to every contributor and reviewer who helped in the creation of this issue.
Without further ado,
Enjoy the content!
PenTest Magazine’s Editorial Team.
Table of Contents
Trustworthy Smart Band: Security Requirement Analysis with Threat Modeling
by Suin Kang, Hye Min Kim, Huy Kang Kim
Looking at the smart band DFD and security requirements, two major parts require authentication and encryption when transmitting a packet. The first part is the communication between the smartphone and the web server. When a packet comes and goes between a smartphone and a web server, the packet must have authentication information for the user and be encrypted. The second part is the communication between the smartphone and smart band. In this case, a secure connection is necessary to solve the problem of the connection process mentioned above. For the secure connection, encryption and the key generation process for encryption are essential.
Threat Modeling for Supply Chain Risks
by Cecilia Clark
To include vendors, work with them to develop their independent risk management strategy, mirroring the stringency of your own. If they are already security-focused and have a risk management plan in place, review it to ensure it includes the three basic categories of a cybersecurity plan. Once satisfied with their plan, use their text-based, detailed threat model to create a threat model map. Determine where your vendor’s systems connect to yours and link your threat model map to the vendor’s map at those points.
Threat Modeling as Code with ThreatSpec
by Fraser Scott
Threat modeling used to be associated with waterfall development practices with big design decisions up front. Agile approaches to threat modeling are starting to show that it doesn't have to be that way - threat modeling is equally if not more effective when done in smaller, iterative bursts. For example, you can threat model a new epic and use the outcomes to drive security requirements for the epic. You can also threat model an individual story and use threat modeling to drive testing requirements for the story, Three Amigos style.
How is Threat Modeling Done?
by Vanshindar Singh
One must always know this is not a one-time activity; as the technology evolves similarly the threat landscape evolves. A certain system that is secure today might not be secure tomorrow. One has to keep a watch for all the system parts. It is vital to understand that all systems interact with other systems and not only users. To be precise, there is no formal process, it is more like use what works.
Google Tag Manager Crown Jewel. Threat Modeling - The Art of Resilience
by Marcelo Castro
Beyond Google security team work, we must challenge ourselves and try to figure out which surface attack could be exploited. I suggest starting with the OWASP Risk Rating Methodology. It can help us to get a first approach in nontechnical speech giving us a risk score that could be easy to understand beyond the technical knowledge. Following these thoughts, in my opinion, the main pitfalls that I found to review are roles and identity management, segregation of containers, coding security compliant and adequate framework to deploy changes to production environments.
Reverse Engineering SAP Security Notes
by Fred van de Langenberg
Using only two such SQL statements, an attacker can create a new SAP user and subsequently assign it super user privileges, which may then be used to attack the SAP system. In effect, it would be a major (and very efficient) type of attack if this vulnerability could be exploited.
Let's Go Phishing!
by Robert Fling
You can craft the email in dozens of different ways to make it enticing to the victim. As you can see, I entered ‘Twitter Link’ for the text to display and have it resolve to the IP address that is the center of the attack. It also helps to have an inviting subject line. This email went right into my inbox within Gmail so deliverability obviously would not be an issue here and, since I am working within my test environment (internal network), it took me right to my fake Twitter page and the attack worked perfectly.
Introduction to AWS Security
by Prashant BS
Cloud services like AWS can be less secure, equally secure, or more secure than your traditional on-premises data center, but if you have good InfoSec hygiene in your organization, then it’s easy to secure your application on cloud as well.
Scaling AWS Security: a Review of Open Source Tools
by Ben de Haan
By now, everyone knows that S3 misconfigurations can lead to problems. However, authenticated compromise is the threat with the most devastating outcome nowadays. Accidentally checking in your access keys to public version control, password reuse, server-side request forgery, local file reads, remote code execution, and internal threats are more likely to test your blast containment than a missing encryption setting on RDS. The downside of offensive tooling is that they only execute known attacks, and cloud environments may change rapidly. Thus, it is extra important that they are extensible and modular to make them future proof.
Thick Client Penetration Testing: A Practical Approach
by Dinesh Sharma
As we saw, the rich functionalities of the thick client application make it vulnerable as well. So a complete penetration test of the thick client application is a must. It should be done using a thorough checklist so that not a single vulnerability gets missed in the penetration test.