# Rapportage Penetratietest DAK Kindercentra

## Scope
- Locatie kinderdagverblijf (Lamgroen 18, 2511 XE Den Haag)
- Locatie Servicekantoor (Maanweg 174, 2516 AB Den Haag)
- Azure omgeving
- Externe componenten DAK

## Gehanteerde richtlijnen
- [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) Application Security Verification Standard
- [OWASP API Security Project](https://owasp.org/www-project-api-security/
- [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers) ) 
- NCSC-NL - [ICT-beveiligingsrichtlijnen](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) voor Transport Layer Security (TLS)
- [MITRE ATT&CK®](https://attack.mitre.org) Matrix for Enterprise
- [OSSTMM 3](https://www.isecom.org/OSSTMM.3.pdf) Open Source Security Testing Methodology
- [PTES](http://www.pentest-standard.org/index.php/Main_Page) Penetration Testing Execution Standard
- [NIST (SP) 800-115](https://csrc.nist.gov/pubs/sp/800/115/final), Technical Guide to Information Security Testing and Assessment

Kwetsbaarheden gescoord volgens het Common Vulnerability Scoring System ([CVSS versie 3.x](https://nvd.nist.gov/vuln-metrics/cvss)). 

## Bevindingen

| Identifcatie | Naam bevinding                                     | Risicoclassificatie |
| ------------ | -------------------------------------------------- | ------------------- |
| ID: F.11     | Kerberoastable Domain Admin Account                | Hoog                |
| ID: F.1      | WP-Cron beschikbaar                                | Medium              |
| ID: F.8      | Service Accounts met domain admin rechten          | Medium              |
| ID: F.3      | Users.json beschikbaar voor anonieme gebruikers    | Laag                |
| ID: F.4      | Toegang tot xml-rpc.php voor anonieme gebruikers   | Laag                |
| ID: F.10     | Kerberoastable service accounts                    | Laag                |
| ID: F.12     | Web applicatie draaiend op port 80                 | Laag                |
| ID: F.2      | DMARC: Quarantine/Reject policy niet geconVgureerd | Informatief         |
| ID: F.5      | Missende security headers                          | Informatief         |
| ID: F.6      | Default Admin account actief binnen Azure          | Informatief         |
| ID: F.7      | Applicatiegeheim met te lange einddatum            | Informatief         |
| ID: F.9      | Verouderde Servers                                 | Informatief         |

**Mijn mening**
- F.8, F.10 en F.11 gaan alledrie over Service Accounts met onnodig hoge rechten. Mogelijk een structurele fout in de benadering van Service Accounts – beleidsvorming lijkt me verstandig. Zou voor mijn begrip graag uitleg willen waarom de risicoclassificatie van F.8 'medium' is
- F.10 en F.11 draaien beiden om Kerberoasting maar F.10 heeft RC 'Laag' en F.11 heeft RC 'Hoog'. Waarom? 
- F12: welke web applicatie is dit? Want als dit gevoelige gegevens betreft vind ik het niet RC 'Laag'
- F1, F4 gerelateerd aan de implementatie van de website – is dit door een partner gedaan? Dit is wat betreft informatiebeveiliging een aandachtspunt voor het leveranciersmanagement
- F6: standaard admin account op Azure actief. Zie F1, F4.
- F7: applicatiegeheim Zorgmail met ongebruikelijk lange geldigheidstermijn in Azure. Wie heeft dit ingesteld? Mogelijk zelfde als F1, F4 en F6. Ik weet niet wat de gevolgen kunnen zijn van een kwetsbaarheid op Zorgmail Domeinboek.




### F.11 Kerberoastable Domain Admin Account

Voor het gebruik van de SA_VEEAM backup software is een Domain Administrator account aangemaakt. Dit geeft directe toegang geeft tot de volledige Active Directory-omgeving. Een aanvaller kan hiermee back-ups manipuleren, verwijderen of zelfs de volledige Active Directory overnemen. Het principe van least privilege lijkt niet te zijn toegepast

Volgens Vitaen is dit 'in de meeste gevallen niet noodzakelijk en verhoogt het aanvalsoppervlak aanzienlijk': 
>Aangezien dit account vatbaar is voor een [Kerberoasting](../../Corpus/🎇%20Sparks/Kerberoasting.md) aanval, is het mogelijk gebleken de wachtwoord hash te bemachtigen. Het bleek echter niet mogelijk in de korte tijd dat de opdracht plaatsvond, om hiervan het wachtwoord te brute-forcen.

**Oplossingsrichting**
> Vitaen adviseert om het principe van least privilege toe te passen: service accounts mogen alleen de rechten krijgen die strikt noodzakelijk zijn voor hun functionaliteit. Waar mogelijk moeten alternatieve oplossingen zoals Managed Service Accounts (MSA) of Group Managed Service Accounts (gMSA) worden gebruikt, die automatisch wachtwoorden roteren en minder risicovol zijn. Daarnaast moet het gebruik van service accounts met verhoogde rechten actief worden gemonitord en gelogd, zodat afwijkend gedrag direct wordt opgemerkt.

NOTA BENE: F.10 draait ook om Kerberoasting maar heeft RC 'Laag'. Waarom? Bij de oplossingsrichting aldaar wordt ook het 'monitoren van Kerberos-verzoeken op verdachte activiteiten' genoemd.

### F.1 WP-Cron beschikbaar

WP-Cron.php is een virtueel cron systeem dat wordt gebruikt door WordPress om geplande taken uit te voeren. Dit endpoint is publiekelijk toegankelijk, wat aanvallers in staat stelt om ongeautoriseerde cron-taken uit te voeren wat kan resulteren in een Denial-of-Service (DoS)-aanval.

**Oplossingsrichting**
> Vitaen adviseert om de toegang tot WP-Cron.php door middel van IP-restricties of authenticatie te beperken. Alternatief kan WP-Cron.php uitgeschakeld worden in de WordPress-conVguratie (wpconVg.php) en vervangen worden door de server-gebaseerde cron om geplande taken uit te voeren. Dit voorkomt ongewenste toegang en minimaliseert de kans op misbruik.

### F.8 Service Accounts with domain admin rechten

> Meerdere service accounts beschikken over Domain Admin-rechten. (...) Het toekennen van dergelijke hoge privileges aanzienlijke risico’s met zich mee.

Bij compromittering van (deze) account(s) kan een aanvaller:
> volledige controle over de Active Directory kan verkrijgen. Dit opent de deur naar privilege escalation, laterale beweging binnen het netwerk en zelfs volledige overname van de IT-infrastructuur. Bovendien worden service accounts vaak uitgesloten van multi-factor authenticatie (MFA), wat het risico op misbruik verder vergroot.

**Oplossingsrichting**
> Vitaen adviseert om het principe van least privilege toe te passen: service accounts mogen alleen de rechten krijgen die strikt noodzakelijk zijn voor hun functionaliteit. Waar mogelijk moeten alternatieve oplossingen zoals Managed Service Accounts (MSA) of Group Managed Service Accounts (gMSA) worden gebruikt, die automatisch wachtwoorden roteren en minder risicovol zijn. Daarnaast moet het gebruik van service accounts met verhoogde rechten actief worden gemonitord en gelogd, zodat afwijkend gedrag direct wordt opgemerkt.



![](20250309%20Rapportage%20security%20assessment%20DAK%20v1.0.pdf)