×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Belgische hacker krijgt toegang tot interne communicatie bedrijven via truc

Door , 31 reacties

Het is een Belgische hacker gelukt om bij bedrijven via een truc toegang te krijgen tot interne communicatie. De truc werkt via de helpdesk van bedrijven. Die maakt vaak gebruik van een geautomatiseerd systeem om tickets aan te maken.

Om de tickets af te handelen, krijgen klanten veelal een tijdelijk e-mailadres op het domein van het bedrijf, schrijft de Belgische Inti De Ceukelaire. Het bleek mogelijk om met dat e-mailadres bij veel bedrijven toegang te krijgen tot interne communicatie via bijvoorbeeld Slack of Yammer. Die diensten werken vaak met een e-mailadres op het domein van het bedrijf om toegang te krijgen.

Volgens de ethische hacker bleken medewerkers in die Slack-kanalen vervolgens onvoorzichtig om te springen met bijvoorbeeld wachtwoorden voor interne systemen of social media, waardoor een kwaadwillende via de zoekfunctie van zo'n chatprogramma makkelijk achter belangrijke wachtwoorden zou kunnen komen.

Waar het ook fout gaat, is dat veel bedrijven niet aan e-mailverificatie doen. Daardoor kon de hacker zelfs zonder e-mailadres op het domein van een bedrijf toegang krijgen tot de interne communicatie. Zo schreef hij zich op videodienst Vimeo in onder de naam feedback@slack.com, waarna hij op Slack via de 'find my workspace'-functie zich aanmeldde voor het Slack-kanaal van Vimeo. Support@vimeo.com registreerde de verificatiemail van Slack als supportticket van feedback@slack.com, waardoor de link in de Vimeo-helpdeskomgeving van de hacker verscheen.

Slack heeft het lek gedicht door een token toe te voegen aan zijn mailadressen, waardoor de laatste truc niet meer werkt. Het lek dat werkt via een tijdelijk e-mailadres op het domein van het bedrijf, blijft werken, omdat het gaat om een functie van Slack en niet een bug. Bedrijven moeten dat zelf verhelpen. Andere chatdiensten als Yammer zijn nog steeds vatbaar voor de truc.

Het is niet de eerste keer dat De Ceukelaire een lek in een bekende webdienst openbaart. In januari vond hij bugs bij Facebook, waardoor hij verborgen telefoonnummers kon opzoeken via het sociale netwerk.

Door Arnoud Wokke

Redacteur mobile

22-09-2017 • 08:54

31 Linkedin Google+

Reacties (31)

Wijzig sortering
Kort voorbeeldje dat aantoont hoe erg dit is (do not try this at home/ enkel als voorbeeld):

Stap 1:
Maak een account aan bij een online helpdesk, met je een wegwerp email adres, ik zeg wat mijn@email.tld In het mailtje dat je krijgt om je registratie te bevestigen staat het adres van de afzender, veelal is dat support@eendomein.be
Maak een ticket aan via het web platform, kijk naar de afzender die je de ticket notificatie stuurt, veelal is dat ook support@eendomein.be
Er zitten nog wat gaatjes in een aantal van die helpdesk toepassingen (ik heb er alvast 2 extra gevonden).

Stap 2:
We gaan een account aanmaken bij Ebay. Schrijf je in, gebruik als afzender: support@domein.be, vooraleer je bevestigen klikt, ga je terug naar de helpdesk site, wijzig het mailadres dat je hebt gebruikt (kies een exploit er zijn er heel wat als je goed zoekt) naar het adres dat Ebay gebruikt om te communiceren (bij wijze van voorbeeld veronderstel ik even dat dit notifications@ebay.tld).
Een dat is aangepast op de helpdesk site, klik dan op bevestigen als laatste stap van de Ebay registratie.


Resultaat: op het helpdesk platform zal alle mail, bestemd voor support@domein.tld en komende vanaf notifications@ebay.tld worden doorgestuurd naar de user account die je hebt aangemaakt. Alle mail komende vanaf Ebay voor support@domein.tld is nu onder jou controle.

De natte droom van elke scammer en phisher.

Je hebt nu een Ebay account met sterke referenties want met mailadres van het echte maildomein en je zou bijvoorbeeld een shop kunnen maken. Hang daar een gekochte 'middleman' account in van een betalingsverwerker, te koop op de betere onion sites. Koop een anonieme prepaid debit betaalkaart. Die koppel je aan je middleman account.

Transfereer de tegoeden van de betalingsverwerker naar je anonieme prepaid debit kaart (die heeft een IBAN dus je kan er geld naar overschrijven)

Je kan beginnen met het maken van listing voor je shop, principe zoals altijd: "iPhone 8 voor 'maar' 500 Euro want refurbished en limited time only. Je kan al raden hoe lucratief zoiets is voor een scammer.


Variaties op bovenstaande zijn eindeloos, vooral voor bedrijven is het gevaar groot als ze slordig omspringen met data. Mits cherry picking hoef je gewoon maar een SME/MKB te zoeken die levert aan enterprise. Komt er op een goede dag een dringend order binnen van (zeg wat) HP. Voor 20 laptops. Maar alleen mits krediet. Een MKB zou misschien geneigd zijn om zoiets te doen want HP is groot en nieuwe klanten en blah blah blah . Neem 15 of 30 dagen later verwacht je dan een betaling die uiteraard nooit komt en is de hele setup al afgebroken en verhuisd.

Inti bewijst andermaal wat velen in de security sector zeggen. Voor offensive security zijn alle dure titels zoals CISSP/CEH/CISA (die quasi te koop zijn, is maar te zien hoeveel je wil investeren in betaalde training met aansluitend examen) waardeloos. Je kan daar niks mee aanvangen in een Red Team, zelfs in Blue team... wegens tunnelvisie. Hoe kan je nu pretenderen expert te zijn in security als je: niet kan programmeren, nooit system engineering of administration hebt gedaan, niks van electronica of UI design en response, kent en maar overweg kan met 1 besturingssysteem?

Het resultaat van die onzin lees je dagelijks in de krant :)
Opleidingen van dure titels zoals CISSP/CEH/CISA gaan er van uit dat iedereen mooi rechts van de autosnelweg rijdt met allemaal dezelfde wagen op allemaal precies dezelfde snelheid: 115 km/u en niet 120, want 120 is 5km per uur te snel voor de politie wiens volledig identieke auto ook maar maximaal 120 kan rijden.

Die dure titels denken criminelen die de autosnelweg gebruiken om te vluchten te kunnen vatten op deze manier.

Zij zijn er immers van overtuigd dat die criminelen ook mooi rechts van de autosnelweg zullen rijden, met allemaal dezelfde wagen op allemaal precies dezelfde snelheid: 115 km/u.

Natuurlijk zullen criminelen bv. een brommer gebruiken die 260km/u rijdt over pechstroken, op de middenberm, in tegenovergestelde richting, tussen andere auto's door en zo verder. Maar dat, dat is onheilig voor de dure titels. Wat dat hebben ze niet geleerd. Wat ze niet geleerd hebben, dat kan niet. Dat bestaat niet. Dat mag niet. Dat is er niet. Oogjes toe. Snaveltjes dicht. Want dat stond niet in het boekje van de dure titel.

Het is precies zoals je het zegt, en zelfs erger: wil je de dag van vandaag een inbreker van het niveau dat voor een andere overheid werkt tegenhouden, dan moet je minimaal kernel ontwikkeling kunnen. Die rootkits draaien immers in de kernel of zelfs in de firmware van hardware (dus boven de kernel) of gewoon hard in de hardware. De virusscanners (en firewall software) die in die opleidingen uitgelegd worden draaien onder de kernel en kunnen het dus vergeten dat ze iets zullen detecteren. Met gebruikt ook niet het netwerk om gegevens te exfiltreren maar wel bv. het LCD scherm, de LEDs van de laptop of computer. Of men gebruikt bv. de eigen interne nameserver (telkens andere subdomains aanvragen op een domain met een kleine TTL).

Merk op dat wat vandaag met de resources van een overheid gedaan wordt, heel binnenkort in handen van criminelen is. Vooral nu dat er tal van lekken zijn geweest bij de NSA met dit soort tools.

Wat we nu meemaken is dus nog maar het begin.
Ha! Slimme truc. Maar het gaat dus vooral mis omdat Slack iedereen met een e-mailadres onder @domeinnaam toestaat om zich te registreren en blijkbaar dus niet aan mailverificatie doet. Dat is haast vragen om problemen.
Jawel, slack doet wel aan mailverificatie, maar als je die mail dus op eoa manier kan onderscheppen dan heb je dus toegang tot slack. Om het legitieme gebruikers makkelijk te maken kon bijvoorbeeld iedereen met een @tweakers.net account een account krijgen op onze interne Slack. Nu moet ik iedereen inviten ;)

Hij had ook Gitlab als voorbeeld, daar kun je een issue aanmaken door naar een mailadres te mailen. Dat issue is dan soms publiek beschikbaar. Als je dan bijvoorbeeld mailed naar incoming-ticket-project@gitlab.com dan maakt hij automatisch een issue aan.

Wat hij dan deed, was bij slack een account aanmaken met als mailadres incoming-ticket-project@gitlab.com. Slack maakte vervolgens een ticket aan bij gitlab (want dat doet dat mailadres) met daarin de verificatielink. Daar click je vervolgens als eerste op en voila, je hebt toegang tot het slack account van gitlab.com.
Wij hebben ook functionaliteit waar gebruikers bestanden kunnen emailen naar een bepaald adres. Echter hebben wij er voor gekozen om een subdomein te gebruiken voor die "publiek" toegangkelijke adressen: xxx@in.domain.com ipv xxx@domein.com.
Slim om dat te doen. Sommige bedrijven gebruiken namelijk e-mail forwarders gebaseerd op non-AD accounts waarmee een catch-all wordt gedaan op het gehele domein.

Ik snap dan ook niet waarom bedrijven in vredesnaam een tijdelijk e-mailadres op eigen domein aanmaken voor supporttickets.

IEDEREEN heeft een e-mailadres. Gebruik dat dan ook in je communicatie voor support tickets. Dan heb je dit soort problemen dus niet. Zelfs als je het mailadres daarna verwijdert blijft het slackaccount namelijk gewoon bestaan.
Mag ik zeggen dat dat wel heel erg dom is? :l
Inviten behoord een standaard te zijn..
In de initiele setupfase is het een stuk makkelijker om een bedrijfswijde email uit te sturen met 'hier is slack, maak een account aan' dan dat iemand ~200 mailadressen gaat invoeren.

Na die fase kan slack inderdaad op invite-only. Maar de default voor dit soort diensten is meestal domein-verificatie, wat prima werkt als alleen werknemers een mailadres krijgen.
Maar waarom zou een een tijdelijk e-mail adres aanmaken op je domein, als iemand alleen maar een ticket aanmaakt?

En hoe gebruik je vervolgens zo e-mail adres?
Er wordt een tijdelijk e-mail adres aangemaakt zodat je er e-mails omtrent je "probleem" kan naar toe zenden. Die e-mails worden dan netjes getoond onder je ticket via een web interface. Het probleem is ook dat de e-mails die er naar toe worden verzonden (registratie e-mails van slack in dit geval) ook getoond worden onder dat ticket in die web interface.

Via deze afbeelding wordt het duidelijk: https://cdn-images-1.medi...uFWONQPwRrvInHLMQsv_Q.png
En dat is dus vragen om problemen blijkt maar weer.

Het systeem met “ do not type below this line and always embed the original message” vangt dan al een hoop af. Je kunt dit dan namelijk niet gebruiken voor verificatiemails van andere diensten.
Dat is wanneer je een ticket "update" via een mail.
Vaak kun je ook nieuwe tickets aanmaken met een mail. En daar wordt hier gebruik van gemaakt.
En dat is dus vragen om problemen als je dit op hetzelfde domein doet. Een subdomein hiervoor instellen is een fluitje van een cent en kost helemaal niets extra.
Op die manier, dank voor de uitleg.
De meeste helpdesk systemen die ik ken, werken met een ticket nummer ergens in de e-mail.
Maar het gaat dus vooral mis omdat Slack iedereen met een e-mailadres onder @domeinnaam toestaat om zich te registreren
Dat is een optie binnen Slack. Je kan het ook uitzetten.
The GitLab team responded to my report on the same Sunday evening I reported it.

They immediately set their slack to invite-only and took additional measures to inform their customers about the dangers of this functionality.
Het lijkt mij dat dit makkelijk op te lossen is door simpel weg een ander domein te gebruiken voor je externe klanten (tickets) communicatie en je interne communicatie. Deze werkwijze is sowieso een stuk veiliger.
Gewoon zorgen dat je in Slack de boel beter dicht timmert in plaats van zegt dat iedereen met een email van jouw domein toegang heeft :)
"krijgen klanten veelal een tijdelijk e-mailadres op het domein van het bedrijf"? Huh? In welk helpdesksysteem werkt dat zo?
Het is al weer even geleden, maar volgens mij biedt Zendesk sowieso die optie. Er zullen er meer zijn, Dan is het wel een random guid@domeinnaam oid, maar die guid wordt gebruikt om de status van tickets te tracken zonder dat een gebruiker die kan verprutsen door de token in subject bijvoorbeeld weg te halen. Kan me voorstellen dat een dergelijke constructie voor dit soort slimme truucs ruimte laat.
e. het reply-to adres is dan de gebruiker zelf, waardoor die de berichten wel gewoon ontvangt -- snap dat het zonder deze toevoeging nogal verwarrend klinkt. Of gebruikers loggen met hun 'nieuwe' emailadres in op een self-service portal.

[Reactie gewijzigd door Old Swartly op 22 september 2017 09:28]

Van marktplaats krijg je ook een mailadres (weet niet meer of het ook op hetzelfde domein is).
Het marktplaats emailadres deed hetzelfde als dat van tweakers. Gebaseerd op een hash van iets een tijdelijk mailadres maken met als reply to het originele adres. Dit is om het initiele mailtje te kunnen versturen maar latere communicatie gaat via het eigen mail adres.

Heb het net even getest maar tegenwoordig gebruiken ze “automatisch@marktplaats”

Dus daarmee werkt dit denk ik niet.
Nee, klant krijgt niet feitelijk een mailadres... Aan betreffende ticket wordt een adres gekoppeld binnen het domein (waar je als klant naar toe mailt als je een bericht wilt toevoegen aan het betreffende ticket). Alle mailverkeer naar dat adres komt dus automatisch bij het juiste ticket in het systeem terecht en veelal is de gehele communicatie rondom zo'n ticket via een web interface toegankelijk voor jou als klant. En dus kun je dat mailadres ook gebruiken/misbruiken om verificatiemails naar te laten verzenden die dan netjes zichtbaar zijn in betreffende ticket op de webinterface. Inclusief de verificatie link naar bijvoorbeeld Slack.
Andere chatdiensten als Yammer zijn nog steeds vatbaar voor de truc.
Dat is wel erg yammer.
Zodra je integratie hebt met Azure AD voor je Yammer omgeving werkt deze truuk ook niet meer. Tenzij je met het email adres ook een user object krijgt maar dat lijkt mij heel erg overbodig.
Number 3 will blow your mind!

edit: /s

[Reactie gewijzigd door oef! op 22 september 2017 09:00]

Vond het ook wel een beetje bijzondere titel, zit dicht in de buurt van clickbait 8)7
"Belgische hacker" dacht gelijk aan Inti. Die jongen is goed bezig laat hem maar schuiven zo. Ook al eens voor Metallica wat gedaan waar hij een gesigneerd toetsenbord aan over gehouden heeft en een pintje met ze gedronken heeft.

Interessant dat dit zo werkt en dat het dus een feature is bij Slack. Zorgelijk eigenlijk.
das wel een beetje yammer weer :D
De hacker is bekend om aalst in het nieuws te krijgen, zo heeft hij eerder een url gehijjacked van een tweet van Trump. Meer van hem kan je hier terugvinden

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*