Skip to main content

Pentest Chronicles

If you’re interested in the world of cybersecurity, the related technical issues, and what’s challenging right now, you’re in the right place! This part talks about IT security more broadly and has the latest information, tips, and advice.
Illustration of Pentest Chronicles

Latest insight

Illustration of Credentials exposure in tinycontrol devices

Credentials exposure in tinycontrol devices

Paweł Różański

It seemed to be a usual LAN test, but the network contained some non-typical devices. One of them was an IoT device (LAN controller), which looked interesting. It had separate admin and user accounts. The user had only read-only permissions, but a default password. The password for the admin was changed from the default one. We decided to check if there is a possibility to perform command injection or read sensitive files. Instead, I found something more interesting: during the opening of the login page by an unauthorized user, the file login.json was fetched from the device.

READ article

Other articles

Illustration of The Danger of Leaking Cookies in HTTP Response Bodies

The Danger of Leaking Cookies in HTTP Response Bodies

Marcin Zięba

According to the Microsoft Developer Network, HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it). If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

READ article
Illustration of Don’t forget to track your vendors’ security advisories

Don’t forget to track your vendors’ security advisories

Adam Borczyk

Every now and then a new critical vulnerability emerges, that has a worldwide impact and is easy to exploit. We’ve all seen Log4Shell, Spring4Shell… and now React2Shell. Despite media coverage, application teams often miss the importance of security patches. This particular vulnerability was found during a recent pentest in a production environment of our client, and it does not require any authentication. Global public disclosure of React2Shell happened just 5 weeks before this pentest.

READ article
Illustration of Active Directory Killchain: How three misconfigurations led to a Domain Compromise

Active Directory Killchain: How three misconfigurations led to a Domain Compromise

Marek Rzepecki

In the world of Active Directory (AD), an administrator needs to keep an eye on countless factors: keeping servers up to date, disabling redundant services, and managing privilege granulation across user groups. However, sometimes, to take over the whole domain (and log into all machines as any user), an attacker doesn't need to exploit technical vulnerabilities or search for CVE’s. It is often enough if an administrator makes a few small mistakes in configuring the relations between different objects in AD. The killchain presented below is a textbook example of such exploitation, where three separate issues were chained together to achieve a critical impact.

READ article
Illustration of From Username to RCE

From Username to RCE

SZYMON STODTKO

"Never trust data sent by the user." This sentence is repeated like a mantra at every security training. Today, we will look at a case where a general lack of field filtration in an application, particularly the username combined with weak file validation, led to a critical Remote Code Execution (RCE) vulnerability. During web application penetration testing, I came across an interesting chain of vulnerabilities. The application had a function for creating users and assigning them disk space for video files. This mechanism, though seemingly standard, turned out to be the system's Achilles' heel.

READ article
Illustration of Path Normalization allow to access internal outdated software with multiple vulnerabilities, leading to remote code execution

Path Normalization allow to access internal outdated software with multiple vulnerabilities, leading to remote code execution

Jakub Żoczek

During the audit for one of our clients, it was found that some servers allow path normalization which may expose sensitive, internal services. Such behaviour exposed outdated, vulnerable version of WSO2 Api Manager software, containing plenty of publicly known security issues, that might be exploited without authentication. That led to successfully exploitation one of such vulnerabilities achieving Remote Code Execution on api.[REDACTED].com production server.

READ article
Illustration of One-Time-Pwn: Unauthenticated account takeover via One-Time Password

One-Time-Pwn: Unauthenticated account takeover via One-Time Password

Maksym Hensitskyi

Security features are meant to strengthen authentication, but sometimes they do the opposite. Due to a logic flaw, the mechanism intended to enhance security instead functions as a backdoor. As a result, an attacker could compromise any registered account in the application simply by knowing its email address. The web application implemented several security measures to protect its OTP-based authentication flow. Each OTP was a uniformly random 6‑digit code, and users were limited to three OTP verification attempts per code. After the third incorrect attempt, a new OTP had to be requested. Additionally, new OTP requests were throttled, enforcing a one‑minute cooldown before another code could be issued. In theory, this combination of rate limiting and cooldown logic was meant to prevent brute‑force attacks.

READ article
Illustration of Desktop app security 101

Desktop app security 101

Adam Borczyk

In Securitum, we also perform security audits of desktop applications – everything ranging from a simple interface to complex systems with custom network protocols. Some of these apps are simply a wrapper around a database connection. It means that we can directly log in to the DB server and just issue SQL commands in there, all within the permissions granted to our role. This approach is called 2 tier architecture (client < - > DB) and is not recommended for security reasons, unless you can implement business logic and permission validation entirely on a database level, through grants, functions, procedures and such.

READ article
A professional cybersecurity consultant ready to assist with your inquiry.

Any questions?

Happy to get a call or email
and help!

Contact Us