soberpistolero/intigriti-santacloud-2025.md

## intigriti-santacloud-2025.md

      
    Raw
  

              intigriti-santacloud-2025.md
            
          
    Intigriti SantaCloud Challenge 2025

Challenge: https://santacloud.intigriti.io/


Flag: INTIGRITI{019b118e-e563-7348-a377-c1e5f944bb46}
Challenge Goal

Find the Flag without user interaction


It should not require bruteforcing
Reconnaissance

We are presented with a login page with no registering option

We can try the following:

Default credentials (ex: admin/admin)
SQL injections patterns in both username and password fields (by triggering errors using ' or ")
Username enumeration (difference in html returned between admin and some random string as username), however we can't be sure of if admin is a valid username

... with no success, as it always displays a simple Invalid credentials

We can then look in Cookies, localStorage or HTTP response to have info about technology use. In the cookies we discover it's a PHP laravel application:

Since it should not require bruteforce or advanced fuzzing we can try manually a few URL path:

/composer.json or composer.lock exposed ? (since it's a PHP application)
/.git/config ?
/.env ?
/register (maybe a register URL exist)
/robots.txt

The last one /robots.txt gives a result:

We can try each patterns as robots.txt is only meant to prevent search engine indexing not actually blocking access ...


And we got a success with composer.json~ !

Main Vulnerability

In the previous section we confirmed the website is affected by a Local File Inclusion ...
{
  "admin-access": {
    "username": "elf_supervisor",
    "password": "CookiesAndMilk1337",
    "api-endpoint": "http://santacloud.intigriti.io/login",
  }
}
... leading to an account compromise as we confirm we can login

As it's unclear if we are admin, let's have a look at our auth_token cookie and use jwt.io to decode it, elf_supervisor has indeed "role": "admin"
{
  "iat": 1767086535,
  "exp": 1767090135,
  "data": {
    "id": 2,
    "username": "elf_supervisor",
    "role": "admin"
  }
}
Conclusion: Your website is vulnerable to a local file inclusion leading to an admin account compromise
Additional Vulnerability

The previous vulnerability only disclosed part of the flag ...
{
  "env": {
    "secret": "INTIGRITI{019b118e-e563-7348",
    "ttl": 3600
  }
}
... so there must be something more.
We can go in each menu and by clicking the user profile we can discover an Internal Notes feature

We can create and modify notes to be either private or internal:

We see nothing interesting in our own notes, we are user_id: 2, maybe there is a user_id: 0 or 1 with interesting notes
If we click edit on a note, it calls GET /api/notes/$id as shown below in Burp Suite

This $id is probably an auto_increment on the note table and shared among users


let's go to Burp Repeater and try to directly access other user's notes by changing the $id, we rapidly discover note_id: 3 from user_id: 1that contains the Flag 🎉

So we have very probably another vulnerability: Improper ACL / Broken Access Control
Finishing the work

The above Improper ACL / Broken Access Control may be intended behavior as we are admin (would be strange/inconsistent since note not belonging to our user are not listed), so it will be intersting to test with a low priviledge user too
Since we have the signing secret it may be possible to sign a valid JWT and complete the reporting
{
  "env": {
    "secret": "INTIGRITI{019b118e-e563-7348",
    "ttl": 3600
  }
}
However, using jwt.io to verify our token with the signature secret INTIGRITI{019b118e-e563-7348 or even INTIGRITI{019b118e-e563-7348-a377-c1e5f944bb46} proves unsuccessful.


The signing secret_key was likely changed so we can't test this Improper ACL / Broken Access Control further
And that's a wrap !
No results found