De Devschuur Coffee Corner - Iteratie ⓬

[kwaakvaak_v2]

Creepy schreef op maandag 18 mei 2020 @ 16:27:
[...]

Klink in mijn ogen toch als een pentest die gedaan wordt voordat het daadwerkelijk in productie staat (zoals het hoort dus )

Dat zeg ik toch, maar wel op de omgeving die daadwerkelijk in productie gaat en niet op een aparte omgeving.

[Firesphere]

Kalentum schreef op maandag 18 mei 2020 @ 10:32:
[...]


Heeft elke klant dan een eigen productie-omgeving? Want anders kan zo'n test ook de data en performance van andere klanten beïnvloeden.

Yeps, shared hosting kom ik nooit (meer) tegen

[Koenvh]

Firesphere schreef op dinsdag 19 mei 2020 @ 00:20:
[...]

Yeps, shared hosting kom ik nooit (meer) tegen

Volgens mij heeft SaaS de shared hostingmarkt volledig verdreven inderdaad.

[Kalentum]

Firesphere schreef op dinsdag 19 mei 2020 @ 00:20:
[...]

Yeps, shared hosting kom ik nooit (meer) tegen

Ah ja het ligt een beetje aan wat voor projecten je doet. Ik werk aan 1 product met miljoenen klanten en dan heb je geen verschillende productieomgevingen per klant. En voor pen tests en dergelijke is een aparte omgeving. Niet helemaal correct omdat die omgeving ook weer andere configuratie heeft en een andere firewall enzo.

[ Voor 6% gewijzigd door Kalentum op 19-05-2020 07:29 ]

[Ryur]

.oisyn schreef op vrijdag 1 februari 2019 @ 15:04:
I'm just going to leave this here...

[YouTube: Marble Race: MarbleLympics 2019 Qualifiers]

Main tournament op 18 april, zet het in je agenda.

Ik vind het super leuk Volg ook veel de FE editie ervan. Zo leuk dat ze dan de baan hebben nagemaakt na een aantal bochten van het circuit & de Jack Nicholls (FE commentator) ook het commentaar doet

[kwaakvaak_v2]

Firesphere schreef op dinsdag 19 mei 2020 @ 00:20:
[...]

Yeps, shared hosting kom ik nooit (meer) tegen

Bij ons ook, wij zijn de oude shared hosted omgeving al een tijdje aan het uitfaseren, en elke klant naar een eigen instance aan het verplaatsen. Dat gaat langzamer dan ik had verwacht. Heel veel organisaties hebben geen idee waar hun domein(en) geregistreerd zijn en wat de inlog gegevens voor het DNS beheer zijn.

Veel klanten hebben die domeinen al jaren, betalen netjes de facturen maar de personen die het regelden zijn al lang en breed vertrokken of in sommige gevallen zelfs al met pensioen. En documentatie van dat soort gegevens is toch helemaal niet nodig. Ze hebben vaak nog wel ergens een excel sheet met wat wachtwoorden. Ja dat die domein/hosting partij jaren geleden is overgenomen, en daarna nog een keer is overgenomen en dat daarom het oude dashboard al lang is opgeheven. tja... lastig...

Ooit bedacht alles met een cname te gaan doen, maar dan krijg je gedoe dat https://klantnaam.nu niet werkt, want je kunt geen cname op een root doen. Dus dat plan was ook snel voorbij. Want ondanks dat 99% van de mensen gewoon netjes www.klantnaam.nu intyped moet klantnaam.nu wel beeld geven

Ryur schreef op dinsdag 19 mei 2020 @ 08:47:
[...]

Ik vind het super leuk Volg ook veel de FE editie ervan. Zo leuk dat ze dan de baan hebben nagemaakt na een aantal bochten van het circuit & de Jack Nicholls (FE commentator) ook het commentaar doet

En sinds John Rolliver zijn sponsordeal op HBO verkondigde een bak welverdiende aandacht erbij! Die gasten gaan deze week denk ik door de 1m abonnees op Youtube heen.

[ Voor 16% gewijzigd door kwaakvaak_v2 op 19-05-2020 09:21 ]

[alienfruit]

Jammer, dat Google Suite geen ondersteuning heeft voor 2FA middels QR code. Nu kan ik het niet gebruiken met 1Password Lijkt mij toch veel veiliger dan SMSjes

[.oisyn]

@alienfruit Werkt anders prima hier?

[alienfruit]

Echt met 1Password, hoe heb je het voor elkaar gekregen dan? Ik kan het niet vinden in de Two Factor Settings elke keer wilt het dat je het via je telefoon met de Google Authenticator app doet

[ Voor 51% gewijzigd door alienfruit op 19-05-2020 15:09 ]

[.oisyn]

@alienfruit Oh niet per se met 1Password, maar ze doen gewoon TOTP met een QR-code. Wat wil 1Password dan?

.edit: ze noemen het alleen "Authenticater App on Android", omdat het eikels zijn.

[ Voor 28% gewijzigd door .oisyn op 19-05-2020 15:13 ]

[alienfruit]

Ah stom van me, inderdaad werkt

Ik vraag mij eigenlijk af hoe je zulke dingen automatisch kan testen. Hebben mensen hier daar ervaring mee?

[ Voor 62% gewijzigd door alienfruit op 19-05-2020 15:22 ]

[Alex)]

Bij het opzetten van 2FA voor een account zul je die QR-code gepresenteerd krijgen, die moet je dan dus uit de pagina zien te halen en te parsen. Daarvoor kun je bijvoorbeeld ZXing gebruiken.

In zo'n QR-code zit niets meer dan een URI. In die URI zit alle informatie die nodig is voor een Authenticator-app om z'n werk te kunnen doen. En aangezien TOTP een standaard is, zijn er ook veel libraries te krijgen die op basis van een secret key en een timestamp je de bijbehorende OTP-response teruggeven.

[CodeCaster]

Microsoft Build is sinds vanavond live te volgen: https://mybuild.microsoft.com/home

Op zich best wat interessant materiaal, onder andere over Azure, C# 9, .NET 5 enzovoorts, maar hoe vaak er nu al "state of the art" is gezegd in de presentatie over WinUI 3...

[R4gnax]

Grijze Vos schreef op maandag 18 mei 2020 @ 12:26:
[...]

Da's toch precies wat anti-DDOS software/hardware doet? Detecteren dat het een DDOS aanval is en dan vrolijk die packets droppen. Niet echt mijn cup of tea dit soort spul verder, dus misschien heb ik het mis.

Het "droppen" houdt wel iets meer in dan simpelweg packets droppen. Daar zit nogal wat network management aan vooraf, omdat je anders bij een echte, hoog-vermogen, DDOS alsnog de druk niet aankunt. Niet voor niets dat partijen een rendabel commercieel business-model van anti-DDOS infrastructuur hebben weten te maken.

[Firesphere]

Kalentum schreef op dinsdag 19 mei 2020 @ 06:54:
[...]


Ah ja het ligt een beetje aan wat voor projecten je doet. Ik werk aan 1 product met miljoenen klanten en dan heb je geen verschillende productieomgevingen per klant. En voor pen tests en dergelijke is een aparte omgeving. Niet helemaal correct omdat die omgeving ook weer andere configuratie heeft en een andere firewall enzo.

Mijn projecten tegenwoordig zijn internal. Ik doe geen klant-projecten meer, maar doe projecten/werk voor mijn werkgever direct. ISO certificering, PCI-DSS, pentests die door een externe klant is aangevraagd, maar wordt doorgezet via het team van de klant, naar ons, dus technisch gezien, gaan al mijn uren naar intern werk, en stuurt het team mijn uren dan weer door naar de klant.

Ook doe ik geen extern dev-werk meer,

[Grijze Vos]

R4gnax schreef op woensdag 20 mei 2020 @ 00:48:
[...]


Het "droppen" houdt wel iets meer in dan simpelweg packets droppen. Daar zit nogal wat network management aan vooraf, omdat je anders bij een echte, hoog-vermogen,

Dat noemen we abstractie.

[Koenvh]

R4gnax schreef op woensdag 20 mei 2020 @ 00:48:
[...]


Het "droppen" houdt wel iets meer in dan simpelweg packets droppen. Daar zit nogal wat network management aan vooraf, omdat je anders bij een echte, hoog-vermogen, DDOS alsnog de druk niet aankunt. Niet voor niets dat partijen een rendabel commercieel business-model van anti-DDOS infrastructuur hebben weten te maken.

Uiteraard, en natuurlijk kun je dat ook nog eens op veel verschillende niveaus toepassen (BGP Blackholing bijvoorbeeld, al dan niet per ongeluk ).

[R4gnax]

Firesphere schreef op woensdag 20 mei 2020 @ 02:05:
[...]

Mijn projecten tegenwoordig zijn internal. Ik doe geen klant-projecten meer, maar doe projecten/werk voor mijn werkgever direct. ISO certificering, PCI-DSS, pentests die door een externe klant is aangevraagd, maar wordt doorgezet via het team van de klant, naar ons, dus technisch gezien, gaan al mijn uren naar intern werk, en stuurt het team mijn uren dan weer door naar de klant.

Ook doe ik geen extern dev-werk meer,

Je hebt jezelf gefirewalled dus.

[Douweegbertje]

Creepy schreef op donderdag 14 mei 2020 @ 22:02:
Op productie een pentest? Leuk... maar in de echte wereld wordt er wel eens iets gevonden. Dat zal productie maar eens even(tjes) plag leggen ofzo, leuk voor de betalende klanten

Wij hebben er een gescheiden omgeving voor, los van de test-, acceptatie- en productie omgeving.

Ik pentest alleen op productie. Ik ga niet eens een opdracht aan als ik een 1 of andere "aparte" omgeving krijg.
Dan heb ik het idee dat ik een soort schijnopdracht zit te doen

Ik draai ook graag de situatie om. Je kan een (blackhat) hacker ook niet vragen om aub niet je production te hacken maar je speciale omgeving daarvoor. Als je al bang bent dat een whitehat, die over het algemeen iets voorzichtiger is, je omgeving sloopt dan ben je toch niet in control?

En bij mijn opdracht wil ik juist graag worden uitgesloten van je systeem. Want dat is een teken dat je enige vorm van mitagation hebt, in plaats van dat "ik whitelist je wel zodat je niet wordt geblocked". - want dan zit je opnieuw die schijnvoortoning op te houden.

Natuurlijk verschilt dit per expliciete opdracht (over wat er getest moet worden), maar daarom doe ik mijn testen vaak "as is" zonder regels vanuit de klant. Ik heb alleen wat endpoints/ips en een waiver. Verder zoek ik zelf alles (inclusief de scope(s) ). Dit is ook wel het verschil in mijn insteek en je ziet dat ook vele dit niet aandurven. Mja, het is wel meer richting een "ultimere test" of je alles een beetje op orde hebt.

Overigens doe ik dit nog steeds semi hobby matig, maar uiteindelijk een prima trackrecord

[Koenvh]

@Douweegbertje Da's natuurlijk leuk, maar als je bedrijf veel geld misloopt als de productieomgeving kapot is, dan is testen op productie natuurlijk niet een optie. Het idee is namelijk dat ze willen voorkomen dat een echte hacker (die toch wel op productie "test") alles stil legt, niet dat iemand anders alvast de productieomgeving lam legt. "Ha, take that hackers! Jullie kunnen onze productieomgeving niet onbereikbaar maken, want dat hebben we zelf al gedaan! "

[Creepy]

Ik draai ook graag de situatie om. Je kan een (blackhat) hacker ook niet vragen om aub niet je production te hacken maar je speciale omgeving daarvoor. Als je al bang bent dat een whitehat, die over het algemeen iets voorzichtiger is, je omgeving sloopt dan ben je toch niet in control?

Niet? Door een omgeving te maken die gelijk is aan productie dan ben je wat mij betreft meer in control. Je laat bewust een hacker los gaan en die hoeft zich dus niet in te houden omdat dat een losse omgeving is die productie niet raakt.Wordt er echt wat ernstigs gevonden? Mooi, oplossen en in productie nemen. En dat zonder extra risico voor je productie omgeving.

Een whitehat die zich in moet houden of extra op zaken moet letten omdat het een productieomgeving betreft is in mijn ogen juist niet hetzelfde. Een blackhat houdt zich ook niet in. Met een losse omgeving kan een whitehat ook helemaal los gaan.

[Douweegbertje]

Koenvh schreef op vrijdag 22 mei 2020 @ 13:12:
@Douweegbertje Da's natuurlijk leuk, maar als je bedrijf veel geld misloopt als de productieomgeving kapot is, dan is testen op productie natuurlijk niet een optie. Het idee is namelijk dat ze willen voorkomen dat een echte hacker (die toch wel op productie test) alles stil legt, niet dat iemand anders alvast de productieomgeving lam legt. "Ha, take that hackers! Jullie kunnen onze productieomgeving niet onbereikbaar maken, want dat hebben we zelf al gedaan! "

Dit is toch juist de contradictie waar ik het over heb:

- "Omgeving mag ten alle tijde niet kapot" -> maar we hebben dat nooit getest en we hebben er zoveel vertrouwen in dat we niets toelaten (maar een blackhat kan het alsnog waarschijnlijk?).

Alles wat jan en alleman kan doen op je productie, zou je ook gewoon door een pentest moeten laten doen. Juist om die zekerheid te hebben.

Creepy schreef op vrijdag 22 mei 2020 @ 13:17:
[...]

Niet? Door een omgeving te maken die gelijk is aan productie dan ben je wat mij betreft meer in control. Je laat bewust een hacker los gaan en die hoeft zich dus niet in te houden omdat dat een losse omgeving is die productie niet raakt.Wordt er echt wat ernstigs gevonden? Mooi, oplossen en in productie nemen. En dat zonder extra risico voor je productie omgeving.

Een whitehat die zich in moet houden of extra op zaken moet letten omdat het een productieomgeving betreft is in mijn ogen juist niet hetzelfde. Een blackhat houdt zich ook niet in. Met een losse omgeving kan een whitehat ook helemaal los gaan.

Zo'n omgeving is leuk voor loadtests en bijvoorbeeld privilege elevation tests. M.a.w. dingen waar je 100% zeker weet dat je bewust om omgeving gaat manipuleren. Anders dan dat zit je een omgeving te testen wat niet de omgeving is waar het daadwerkelijk om gaat. Begrijp mij niet verkeerd, maar dan kan je toch net zo goed niet testen want...appels en peren.

Overigens zei ik ook niet "inhouden", maar voorzichtig zijn. M.a.w. ik kijk bewust wat wel/niet een risico is en mogelijk voer ik dat niet uit of in goed overleg (of alsnog op een seperate omgeving). Het is niet "schijt hebben" aan je omgeving, maar wel echt je production testen

-----
Ik vind vergelijkingen heel vervelend, maar om toch ietswat van een punt te maken: 99% van de bedrijven/organisaties/producten die zijn aangesloten bij bug bounty programma's bieden hun production omgeving in volledigheid aan. Voor sommige cases (echt in het systeem testen) is een aparte omgeving voor je accounts e.d. maar anders dan dat: production.
En dat zijn toch ook echt programma's die het verre van kunnen permiteren om offline te gaan.

[Creepy]

Appels en peren ben ik niet met je eens, maar dat kan bij andere bedrijven anders zijn. Onze pentest omgeving is 100% gelijk aan productie. Effectief een ander setje IP's en hostnames, maar that's it. Die mag dan ook kapot, je mag proberen om data uit andere accounts te trekken etc.

En inhouden of voorzichtig zijn, een blackhat is hoogstens voorzichting om niet ontdekt te worden, maar dat is het dan ook.

En de bugbounty programma's, daar staan vaak beperkende voorwaarden in om risico's in te dammen, iets waar een blackhat zich ook niks van aantrekt. Berkingen die je moet een losse omgeving niet hoeft op te nemen. Maar een bug bounty programma staat wat mij betreft los van de discussie over een losse pentest omgeving of niet.

[ Voor 5% gewijzigd door Creepy op 22-05-2020 13:35 ]

[Douweegbertje]

Creepy schreef op vrijdag 22 mei 2020 @ 13:34:

Onze pentest omgeving is 100% gelijk aan productie. Effectief een ander setje IP's en hostnames, maar that's it.

Dus je begint je scope al met "deze omgeving is 100% zeker, op alle vlakken, op alle rules, patches, servers, cpu's, subnet, configuratie, dns config, code, checkouts, vm, whatever hetzelfde als production".

Ik vind dat persoonlijk (en gelukkig is iedereen anders ) een slechte manier om van start te gaan. Ten eerste is het echt heel lastig om zo'n statement te maken (ik twijfel niet over je kunde overigens) maar je kan net zo goed ook een foutje hebben gemaakt. Iets wat in prd wel staat en op je andere omgeving niet.

Dus tenzij je van de gehele scope een bepaalde hash kan maken en die kan vergelijken met je andere omgeving, heb je nogmaals met alle respect geen garantie dat je over hetzelfde praat.

Want nu kan je potentieel de situatie krijgen:
"oh kut we zijn gehacked" - "maar we hebben toch getest op onze hackomgeving"?!
"Ah ja, maar ik was 1 dingetje vergeten over te zetten.."

Dus ja. Laten we het in elkgeval eens zijn dat we het hier niet eens over worden

[Creepy]

Douweegbertje schreef op vrijdag 22 mei 2020 @ 13:42:
[...]
"oh kut we zijn gehacked" - "maar we hebben toch getest op onze hackomgeving"?!
"Ah ja, maar ik was 1 dingetje vergeten over te zetten.."

Iedereen maakt fouten, pentesters ook. Ik weet dat je dit niet zo bedoeld maar je zou kunnen denken dat pentesters geen fouten maken en dus alles vinden wat er te vinden is

Dus ja. Laten we het in elkgeval eens zijn dat we het hier niet eens over worden

[gekkie]

Kunnen de meeste pentesters zich dan niet inhouden ?
Ik bedoel als je root shell acces verkrijgt one or the other way, dan is het toch niet nodig om dan ook aan te tonen wat je allemaal zou kunnen door de meuk te wipen ?

[Sandor_Clegane]

Typo's...... Daar ging weer een paar uur.

Het helpt ook niet echt als je niet helemaal thuis bent in PWM en dergelijke.......

[F.West98]

Ik weet niet waarom ik het nog niet kende, maar SSH CA is toch echt wel erg fijn (zie https://engineering.fb.co...d-secure-access-with-ssh/). Gekoppeld aan Vault werkt het ideaal: lokaal authenticaten via in mijn geval LDAP, je pubkey signen en je kan overal bij. Zodra je niet meer in de juiste groep zit, heb je ook geen toegang meer. Provisionen van servers is ook eenvoudig, en het is niet meer zo erg als je je keypair verliest.

En zo vul ik mijn tijd met dit soort kleien quality of life verbeteringen.

[azerty]

F.West98 schreef op zaterdag 23 mei 2020 @ 01:50:
Ik weet niet waarom ik het nog niet kende, maar SSH CA is toch echt wel erg fijn (zie https://engineering.fb.co...d-secure-access-with-ssh/). Gekoppeld aan Vault werkt het ideaal: lokaal authenticaten via in mijn geval LDAP, je pubkey signen en je kan overal bij. Zodra je niet meer in de juiste groep zit, heb je ook geen toegang meer. Provisionen van servers is ook eenvoudig, en het is niet meer zo erg als je je keypair verliest.

En zo vul ik mijn tijd met dit soort kleine quality of life verbeteringen.

Nu nog een spellcheck in je browser integreren en het is ook weer een hele stap vooruit

[Vaan Banaan]

Spelling is oké, maar de grammatica is niet helemaal correct.
En zo vul ik mijn tijd met dit soort kleien quality of life verbeteringen kleien.

[Sebazzz]

Wat is jullie ervaring met OpenBugBounty.org? We krijgen een XSS vulnerability binnen via dat platform, maar deze beste man heeft 100 vulnerabilities voor allerlei sites gerapporteerd in twee dagen. Ons vermoeden is dat hij een automated scanner gebruikt - en omdat we op ASP.NET Web Forms zitten weigert het framework zelf al zulke requests (met script tags erin) - dus heeft hij de error 500 of 400 die terugkomt als vulnerability gerapporteerd.

[roeleboel]

nevermind, ik moet vroeger opstaan

[ Voor 91% gewijzigd door roeleboel op 25-05-2020 09:24 ]

[RagingPenguin]

Sebazzz schreef op maandag 25 mei 2020 @ 08:52:
Wat is jullie ervaring met OpenBugBounty.org? We krijgen een XSS vulnerability binnen via dat platform, maar deze beste man heeft 100 vulnerabilities voor allerlei sites gerapporteerd in twee dagen. Ons vermoeden is dat hij een automated scanner gebruikt - en omdat we op ASP.NET Web Forms zitten weigert het framework zelf al zulke requests (met script tags erin) - dus heeft hij de error 500 of 400 die terugkomt als vulnerability gerapporteerd.

Als het works-as-intended is het geen bug. Normaal zou ik zeggen: plaats een enkele regel als comment en sluit de tickets, maar als je er honderden hebt is dat misschien ook weer een beetje veel werk. Heb je optie om hem direct te mailen?

[Antrax]

RagingPenguin schreef op maandag 25 mei 2020 @ 09:25:
maar als je er honderden hebt

Hij bedoelde voor verschillende websites, niet specifiek die van hem

[ Voor 7% gewijzigd door Antrax op 25-05-2020 10:05 ]

[Sebazzz]

Antrax schreef op maandag 25 mei 2020 @ 10:05:
[...]

Hij bedoelde voor verschillende websites, niet specifiek die van hem

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Ondertussen heeft hij al 8 pagina's a 20 stuks per pagina.

[Boudewijn]

Een automatisch gevonden kwetsbaarheid moet je altijd ff met de hand testen. Veel scanners rapporteren veel poep, en die poep werkt dan alsnog niet goed.

Werkt de kwetsbaarheid: Top, mooi dat ie gemeld is. Heeft hij er 20? Is het 1 en dezelfde kwetsbaarheid, bijvoorbeeld op URLs.... ga even in gesprek met hem en doneer hem je beloning voor 1-5 kwetsbaarheden.
Heeft hij 20 verschillende kwetsbaarheden gevonden: Stuur de man 20 shirtjes/mokken/cheques en ga met je IT-leverancier praten

[Sebazzz]

Boudewijn schreef op maandag 25 mei 2020 @ 10:35:
Werkt de kwetsbaarheid: Top, mooi dat ie gemeld is. Heeft hij er 20? Is het 1 en dezelfde kwetsbaarheid, bijvoorbeeld op URLs....

Check maar zijn profiel, hij rapporteert aan de lopende band kwesbaarheden en heeft ondertussen al 160 gevonden op allerlei sites. Hij beweert op de site waar wij beheer over hebben twee gevonden te hebben.

[Gropah]

Sebazzz schreef op maandag 25 mei 2020 @ 10:59:
[...]

Check maar zijn profiel, hij rapporteert aan de lopende band kwesbaarheden en heeft ondertussen al 160 gevonden op allerlei sites. Hij beweert op de site waar wij beheer over hebben twee gevonden te hebben.

Dus wat houd je tegen om ze even te controleren? Neem aan dat er iets als een poc bij zit oid. Als het wel iets is, top, is het niets dan kun je hem daar op wijzen. Hoeft niet veel tijd te kosten denk ik zo?

[ Voor 4% gewijzigd door Gropah op 25-05-2020 11:05 ]

[Sebazzz]

Gropah schreef op maandag 25 mei 2020 @ 11:05:
[...]


Dus wat houd je tegen om ze even te controleren? Neem aan dat er iets als een poc bij zit oid. Als het wel iets is, top, is het niets dan kun je hem daar op wijzen. Hoeft niet veel tijd te kosten denk ik zo?

Niets. Kennelijk communiceer ik erg onduidelijk.

Mijn vraag is wat jullie ervaring is bij het platform (is het legitiem, heb je er goede ervaringen ermee, etc)

[Boudewijn]

Geen ervaring bij dat platform, wel binnen mijn werk. Daar pas ik bovenstaande methodiek toe.

[kwaakvaak_v2]

Sebazzz schreef op maandag 25 mei 2020 @ 10:20:
[...]


***members only***


Ondertussen heeft hij al 8 pagina's a 20 stuks per pagina.

Heb ook zo'n gast aan de haak, gebruikt een owasp based automatische scanner die sites gemaakt met bepaalde frameworks op known vectors scanned en ze dan als 'hackable' rapporteert voor de faam en geld.

Ze noemen zich white hat hackers, ik zou ze eerder onder de noemer scriptkiddo scharen. Geeft wel een hoop gedoe bij klanten die de mailtjes krijgen met ferme taal over de hack publiek maken en zulks.

[GrooV]

kwaakvaak_v2 schreef op maandag 25 mei 2020 @ 22:07:
[...]


Heb ook zo'n gast aan de haak, gebruikt een owasp based automatische scanner die sites gemaakt met bepaalde frameworks op known vectors scanned en ze dan als 'hackable' rapporteert voor de faam en geld.

Ze noemen zich white hat hackers, ik zou ze eerder onder de noemer scriptkiddo scharen. Geeft wel een hoop gedoe bij klanten die de mailtjes krijgen met ferme taal over de hack publiek maken en zulks.

Waarom doe je dat zelf dan ook niet? Als er 1 of 2 dingen niet kloppen dan kan dat een uitnodiging zijn om toch even wat beter naar de rest te kijken

[gekkie]

Oef .. net door wat react + nodejs + mysql zitten bladeren op github .. ik zeg het maar met muziek:
YouTube: 1990 HANNY maar vanavond heb ik hoofdpijn

[kwaakvaak_v2]

GrooV schreef op maandag 25 mei 2020 @ 22:57:
[...]

Waarom doe je dat zelf dan ook niet? Als er 1 of 2 dingen niet kloppen dan kan dat een uitnodiging zijn om toch even wat beter naar de rest te kijken

Omdat het false positives zijn. Puur een versie nummer van een library parsen en dan heel hard roepen dat alles kapot is.

[Sebazzz]

kwaakvaak_v2 schreef op dinsdag 26 mei 2020 @ 08:34:
[...]


Omdat het false positives zijn. Puur een versie nummer van een library parsen en dan heel hard roepen dat alles kapot is.

Dat is wat Infosec bij ons voorstelt Ja je gebruikt Bootstrap 3.x, onveilig!

Ja vriend, weet je wel hoeveel werk het is naar Bootstrap 4 te upgraden? We backporten eventuele security fixes wel zelf.

[Ealanrian]

Sebazzz schreef op dinsdag 26 mei 2020 @ 08:51:
[...]

Dat is wat Infosec bij ons voorstelt Ja je gebruikt Bootstrap 3.x, onveilig!

Ja vriend, weet je wel hoeveel werk het is naar Bootstrap 4 te upgraden? We backporten eventuele security fixes wel zelf.

Hoe zorg je er voor dat je de security fixes niet mist?

[Hydra]

Douweegbertje schreef op vrijdag 22 mei 2020 @ 13:00:
Ik pentest alleen op productie. Ik ga niet eens een opdracht aan als ik een 1 of andere "aparte" omgeving krijg.
Dan heb ik het idee dat ik een soort schijnopdracht zit te doen

Dat vind ik wel vreemd. Ik mag dan geen pentester zijn, ik heb wel veel met ze vanaf de andere kant samengewerkt (bij verschillende grote bedrijven), en daar was het nooit een kwestie van 'of'. Dus zowel op productie, waarin ze dan wel voorzichtig moeten zijn (een table droppen is daar niet bepaald een optie), als een productie-like omgeving waar ze meer mochten, maar ook veel meer konden zien.

Wat je zegt over een black-hat hacker kan ook omgedraaid worden. Die zullen vaak geen toegang hebben tot de sourcecode. Maar die geven we meestal wel aan de pentesters zodat ze beter en efficienter op zoek kunnen gaan naar gaten.

Volgens mij is het dus geen "of" verhaal maar een "en" verhaal; dat je eerst losgaat op een productie like omgeving en daarna gaat checken of diezelfde issues ook op productie bestaan.

Totaal iets anders: Wel grappig trouwens om te zien hoeveel pentesters erin stinken als we "powered by PHP 4.0" headers meesturen.

[Hydra]

kwaakvaak_v2 schreef op dinsdag 26 mei 2020 @ 08:34:
Omdat het false positives zijn. Puur een versie nummer van een library parsen en dan heel hard roepen dat alles kapot is.

Mijn ervaring is dat er maar heel weinig goede pentest clubs zijn. De meeste komen niet verder dan standaard scripts draaien en dan hard roepen dat er wat stuk is. Erger nog; ik heb meerdere malen meegemaakt dat dit soort rapporten vol met false-positives direct naar het management gestuurd werden, zonder dit met de developers te overleggen.

Goeie pentesters die echt zelf gaan graven zijn zeldzaam. En dus duur.

[Creepy]

Hydra schreef op dinsdag 26 mei 2020 @ 11:33:
[...]
Totaal iets anders: Wel grappig trouwens om te zien hoeveel pentesters erin stinken als we "powered by PHP 4.0" headers meesturen.

Hydra schreef op dinsdag 26 mei 2020 @ 11:36:
Mijn ervaring is dat er maar heel weinig goede pentest clubs zijn. De meeste komen niet verder dan standaard scripts draaien en dan hard roepen dat er wat stuk is. Erger nog; ik heb meerdere malen meegemaakt dat dit soort rapporten vol met false-positives direct naar het management gestuurd werden, zonder dit met de developers te overleggen.

Goeie pentesters die echt zelf gaan graven zijn zeldzaam. En dus duur.

Dat is wat we hier ook zien ja. Gelukkig hebben we nu 2 partijen die wel een gedegen pentest doen en veel meer doen dan alleen een standaard scan. Dat laatste kunnen we zelf ook wel.

[Douweegbertje]

Hydra schreef op dinsdag 26 mei 2020 @ 11:33:
[...]


Dat vind ik wel vreemd. Ik mag dan geen pentester zijn, ik heb wel veel met ze vanaf de andere kant samengewerkt (bij verschillende grote bedrijven), en daar was het nooit een kwestie van 'of'. Dus zowel op productie, waarin ze dan wel voorzichtig moeten zijn (een table droppen is daar niet bepaald een optie), als een productie-like omgeving waar ze meer mochten, maar ook veel meer konden zien.

Wat je zegt over een black-hat hacker kan ook omgedraaid worden. Die zullen vaak geen toegang hebben tot de sourcecode. Maar die geven we meestal wel aan de pentesters zodat ze beter en efficienter op zoek kunnen gaan naar gaten.

Volgens mij is het dus geen "of" verhaal maar een "en" verhaal; dat je eerst losgaat op een productie like omgeving en daarna gaat checken of diezelfde issues ook op productie bestaan.

Totaal iets anders: Wel grappig trouwens om te zien hoeveel pentesters erin stinken als we "powered by PHP 4.0" headers meesturen.

Mijn persoonlijke ervaring is waarschijnlijk exact hetzelfde als jou en Creepy (vergeet niet dat ik 10 jaar ook aan die kant zat, en soms nog zit). Dat is ook exact de reden dat als ik zelf iets doe m.b.t. security, het juist niet invul als een standaard pen-test. Idem dat ik niet echt een pentest bedrijfje heb, noch het expliciet als een 'pro' uitvoer. Mijn doel is om bezig te gaan op een manier dat ik het leuk vind en uiteindelijk iets vinden wat een issue is, waar men niet bewust van was.

Mijn werkwijze is waarschijnlijk uniek te noemen, maar dat is domweg hoe ik het graag doe. En omdat ik die vrijheid heb (ik leef niet van mijn opdrachten, geld is een bijzaak in zo'n geval), kies ik bewust mijn opdrachten. Uiteindelijk wil ik puur een endpoint of een IP en stop wat tijd in een discovery fase. Want nogmaals, jullie weten misschien verdomd goed waar je mee bezig bent, maar geloof mij nou maar als ik zeg dat ik alleen al met het onderzoeken naar "wat is er allemaal" al genoeg entries ben tegen gekomen.
Als ik alleen een statische scope krijg dan voel ik mij direct "gevangen", alsof ik dan niet verder mag/kan kijken dan mijn neus lang is. Dus daarom dat ik aangeef dat ik simpelweg de vrijheid wil hebben en dat dit PRD gaat zijn.

Mijn eindstand is het volgende: Van alle opdrachten afgelopen jaar dat ik heb gedaan, heb ik altijd "iets" gevonden. En dat "iets" is altijd een CVSS van medium geweest. De eindgebruikers zaten er altijd zo in, dat ze het niet deden om domweg een papiertje/waiver te hebben van "oh wat veilig zijn wij" - maar meer: ga aub los, en ik ben benieuwd of we het goed doen. Een hele relaxte samenwerking, zonder gezeik en gewoon puur voor security.

De "lol" hierin is, is dat ze heel veel waarde krijgen van een nerdje die dit als hobby doet (ikzelf dus). Visa-versa krijg ik de vrijheid om mijn hobby te mogen uitoefenen, mijn skills te vergroten en toch wel enigsinds grote namen op mijn "CV" te kunnen plaatsen.

En ja, ik zal vast in sommige gevallen het niet doen zoals je eigenlijk zou verwachten, maar ik heb niet de insteek als menig pen-test club. Ik wil niet vast hangen in een shitload aan papierwerk, standaard flows, contracten, etc. Ik heb 1 document met een waiver voor mijzelf en that's it. En zo ben ik ook begonnen; 3 jaar geleden bood ik dit gratis aan en heb ik heel veel ervaring in een relaxte omgeving kunnen op doen. Dit groeit gewoon en ik behoud mijn eigen lol erin, door het zo aan te bieden dat ik het leuk vind om te doen. Desnoods zonder inkomsten

[Hydra]

@Douweegbertje je reageert helemaal niet op het punt dat je in eerste instantie meestal niet op Pro bezig gaat omdat de schade enorm kan zijn. Daar gaat het juist om. Als ik dit lees zou ik je nooit aan een serieuze applicatie aan de slag laten gaan omdat je juist claimt dat je dit "er bij" doet en niet wil "gevangen" zitten of whatever. Ja leuk en aardig; maar een "DROP TABLE users" van jou, kost een bedrijf zo een ton in verloren omzet.

Je kunt prima exact hetzelfde werk doen op een production like omgeving en daarna, voorzichtig, het nog eens op pro herhalen. Het is voor jou hetzelfde en voor het bedrijf veel minder risicovol.

Ik snap echt niet dat je 'trots' vertelt dat je het gewoon gratis doet. Ik vind dat net zo iets als de buurjongen die wel even 'gratis' die site maakt die bij een echt bedrijf een ton kost. Daar schiet niemand van ons wat mee op.

[Douweegbertje]

Hydra schreef op dinsdag 26 mei 2020 @ 17:19:
@Douweegbertje je reageert helemaal niet op het punt dat je in eerste instantie meestal niet op Pro bezig gaat omdat de schade enorm kan zijn. Daar gaat het juist om. Als ik dit lees zou ik je nooit aan een serieuze applicatie aan de slag laten gaan omdat je juist claimt dat je dit "er bij" doet en niet wil "gevangen" zitten of whatever. Ja leuk en aardig; maar een "DROP TABLE users" van jou, kost een bedrijf zo een ton in verloren omzet.

Je kunt prima exact hetzelfde werk doen op een production like omgeving en daarna, voorzichtig, het nog eens op pro herhalen. Het is voor jou hetzelfde en voor het bedrijf veel minder risicovol.

Ik snap echt niet dat je 'trots' vertelt dat je het gewoon gratis doet. Ik vind dat net zo iets als de buurjongen die wel even 'gratis' die site maakt die bij een echt bedrijf een ton kost. Daar schiet niemand van ons wat mee op.

Je hoeft het niet met mij eens te zijn maar om nou voor iedereen in te vullen dat ik pauper werk oplever waar niemand iets aan heeft is echt weer het uiterste. Want ik kan er prima mee leven dat jij het niets vindt. Anders is het gewoon een beetje zuur.

En wat kan ik zeggen over PRD vs whatever omgeving. Dat is wat ik doe en er zijn genoeg bedrijven die daar open voor staan. Menig bedrijf realiseert zich ook dat als iemand nu wel of niet test, dat PRD toch beschikbaar is. Dat handelen ze af met een security disclosure policy of whatever policy.

Maar nu gaan we weer terug naar het stuk waar we het al eerder over hebben gehad: Wat boeit het als die omgeving toch al beschikbaar is. Je houdt je vast een een neppe veiligheid: "We hebben hier geen akkoord voor gegeven dus mensen blijven nu buiten"? Dat is zo krom als het maar zijn kan.
Even heel simpel gezegd, als ik het niet doe, kan iemand anders het nog wel doen. Maar dat het is verschil; ik zit er niet om je systeem naar de klote te helpen en ik weet echt wel wat mogelijk READ acties zijn of daadwerkelijke destructieve acties. Idem voor "bewijs" m.b.t. root access (cat /proc/1/maps, touch /root/foo) en point proven.

En hoewel ik heb een waiver heb, ben ik alsnog verantwoordelijk voor mijn fuckups. Ik wil niet beweren dat dit waterdicht is, maar daar heb ik wel een verzekering voor. Los van dat, als iemand echt komt met zo'n bedrijfskritische applicatie waar miljoenen in om gaan dan bestaat de kans dat ik dit weiger. Domweg omdat ik het eventuele risico, al is dat maar 0.01%..domweg niet kan dragen. Ik hoef niet ten onder te gaan met mijn hobby

Echter ben ik simpelweg van mening dat iemand z'n werk, of een outsider, nooit een situatie mogen opleveren die jij schetst:

een "DROP TABLE users" van jou, kost een bedrijf zo een ton in verloren omzet.

Ik vind het veel belangrijker om dan te bedenken: Ok, er is iemand binnen, wat is er beschikbaar om te voorkomen dat we zo'n schadepost krijgen. Als 1 query mij een ton kost, dan moet ik hier anders mee om gaan.

Ik doe nu een opdracht bij een bank, en ik zit hier nu een bepaald enterprise systeem op te zetten. Ik hoef denk ik niet uit te leggen hoeveel regels er bij een bank zitten. Maar; iedereen mag van mij heel data systeem slopen, alle data weggooien en whatnot. Want dit is zo belangrijk; daar is juist over nagedacht. Sterker nog, dat wordt bewust gedaan om de integriteit te (blijven) controleren. Mij boeit het niet eens als iemand op die PRD omgeving een test doet, want ik ben in control en er zijn procedures die de overige zaken (in case shit hits the fan) overnemen.

Want nu zitten we meer met elkaar te praten over OF iemand wel toegang mag om daar (goedwillend) te testen, terwijl dat eigenlijk niet relevant mag zijn.Dat is mijn mening. En ik verschil daarin met andere echter deel ik net zo goed mijn mening met weer andere mensen. En dat zou, of we het nu wel/niet eens zijn, prima mogen zijn

---------

Maar weet je wat het is. Ik doe dit omdat ik geef om security en omdat ik het leuk vind. Net zo goed dat ik relatief actief ben in de Open Source wereld. Ik investeer heel veel tijd in dit soort projecten en zaken (idem als wat directe collega's van mij). Maar dat is omdat we er om geven en nerds zijn. Ik heb ook nooit aangegeven dat wat ik doe, een vervanging is van een echte pen-test. Zie het als iets extra's (overigens wil ik wel aangeven dat ik ook na een pen-test meer had gevonden dan wat zo'n bedrijf had gedaan.. maar soit).

In sommige gevallen krijg ik een bounty of 'swag'. In enkele gevallen krijg ik vooraf betaald, maar dat zijn soms terugkerende gebruikers die er heel erg gebaat bij waren/zijn. Hier heb ik een goede relatie mee, en als iemand nu aanklopt om echt zakelijk iets te doen; dan krijg je waarschijnlijk "nee" te horen. Dat is niet mijn doel/ambitie noch het geen wat ik "aanbied". Ik probeer alles zo netjes mogelijk te doen. Je ziet verschillende verhalen van "whitehat" die even onaangekondigd erin gaan zitten (Efteling bijv, de posts van hierboven een paar keer, etc).

[Koenvh]

Ik pak de popcorn alvast (zoet of zout? )

[gekkie]

* gekkie pakt een erbij *plop*.

[Merethil]

Douweegbertje schreef op dinsdag 26 mei 2020 @ 18:30:
[...]


Je hoeft het niet met mij eens te zijn maar om nou voor iedereen in te vullen dat ik pauper werk oplever waar niemand iets aan heeft is echt weer het uiterste. Want ik kan er prima mee leven dat jij het niets vindt. Anders is het gewoon een beetje zuur.

En wat kan ik zeggen over PRD vs whatever omgeving. Dat is wat ik doe en er zijn genoeg bedrijven die daar open voor staan. Menig bedrijf realiseert zich ook dat als iemand nu wel of niet test, dat PRD toch beschikbaar is. Dat handelen ze af met een security disclosure policy of whatever policy.

Maar nu gaan we weer terug naar het stuk waar we het al eerder over hebben gehad: Wat boeit het als die omgeving toch al beschikbaar is. Je houdt je vast een een neppe veiligheid: "We hebben hier geen akkoord voor gegeven dus mensen blijven nu buiten"? Dat is zo krom als het maar zijn kan.
Even heel simpel gezegd, als ik het niet doe, kan iemand anders het nog wel doen. Maar dat het is verschil; ik zit er niet om je systeem naar de klote te helpen en ik weet echt wel wat mogelijk READ acties zijn of daadwerkelijke destructieve acties. Idem voor "bewijs" m.b.t. root access (cat /proc/1/maps, touch /root/foo) en point proven.

En hoewel ik heb een waiver heb, ben ik alsnog verantwoordelijk voor mijn fuckups. Ik wil niet beweren dat dit waterdicht is, maar daar heb ik wel een verzekering voor. Los van dat, als iemand echt komt met zo'n bedrijfskritische applicatie waar miljoenen in om gaan dan bestaat de kans dat ik dit weiger. Domweg omdat ik het eventuele risico, al is dat maar 0.01%..domweg niet kan dragen. Ik hoef niet ten onder te gaan met mijn hobby

Echter ben ik simpelweg van mening dat iemand z'n werk, of een outsider, nooit een situatie mogen opleveren die jij schetst:

[...]


Ik vind het veel belangrijker om dan te bedenken: Ok, er is iemand binnen, wat is er beschikbaar om te voorkomen dat we zo'n schadepost krijgen. Als 1 query mij een ton kost, dan moet ik hier anders mee om gaan.

Ik doe nu een opdracht bij een bank, en ik zit hier nu een bepaald enterprise systeem op te zetten. Ik hoef denk ik niet uit te leggen hoeveel regels er bij een bank zitten. Maar; iedereen mag van mij heel data systeem slopen, alle data weggooien en whatnot. Want dit is zo belangrijk; daar is juist over nagedacht. Sterker nog, dat wordt bewust gedaan om de integriteit te (blijven) controleren. Mij boeit het niet eens als iemand op die PRD omgeving een test doet, want ik ben in control en er zijn procedures die de overige zaken (in case shit hits the fan) overnemen.

Want nu zitten we meer met elkaar te praten over OF iemand wel toegang mag om daar (goedwillend) te testen, terwijl dat eigenlijk niet relevant mag zijn.Dat is mijn mening. En ik verschil daarin met andere echter deel ik net zo goed mijn mening met weer andere mensen. En dat zou, of we het nu wel/niet eens zijn, prima mogen zijn

---------

Maar weet je wat het is. Ik doe dit omdat ik geef om security en omdat ik het leuk vind. Net zo goed dat ik relatief actief ben in de Open Source wereld. Ik investeer heel veel tijd in dit soort projecten en zaken (idem als wat directe collega's van mij). Maar dat is omdat we er om geven en nerds zijn. Ik heb ook nooit aangegeven dat wat ik doe, een vervanging is van een echte pen-test. Zie het als iets extra's (overigens wil ik wel aangeven dat ik ook na een pen-test meer had gevonden dan wat zo'n bedrijf had gedaan.. maar soit).

In sommige gevallen krijg ik een bounty of 'swag'. In enkele gevallen krijg ik vooraf betaald, maar dat zijn soms terugkerende gebruikers die er heel erg gebaat bij waren/zijn. Hier heb ik een goede relatie mee, en als iemand nu aanklopt om echt zakelijk iets te doen; dan krijg je waarschijnlijk "nee" te horen. Dat is niet mijn doel/ambitie noch het geen wat ik "aanbied". Ik probeer alles zo netjes mogelijk te doen. Je ziet verschillende verhalen van "whitehat" die even onaangekondigd erin gaan zitten (Efteling bijv, de posts van hierboven een paar keer, etc).

Dus in een gigantische lap tekst zeg je "ik doe dit omdat een blackhat het ook zou kunnen en dus ben je even fucked als die het zouden doen."? Want dat vind ik echt een belachelijke redenering.

Dat een blackhat ergens binnen kan komen mag nooit een reden zijn dat je de boel verkloot met je eigen whitehatgedrag "omdat je alleen op productie wil testen". Een bedrijf betaalt (grof) geld om te zien of ze veilig zijn; ze dan expres in gevaar brengen door prod te gebruiken in plaats van een exacte kopie waar je los mag is dan vrij contra-intuitief.
Waarom zou een exacte kopie van productie trouwens niet werken volgens jou? Juist daar mag je los, en al die gevonden zaken port je over. Wat is daar zo lastig aan te begrijpen?

Echt, als de bedrijven waar ik voor werk bij jou uitkomen voor zulke tests dan zou ik een fake-prod opzetten en je gewoon doen denken dat het productie is. Die bedrijven en ik gaan echt geen domme gevaren lopen vanwege jouw overtuiging dat het "niet echt genoeg is" als je geen echte productie voor je hebt.

[F.West98]

Merethil schreef op dinsdag 26 mei 2020 @ 20:36:
[...]


Dus in een gigantische lap tekst zeg je "ik doe dit omdat een blackhat het ook zou kunnen en dus ben je even fucked als die het zouden doen."? Want dat vind ik echt een belachelijke redenering.

Dat een blackhat ergens binnen kan komen mag nooit een reden zijn dat je de boel verkloot met je eigen whitehatgedrag "omdat je alleen op productie wil testen". Een bedrijf betaalt (grof) geld om te zien of ze veilig zijn; ze dan expres in gevaar brengen door prod te gebruiken in plaats van een exacte kopie waar je los mag is dan vrij contra-intuitief.
Waarom zou een exacte kopie van productie trouwens niet werken volgens jou? Juist daar mag je los, en al die gevonden zaken port je over. Wat is daar zo lastig aan te begrijpen?

Echt, als de bedrijven waar ik voor werk bij jou uitkomen voor zulke tests dan zou ik een fake-prod opzetten en je gewoon doen denken dat het productie is. Die bedrijven en ik gaan echt geen domme gevaren lopen vanwege jouw overtuiging dat het "niet echt genoeg is" als je geen echte productie voor je hebt.

Nouja de redenering is als volgt:
- Ik (Douweegbertje) doe in principe geen harmful dingen op productie, iets lezen is al goed genoeg als bewijs dat er een lek is, daarvoor hoef je geen DROP te doen.
- Als er al iets harmful plaatsvindt, iets onverwachts, dan zou je backupstrategie als bedrijf goed genoeg moeten zijn dat het alsnog niet uitmaakt.

Ik snap ook wel dat als een bedrijf mij alleen maar op een testomgeving zou laten werken, dat dat dan wel wat suspicious is. Dan kan ik wel heel leuk testen dat alles dicht zit, maar als op productie je database van buiten bereikbaar is schiet je er niets mee op.

Dan draag jij aan dat je wil werken op "exacte kopie van productie", maar die heb je ook niet zomaar. Het is nou eenmaal lastig te garanderen dat het op exact dezelfde hardware draait met alles exact hetzelfde geconfigureerd, een foutje is snel gemaakt. En dat kan op alle niveaus voorkomen, configuratie van de applicatie zelf, de provisioning van de VMs/clusters zelf, een net iets andere bugfix versie op de hypervisor, etc.

Dus eigenlijk zou je kunnen zeggen: als je me níet op productie laat werken, dan heb ik alvast het eerste zwakke punt gevonden: de backupstrategie

[ Voor 3% gewijzigd door F.West98 op 26-05-2020 20:47 ]

[Merethil]

F.West98 schreef op dinsdag 26 mei 2020 @ 20:46:
[...]

Dan draag jij aan dat je wil werken op "exacte kopie van productie", maar die heb je ook niet zomaar. Het is nou eenmaal lastig te garanderen dat het op exact dezelfde hardware draait met alles exact hetzelfde geconfigureerd, een foutje is snel gemaakt. En dat kan op alle niveaus voorkomen, configuratie van de applicatie zelf, de provisioning van de VMs/clusters zelf, een net iets andere bugfix versie op de hypervisor, etc.

Met de manieren van werken die je hedentendaags hebt kan je alles relatief simpel hetzelfde opzetten, vooral met cloudoplossingen als Fargate e.d.
En ja, dan kan er alsnog een foutje in zitten maar dat is het risico dat je neemt. En dat risico ligt bij de opdrachtgever, maar daar kiezen ze dan expliciet zelf voor.

De keuze niet eens krijgen want "productie en een gelijksoortige omgeving komt nooit overeen dus werk ik alleen op productie" is naar mijn mening echt te absoluut.

Dus eigenlijk zou je kunnen zeggen: als je me níet op productie laat werken, dan heb ik alvast het eerste zwakke punt gevonden: de backupstrategie

Ik hoop dat je sarcastisch bent, gezien de smiley geen enkele backup die mijn verloren bedrijfsuren vergoedt

[ Voor 7% gewijzigd door Merethil op 26-05-2020 21:04 ]

[edeboeck]

Merethil schreef op dinsdag 26 mei 2020 @ 20:36:
[...]
Dus in een gigantische lap tekst zeg je "ik doe dit omdat een blackhat het ook zou kunnen en dus ben je even fucked als die het zouden doen."? Want dat vind ik echt een belachelijke redenering.

Misschien toch maar even minder scherp reageren en eens goed die "gigantische lap tekst" herlezen. Zijn argument snijdt hout als de kopie van productie waarop je test niet *exact* dezelfde is.

Dat een blackhat ergens binnen kan komen mag nooit een reden zijn dat je de boel verkloot met je eigen whitehatgedrag "omdat je alleen op productie wil testen". Een bedrijf betaalt (grof) geld om te zien of ze veilig zijn; ze dan expres in gevaar brengen door prod te gebruiken in plaats van een exacte kopie waar je los mag is dan vrij contra-intuitief.

Doe je dit nu expres of heb je gewoon iets te snel gelezen? Hij zegt net dat hij dit destructieve acties van een blackhat niet doet en die "vervangt" door acties die het punt aantonen zonder de schade.

Waarom zou een exacte kopie van productie trouwens niet werken volgens jou? Juist daar mag je los, en al die gevonden zaken port je over. Wat is daar zo lastig aan te begrijpen?

De crux zit in de *exacte* kopie.

Echt, als de bedrijven waar ik voor werk bij jou uitkomen voor zulke tests dan zou ik een fake-prod opzetten en je gewoon doen denken dat het productie is. Die bedrijven en ik gaan echt geen domme gevaren lopen vanwege jouw overtuiging dat het "niet echt genoeg is" als je geen echte productie voor je hebt.

Heb ook ooit een systeembeheerder gehad... het gevolg was dat we, ondanks alle geslaagde testen e.d. binnen de 48u na het live gaan gehackt waren, want op de productieserver (Windows NT 4.0 Server nog in die tijd) stond een bepaalde patch niet geïnstalleerd.

Ik begrijp jouw standpunt wat betreft "niet morrelen in productie" maar al te goed (had ooit een collega wiens laatste actie als collega was om de productie-db even om zeep te helpen). Wat jij echter niet lijkt te (willen?) snappen is dat een kopie van productie niet zelden niet *exact* hetzelfde is (en volgens mij is dat deel van de redenering van @Douweegbertje).
Je kan het daar gerust mee oneens zijn, maar speel dan wat meer de bal en minder de man.

TLDR; wat @F.West98 hierboven zegt dus.

[ Voor 2% gewijzigd door edeboeck op 26-05-2020 21:29 . Reden: TLDR toegevoegd ]

[Merethil]

edeboeck schreef op dinsdag 26 mei 2020 @ 21:27:.

[...]
Doe je dit nu expres of heb je gewoon iets te snel gelezen? Hij zegt net dat hij dit destructieve acties van een blackhat niet doet en die "vervangt" door acties die het punt aantonen zonder de schade.

Ik heb dat inderdaad gelezen, maar een pagina eerder was daar nog geen sprake van. Ik zou echter willen zien hoe hard een systeem onderuit te halen is met als hij erin inbreekt.
Een bestandje aanmaken is inderdaad een ding, net als een "select 1 from system" of whatever, maar het laat dan weer niet exact zien wat er allemaal mis kan gaan en wie weet mist hij op die manier juist weer dieperliggende issues.

[...]
De crux zit in de *exacte* kopie.

Als het nu 2005 was had ik je aardig gelijk gegeven maar er zijn zat bedrijven die daadwerkelijk een exacte of 99%-exacte (want, hardware zou net anders kunnen zijn omdat je een cpu van een andere batch hebt .. tja, er is ook zoiets als marge) kopie kunnen uitrollen omdat ze hun infra wel op orde hebben.
Als dat niet relatief goed kan dan heb je ook andere problemen en zou ik die pentest nog even uitsparen tot je je infra meer op orde hebt.

Ik begrijp jouw standpunt wat betreft "niet morrelen in productie" maar al te goed (had ooit een collega wiens laatste actie als collega was om de productie-db even om zeep te helpen). Wat jij echter niet lijkt te (willen?) snappen is dat een kopie van productie niet zelden niet *exact* hetzelfde is (en volgens mij is dat deel van de redenering van @Douweegbertje).
Je kan het daar gerust mee oneens zijn, maar speel dan wat meer de bal en minder de man.

TLDR; wat @F.West98 hierboven zegt dus.

Ik speel voornamelijk "op de man" omdat er een hele sterke mening wordt geuit door Douweegbertje dat hij niet zou willen testen op een omgeving die niet productie is, maar zichzelf wel fatsoenlijk als pentester wil inzetten.

Ik vind er echt wel wat voor te zeggen dat je belangrijkste issues te vinden zijn in productie, maar hij gaat nu principieel niét werken met een omgeving die hij stuk mag maken om maar te achterhalen wat er allemaal mis is, en wel zich uiteindelijk inhouden op een productieomgeving want "je moet inderdaad geen onnodige kosten krijgen".
Het geeft mij heel erg het gevoel van "zachte heelmeesters..." en dan vind ik het frappant dat hij niet openstaat voor een combinatie, of voor de logica die hierachter schuilt.

Je kan vinden dat ik wat scherp reageerde maar dat komt vooral door het boze internet denk ik, want ik schrijf hier niet een hele lap om iemand de grond in te boren maar merk op Tweakers wel dat je nergens komt door je mening teveel te "verpakken"

[gekkie]

On a side note ... thinkpad (die aanstond) vs betontegels, 1,5m hoogte .. 1-0 (okee okee, 1 tegen 0,00000000001 (vanwege een paar cosmetische krasjes erbij). Wel blij met een SSD

[edeboeck]

Merethil schreef op dinsdag 26 mei 2020 @ 21:43:
[...]
Ik heb dat inderdaad gelezen, maar een pagina eerder was daar nog geen sprake van. Ik zou echter willen zien hoe hard een systeem onderuit te halen is met als hij erin inbreekt.
Een bestandje aanmaken is inderdaad een ding, net als een "select 1 from system" of whatever, maar het laat dan weer niet exact zien wat er allemaal mis kan gaan en wie weet mist hij op die manier juist weer dieperliggende issues.

Ik ben het met jou eens dat dat inderdaad nog wel wat anders is... persoonlijk denk ik dat de combinatie van beide wel een goede insteek is

[...]
Als het nu 2005 was had ik je aardig gelijk gegeven maar er zijn zat bedrijven die daadwerkelijk een exacte of 99%-exacte (want, hardware zou net anders kunnen zijn omdat je een cpu van een andere batch hebt .. tja, er is ook zoiets als marge) kopie kunnen uitrollen omdat ze hun infra wel op orde hebben.
Als dat niet relatief goed kan dan heb je ook andere problemen en zou ik die pentest nog even uitsparen tot je je infra meer op orde hebt.

Gelukkig zijn er de laatste 15-20j inderdaad veel extra mogelijkheden op dat gebied... en zou het inderdaad op orde moeten staan... ben van mening (dit is buikgevoel, niet onderbouwd met cijfers) dat er toch nog héél wat bedrijven zijn waar daar geen sprake van is (wegens gebrek aan kennis of budget)... allicht zullen zij in veel gevallen geen pentest laten doen natuurlijk (wegens diezelfde redenen ).

[...]

Ik speel voornamelijk "op de man" omdat er een hele sterke mening wordt geuit door Douweegbertje dat hij niet zou willen testen op een omgeving die niet productie is, maar zichzelf wel fatsoenlijk als pentester wil inzetten.

Ik vind er echt wel wat voor te zeggen dat je belangrijkste issues te vinden zijn in productie, maar hij gaat nu principieel niét werken met een omgeving die hij stuk mag maken om maar te achterhalen wat er allemaal mis is, en wel zich uiteindelijk inhouden op een productieomgeving want "je moet inderdaad geen onnodige kosten krijgen".
Het geeft mij heel erg het gevoel van "zachte heelmeesters..." en dan vind ik het frappant dat hij niet openstaat voor een combinatie, of voor de logica die hierachter schuilt.

Hier ben ik het grotendeels met jou eens: ik zou persoonlijk eerder voor het en-en verhaal gaan.

Je kan vinden dat ik wat scherp reageerde maar dat komt vooral door het boze internet denk ik, want ik schrijf hier niet een hele lap om iemand de grond in te boren maar merk op Tweakers wel dat je nergens komt door je mening teveel te "verpakken"

Té veel inpakken hoeft inderdaad niet, maar een béétje mag wel
Fijn dat je mijn post hebt genomen zoals ik het bedoelde en genuanceerd reageert!

[Merethil]

gekkie schreef op dinsdag 26 mei 2020 @ 21:58:
On a side note ... thinkpad (die aanstond) vs betontegels, 1,5m hoogte .. 1-0 (okee okee, 1 tegen 0,00000000001 (vanwege een paar cosmetische krasjes erbij). Wel blij met een SSD

Ik heb Thinkpads altijd "de laptop waarmee je een dief z'n hoofd in kan slaan en rustig verder kan werken" genoemd. Die zin verkocht best goed, eigenlijk

[Merethil]

edeboeck schreef op dinsdag 26 mei 2020 @ 22:28:

[...]
Té veel inpakken hoeft inderdaad niet, maar een béétje mag wel
Fijn dat je mijn post hebt genomen zoals ik het bedoelde en genuanceerd reageert!

Geschreven tekst is niet altijd even genuanceerd en soms vind ik het ook gewoon lastig om online de juiste balans "vriendelijk" en "dit is mijn mening" te vinden, dus op zich zijn je opmerkingen goed en bedank ik je daar sowieso voor.

Gelukkig heb ik @Douweegbertje wel vaker hier rond zien hopsen en gok ik dat hij van mijn mening niet wakker ligt, noch van de melding dat ie mij niet zomaar als klant zou hebben door een verschil in mening hierover.

[Douweegbertje]

Zolang we scherp zijn in de discussie en niet naar elkaar dan lig ik daar niet wakker van. Ik heb in een voorgaande post bijvoorbeeld aangegeven dat het prima is om een test systeem te gebruiken om internals te checken of mutaties te doen.

En eigenlijk zeik je op de details wat ik dan niet expliciet aangaf maar als ik een langere post maak dan wordt ie al bij de eerste zin van je reactie afgeschoten.

Ik kan een concreet voorbeeld geven waarom ik overal bij wil. Een klant kwam met de vraag voor een pentest. Deze had idem alleen een test URL doorgegeven en that's it. "Want de rest was wel veilig en kan je niet bij". Na wat mail verkeer toch een akkoord gekregen dat er geen limiet zat op de scope.
Door DNS enumeration en verdere checks op de houder inclusief zoeken in het subnet vervolgens meer hosts gevonden. Door een flaw in 1 van de servers intern network access gekregen en met een andere flaw root (privilege elevation). Vervolgens was er een soort C&C server (kan niet helemaal in de details treden maar daar stond de data voor alle front-end meuk) die vatbaar was voor een SQL injection. Met een beetje craften de admin table gevonden en low and behold.. fooking md5. Nu met zowel root op 1 server als full admin kon ik overal bij. Die server was niet van buiten bereikbaar en derhalve veilig..

Ik kan dit pertinent niet als ik op een 1 of ander test domain vast zit. Vele technieken zoals SSRF, request smuggling zijn een ding. Multi stage attacks ook. Ik kan het heel erg fout hebben, maar bij menig test wordt hier niet naar gekeken. Ik kijk minder naar de standaard OWASP en meer naar "can you get fckd".

Is dat een deal breaker. Ja, voor sommige wel. Andere betalen 10k$ uit als bounty en zijn heel er blij

[azerty]

Douweegbertje schreef op woensdag 27 mei 2020 @ 00:35:
Zolang we scherp zijn in de discussie en niet naar elkaar dan lig ik daar niet wakker van. Ik heb in een voorgaande post bijvoorbeeld aangegeven dat het prima is om een test systeem te gebruiken om internals te checken of mutaties te doen.

En eigenlijk zeik je op de details wat ik dan niet expliciet aangaf maar als ik een langere post maak dan wordt ie al bij de eerste zin van je reactie afgeschoten.

Ik kan een concreet voorbeeld geven waarom ik overal bij wil. Een klant kwam met de vraag voor een pentest. Deze had idem alleen een test URL doorgegeven en that's it. "Want de rest was wel veilig en kan je niet bij". Na wat mail verkeer toch een akkoord gekregen dat er geen limiet zat op de scope.
Door DNS enumeration en verdere checks op de houder inclusief zoeken in het subnet vervolgens meer hosts gevonden. Door een flaw in 1 van de servers intern network access gekregen en met een andere flaw root (privilege elevation). Vervolgens was er een soort C&C server (kan niet helemaal in de details treden maar daar stond de data voor alle front-end meuk) die vatbaar was voor een SQL injection. Met een beetje craften de admin table gevonden en low and behold.. fooking md5. Nu met zowel root op 1 server als full admin kon ik overal bij. Die server was niet van buiten bereikbaar en derhalve veilig..

Ik kan dit pertinent niet als ik op een 1 of ander test domain vast zit. Vele technieken zoals SSRF, request smuggling zijn een ding. Multi stage attacks ook. Ik kan het heel erg fout hebben, maar bij menig test wordt hier niet naar gekeken. Ik kijk minder naar de standaard OWASP en meer naar "can you get fckd".

Is dat een deal breaker. Ja, voor sommige wel. Andere betalen 10k$ uit als bounty en zijn heel er blij

Dus moest er in dit geval een complete mirror beschikbaar geweest zijn van al die servers (inclusief de "afgeschermde" servers), dan was er ook niets aan de hand geweest

[Kalentum]

@Douweegbertje Mooi voorbeeld van hoe productie zich anders kan gedragen. Ik denk dat veel developers bij 'pentest' denken aan applicatieniveau en dat valt wel enigszins op een test omgeving te doen (dingen als XSS, SQL injection, file uploads etc).

Maar hoe je het ook inricht, je production env is per definitie anders: DNS, IP adressen, load balancers, firewall is vaak niet te dupliceren. Het gebruik is ook anders: er kan prima een attack vector zijn die zich alleen maar toont als je productie onder hoge load zit (ik noem maar wat: een fail over waarbij de standby een configfout bevat ofzo).

[Merethil]

Douweegbertje schreef op woensdag 27 mei 2020 @ 00:35:
Zolang we scherp zijn in de discussie en niet naar elkaar dan lig ik daar niet wakker van. Ik heb in een voorgaande post bijvoorbeeld aangegeven dat het prima is om een test systeem te gebruiken om internals te checken of mutaties te doen.

En eigenlijk zeik je op de details wat ik dan niet expliciet aangaf maar als ik een langere post maak dan wordt ie al bij de eerste zin van je reactie afgeschoten.

Ach je weet zelf ook wel dat het niet uitmaakt of je drie regels of een heel artikel had geschreven, ik richtte me vooral op de argumentatie erachter. Die heb je nu wat verder uitgelegd en ik blijf het met je oneens maar ik denk dat dat geen probleem hoeft te zijn voor ons beiden

Ik kan een concreet voorbeeld geven waarom ik overal bij wil. Een klant kwam met de vraag voor een pentest. Deze had idem alleen een test URL doorgegeven en that's it. "Want de rest was wel veilig en kan je niet bij". Na wat mail verkeer toch een akkoord gekregen dat er geen limiet zat op de scope.
Door DNS enumeration en verdere checks op de houder inclusief zoeken in het subnet vervolgens meer hosts gevonden. Door een flaw in 1 van de servers intern network access gekregen en met een andere flaw root (privilege elevation). Vervolgens was er een soort C&C server (kan niet helemaal in de details treden maar daar stond de data voor alle front-end meuk) die vatbaar was voor een SQL injection. Met een beetje craften de admin table gevonden en low and behold.. fooking md5. Nu met zowel root op 1 server als full admin kon ik overal bij. Die server was niet van buiten bereikbaar en derhalve veilig..

Ik kan dit pertinent niet als ik op een 1 of ander test domain vast zit. Vele technieken zoals SSRF, request smuggling zijn een ding. Multi stage attacks ook. Ik kan het heel erg fout hebben, maar bij menig test wordt hier niet naar gekeken. Ik kijk minder naar de standaard OWASP en meer naar "can you get fckd".

Is dat een deal breaker. Ja, voor sommige wel. Andere betalen 10k$ uit als bounty en zijn heel er blij

Het probleem is dat ook jij fouten kan maken. Stel, je bent bezig op een productieomgeving en daar ben je net even iets harder aan het pushen omdat het anders niet lukt. Je doet iets en komt erachter dat je bepaalde data weet te achterhalen door een bug in een processor (goh, die exploits zijn er best veel geweest de laatste tijd). Daar maak je per ongeluk een wijziging in, of je komt bij gegevens die écht niet mogen lekken. Tja.

Ik wil écht heel graag weten wat er kapot kan, mis kan gaan en onveilig is op de productieomgevingen die ik tegenkom. Er is echter de afweging of je zoveel risico wil lopen op je actieve productiesysteem. Ja, een blackhat kan er ook bij maar die leid je niet zelf expres naar je voordeur

Kalentum schreef op woensdag 27 mei 2020 @ 10:31:
@Douweegbertje Mooi voorbeeld van hoe productie zich anders kan gedragen. Ik denk dat veel developers bij 'pentest' denken aan applicatieniveau en dat valt wel enigszins op een test omgeving te doen (dingen als XSS, SQL injection, file uploads etc).

Maar hoe je het ook inricht, je production env is per definitie anders: DNS, IP adressen, load balancers, firewall is vaak niet te dupliceren. Het gebruik is ook anders: er kan prima een attack vector zijn die zich alleen maar toont als je productie onder hoge load zit (ik noem maar wat: een fail over waarbij de standby een configfout bevat ofzo).

En ik denk dat veel bedijven het risico durven nemen dat niet alles gevonden wordt. Het is niet alsof een pentest van Douweegbertje of iemand anders die op dezelfde manier werkt alles zal vinden, noch dat je direct alles kan aanpakken. Elke kluis is ook te kraken, elke auto is te stelen, elk huis is binnen te komen en elk document is na te maken. Er zit een kosten-baten-analyse achter en die is naar mijn mening al best sluitend op een non-productieomgeving die je wel soortgelijk opzet.
En ja, dat betekent dat je een exacte kopie van je loadbalancers, DNS-oplossingen, firewalls en eventuele onderliggende hardware zou moeten hebben. Dat moet met VM's en cloudoplossingen goed te doen zijn, maar is inderdaad een werkje.

Het is echter nooit zo dat we "het dan maar niet doen omdat we het toch niet gelijk kunnen krijgen". Je acceptatieomgeving is ook nooit 100% gelijk aan je productieomgeving, maar toch vertrouwen we erop dat code die goedgekeurd wordt in een acceptatieomgeving ook (nagenoeg) gelijk zal werken in een productieomgeving. Ook dat is een kosten-baten-analyse.
Dus het is niet zo zwart-wit als dat jij het nu stelt. Het is meer lichtgrijs/donkergrijs naar mijn mening.

[gekkie]

* gekkie pakt het handboek 50 shades of grey/gray (geheel naar voorkeur) er maar weer eens bij

[Hydra]

Douweegbertje schreef op dinsdag 26 mei 2020 @ 18:30:
Je hoeft het niet met mij eens te zijn maar om nou voor iedereen in te vullen dat ik pauper werk oplever waar niemand iets aan heeft is echt weer het uiterste. Want ik kan er prima mee leven dat jij het niets vindt. Anders is het gewoon een beetje zuur.

Ik geef je gewoon open en eerlijk mijn visie op hoe je argumentatie overkomt. En ik denk dat dat voor jou waardevol is, want iedereen (ook ikzelf) hebben een enorme blinde vlek als het aankomt op de perceptie van anderen over de dingen die in ons hoofd zitten. Ik zeg niet dat je een prutser bent; ik ken je niet en ik ken je werk niet.

Kort door de bocht: waar jij voor jezelf zegt "ik ben een echte professional omdat ik geen vaste structuur heb" komt het op anderen over als "hij heeft geen vaste structuur, dus hij kloot maar wat aan".

Ik heb wel je hele post gelezen, maar ik licht er even een paar punten uit omdat die specifiek mijn punt ondersteunen:

Maar dat het is verschil; ik zit er niet om je systeem naar de klote te helpen en ik weet echt wel wat mogelijk READ acties zijn of daadwerkelijke destructieve acties. Idem voor "bewijs" m.b.t. root access (cat /proc/1/maps, touch /root/foo) en point proven.

Nou dat weet je dus gewoon niet. Developers maken fuck-ups. Misschien is er een Admin endpoint dat een periodieke cleanup doet, die niet aangeroepen zou mogen worden. Dat is dus ook de reden dat ik een voorstander ben van het geven van de source code; zodat je ook achter dat soort dingen komt zonder daadwerkelijk iets stuk te maken.

Grappig genoeg maak je hier dezelfde denk-fout als die jij als pen-tester zou moeten blootleggen; 'denken' dat een actie niet destructief is, is heel wat anders dan weten dat het niet destructief is. Je komt er over het algemeen pas achter dat je fout zat als je het al gedaan hebt. Been there. Done that.

En hoewel ik heb een waiver heb, ben ik alsnog verantwoordelijk voor mijn fuckups. Ik wil niet beweren dat dit waterdicht is, maar daar heb ik wel een verzekering voor. Los van dat, als iemand echt komt met zo'n bedrijfskritische applicatie waar miljoenen in om gaan dan bestaat de kans dat ik dit weiger.

Okay, maar dat zijn dus de projecten waar ik altijd aan werk. Vandaar dat ik zeg dat ik jouw aanpak te riskant vindt voor de projecten waar ik een mening over kan hebben. Dus in essentie zijn we het met elkaar eens; er zit een risico aan vast en dat risico kan in veel gevallen te groot zijn.

En dat je een verzekering hebt is mooi; die heb ik ook (ben ZZPer). En ik weet ook genoeg van deze verzekeringen dat deze dit soort schade helemaal niet dekken, gewoon omdat er opzet in het spel is. En al zouden ze dat wel doen; dan nog zijn ze ten eerste gelimiteerd, en schiet ten tweede een bedrijf daar natuurlijk weinig mee op: die willen gewoon dat er niks stukgaat.

Echter ben ik simpelweg van mening dat iemand z'n werk, of een outsider, nooit een situatie mogen opleveren die jij schetst:

Het "zou nooit morgen" is het hele bestaansrecht van Pen-testers. Natuurlijk zouden er in de ideale wereld geen fouten gemaakt mogen worden. Maar dat gebeurt wel. En die zijn vaak een heel stuk complexer dan een simpele SQL injection (die in de applicaties waar ik in werk gewoon eigenlijk niet mogelijk zijn en nooit door een review zouden komen).

Ik doe nu een opdracht bij een bank, en ik zit hier nu een bepaald enterprise systeem op te zetten. Ik hoef denk ik niet uit te leggen hoeveel regels er bij een bank zitten. Maar; iedereen mag van mij heel data systeem slopen, alle data weggooien en whatnot. Want dit is zo belangrijk; daar is juist over nagedacht. Sterker nog, dat wordt bewust gedaan om de integriteit te (blijven) controleren. Mij boeit het niet eens als iemand op die PRD omgeving een test doet, want ik ben in control en er zijn procedures die de overige zaken (in case shit hits the fan) overnemen.

Ik heb bij de ING gezeten en note bene voor een ING start-up samen gezeten met pen-testers als een van de back-end leads. Daar werd de aanpak gebruikt zoals ik die aangaf; toegang op zowel een productie-like test omgeving als op productie, waar eerst gecheckt werd op acceptatie en daarna nog heel voorzichtig op productie. Ik vind het moeilijk te geloven dat 'een bank' je op een bedrijfs-ktitische productie omgeving los laat gaan, ook omdat ik weet hoe die processen binnen een bank werken.

In sommige gevallen krijg ik een bounty of 'swag'. In enkele gevallen krijg ik vooraf betaald, maar dat zijn soms terugkerende gebruikers die er heel erg gebaat bij waren/zijn. Hier heb ik een goede relatie mee, en als iemand nu aanklopt om echt zakelijk iets te doen; dan krijg je waarschijnlijk "nee" te horen. Dat is niet mijn doel/ambitie noch het geen wat ik "aanbied". Ik probeer alles zo netjes mogelijk te doen. Je ziet verschillende verhalen van "whitehat" die even onaangekondigd erin gaan zitten (Efteling bijv, de posts van hierboven een paar keer, etc).

Als je zo goed bent als je zegt dat je bent, is het m.i. volkomen krankjorem dat je het gratis doet, of voor wat 'swag'. En ik heb ook werkelijk in heel m'n 18+ jarige carriere nog nooit meegemaakt dat een grote enterprise toko (ING, UWV, IND, D-Reizen, Bol.com, Olympia, Randstadt, to name a few) iemand voor een appel en een ei los liet gaan op productie omgevingen.

Dus nogmaals; ik zeg niet dat je slecht bent in je werk. Ik zeg alleen dat op basis van wat je hier vertelt eist dat je bepaalde grote risico's mag nemen die ik zelf niet zou accepteren, vooral omdat je het grootste deel van de issues ook al op een prod-like omgeving zou kunnen vinden. Ik ben het met je eens dat op prod testen niet taboe moet zijn; waar we van mening verschillen is waar je begint.

[Hydra]

edeboeck schreef op dinsdag 26 mei 2020 @ 21:27:
Doe je dit nu expres of heb je gewoon iets te snel gelezen? Hij zegt net dat hij dit destructieve acties van een blackhat niet doet en die "vervangt" door acties die het punt aantonen zonder de schade.

Je weet niet vooraf wat destructief is en wat niet. Als het zo simpel was, hadden we geen pentesters nodig.

Pentesten gaat op verschillende niveau's. Er kunnen fouten zitten in de applicatie, maar ook in de inrichting van het OS, van de infrastructuur, welke rechten gebruikers hebben, etc. Pentesten is enorm complex en wat ik tot nu toe gezien heb bij de echt goeie bedrijven, is dat ze verschillende specialisten in dienst hebben die elk een klein deel van hun rekening nemen.

Ik ben het helemaal met je eens dat het prima kan zijn dat er bepaalde patches niet op Pro staan die wel op Pro-accent staan. En daar moet je op kunnen checken. Dat mag inderdaad niet taboe zijn. Maar als een pentester onze applicatie test, en wij zorgen dat op pro-accent exact dezelfde versie staat, dan ga je daar als het goed is het grootste deel van de fouten vinden.

En dat is eigenlijk hoe ik tot nu toe altijd in die projecten meegewerkt heb: wij gaven ook aan de desbetreffende specialisten gewoon toegang tot de code van zowel de back-end API's als de mobiele / web applicatie. Gewoon omdat het veel effecienter werkt.

Juist omdat we een pen-tester de vrijheid willen geven helemaal los te gaan en aan te tonen dat hun hypothese werkt, heb je een pro-like omgeving nodig. Leuk dat je claimt dat je een user table kunt droppen, maar laat maar eens zien. En dat kunnen we natuurlijk niet toestaan op Pro zelf. Betekent dat niet dat je niet mag kijken of je niet met root/root op pro binnen kunt komen? Tuurlijk niet.

Maar als een pentester weigert om op iets anders als Pro te testen dan is het een hele snelle "dan zoeken we iemand anders". Dat was waarom ik reageerde.

[ Voor 4% gewijzigd door Hydra op 27-05-2020 11:51 ]

[Hydra]

Koenvh schreef op dinsdag 26 mei 2020 @ 18:33:
Ik pak de popcorn alvast (zoet of zout? )

Doe maar wat wortels. Die coronakilo's moeten er echt af

[gekkie]

Hydra schreef op woensdag 27 mei 2020 @ 11:52:
[...]
Doe maar wat wortels. Die coronakilo's moeten er echt af

Meest effectieve schijnt te zijn het te krijgen en een paar weekjes op de IC te belanden .

[Hydra]

gekkie schreef op woensdag 27 mei 2020 @ 11:59:
Meest effectieve schijnt te zijn het te krijgen en een paar weekjes op de IC te belanden .

Als je leest over al die mensen die blijvende klachten hebben; liever niet

[Douweegbertje]

Ja ik heb er niets aan toe te voegen @Hydra . Ik snap je verhaal en ben het daar ook in grote lijnen mee eens. Wat betreft dat stukje "geld" wat je niet snapte. Eigenlijk is dat vrij simpel.

Ik verdien genoeg met mijn "echte werk" en ik ben jaren geleden goed ziek geweest. Dat geeft soms een ander perspectief op het leven en andere zaken in het algemeen. Toen was ik ook aardig door mijn buffers heen gegaan en nu zou een paar ton mijn leven makkelijker maken, zeker omdat ik opzoek ben naar een koopwoning. Maar ik heb echt geen snars te klagen.

Als alles in het leven maar in het teken van geld moest staan dan word ik daar domweg niet gelukkig van. Derhalve doe ik vrijwilligerswerk, gratis opdrachten en sponsor ik diverse developers maandelijks die aan Open source projecten werken.

Overigens zou mij ook niet verbazen dat als wij elkaar in real life tegenkwamen en jij niet wist dat ik Douweegbertje was, dat je een totaal andere mening zou vormen. Want over het algemeen zitten we hier in de dev corner meer discussies tegen elkaar te voeren dan met elkaar. Met een biertje en identieke onderwerpen zou het een stuk gezelliger zijn denk ik

edit:

Ben ik de enige die overigens bij Hydra zijn post, diverse forum buttons (quote, score, etc) zie in zijn quotes? Volgens mij is de opmaak tamelijk kapot geraakt daar..

[ Voor 7% gewijzigd door Douweegbertje op 27-05-2020 17:10 ]

[gekkie]

Douweegbertje schreef op woensdag 27 mei 2020 @ 17:09:
Want over het algemeen zitten we hier in de dev corner meer discussies tegen elkaar te voeren dan met elkaar. Met een biertje en identieke onderwerpen zou het een stuk gezelliger zijn denk ik

Maarja is een discussie nog een discussie als je niet tegenover elkaar staande visies uit gaat wisselen (of het je mening / overtuiging is, of dat het een gelegenheidsstandpuntje wat je voor de dicussie verdedigt) maar gezellig het met elkaar eens bent?

En de bruikbare genuanceerde concensus die valt er doorgaans wel prima zelf uit op te maken.
Hou je wellicht de toon van de discussie over, maarja we zijn niet voor niets (okee en een deel ).

Klinkt meer als een bierkransje *proost* !

[ Voor 14% gewijzigd door gekkie op 27-05-2020 17:24 ]

[Hydra]

Douweegbertje schreef op woensdag 27 mei 2020 @ 17:09:
Ja ik heb er niets aan toe te voegen @Hydra . Ik snap je verhaal en ben het daar ook in grote lijnen mee eens. Wat betreft dat stukje "geld" wat je niet snapte. Eigenlijk is dat vrij simpel.

Ik verdien genoeg met mijn "echte werk" en ik ben jaren geleden goed ziek geweest. Dat geeft soms een ander perspectief op het leven en andere zaken in het algemeen. Toen was ik ook aardig door mijn buffers heen gegaan en nu zou een paar ton mijn leven makkelijker maken, zeker omdat ik opzoek ben naar een koopwoning. Maar ik heb echt geen snars te klagen.

Ik ook niet. Ik ben freelance Java dev. Maar ik ga over een poosje een paar trainingen geven,en dat doe ik toch echt niet gratis. Ten eerste is mijn expertise geld waard. Ten tweede is het enige wat onbeperkt is in het leven tijd, dus wil ik daarvoor vergoed worden

Niet dat je instelling 'verkeerd' is hoor, helemaal niet. Dat moet je zelf weten

Overigens zou mij ook niet verbazen dat als wij elkaar in real life tegenkwamen en jij niet wist dat ik Douweegbertje was, dat je een totaal andere mening zou vormen. Want over het algemeen zitten we hier in de dev corner meer discussies tegen elkaar te voeren dan met elkaar. Met een biertje en identieke onderwerpen zou het een stuk gezelliger zijn denk ik

Ik kan prima iemand persoonlijk graag mogen en het volledig met 'em oneens zijn hoor Die dingen staan wmb lost van elkaar. Ik vind discussies leuk en leerzaam bovendien. Een goeie vriend van me is streng gelovig; ik het tegenovergestelde. Heb eindeloze discussies met 'em gehad hierover

edit:

Ben ik de enige die overigens bij Hydra zijn post, diverse forum buttons (quote, score, etc) zie in zijn quotes? Volgens mij is de opmaak tamelijk kapot geraakt daar..

Tegenwoordig worden posts autoomatisch samengevoegd. Moet ik ook nog een beetje aan wennen na bijna 20 jaar GoT

[Koenvh]

Hydra schreef op woensdag 27 mei 2020 @ 11:52:
[...]


Doe maar wat wortels. Die coronakilo's moeten er echt af

Wederom: Zout of zoet, of toch gewoon rauw?

[azerty]

Douweegbertje schreef op woensdag 27 mei 2020 @ 17:09:

edit:

Ben ik de enige die overigens bij Hydra zijn post, diverse forum buttons (quote, score, etc) zie in zijn quotes? Volgens mij is de opmaak tamelijk kapot geraakt daar..

Nee, jullie lezen gewoon niet de .plans die Tweakers post

[WernerL]

Mag ik jullie lastig vallen voor wat advies?

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Mugwump]

WernerL schreef op donderdag 28 mei 2020 @ 08:53:
Mag ik jullie lastig vallen voor wat advies?


***members only***

Eerlijk gezegd zou ik absoluut niet voor een baan kiezen waarvan je doodongeluk wordt en ook nog eens flinke extra kosten moet maken (eigen auto) omdat je werkgever je anders wil dumpen. Ik weet niet hoe je contract nu is geregeld en hoe lang je recht hebt op WW, maar het is niets alsof je werkgever je morgen op straat kan zetten en je dan zonder inkomen zit. Je geeft zelf al aan dat je bij je huidige werkgever toch al niet op je plek zit, dus waarom niet gewoon flink aan het solliciteren slaan bij werkgevers die je wel leuk lijken?

[Giesber]

WernerL schreef op donderdag 28 mei 2020 @ 08:53:
Mag ik jullie lastig vallen voor wat advies?


***members only***

Om op die laatste vraag te antwoorden: nee, dan ben je eerder wijs. Tenzij je daardoor geen brood meer op de plank zou krijgen.

Je hebt in deze situatie eigenlijk de tijd om rustig een andere job te zoeken. Ik zou rustig andere opportuniteiten afwachten, en pas iets waarvan je twijfelt gaan accepteren als je ofwel bijna door je financiële buffer dreigt te gaan, ofwel teveel stress krijgt van de onzekerheid.

Ik zit nu zelf zonder werk, maar de buffer is nog zeer ruim, en stress van onzekerheid heb ik niet. Bij mij is het eerder de partner die al doemscenario's ziet door een nakende crisis en de grote vakantie in het voorzuitzicht. Zelf denk ik dat het in de IT wereld wel zal loslopen, zeker als je ergens vast in dienst wil gaan. Ik heb dan ook al enkele voorstellen afgewezen (inhoud of afstand), en kijk rustig verder naar iets wat me echt bevalt.

[wackmaniac]

WernerL schreef op donderdag 28 mei 2020 @ 08:53:
Mag ik jullie lastig vallen voor wat advies?


***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[alienfruit]

Wat een vervelende manier van werken van je werkgever zeg! Ik heb eigenlijk nog nooit eerder gehoord dat je 'weggezet' wordt bij een andere 'wegzetter' om vervolgens voor hun klant te gaan werken. Ik snap goed dat je dat in combinatie met een vervelende werk-woonverkeer.

Zelf was sinds Januari ook werkloos omdat ik een beetje weggepest ben bij mijn oude werkgever. Lange tijd lekker bank wezen hangen maar mijn drang naar nieuwe werk heeft mij toch gemaakt om een job te accepteren. Zeker als je ziet hoeveel bedrijven mensen ontslaan in Londen. Ik weet niet hoe het in Nederland zit maar hier vielen toch een hoop ontslagen.

Ik werk nu bij een startup en heb het tot nu naar mijn zin en genoeg om te leren omdat ik zelf nooit echt vaak met Big Cloud gewerkt heb dus genoeg te leren nog en het is wat anders dan met SAP werken! Helaas wel een kleine korting op mijn salaris (~5%) maar beter dan helemaal geen salaris en interen op je spaargeld. Maar ik zie wel mogelijkheden om mijn salaris op te krikken. Na dat ik deze baan had aangenomen kwam er wel een andere leuke baan voorbij maar helaas pindakaas

[ Voor 14% gewijzigd door alienfruit op 28-05-2020 11:13 ]

[WernerL]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 23% gewijzigd door WernerL op 28-05-2020 11:58 ]

[downtime]

WernerL schreef op donderdag 28 mei 2020 @ 08:53:
Mag ik jullie lastig vallen voor wat advies?


***members only***

Situatie die mij bekend voorkomt. Jou ontslaan kost geld. Maar deze methode levert hun geld op.

Een vroegere werkgever van mij, die nooit aan werving en selectie voor derden deed, ging dat opeens toch doen toen ze van hun eigen bankzitters af moesten. Dat is voor iedereen winst: Oude werkgever is van jou af en verdient er nog wat aan voor de bemiddeling, nieuwe werkgever heeft een medewerker erbij, en jij bent niet werkeloos (UWV is ook niet alles). Maar het werkt natuurlijk alleen als alle drie partijen het ook echt willen.

In het kort: Je bent niets verplicht als je niet wilt. Die auto zou ik sowieso niet aanschaffen voor een baan die ik niet echt wil maar je zou dat kunnen aankaarten en om compensatie en/of een leaseauto vragen. Zo heeft een collega van mij er ooit genoeg geld uit gesleept voor een leuke occasion.

Maar ik proef dat je helemaal niet naar deze werkgever wilt. Dan is het simpel: Zelf gaan zoeken en het ontslag niet afwachten.

[Hydra]

@WernerL ik ben het ook eens met de rest: ik vind het echt een rotsituatie en ik zou ook zeker niet akkoord gaan met het gedumpt worden bij een bedrijf waar je gewoon ongelukkig gaat worden. Laat ze je dan maar ontslaan. En zorg dat je vast dossier op gaat bouwen voor 't geval je m.b.t. de ontslagvergoeding voor de rechter komt te staan. Stel dus alle mailtjes e.d. hierover veilig.

[alienfruit]

Vandaag lekker aan het klungelen in mijn Google Cloud zandbak

[.oisyn]

WernerL schreef op donderdag 28 mei 2020 @ 11:57:
***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[whoami]

alienfruit schreef op vrijdag 29 mei 2020 @ 11:10:
Vandaag lekker aan het klungelen in mijn Google Cloud zandbak

Ik ben aan het klungelen in mijn Azuur blauwe zandbak, waar ik de logging van een aantal services eens proper wil krijgen zodanig dat er ook mooi weergegeven wordt welke services er door een andere worden aangeroepen.

[alienfruit]

Aan het strand hoop ik?

Leuk idee @whoami hoe ga je het aanpakken?

[ Voor 47% gewijzigd door alienfruit op 29-05-2020 15:53 ]

[Grijze Vos]

WernerL schreef op donderdag 28 mei 2020 @ 11:57:
***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Douweegbertje]

alienfruit schreef op vrijdag 29 mei 2020 @ 11:10:
Vandaag lekker aan het klungelen in mijn Google Cloud zandbak

hehe, ik had dat ook gedaan. Ik ben nu nog steeds aan het afbetalen

No joke overigens, ik was vergeten mijn resources weer te verwijderen. Tijdens het spelen even wat dikke machines de lucht in gegooid. Dat is peanuts voor een paar uurtjes (paar euro). Laat ik nou net een project vergeten te verwijderen.
In zekere zin heb ik wel alerts staan op mijn $$ maar aangezien ik legitiem voor wat honderd euro p/m wat draai, en dan alleen de alert heb voor een x-bedrag (ongeacht de periode) ging ik in enkele dagen daar overheen. Enigszins de schade beperkt, maar alsnog 700 euro lichter.. dure les.

[Woy]

Douweegbertje schreef op maandag 1 juni 2020 @ 20:20:
[...]


hehe, ik had dat ook gedaan. Ik ben nu nog steeds aan het afbetalen

No joke overigens, ik was vergeten mijn resources weer te verwijderen. Tijdens het spelen even wat dikke machines de lucht in gegooid. Dat is peanuts voor een paar uurtjes (paar euro). Laat ik nou net een project vergeten te verwijderen.
In zekere zin heb ik wel alerts staan op mijn $$ maar aangezien ik legitiem voor wat honderd euro p/m wat draai, en dan alleen de alert heb voor een x-bedrag (ongeacht de periode) ging ik in enkele dagen daar overheen. Enigszins de schade beperkt, maar alsnog 700 euro lichter.. dure les.

Ja als je niet oplet kan het snel gaan met je cloud resources. Heb ook al vaker gezien dat er flinke bedragen onnodig uitgegeven zijn, terwijl het best goed te regelen is als je je test/acc/productie subscriptions goed uit elkaar houdt, en ook de juiste alerts in stelt voor uitgaven voor resources. Het is immers vaak vooral resources die niet eens echt nodig waren, maar voor een testje uitgerold zijn, die achteraf toch best een zware last op de totale kosten zijn.

[alienfruit]

Bij AWS gebruikte ik altijd AWS Scheduler om te zorgen dat resources niet onnodig draaien. Helaas, heb ik zoiets vergelijkbaars nog niet kunnen vinden voor Google Cloud.

Ach op mijn vorige werk hadden we een RDS Postgres (db.t3.2xlarge) draaien voor anderhalve jaar waar niemand vanaf wist Tot dat, we een Head of Cloud kregen die mij vroeg waarom er een RDS draaide voor project X.

[ Voor 39% gewijzigd door alienfruit op 01-06-2020 21:39 ]

[Douweegbertje]

Woy schreef op maandag 1 juni 2020 @ 21:22:
[...]

Ja als je niet oplet kan het snel gaan met je cloud resources. Heb ook al vaker gezien dat er flinke bedragen onnodig uitgegeven zijn, terwijl het best goed te regelen is als je je test/acc/productie subscriptions goed uit elkaar houdt, en ook de juiste alerts in stelt voor uitgaven voor resources. Het is immers vaak vooral resources die niet eens echt nodig waren, maar voor een testje uitgerold zijn, die achteraf toch best een zware last op de totale kosten zijn.

tja, dit is ook wel het verschil tussen mijn eigen meuk als hobby en wat ik profesioneel zou opzetten. Ik denk dat ik erm, niet eens 1% van de best practises hanteer.
Juist omdat ik weet hoeveel werk het is om het goed op te zetten, met de juiste IAM meuk, project setups en billings, dat ik dus bewust zelf helemaal geen zak heb om gewoon los te kunnen gaan.
In fairness; dit is ook voor het eerst in 4-5 jaar dat mij dit overkomt, hoewel misschien niet de laatste keer, ik verwacht niet dat zo'n kostenpost nog een keer gebeurd

Het zure is dat ik dit niet eens zo zeer voor mijzelf had opgezet maar als proof of concept voor Google..dus mogelijk dat ik nog wat geld terug krijg

[TheMaxMan]

Een paar dagen geleden met Swift te leren dmv de 100 Days of Swift van Paul Hudson. Ik ga er wat sneller door, maar closures en protocols gaan er moeilijk in, ik hoop dat dat iets is wat achteraf nog duidelijk wordt. Ik kijk al uit naar de projectjes

[Scott]

TheMaxMan schreef op maandag 1 juni 2020 @ 23:34:
Een paar dagen geleden met Swift te leren dmv de 100 Days of Swift van Paul Hudson. Ik ga er wat sneller door, maar closures en protocols gaan er moeilijk in, ik hoop dat dat iets is wat achteraf nog duidelijk wordt. Ik kijk al uit naar de projectjes

De syntax is wat vreemd maar closures zijn eigenlijk gewoon functies en protocols zijn zoals interfaces in Java. Even wennen inderdaad, maar je ziet beiden heel veel dus dat ga je vanzelf begrijpen.

[dev10]

alienfruit schreef op maandag 1 juni 2020 @ 21:37:
Ach op mijn vorige werk hadden we een RDS Postgres (db.t3.2xlarge) draaien voor anderhalve jaar waar niemand vanaf wist Tot dat, we een Head of Cloud kregen die mij vroeg waarom er een RDS draaide voor project X.

Ik zat even te kijken wat dat kost, maar als ik dat vergelijk met wat andere mensen soms kwijt zijn door niet op te letten met hun cloud resources viel me dat nog best mee. Ik weet niet hoeveel er maandelijks naar AWS ging, maar ik kan me voorstellen dat die paar honderd euro voor een DB instance daarbij niet opvallen.

[Voutloos]

Ja, dat klinkt inderdaad wel duur, zo’n Head of Cloud.

[gekkie]

Wat is jouw functie ?
Ik loop de hele dag met m'n hoofd in de wolken

Urgh, leuk die PDF formulieren waar in een veld je aanslagnummer weigert te accepteren .

[ Voor 39% gewijzigd door gekkie op 02-06-2020 10:18 ]