Zdravitas - ko ga je i od čega pravio i zašto je postojao tajni login na stranici?

[milos_rs]

Pošto sam na linkedinu ovde video objavu koja dovodi u pitanje korišćenje eksternih resursa na admin stranici Zdravitas portala, rešio sam da malo dublje pogledam Zdravitas priču i iznesem neko svoje mišljenje i vidim šta se još može otkriti...

kratki sažetak Zdravitas-a iz medija:

• „Portal Zdravitas predstavlja elektronsko vođenje evidencije o postignućima učenika u okviru nastavnog predmeta Fizičko i zdravstveno vaspitanje kroz osam merenja (šest testova i merenje visine i mase tela), koji su i do sada bili evidentirani u pedagoškoj dokumentaciji i pratili fizički razvoj i motoričke sposobnosti učenika.
  
• Dve privatne firme su pobedile na tenderu, jedna SAGA d.o.o, druga PortalMasters Solutions registrovana 9.4.2024, direktor Marko Petrović ima 60 odsto udela u vlasništvu, a Filip Furtula poseduje 40 odsto.
  
• Javni poziv za prikupljanje ponuda je objavljen 10.05.2024, samo mesec dana posle osnivanja firme PortalMaster Solutions. Tender je okončan 28.06.2024
  
• Iznos tendera je 42.000.000RSD ili oko 350.000eur
  
• Prema odluci o dodeli ugovora iz tenderske dokumentacije, vrednost ili procenat dela koji će izvršavati podeljen je ovako: Portal Master Solutions (48,3 odsto), Fakultet sporta i fizičkog vaspitanja (39 odsto), Kompanija Saga (7,4 odsto) i Fakultet organizacionih nauka (5,3 odsto).
  
• "podaci se ne dele sa trećim licima i biće čuvani u Državnom data centru, neće se iznositi iz Republike Srbije niti prenositi u drugu državu ili međunarodnu organizaciju."
  

   


Mislim da je svima očigledno da je firma PortalMaster znala da će dobiti ovaj tender i da je sve unapred dogovoreno. Ne bi me čudilo i da su krenuli da prave platformu pre nego je tender uopšte okončan. Možda imam ovde dokaze zašto se to tako i desilo, jer pre PortalMastera imali smo TestMaster...


Da li je firma PortalMaster zaista radila na ovom projektu?

Čudi me da mediji nisu povezali drugu firmu Marka Petrovića i Filipa Furtule sa ovim projektom. Naime oni su takođe vlasnici firme Testmaster Solutions (testmastersolutions.com) i prema APR-u imaju istu vlasničku strukturu kao i PortalMaster, iste kontakt podatke, a registrovani su na istoj adresi. Firma Testmaster Solutions takođe ima istoriju rada na javnim projektima.

Testmaster Solutions ima svoj proizvod zvani Testmaster za "softversko i organizaciono rešenje za realizaciju testiranja kandidata". Rešenje je razvijeno (valjda) 2020. na Fakultetu organizacionih nauka, pod rukovodstvom Doc. dr Marka Petrovića i u saradnji sa Vladom Republike Srbije, Ministarstvom prosvete i Kancelarijom za IT i eUpravu. Zasniva se na aplikacijama koje se instaliraju na fizičkim računarima u školama, postoji i online komponenta koja se zove "javni portal za kandidate".

Pitam se zašto je softversko rešenje koje je razvijeno javnim novcem na državnom fakultetu sada u rukama privatne firme TestMaster d.o.o. koja profitira od njega? Pošto se ne razumem u to ko polaže intelektualno pravo nad nečim razvijenim u okviru državnog fakulteta niti znam pod kojim okolnostima je to razvijano na fakultetu, ostavljam drugome da to istraži i pojasni i/ili novinarima da saznaju kroz zahtev za pristup informacijama od javnog značaja.

Firma TestMaster je registrovana 1.11.2022 a 30.01.2023 je već dobila prvi ugovor, slična priča kao i portalmaster :


   


Firma je odlično profitirala u kratkom roku što je razumljivo kada su već imali gotov proizvod koji je razvijan javnim sredstvima na FON-u još 2020. godine :


   


Ali čemu sve ovo i kakve veze ima TestMaster sa Zdravitasom?????

U samom kôdu admin portala Zdravitasa imali smo jedan mali detalj:

Code:

<meta content="TestMaster Solutions" name="author">

Dakle, u metapodatku u kome se upisuje autor sajta navodi se kao autor "TestMaster Solutions", tj. navodio se jer je promenjeno (više o tome kasnije). Ovo je bilo prisutno u kôdu glavne stranice Zdravitas admin portala do 03.12.2024. Špekulišem da su jednostavno klonirali kôd sa nekog dela TestMaster portala i napravili Zdravitas.

Koliko je javno vidljivo, iskustvo firme TestMaster je u razvijanju desktop aplikacije koja ima drastično drugačije sigurnosne zahteve od javnog online portala, te moram imati sumnju u njihovo iskustvo u osiguranju takvog visokorizičnog javnog portala.

Iz ovoga se postavljaju pitanja:

Ko je tačno napravio Zdravitas i da li je Zdravitas samo klonirana i modifikovana platforma Testmaster?

Ko ima pristup podacima dece i roditelja ako je iz izloženog moguće da firma Portalmaster Solutions nije radila na samom portalu, nego je to radila firma Testmaster Solutions?

Ok ovo je očigledno jedna te ista firma a verovatno i zaposleni ali poenta mi je da ilustrujem kako ovo izaziva sumnju jer nije transparentno šta se tačno radi i ko tačno radi i ko tačno ima pristup čemu?

Problem eksternih resursa na sajtu

Problem izveden iz kôda je to što su koristili eksterne resurse u obliku biblioteka za korisnički interfejs i prikaz sajta. Ovo znači da ti eksterni resursi koji se nalaze na javnom internetu i van naše kontrole imaju pristup IP adresama koje pristupaju Zdravitas portalu, takođe može doći do problema ako ti eksterni resursi budu nedostupni ili dođe do njihove kompromitacije. Sa aspekta privatnosti nije idealno, sa aspekta sigurnosti takođe jer bi državni portal koji barata osetljivim podacima trebao da bude zatvorena kutija sa strogo kontrolisam ulazima i izlazima podataka.

Problem potencijalnog tajnog logina

Još jedan problem izveden iz kôda sajta je daleko veći sa aspekta bezbednosti i poverenja u platformu. Naime, na sajtu je od osnivanja pa do 03.12.2024 stajalo ovo parče kôda:


   


Po onome što sam uspeo da vidim ovo je potencijalno nekakav "tajni" login koji se aktivira kada se tri puta klikne na određeno dugme na stranici. Da li je ikada bilo moguće koristiti ga, za koju svrhu i pod kojim tačno okolnostima nije mi poznato jer kad sam saznao za postojanje ovog kôda sajt je već bio izmenjen i sporni kôd uklonjen te nisam bio u prilici da isprobam.

Prepustio sam analizu ovog kôda ChatGPT-u, moguće je naravno da negde greši, ali sam proverio i neke stavke u dokumentaciji i potvrdio deo za tri klika jer mi je bilo toliko suludo da se koristi takva "sigurnost kroz opskurnost". A evo šta je sve imao da kaže ChatGPT :

Code:

Q. explain to me in simple terms what the following code snippet accomplishes


This JavaScript code snippet contains three main functionalities. Here's a simple explanation:

---

### 1. **Tooltip Setup Using `tippy.js`:**

```javascript
tippy('#btn-eid', {
    content: 'Пријава преко јединственог државног система за електронску идентификацију грађана',
    theme: 'light',
    animation: 'scale'
});
```

- **Purpose:** Adds a tooltip to an HTML element with the ID `btn-eid`.
- **What Happens:** When a user hovers over `#btn-eid`, a tooltip with the specified message (in Serbian, explaining something about an electronic identification system) will appear. The tooltip uses a "light" theme and a "scale" animation.

---

### 2. **Triple-Click Modal Trigger:**

```javascript
$("#loginText").on("click", function (event) {
    var isProdEnv = $("#isProdEnv").val();

    if (isProdEnv === "True") {
        return;
    }

    if (event.detail === 3) {
        $("#myModal").modal('show');
    }
});
```

- **Purpose:** Opens a modal (`#myModal`) when the user triple-clicks an element with the ID `loginText`.
- **How It Works:**
  - Checks if the `#isProdEnv` value is `"True"` (indicating a production environment). If true, it stops execution.
  - If in a non-production environment and the element is clicked three times (`event.detail === 3`), it shows the modal.

---

### 3. **Test Login Button Functionality:**

```javascript
$("#test-login-btn").on("click", function (e) {
    e.preventDefault();

    var isProdEnv = $("#isProdEnv").val();

    if (isProdEnv === "True") {
        return;
    }

    var obj = JSON.stringify({
        username: $("#username").val(),
        password: $("#psw").val()
    });

    $.ajax({
        url: "/Auth/TestLogin",
        type: "POST",
        contentType: 'application/json; charset=utf-8',
        data: obj,
        success: function (xhr) {
            console.log("aaaa");
            location.replace('/Home/Index')
        },
        error: function (xhr) {
            alert("Погрешно корисничко име или шифра");
        }
    });
});
```

- **Purpose:** Simulates a login action for testing purposes when the button with ID `test-login-btn` is clicked.
- **How It Works:**
  1. **Prevent Default Behavior:** Stops the default button behavior (like form submission).
  2. **Check Production Environment:** If the `#isProdEnv` value is `"True"`, it stops execution.
  3. **Send Login Data:** Creates a JSON object containing the entered username (`#username`) and password (`#psw`) values, then sends it to `/Auth/TestLogin` using an AJAX `POST` request.
  4. **Handle Server Response:**
     - If the request succeeds: Redirects the user to `/Home/Index`.
     - If it fails: Displays an alert saying "Погрешно корисничко име или шифра" (Serbian for "Incorrect username or password").

---

### Summary:
- Adds a tooltip to `#btn-eid`.
- Opens a modal on triple-click of `#loginText` in non-production.
- Simulates a test login by sending user credentials to the server and handles success or failure accordingly.

Let me know if you'd like further clarification!


Q. could this code be used to include a secret login into the system used only by those who know to triple click on the element with ID loginText?



Yes, this code could be used to create a secret login mechanism, but it depends on how the system is designed and how the triple-click feature is tied to actual authentication. Here's why and how this might work:

---

### How It Might Work as a Secret Login:
1. **Triple-Click Opens the Modal:**
   - The element with ID `#loginText` is programmed to show a modal (`#myModal`) if triple-clicked.
   - This behavior only occurs in a non-production environment (when `#isProdEnv` is not `"True"`).

2. **Test Login Process:**
   - Once the modal is open, the user could enter credentials in the modal's input fields (e.g., `#username` and `#psw`).
   - Clicking the "Test Login" button (`#test-login-btn`) sends the credentials to `/Auth/TestLogin`.
   - If valid credentials are provided, the server redirects the user to the home page (`/Home/Index`).

---

### Secret Nature:
- **Obscurity of Trigger Mechanism:**
   - The triple-click requirement makes this feature non-obvious to casual users.
   - Only users who know about the triple-click functionality would be able to access this path.

- **Environment-Specific Behavior:**
   - The code is designed to work only in non-production environments. However, if this check were disabled or the code were deployed in production without modification, the triple-click functionality could become available to all users who discover it.

---

### Potential Security Risks:
1. **Reliance on Obscurity:** Security-through-obscurity is not a robust strategy. If someone discovers the triple-click mechanism (e.g., by inspecting the code), they can easily exploit it.
2. **Server-Side Vulnerabilities:**
   - If the server endpoint (`/Auth/TestLogin`) lacks proper security measures (e.g., rate limiting, input validation, strong authentication), it could be abused.
3. **Insecure Deployment:**
   - If the code is mistakenly deployed in production without disabling this feature, it could allow unauthorized access to the system.

---

### Recommendations:
- **Disable in Production:** Ensure that the `isProdEnv` check is enforced rigorously, and consider removing this feature entirely in production environments.
- **Use Proper Authentication:** Any login mechanism (even for testing) should rely on secure, well-implemented authentication practices, not hidden UI interactions.
- **Audit Code:** Regularly review code to identify and eliminate potential backdoors or unintended functionalities.

While the code could function as a "secret login" mechanism, relying on such hidden interactions is risky and not recommended for secure systems. Let me know if you need help improving its security!


Q. could another potential security risk be that isProdEnv can be edited on the client side by a malicious actor in order to trigger the "secret login"?



Absolutely, **manipulating the `isProdEnv` value on the client side** is a significant security risk in this implementation. Since the value is presumably being stored on the client (likely as a hidden input field or JavaScript variable), a malicious actor could easily modify it to bypass the environment check. Here's how and why this is a concern:

---

### Why It's a Risk:
1. **Client-Side Control:**
   - The `isProdEnv` variable is read directly from the DOM using `$("#isProdEnv").val()`.
   - A malicious user can open the browser's developer tools and modify the value of `#isProdEnv` (or inject a new element with the desired value).

2. **Bypassing the Environment Check:**
   - If the attacker changes `#isProdEnv` to a value other than `"True"`, they could activate the triple-click or test-login functionality, even in a production environment.

3. **No Server-Side Enforcement:**
   - If the server does not independently validate the environment or enforce authentication restrictions, this client-side manipulation could provide unauthorized access.

---

### Real-World Exploitation:
Here’s how an attacker could exploit this:
1. Open developer tools in their browser.
2. Locate the `#isProdEnv` input field or the JavaScript variable controlling the environment.
3. Change its value to something other than `"True"` (e.g., `"False"` or delete the input altogether).
4. Perform the triple-click or use the test login feature to trigger the secret login functionality.

---

### Mitigation Strategies:
1. **Server-Side Enforcement:**
   - Validate the environment on the server, not the client. For example, the `/Auth/TestLogin` endpoint should reject all requests in production, regardless of the client-side environment variable.
   - Never rely solely on client-side logic for critical security decisions.

2. **Remove Client-Side Environment Logic:**
   - Avoid exposing environment-dependent behavior to the client. This information should remain server-side and not be modifiable by users.

3. **Secure the Modal Trigger:**
   - Use server-side authorization to ensure that only authenticated and authorized users can access sensitive features, such as the modal or test login endpoint.

4. **Audit and Pen-Test:**
   - Perform regular security audits and penetration testing to identify vulnerabilities like this before deployment.

---

### Summary:
Yes, the `isProdEnv` client-side check introduces a serious security risk because it can be manipulated by an attacker. This highlights the critical principle of **never trusting client-side data** for security decisions. Ensure all environment checks and sensitive functionality are enforced on the server side to mitigate this risk. Let me know if you'd like help refactoring this!



what does this code accomplish:

<input type="hidden" id="isProdEnv" value="value">




The code snippet below creates an **HTML hidden input field**:

```html
<input type="hidden" id="isProdEnv" value="value">
```

### What It Does:
1. **Hidden Field:**
   - The `type="hidden"` attribute makes this input invisible in the browser's UI. It does not appear on the webpage but is still present in the DOM (Document Object Model).

2. **ID Attribute:**
   - The `id="isProdEnv"` attribute assigns a unique identifier to the input field. This allows JavaScript or other client-side scripts to locate and interact with it.

3. **Value Attribute:**
   - The `value="value"` attribute holds a value (in this case, `"value"`) that can be used programmatically. In practice, this would often be replaced dynamically with `"True"`, `"False"`, or some other context-specific value.

### Purpose:
Hidden inputs like this are typically used to store data that needs to be available to scripts but does not need to be displayed to the user. For example:
- Passing data between forms or pages without showing it to the user.
- Storing application state or configuration details for client-side use.

In this specific example, it likely stores a flag (`isProdEnv`) that indicates whether the application is running in a production or non-production environment.

---

### Security Implications:
Hidden fields are **not secure** because:
- They are still accessible in the browser's developer tools.
- A malicious user can easily modify the value of the field.

If the application relies on the value of `isProdEnv` for critical decisions (like enabling or disabling features), this creates a security risk. All sensitive decisions (e.g., environment checks) should be validated on the **server-side** rather than trusting the client.

Let me know if you'd like to dive deeper into its use cases or security considerations!

Pošto je ID dugmeta nazvan "test-login-btn" moguće je da su test sajt pustili u produkciju. Ovo ne uliva poverenje u sajt i tvorce istog obzirom da je takav kôd stajao na sajtu najmanje 2 meseca bez da ga iko primeti i ukloni. I da nije uopšte tajni login i da je potpuno bezazleno parče koda opet predstavlja problem jer mu nije mesto na sajtu u produkciji i oslikava propust programera i postavlja pitanje kakvih još propusta ima?

---

Ovi tehnički problemi, dakle eksterni sadržaj i "tajni" login su bili prisutni na sajtu od kada je postao dostupan negde krajem septembra pa do 03.12 kada su izmenili stranicu i izbacili obe sporne stavke. Ne znam da li su primetili na osnovu Linkedin objave gde sam i ja primetio a koji je objavljen baš 03.12.2024 kada je sajt i izmenjen. Znamo da je neko iz SAGA d.o.o. pročitao tu Linkedin objavu i ostavio reakciju tj. lajk.

I čisto da uspostavimo nekakav vremenski okvir:

• najranija verzija za koju znam da je imala ove nedostatke:
  Верзија портала: Prod - 0.1.0.5 | 26.09.2024. 16:00
  

• poslednja verzija sa nedostacima:
  Верзија портала: Prod - 0.1.4.7 | 02.12.2024. 20:00
  

• sređena verzija:
  Верзија портала: Prod - 0.1.4.9 | 03.12.2024. 21:00
  

---

Poverenik

Zanimljivo je da je Poverenik za informacije od javnog značaja i zaštitu podataka o ličnosti "izvršio vanredni terenski inspekcijski nadzor nad primenom Zakona o zaštiti podataka o ličnosti povodom obrade podataka maloletnih lica u okviru portala „Zdravitas“ od strane Ministarstva prosvete kao Rukovaoca." Gde je izdato [/url][url=https://www.poverenik.rs/sr-yu/saopstenja/4275-%D1%81%D0%B0%D0%BE%D0%BF%D1%88%D1%82%D0%B5%D1%9A%D0%B5-%D0%B7%D0%B4%D1%80%D0%B0%D0%B2%D0%B8%D1%82%D0%B0%D1%81.html]Saopštenje Poverenika: „Zdravitas“

u Saopštenju se spominje:

Projekat je pokrenut na osnovu Sporazuma o saradnji u vezi sa uspostavljanjem platforme... Navedenim sporazumom bliže su uređeni... da obezbedi neophodne integracije sistema „Zdravitas“ sa jedinstvenom prijavom (single sign-on sistem dostupan na eid.gov.rs)

takođe:

Administrativnom delu portala pristup podacima pored administratora ima isključivo autorizovani korisnik odnosno direktor škole, zaposleni u školi – ovlašćeno lice od strane direktora škole, odeljenjski starešina, nastavnik razredne nastave i nastavnik fizičkog i zdravstvenog vaspitanja za učenike za koje su nadležni.

Po ovome vidimo da je inspekcijski nadzor samo gledao dokumentaciju i utvrdio da je na papiru sve u redu, što je možda i njihova nadležnost. To što postoji potencijalni zaobilazak za eid.gov.rs preko tajnog logina nikom ništa, ne očekujem da imaju kadar koji bi to otkrio pa im ne zameram previše, znamo već da su nam institucije beskorisne, jednostavno ne možemo imati poverenje u Poverenika kada samo gleda dokumentaciju a ne realno stanje na terenu. 

Ovo je otprilike isti način na koji je Srbija "svrstana u sam vrh globalne i regionalne liste" globalnog indeksa informacione bezbednosti jer je ocena na indeksu zasnovana na self-reporting upitniku, tj. na papirima a ne na realnom stanju na terenu. Ako vas zanima o tome možete više pročitati na https://bezbedanbalkan.net/thread-1626.html

---

Kopiranje prethodno napravljenog kôda u novi projekat nije retka pojava i nije samo po sebi sporno. Ali ovde se to krije od javnosti, krije se da je Zdravitas portal potencijalno nekim delom ili u celosti zapravo prepravljen Testmaster portal koji je naizgled napravljen javnim sredstvima. Da li Zdravitas onda košta koliko je plaćen? I ako se već prepravlja nešto postojeće zašto se nije prepravio eDnevnik da ugosti i podatke koje prikuplja Zdravitas kako su mnogi iz IT sfere i van nje preporučili kao logičnije rešenje od ove potpuno nove, skupe i nepoznate platforme?

Za sada toliko, kada bude dostupan deo portala koji je za roditelje biće moguće uraditi detaljniju analizu jer će sigurno među roditeljima biti ljudi iz IT bezbednosne sfere koji će pogledati malo kako stvari u pozadini funkcionišu.

---

Korišćeni medijski izvori:

Država potrošila 360.000 evra na kontroverzni projekat “Zdravitas”, a prosvetari odbijaju da ga koriste: U posao uključene i 2 privatne firme
https://nova.rs/vesti/drustvo/drzava-pot...zdravitas/

Podaci o đacima onlajn - šta je "Zdravitas" i zašto su niški roditelji, pravnici i prosvetari protiv
https://www.juznevesti.com/Drushtvo/Poda...iv.sr.html

Portal Zdravitas: pravni aspekti obrade podataka o deci, prosvetnim radnicima i roditeljima
https://www.youtube.com/watch?v=1dB2Wkpe6Sk

(Ne)sporan dopis ministarstva o projektu Zdravitas upućen roditeljima
https://prviprvinaskali.com/clanci/dom/r...ljima.html

Ministarstvo prosvete objavilo koje tačno podatke prikuplja Zdravitas i gde se čuvaju
https://zelenaucionica.com/ministarstvo-...script=lat

Решење развијено на ФОН-у и ове године успешно примењено за тестирање ученика на малој матури
https://oldfon.fon.bg.ac.rs/blog/2023/06...oj-maturi/