Interne IP-adressen en hostnamen blootgesteld

Een aanvaller die binnenkomt, weet niet hoe uw netwerk eruitziet. Dat in kaart brengen kost tijd en veroorzaakt verkeer dat kan opvallen. Interne adressen die uw applicatie zelf prijsgeeft, besparen hem die stap. Hieronder leest u langs welke wegen dat gebeurt en waarom het vooral in combinatie met andere kwetsbaarheden telt.

Wat lekt er precies?

Van blootgestelde interne adressen spreken we wanneer een applicatie adressen of namen prijsgeeft die alleen binnen uw eigen netwerk betekenis hebben. Het gaat om privé-IP-adressen uit de gereserveerde bereiken, om servernamen, en om interne domeinnamen die niet publiek zijn.

Die gegevens zijn niet geheim in de zin dat er iets mee te openen valt: een aanvaller op internet kan een privéadres niet benaderen. Wat ze prijsgeven is structuur: hoeveel servers er zijn, hoe ze heten, hoe de nummering is opgebouwd, welke rollen er bestaan. Een naam als db-prod-02.intern.bedrijf.nl vertelt in één regel dat er een productiedatabase is, dat er waarschijnlijk een db-prod-01 bestaat, en dat het interne domein intern.bedrijf.nl heet.

Zoiets als een plattegrond die uit een gebouw naar buiten waait. Er zit geen sleutel bij, en toch is hij waardevol voor wie van plan is naar binnen te gaan.

Waar komen die interne adressen vandaan?

Kwetsbaar:

HTTP/1.1 500 Internal Server Error
X-Backend-Server: app-node-03.intern.bedrijf.nl
Via: 1.1 proxy-dmz-01 (squid/5.2)

Kan geen verbinding maken met 10.0.4.12:5432 (database-prod-02)

Drie regels, drie lekken. De header verraadt de naam van de applicatieserver en het interne domein. De proxyheader noemt een systeem in de gedemilitariseerde zone. Verder de foutmelding geeft het IP-adres, de poort en de naam van de databaseserver.

Andere plekken zijn minder opvallend maar even productief. Een redirect die het interne adres bevat in plaats van het publieke. HTML-commentaar met een verwijzing naar een testserver. Een e-mailheader die de volledige interne route toont. Een Location-header die na een verkeerd geconfigureerde proxy het adres van de achterliggende server draagt.

Veilig:

# De proxy schoont op wat de achterliggende server toevoegt
proxy_hide_header X-Backend-Server;
proxy_hide_header X-Powered-By;
proxy_hide_header Via;

# Redirects herschrijven naar het publieke adres
proxy_redirect http://app-node-03.intern.bedrijf.nl/ https://portaal.example/;

// En foutmeldingen bevatten nooit adressen
app.use((fout, req, res, next) => {
  const referentie = randomUUID();
  logger.error({ referentie, bericht: fout.message, stack: fout.stack });
  res.status(500).json({ fout: 'Er is iets misgegaan', referentie });
});

De proxy is hier de aangewezen plek, omdat u daar in één keer opschoont wat elke achterliggende dienst toevoegt, ook diensten waarvan u de configuratie niet in de hand hebt. De foutafhandeling zorgt dat er nooit een adres in het antwoord terechtkomt; de details staan in uw logbestand, gekoppeld aan een referentienummer.

Wat is de impact van blootgestelde interne adressen?

De ernst is laag, en dat blijft zo in vrijwel elke situatie. Er is geen aanval die door deze informatie mogelijk wordt gemaakt; er wordt geen toegang verkregen en er lekken geen gegevens van gebruikers.

De waarde ligt in de verkenning. Een aanvaller die via een andere weg binnen is gekomen (een gecompromitteerd account, een werkstation, een kwetsbaarheid in een andere dienst) moet uitzoeken waar hij is en wat er te bereiken valt. Dat uitzoeken kost tijd en genereert netwerkverkeer dat door detectiesystemen kan worden opgemerkt. Kent hij de adressen al, dan kan hij gericht te werk gaan en blijft hij langer onopgemerkt.

Er is nog een tweede overweging. De plekken waar interne adressen weglekken, zijn vrijwel altijd dezelfde plekken waar ook andere informatie weglekt: uitgebreide foutmeldingen, headers die niet zijn opgeschoond, commentaar dat is blijven staan. Het opruimen ervan pakt daarom meestal meer aan dan alleen deze bevinding.

Hoe spoor je blootgestelde interne adressen op?

Een tester zoekt in alle antwoorden naar patronen die op privéadressen wijzen, en naar hostnamen met een intern aandoend domein. Dat gebeurt niet alleen op de gewone pagina’s maar juist op de plekken waar het misgaat: foutpagina’s, redirects, antwoorden op verkeerd gevormde verzoeken en tijdelijke storingen.

Daarnaast worden de headers van verschillende soorten antwoorden vergeleken, omdat een statisch bestand en een API-antwoord door verschillende componenten worden afgehandeld en dus verschillende headers dragen. Ook wordt gekeken naar HTML-commentaar, naar JavaScript-bestanden met geconfigureerde adressen, en naar de headers van e-mail die de applicatie verstuurt. Verder krijgen bestanden aandacht die vanuit een interne omgeving zijn gepubliceerd, omdat daar paden naar netwerklocaties in kunnen staan. AssistSec combineert deze bevindingen tot een beeld van uw interne structuur, precies zoals een aanvaller dat zou doen, en dat beeld maakt vaak duidelijker dan de losse regels waarom het opruimen de moeite waard is.

Hoe voorkom je blootgestelde interne adressen?

• Schoon headers op bij uw reverse proxy, zodat achterliggende diensten hun namen niet meesturen.
• Herschrijf redirects naar het publieke adres in plaats van het interne door te geven.
• Neem nooit adressen of servernamen op in foutmeldingen die de gebruiker te zien krijgt.
• Verwijder HTML-commentaar en geconfigureerde interne adressen uit uw frontendbestanden.
• Laat uw uitgaande mailserver de interne routeringsregels uit e-mailheaders verwijderen.
• Controleer of Location-headers na een proxy het publieke adres bevatten.
• Gebruik neutrale servernamen die geen rol of nummering verraden.
• Neem deze controle op in uw acceptatieproces, omdat het lekken meestal ontstaat bij een configuratiewijziging.