Security Professionals - ipfw add deny all from eindgebruikers to any

IBM Aspera Connect security

06-03-2020, 17:04 door Erik van Straten, 37 reacties
N.a.v. de discussie in https://www.security.nl/posting/646555/Aspera+Client+verplicht+voor+downloaden+bij+de+belastingdienst___ het volgende.

Vooraf
Nb. het is me nog niet voor 100% duidelijk of de Belastingdienst je vraagt om de IBM Aspera Connect software te installeren, of iets anders (zoals de Aspera Desktop Client). Alle pagina's op de site van de Belastingdienst lijken echter naar eerstgenoemde te refereren, dus daar ga ik vanuit.

SSL certificaat voor local.connectme.us met IP-adres 127.0.0.1
Na mijn reactie in https://security.nl/posting/646604 heb ik wat vervolgonderzoek gedaan en zag in https://www.ibm.com/support/pages/troubleshooting-connect-issues-involving-localconnectmeus-and-local-ports iets griezeligs:
Connect 3.6.5 and newer uses the domain name local.connectme.us that points to a machine's local 127.0.0.1 IP address. There is an SSL certificate for the domain that allows Connect to make requests to the local machine through HTTPS.

Hardcoded private key voor publiek certificaat
Dat kan natuurlijk niet goed gaan, net zoals Netgear die al haar routers voorzag van een publiek erkend certificaat plus private key voor o.a. www.routerlogin.net (zoals je kunt lezen in de bovenste link in https://www.security.nl/posting/640348/IoT+authenticiteit). Het -terechte- gevolg is dan ook dat het certificaat voor https://local.connectme.us/ ondertussen is ingetrokken.

Certificaatfoutmelding
Als je de IBM Aspera Connect software installeert, start en met bijv. Firefox de volgende URL benadert:
https://local.connectme.us:43003/v5/connect/info/ping
krijg je een certificaatfoutmelding - die je niet kunt omzeilen (vervangen van https door http gaf bij mij een "connection reset" en lijkt dus niet te werken). Als je Firefox gebruikt en deze Aspera Connect software moet gebruiken, zul je tijdelijk OCSP checks uit moeten zetten. Dit kan in about:config (zoek naar OCSP) van de naam "security.OCSP.enabled" de waarde te wijzigen van 1 in 0 (Nb. deze Firefox settings zijn account-specifiek). Vergeet niet dit weer terug te zetten zodra je klaar bent! Nb. OCSP informatie wordt niet onthouden door de browser (het is dus geen probleem als je al een keer een certificaatfoutmelding hebt gehad; als je daarna OCSP checks uitzet, zal Firefox niet klagen over revocation).

Met Google Chrome zal dit wellicht helemaal geen problemen geven, omdat in Chrome OCSP revocation checks by default uit staan (als ik me niet vergis, ik ben geen Chrome gebruiker).

Security risico's
Mijn bezwaar tegen dit systeem is niet dat het certificaat nu is ingetrokken. Dat zijn:
1) Het gebruik van publieke DNS-lookup van local.connectme.us, als het goed is 127.0.0.1;
2) Het feit dat het certificaat (als het niet zou zijn ingetrokken) niet voorkomt dat je, t.g.v. een gemanipuleerd DNS antwoord, met een andere computer verbindt dan met jouw eigen PC;
3) Ik geen andere maatregelen heb kunnen ontdekken die voorkomen dat jouw webbrowser met een andere PC verbindt bij een gemanipuleerd DNS antwoord [*].

Het doel van een https certificaat is het authenticeren van een server (eventueel van meerdere servers van dezelfde organisatie, die allen over de bij het certificaat horende private key moeten beschikken). Als die private key in verkeerde handen valt, waar je op kunt wachten als je deze in software verspreidt, is nog steeds sprake van een versleutelde verbinding, alleen heb je geen enkele zekerheid met wie.

Essentieel hier is dat je zeker weet dat jouw webbrowser met software op de lokale computer communiceert. Dat vraagstuk los je niet op door elke computer, waarop deze software is geïnstalleerd, te laten bewijzen dat hij de enige echte local.connectme.us is.

Het is jammer dat de IBM Aspera Connect software geen http verbinding meer lijkt te ondersteunen, want http://localhost:43003/ of http://127.0.0.1:43003/ zijn natuurlijk veilig genoeg als je met jouw eigen PC communiceert (als je software buiten de browser, zoals IBM Aspera Connect, moet vertrouwen, is het tevens noodzakelijk dat je alle draaiende software op die computer vertrouwt). Hier met simpele middelen https van proberen te maken levert alleen maar schijnveiligheid op.

[*] Zoals ik verderop beschrijf luistert de software uitsluitend "op localhost", maar aanvallers kunnen van relay software en/of van bijv. iptables gebruik maken om poorten op routable IP-adressen te laten luisteren.

Mitigerende maatregelen
Mijn advies is dan ook, als je met deze software aan de slag gaat, om het volgende toe te voegen aan de hosts file op de gebruikte computer:
127.0.0.1 local.connectme.us
::1 local.connectme.us

Of Firefox die tweede (IPv6) regel respecteert weet ik niet zeker. Om uit te sluiten dat Firefox toch een publieke IPv6 DNS lookup gebruikt, kun je in Firefox (about:config, zoek naar DNS) tijdelijk network.dns.disableIPv6 wijzigen van "false" in "true". Niet vergeten om ook deze instelling later weer terug te zetten!

Om zeker te weten dat Firefox verbinding maakt met 127.0.0.1 (in plaats van een extern IP-adres) kun je op F12 drukken, het Network-tabblad openen, met F5 de pagina herladen en op de bovenste regel in het debug venster klikken. Rechts verschijnt dan een deelvenster waarin het "Remote address" staat, dat natuurlijk 127.0.0.1 moet zijn.

Een andere maatregel die je kunt treffen is met een firewall voorkomen dat de PC verbindingen kan maken met de TCP poort en 33003, 43003 en 51868 op andere IP-adressen dan 127.0.0.1. Overigens luistert de IBM Aspera Connect software uitsluitend op localhost, relevante output van netstat -ano op de gebruikte Windows PC:
Proto Local Address Foreign Address State PID
TCP 127.0.0.1:33003 0.0.0.0:0 LISTENING 6984
TCP 127.0.0.1:43003 0.0.0.0:0 LISTENING 6984
TCP 127.0.0.1:51868 0.0.0.0:0 LISTENING 6984

Verantwoording
Ik heb de IBM Aspera Connect software gedownload, mijn PC ontkoppeld van internet, de software geïnstalleerd (aanvankelijk single-user, later multi-user), bovenstaande wijzigingen in de hosts file gemaakt, de software gestart en met Firefox https://local.connectme.us:43003/v5/connect/info/ping geopend. Dit gaf, naast de verwachte pagina, een groen slotje en geen certificaatfoutmelding. Doordat er op dat moment geen internetconnectiviteit was, weet ik zeker dat de private key zich ergens in de software moet bevinden. Ik heb even een poging gedaan om deze uit de software en een memory-dump te peuteren, maar deze is vermoedelijk versluierd opgenomen. Aangezien het certificaat ondertussen is ingetrokken heb ik hier verder geen tijd aan besteed.

Gisteren omstreeks 12:40 heb ik hierover een e-mail naar de Belastingdienst gestuurd (en een CC naar NCSC.nl). De Belastingdienst heeft de ontvangst van mijn e-mail bevestigd, en aangegeven dat ze naar de zaak zullen kijken en mij gewezen op hun disclosure policy in https://www.belastingdienst.nl/security.

Ik heb besloten om deze informatie nu toch te publiceren, omdat ik niet verwacht dat de Belastingdienst op korte termijn een andere, veiliger, oplossing kan bieden. En omdat, met bovenstaande informatie, gebruikers hun computers (ondanks de knullige aanpak in de door mij geteste IBM Aspera Connect software) kunnen beveiligen en voorkomen dat vertrouwelijke gegevens die zij met bijv. de Belastingdienst uitwisselen, in handen van derden kunnen vallen. En dat gebruikers deze versie van die software, ondanks het ingetrokken certificaat, toch kunnen gebruiken - met, voor zover ik nu kan overzien, nauwelijks risico's (als je zeker weet dat de browser met de eigen computer communiceert, heb je helemaal geen certificaat nodig, en dus vormt een ingetrokken certificaat geen risico). Ik hoop dan ook dat de Belastingdienst mijn adviezen overneemt, zodat iedereen, die dat moet, belasting kan betalen.

Ten slotte vind ik dat, in z'n algemeenheid, securityprofessionals werkzaam bij softwareleveranciers moeten voorkomen dat er van schijnveiligheid gebruik gemaakt wordt. En dat partijen die overwegen om dit soort software in te zetten, beter moeten (laten) onderzoeken wat ze in huis halen - vooral als zij hun "klanten" vragen/dwingen om dergelijke software te installeren. Onze maatschappij wordt steeds afhankelijker van digitale communicatie; het is m.i. essentieel dat we dit zo veilig mogelijk maken, waarbij schijnveiligheid en "quick and dirty tricks" worden vermeden.
Reacties (37)
06-03-2020, 17:31 door Anoniem
Ja het is inderdaad de Aspera Connect software die men gebruikt. Ik had in de eerdere posting Aspera Client genoemd
en dat had ik ook geinstalleerd en daar kwam ik niet verder mee, de belastingdienst zei toen dat ik Aspera Connect
moest hebben maar dat kreeg ik ook niet werkend. Ik begin nu te snappen waarom: die machine zit achter een proxy
en die zal daarom die localhost connectie niet hebben kunnen maken. En OCSP staat ook aan uiteraard.

Wat een prutsers! Met het gebruik van deze "speciale software voor de veiligheid" hebben ze het alleen maar
onveiliger gemaakt! Gewoon in de browser downloaden met een veilig certificaat van de belastingdienst was veel
beter geweest.

Ik denk nog steeds dat ze door een stel mannen in blauwe pakken erin getild zijn. "experts op het gebied van veiligheid"
kunnen in een bedrijf zowat alles maken, en als er iemand (bijv van ICT) een beetje wantrouwend is dan steken ze
gewoon rechtsrtreeks door naar de directie "meneer u wilt met de veiligheid toch geen enkel risico lopen??"...

Fijn dat je dit aan de orde gesteld hebt, wellicht bespoedigt dit de uitfasering van dit stuk software.
06-03-2020, 18:12 door karma4
Nog wel een vraag....
Waar komt het vandaan dat aspera verplicht is?
Bedrijven gebruiken verplicht xbrl.

Particulier moet je onder 16mb wel uitkomen met mail
Daarboven gaat het niet. Hele video uitwisseling lijkt me niet logisch.
https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/standaard_functies/prive/contact/per_brief_of_email/voorwaarden_e-mailen/voorwaarden_voor_het_gebruik_van_e-mail
06-03-2020, 19:48 door Anoniem
Door Anoniem:

Wat een prutsers! Met het gebruik van deze "speciale software voor de veiligheid" hebben ze het alleen maar
onveiliger gemaakt! Gewoon in de browser downloaden met een veilig certificaat van de belastingdienst was veel
beter geweest.
Was jij dan niet die prutser, die eerst de verkeerde software installeren?
06-03-2020, 22:26 door Erik van Straten
Door Anoniem: Was jij dan niet die prutser, die eerst de verkeerde software installeren?
Aanvankelijk vond ik dit ook verwarrend, want de belastingdienst heeft het op meerdere pagina's over de "IBM Aspera Connect client, in https://filetransfer.belastingdienst.nl/info/pages/filetransferbasics.html.nl?ver=2.3 wordt "Client" zelfs 2x met een hoofdletter geschreven (vette en cursieve opmaak na "Let op!!" toegevoegd door mij):

Let op!!
Gebruikt u Chrome, Firefox, Safari of Microsoft Edge? Dan kunt u Belastingdienst filetransfer alleen nog gebruiken als u de IBM Aspera Connect Client bijwerkt. U wordt geforceerd dit te doen zodra u een up- of download-uitnodiging gebruikt. De upgrade van de IBM Aspera Connect Client is nodig om op het hoogste beveiligingsniveau te blijven.

In de tabel op pagina 2 van https://asperasoft.com/software/clients/ (PDF) is geen sprake van een (IBM) Aspera Connect Client. Wel van o.a. een Aspera Desktop Client en Aspera Connect software.
06-03-2020, 23:40 door Erik van Straten
Ik heb nog wat verder gespit: in https://www.ibm.com/support/pages/security-bulletin-denial-service-vulnerability-affecting-aspera-connect-37-or-38 lees ik dat een certificaat voor local.connectme.us eind 2019 al is ingetrokken.

Als ik die tekst goed begrijp is in december het certificaat voor de versies 3.7 en 3.8 van Aspera Connect ingetrokken, en heeft IBM/Aspera een nieuw certificaat verkregen en dat (samen met de bijbehorende private key) opgenomen in versie 3.9.x - en is dat tweede certificaat ondertussen ook ingetrokken. Maar mogelijk begrijp ik de tekst verkeerd en is er "pas" 1 certificaat ingetrokken, maar dan snap ik niet dat je deze software (met ingetrokken certificaat), 3 maanden later, nog steeds kunt downloaden - zonder dat er een alternatieve houdbare oplossing voor bedacht en gemaakt is.
07-03-2020, 06:22 door Anoniem
Door karma4: Nog wel een vraag....
Waar komt het vandaan dat aspera verplicht is?
Bedrijven gebruiken verplicht xbrl.
Dit is voor ad hoc file transfers, dus voor dingen die buiten de normale uitwisseling van gegevens vallen.
https://filetransfer.belastingdienst.nl/info/pages/howdoesitwork.html.nl?ver=2.3
07-03-2020, 08:51 door karma4
Door Erik van Straten: ..maar dan snap ik niet dat je deze software (met ingetrokken certificaat), 3 maanden later, nog steeds kunt downloaden - zonder dat er een alternatieve houdbare oplossing voor bedacht en gemaakt is.

Je mist twee belangrijke punten:
- in welke gevallen wordt dit aspera product gebruikt?
Ik kan het nergens in de standaard koppelingen vinden.
Alleen in bijzondere gevallen met uitwisseling van echt grote hoeveelheden.
- Het achterliggende protocol hoeft niet de jouw bekende techniek te zijn.
https://www.ibm.com/downloads/cas/QGRQMREW
"Once the secure session channel is established, the transfer endpoints authenticate using SSH. Both password and public-key authentication with passphrase-protected keys are supported"

Once SSH authentication has completed, the Aspera FASP transfer session performs a three-way handshake during which the client endpoint generates a random per-session AES key for data encryption (supporting sizes of 128, 192, and 256 bits), and sends these keys to the server endpoint over the secure SSH channel. A new encryption key is generated for each Aspera FASP transfer session, and the key is never stored on disk.
"
07-03-2020, 10:34 door Anoniem
Door Erik van Straten:
Door Anoniem: Was jij dan niet die prutser, die eerst de verkeerde software installeren?
Aanvankelijk vond ik dit ook verwarrend, want de belastingdienst heeft het op meerdere pagina's over de "IBM Aspera Connect client, in https://filetransfer.belastingdienst.nl/info/pages/filetransferbasics.html.nl?ver=2.3 wordt "Client" zelfs 2x met een hoofdletter geschreven (vette en cursieve opmaak na "Let op!!" toegevoegd door mij):
Precies zo ben ik ook op het verkeerde been gezet. Bedenk dat ik in onze kantooromgeving een mail krijg van de
boekhouder met "we lopen tegen dit probleem aan" met een link erbij waar je dan een pagina krijgt waar je eigen files
op staan en een "klik hier om de client te downloaden of download deze bij IBM blabla". De URL van die pagina is
wel 120 tekens lang. Ik pak er dus een 2e computer bij en ga daar naar die IBM site zoeken naar de betreffende
software (dus niet via die link) en download en installeer die (want ik kan niet knippen en plakken tussen die 2 computers
zonder moeilijk gedoe, dat heb ik later pas gedaan). Dat was dan dus de "desktop client" en dit is het programma
wat in java geschreven is en standalone werkt (met zo'n bekende foeilelijke Java GUI). Daar kan het volgens mij in
principe ook wel mee, want als ik de juiste host en onze NLxxxx naam invoer dan krijg ik "authentication error" omdat
ik niet het juiste password weet, en verander ik die NLxxxx naam dan komt er een andere fout. Dus ik denk dat als
ik het juiste password zou weten ik gewoon op diezelfde pagina uit zou komen en die files kon downloaden.
(dit programma werkt met de bekende 2-window view van je lokale en de remote directory waar je dan files tussen
kunt verplaatsen)

De Aspera Connect client is denk ik gewoon een andere interface naar hetzelfde protocol die dan usernaam en
password aanlevert via een of andere javascript truuk ofzo, want onze NLxxxx naam en het password staan niet
zichtbaar in de URL van die webpagina.
07-03-2020, 10:58 door The FOSS
Door Anoniem:
Door karma4: Nog wel een vraag....
Waar komt het vandaan dat aspera verplicht is?
Bedrijven gebruiken verplicht xbrl.
Dit is voor ad hoc file transfers, dus voor dingen die buiten de normale uitwisseling van gegevens vallen.
https://filetransfer.belastingdienst.nl/info/pages/howdoesitwork.html.nl?ver=2.3

Aha, dan kan ik me de keuze voor deze software goed voorstellen. Want bij ad hoc file transfers kan er sprake zijn van grote bestanden en het via publieke diensten als WeTransfer sturen is natuurlijk not done.
07-03-2020, 11:28 door Anoniem
Door The FOSS:
Aha, dan kan ik me de keuze voor deze software goed voorstellen. Want bij ad hoc file transfers kan er sprake zijn van grote bestanden en het via publieke diensten als WeTransfer sturen is natuurlijk not done.
Het feit dat een dienst als WeTransfer gewoon goed werkt (zonder specifieke lokale software) geeft al aan dat dat "grote bestanden" argument totaal bogus is. Blijft alleen over het argument van beveiliging en privacy, en de studie van Erik geeft aan dat het risico daar met gebruik van Aspera Connect juist hoger wordt.

Het is erg makkelijk om managers onder de indruk te brengen met algemene kreten als
the Aspera FASP transfer session performs a three-way handshake during which the client endpoint generates a random per-session AES key for data encryption (supporting sizes of 128, 192, and 256 bits), and sends these keys to the server endpoint over the secure SSH channel. A new encryption key is generated for each Aspera FASP transfer session, and the key is never stored on disk
zoals hierboven genoemd, maar dit zegt nog helemaal niks over hoe veilig het nou eigenlijk is.
(en bovendien is het ook nog eens niks bijzonders, iedere https verbinding doet dit al)

Of je speciale maatregelen moet nemen voor grote transfers hangt af van de grootte van de bestanden gedeeld door het product van de typisch bij de klant beschikbare verbindingssnelheid en de faalkans van de verbinding. "vroeger" hadden we al "downloadmanagers" om een file van 10MB te kunnen downloaden, wat een half uur duurde met je supermoderne 56k modem. Waarbij de verbinding er ieder moment uit kon knallen. Dan was het wel leuk om een resume te kunnen doen.
Maar tegenwoordig heeft niemand meer problemen om files van een paar GB te downloaden via hun vaste internet verbinding, en de bedrijven (waar de belastingdienst dit op richt) al helemaal niet.
Plus dat files van meerdere GB groot is al niet erg vaak zullen voorkomen. Bedenk dat het hier niet gaat om films ofzo maar om typische boekhoudkundige informatie. Zoals al vermeld, de file waar het allemaal om ging was 111KB voor een bedrijf met 1600 medewerkers, stel het bedrijf was 160000 medewerkers dan zou ie wellicht 11MB geweest zijn. No problem.
07-03-2020, 11:42 door Anoniem
Door The FOSS: Aha, dan kan ik me de keuze voor deze software goed voorstellen. Want bij ad hoc file transfers kan er sprake zijn van grote bestanden en het via publieke diensten als WeTransfer sturen is natuurlijk not done.
Nee, maar de webinterface van de belastingdienst moet goed genoeg beveiligd zijn om up- en downloads van vertrouwelijke gegevens te kunnen doen.

Het zal hier niet om verbijsterend grote bestanden gaan, maar domweg over wat ze niet via e-mail ondersteunen. Ze hanteren een limiet van 16MB per e-mail en hebben een lijst extensies die hun e-mailsysteem weigert:
https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/standaard_functies/prive/contact/per_brief_of_email/voorwaarden_e-mailen/bestanden_die_wij_niet_kunnen_ontvangen/bestanden_die_wij_niet_kunnen_ontvangen

Inhoudelijk zal het gaan om bijvoorbeeld het onderbouwen van een aangifte met documenten. De oorspronkelijke topic starter had het over gegevens rond loonbelasting. Dan heb je het over persoonsgegevens, die beslist vertrouwelijk moeten worden behandeld, maar als de belastingdienst dat in hun webinterface niet aankan dan kunnen ze ook geen online belastingaangiftes aan.
07-03-2020, 12:21 door karma4 - Bijgewerkt: 07-03-2020, 12:24
Door The FOSS: Aha, dan kan ik me de keuze voor deze software goed voorstellen. Want bij ad hoc file transfers kan er sprake zijn van grote bestanden en het via publieke diensten als WeTransfer sturen is natuurlijk not done.
Zijn we het over eens. Komt bij: je wilt de boel centraal gelogd gemonitored hebben voor als er lastige vragen komen.

De algemene optie was email naar een medewerker van ze die additionele informatie wil.
Niet de bedoeling dat je dan gaat spammen met andere zaken naar zo iemand. Velen begrijpen dat niet. Ik kan me voorstellen dat er dan een reactie op gang komt om achter iets meer anoniems te gaan zitten.

Ik kan best begrijpen dat de keuze voor dat IBM product vraagtekens oproept. He tis een leverancier met een flinke vinger in de beslisketen. Over het algemeen zijn hun producten best goed, bij de uitrol kom je bij wat anders intern.
07-03-2020, 17:04 door Anoniem
Door Anoniem:
Door The FOSS: Aha, dan kan ik me de keuze voor deze software goed voorstellen. Want bij ad hoc file transfers kan er sprake zijn van grote bestanden en het via publieke diensten als WeTransfer sturen is natuurlijk not done.
Nee, maar de webinterface van de belastingdienst moet goed genoeg beveiligd zijn om up- en downloads van vertrouwelijke gegevens te kunnen doen.

Het zal hier niet om verbijsterend grote bestanden gaan, maar domweg over wat ze niet via e-mail ondersteunen. Ze hanteren een limiet van 16MB per e-mail en hebben een lijst extensies die hun e-mailsysteem weigert:
Het heeft niks te maken met de soort of grootte van bestanden, dit is gewoon een "manier van werken" die hen
ongetwijfeld van hogerhand ingepeperd is: bestanden stuur je niet per mail maar zet je klaar in onze beveiligde omgeving
waar de klant het kan ophalen.
Ik denk (gezien de mailwisseling) dat in dit geval het bestand ook niet "door een medewerker van de belastingdienst
gestuurd is" maar dat er als gevolg van een contact met de belastingdienst door die medewerker een of andere opdracht
aan een batchproces gegeven is (het terrein van karma4 zeg maar) wat een bestand heeft opgeleverd wat automatisch
geplaatst is in het filetransfer gebied wat aan ons bedrijf is toegewezen, waar we het dus kunnen ophalen.
Maar de toegang tot dat gebied gaat gewoon via een lange ingewikkelde URL en is dus in feite niets anders dan een
willekeurige website met CMS en beveiligde verbinding (https). Iedereen die op de een of andere manier achter die
URL komt kan dit bestand in principe ophalen. Als ie er op tijd bij is, want er staat een "datum beschikbaar tot" bij
waarna het natuurlijk automatisch wordt weggegooid.

Kijk zoals al eerder uitgelegd snap ik best dat er aan de kant van de server allerlei speciale software nodig is om dit
allemaal in goede banen te leiden. Laat IBM/Asperasoft dat vooral maken en verkopen, daar is vast een markt voor.

Maar laat alsjeblieft die "speciaal protocol met allerlei truukjes voor optimalisatie van resume en packetloss" ellende
die een lokaal stuk software vereist weg! Daar hebben we helemaal geen behoefte aan en HET GEEFT PROBLEMEN.

Gelukkig begreep ik uit een antwoord van de belastingdienst dat men dat daar ook wel inziet. En dat er naar gekeken
wordt om dit later in dit jaar te veranderen. Wie weet wordt dit zelfs bespoedigd nu er iemand (Erik) een melding gedaan
heeft dat het onveilig is....
07-03-2020, 19:57 door Anoniem
Door Anoniem: Iedereen die op de een of andere manier achter die URL komt kan dit bestand in principe ophalen.
Dan is zelfs duidelijk veiliger om het te integreren in het aanlogdeel van de website.
Gelukkig begreep ik uit een antwoord van de belastingdienst dat men dat daar ook wel inziet. En dat er naar gekeken
wordt om dit later in dit jaar te veranderen.
Kijk aan.
08-03-2020, 06:59 door The FOSS - Bijgewerkt: 08-03-2020, 07:05
Door Anoniem:
Door The FOSS:
Aha, dan kan ik me de keuze voor deze software goed voorstellen. Want bij ad hoc file transfers kan er sprake zijn van grote bestanden en het via publieke diensten als WeTransfer sturen is natuurlijk not done.
Het feit dat een dienst als WeTransfer gewoon goed werkt (zonder specifieke lokale software) geeft al aan dat dat "grote bestanden" argument totaal bogus is.

Het is een werkende oplossing maar wellicht zijn er andere of aanvullende eisen.

Door Anoniem:
Door Anoniem: Iedereen die op de een of andere manier achter die URL komt kan dit bestand in principe ophalen.
Dan is zelfs duidelijk veiliger om het te integreren in het aanlogdeel van de website.
Gelukkig begreep ik uit een antwoord van de belastingdienst dat men dat daar ook wel inziet. En dat er naar gekeken
wordt om dit later in dit jaar te veranderen.
Kijk aan.

Ja, ja. Ik zou net zo goed kunnen zeggen dat ik zojuist uit een antwoord van de belastingdienst heb begrepen dat er zwaar wordt ingezet op het Java EE platform. (Met dank aan Kraak.)
08-03-2020, 08:00 door karma4 - Bijgewerkt: 08-03-2020, 08:08
Door Anoniem:
Door Anoniem: Iedereen die op de een of andere manier achter die URL komt kan dit bestand in principe ophalen.
Dan is zelfs duidelijk veiliger om het te integreren in het aanlogdeel van de website....
Nou nee, een website - webserver is notoir onveilig. Dit soort tools, er zijn er meer, ontkoppelen dat juist zodat er nergens een url naar dat bestand kan werken. De webserver in een DMZ maar de echte data elders.
Die datum beschikbaar tot is een mechanisme in dat aparte gebeid. Een beetje zoals een document management systeem werkt.

Onverlet dat als ze zoiets neerzetten met allerlei eigen instructies dat het dan overal buiten zonder extra code moet werken. Een ander product dat je kan tegenkomen is: https://www.cryptshare.com/nl/start/
"Voorbeelden van populaire cloud oplossingen zijn Wetransfer of Dropbox. Met deze alternatieve systemen wordt naast het standaard mailprogramma een tweede vorm van communicatie geïntroduceerd. Ook wel Shadow IT genoemd." Een usb sticky over de post lijkt me niet echt geslaagd.
08-03-2020, 08:37 door Anoniem
Door karma4: Nou nee, een website - webserver is notoir onveilig. Dit soort tools, er zijn er meer, ontkoppelen dat juist zodat er nergens een url naar dat bestand kan werken. De webserver in een DMZ maar de echte data elders.
Een webserver kan met backend-systemen communiceren en de bestanden hoeven helemaal niet op de webserver zelf of in het DMZ opgeslagen te worden, de datastroom loopt daar alleen maar langs. Zo'n opzet verschilt niet qua beveiliging van wat ze al doen, het verschil zit hem in de omvang van requests en responses en in de manier waarop de afhandeling ervan gecodeerd is.

De details zullen afhangen van het gebruikte framework en de gebruikte programmeertaal, maar de ene TCP-datastroom doorschrijven naar de andere is in essentie niet meer dan een simpele loop waarin je data met een zelf gekozen maximale blokgrootte uit de ene stroom leest en naar de andere stroom schrijft. Dat kan in beide richtingen, voor uploads en downloads, en foutafhandeling is ook goed te regelen. Dit kan gewoon, met basale programmeertechnieken. Hier is echt niets bijzonders aan.

Als een webserver notoir onveilig is, zoals je beweert, wat vind je dan van het feit dat de belastingdienst online aangiftes via een webserver laat lopen? En online bankieren? Zelfde probleem. DigID? Onbruikbaar, dat praat ook al met een server, notoir onveilig.
08-03-2020, 09:57 door The FOSS - Bijgewerkt: 08-03-2020, 10:18
Door Anoniem: Als een webserver notoir onveilig is, zoals je beweert, wat vind je dan van het feit dat de belastingdienst online aangiftes via een webserver laat lopen? En online bankieren? Zelfde probleem. DigID? Onbruikbaar, dat praat ook al met een server, notoir onveilig.

Je neemt die uitspraak toch niet serieus? Zoals je zelf aangeeft worden er op grote schaal serieuze toepassingen met webservers geïmplementeerd. Door mensen die er wél verstand van hebben.
08-03-2020, 11:35 door karma4
Door The FOSS:
Door Anoniem: Als een webserver notoir onveilig is, zoals je beweert, wat vind je dan van het feit dat de belastingdienst online aangiftes via een webserver laat lopen? En online bankieren? Zelfde probleem. DigID? Onbruikbaar, dat praat ook al met een server, notoir onveilig.

Je neemt die uitspraak toch niet serieus? Zoals je zelf aangeeft worden er op grote schaal serieuze toepassingen met webservers geïmplementeerd. Door mensen die er wél verstand van hebben.
Een webserver is notoir onveilig. Mensen die er verstand van hebben zetten er dan ook wat achter. Die DMZ hou je zo leeg mogelijk. https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties/ICT-Beveiligingsrichtlijnen-voor-Webapplicaties-Verdieping-Leesversie.pdf
Let even op de toelichtingen met dmz. Als je dat soort kennis als basis mist snap je niets van informatieveiligheid.
Goed de heren evangelisten vinden dat het ncsc niet serieus te nemen is, omdat zij het wel beter weten.
08-03-2020, 11:38 door Erik van Straten
Door karma4:
Door Erik van Straten: ..maar dan snap ik niet dat je deze software (met ingetrokken certificaat), 3 maanden later, nog steeds kunt downloaden - zonder dat er een alternatieve houdbare oplossing voor bedacht en gemaakt is.

Je mist twee belangrijke punten:
- in welke gevallen wordt dit aspera product gebruikt?
Ik kan het nergens in de standaard koppelingen vinden.
Alleen in bijzondere gevallen met uitwisseling van echt grote hoeveelheden.
In https://www.security.nl/posting/646555/Aspera+Client+verplicht+voor+downloaden+bij+de+belastingdienst___ kun je lezen dat iemand verplicht wordt (door de Belastingdienst) om dit te gebruiken. Om dit goed te laten werken moet je overigens ook een browser extension installeren, voor Firefox: https://addons.mozilla.org/en-US/firefox/addon/ibm-aspera-connect/?src=search. Nb. "This is not a Recommended Extension. Make sure you trust it before installing". Deze software heeft onbeperkte rechten in jouw browser waaronder "Exchange messages with programs other than Firefox". Dat zorgt ervoor dat "asperaconnect.exe" op jouw PC door een webpage gestart kan worden (dit gebeurt o.a. als je https://test-connect.asperasoft.com/ opent, en als je die file met de inhoud van notepad.exe in dezelfde map overschrijft, start notepad).

Overigens wezen mijn tests met https://test-connect.asperasoft.com/ uit dat bij de communicatie tussen de webapplicatie en de Aspera connect software gecommuniceerd wordt met http://127.0.0.1:33003/ - op basis van instructies in "asperaweb-4.min.js"; hier wordt dus geen gebruik gemaakt van https en de "local.connectme.us" truc. Wat de Belastingdienst de browser van de gebruiker laat doen weet ik niet.

Door karma4: - Het achterliggende protocol hoeft niet de jouw bekende techniek te zijn.
https://www.ibm.com/downloads/cas/QGRQMREW
"Once the secure session channel is established, the transfer endpoints authenticate using SSH. Both password and public-key authentication with passphrase-protected keys are supported"
Ik hoop dat het zo werkt als wordt uitgelegd in de (webonvriendelijke) presentatie van de Belastingdienst, te vinden in https://filetransfer.belastingdienst.nl/info/pages/connectclientdetail.html.nl?ver=2.3. Die presentatie vereist een heel breed scherm, anders wordt de knop "Volgende" niet getoond. Omdat de Belastingdienst dingen niet graag makkelijker maakt, doe ik dat maar - want die presentatie bestaat uit 9 plaatjes van 1920x1080 pixels. Die plaatjes kun je (in elk geval op dit moment) ook los bekijken - geschaald door jouw brouwser, dus ook op een scherm met lagere resolutie:

1: https://filetransfer.belastingdienst.nl/info/images/clientdetail1.png
2: https://filetransfer.belastingdienst.nl/info/images/clientdetail2.png
3: https://filetransfer.belastingdienst.nl/info/images/clientdetail3.png
4: https://filetransfer.belastingdienst.nl/info/images/clientdetail4.png
5: https://filetransfer.belastingdienst.nl/info/images/clientdetail5.png
6: https://filetransfer.belastingdienst.nl/info/images/clientdetail6.png
7: https://filetransfer.belastingdienst.nl/info/images/clientdetail7.png
8: https://filetransfer.belastingdienst.nl/info/images/clientdetail8.png
9: https://filetransfer.belastingdienst.nl/info/images/clientdetail9.png

In plaatje 2 zie je dat verbinding wordt gemaakt met local.connectme.us met IP-adres 127.0.0.1 op poort 43003. Dat is waar ik op aansloeg. Certificaten zijn er voor authenticatie. Als een private key gelekt wordt (zeker als iedereen deze kan downloaden in een softwarepakket), is een certificaat waardeloos en hoort te worden ingetrokken.

In plaatje 5 zie je dat sleutels tussen de (volgens jou "notoir onveilige") webserver en webbrowser worden uitgewisseld, waarna (in plaatje 6) de browser de sleutels aan de Aspera Connect software geeft.

Ik hoop maar dat hierbij geen gebruik gemaakt wordt van de met de software meegeleverde private keys. Als je https://test-connect.asperasoft.com/ start krijg je een foutmelding als de file
Aspera Connect\etc\asperaweb_id_dsa.openssh ontbreekt, maar de test verliep wel goed nadat ik een leeg exemplaar van die file had aangemaakt (kennelijk wordt deze niet gebruikt).

Onder andere exact diezelfde (op CRLF vs LF regeleindes na) SSH private key is, zo te zien al 9 jaar, onversleuteld te vinden op internet: https://github.com/mlangill/MicrobeDB/blob/master/scripts/aspera_32/connect/etc/asperaweb_id_dsa.openssh.

Ook wordt er een private key + CA rootcertificaat (self-signed dus) meegeleverd voor "IBM Corp." - waarvan ik niet heb kunnen vaststellen dat dit geïnstalleerd wordt (in de certificate stores van Firefox en Windows).

Waarom worden in software, die je maar moet vertrouwen, private keys (en een root certificaat) meegestuurd? Softwareontwikkelaars die zo omgaan met security, vertrouw ik verder ook voor geen meter. Ook al worden rootcerts niet geïnstalleerd en private keys alleen voor tests gebruikt (zoals wellicht de private key voor het certificaat van local.connectme.us).
08-03-2020, 11:52 door The FOSS - Bijgewerkt: 08-03-2020, 11:54
Door karma4:
Door The FOSS:
Door Anoniem: Als een webserver notoir onveilig is, zoals je beweert, wat vind je dan van het feit dat de belastingdienst online aangiftes via een webserver laat lopen? En online bankieren? Zelfde probleem. DigID? Onbruikbaar, dat praat ook al met een server, notoir onveilig.

Je neemt die uitspraak toch niet serieus? Zoals je zelf aangeeft worden er op grote schaal serieuze toepassingen met webservers geïmplementeerd. Door mensen die er wél verstand van hebben.
Een webserver is notoir onveilig. Mensen die er verstand van hebben zetten er dan ook wat achter. Die DMZ hou je zo leeg mogelijk. https://www.ncsc.nl/binaries/ncsc/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties/ICT-Beveiligingsrichtlijnen-voor-Webapplicaties-Verdieping-Leesversie.pdf
Let even op de toelichtingen met dmz. Als je dat soort kennis als basis mist snap je niets van informatieveiligheid.
Goed de heren evangelisten vinden dat het ncsc niet serieus te nemen is, omdat zij het wel beter weten.

De robuuste webservers voor de beschreven dienstverlening (DigID, internetbankieren, etc.) hangen natuurlijk gewoon aan internet. Duh. Jouw DMZ verhaal speelt zich in een heel andere - hier niet ter zake doende - context af. Waarmee je wederom duidelijk demonstreert er geen verstand van te hebben; q.e.d. Een minder fijnbesnaard persoon dan ik zou zeggen "houd toch je mond, dwaas!"
08-03-2020, 12:22 door karma4 - Bijgewerkt: 08-03-2020, 12:25
Door The FOSS:
De robuuste webservers voor de beschreven dienstverlening (DigID, internetbankieren, etc.) hangen natuurlijk gewoon aan internet. Duh. Jouw DMZ verhaal speelt zich in een heel andere - hier niet ter zake doende - context af. Waarmee je wederom duidelijk demonstreert er geen verstand van te hebben; q.e.d. Een minder fijnbesnaard persoon dan ik zou zeggen "houd toch je mond, dwaas!"

Die DMZ is de basis waar het om gaat. Netwerksegmentatie monitoring en meer. Jij zou met een USB en algemene locatie waar iedereen van alle in mag dumpen komen. Je hebt weinig begrepen van alle commotie van een falende ICT.
Je hangt dat soort basisverwerkingen niet zo maar aan internet. Dat je dat wel zo wilt voorstellen is te gek voor woorden.
"De DMZ vormt de scheiding tussen het internet enerzijds en het interne netwerk anderzijds. Op alle snijvlakken (internet-DMZ en DMZ intern netwerk) worden beperkte verkeersstromen toegestaan, waardoor het risico op het binnendringen van het interne netwerk via het internet zo laag mogelijk wordt gehouden."
08-03-2020, 12:34 door karma4 - Bijgewerkt: 08-03-2020, 12:36
Door Erik van Straten: ….
In plaatje 2 zie je dat verbinding wordt gemaakt met local.connectme.us met IP-adres 127.0.0.1 op poort 43003. Dat is waar ik op aansloeg. Certificaten zijn er voor authenticatie. Als een private key gelekt wordt (zeker als iedereen deze kan downloaden in een softwarepakket), is een certificaat waardeloos en hoort te worden ingetrokken. ...
Daar heb je goede punten. Het ontwerp via aparte sleutels met een eerdere SSH sessie lijkt me goed. Het verlegt wel een probleem voor sleutels naar die SSH sessie. Wat me ook nog tegenstaat in de BD plaatjes is die fallback naar https, dat is geen duidelijke keuze. Genoeg aandachtspunten in de betreffende configuratie van het product. Ik twijfel of het grondig is doorgelopen op dat soort aspecten. De prioriteitsstelling bij uitrollen van dat soort producten is soms nogal wonderlijk.
08-03-2020, 12:45 door Anoniem
Door karma4: Een webserver is notoir onveilig. Mensen die er verstand van hebben zetten er dan ook wat achter. Die DMZ hou je zo leeg mogelijk.
Weet je, deze hele onzinnige discussie begon met iets wat helemaal niet in tegenspraak is met het gebruik van een DMZ. Je kan file up- en downloads net zo goed als andere interacties via een webserver in een DMZ leiden naar een backend-systeem op een beter afgeschermd netwerk. Je nam kennelijk aan dat file transfers vereisen dat de files op de webserver zelf opgeslagen worden. Dat hoeft helemaal niet.

Dat is je al uitgelegd. Misschien moet je die uitleg tot je laten doordringen voor je verder gaat met reageren, hij is korter en simpeler dan het document waarnaar je verwijst.

En natuurlijk zijn webservers niet notoir onveilig. Een DMZ dient niet om ontbrekende veiligheid te compenseren, een DMZ dient om er een paar schepjes bovenop te doen. Een webserver die notoir onveilig is zou die extra beveiliging grondig onderuit trekken, dus notoir onveilige webservers hebben geen plaats in het geheel.

Dat kan je uit het document halen waar je zelf naar linkt, als je begrijpend leest in plaats van je op een paar buzzwords te richten.
08-03-2020, 13:26 door karma4
Door Anoniem: ….
Dat kan je uit het document halen waar je zelf naar linkt, als je begrijpend leest in plaats van je op een paar buzzwords te richten.
Lees het betreffende document nog maar eens met de opmerkingen dat het plaatsen van bestand bereikbaar via een url die je kan vinden net zo makkelijk zou zijn. Laat het eens even bezinken …. misschien valt er toch nog dat kwartje.
08-03-2020, 13:27 door Anoniem
Door karma4: Die DMZ is de basis waar het om gaat. Netwerksegmentatie monitoring en meer.
Je doet alsof dat het enige is. Een goed ingericht DMZ is essentieel, maar de web facing servers die je erin plaatst, met de webapplicaties die erop draaien, moeten bepaald niet "notoir onveilig" zijn, want als ze dat zijn heb je zo een aanvaller in je DMZ en verliest je basis zijn waarde. Dat is dus ook essentieel, en dus ook onderdeel van de basis.

Je hangt dat soort basisverwerkingen niet zo maar aan internet. Dat je dat wel zo wilt voorstellen is te gek voor woorden.
Niemand heeft het belang van een DMZ weersproken, wat weersproken werd is dat webservers notoir onveilig zijn. Als ze dat zijn hebben ze geen plaats in een infrastructuur als die van de belastingdienst - of in welke infrastructuur dan ook.

Wat je hier doet is iets evident onzinnigs roepen ("webservers zijn notoir onveilig") en iets anders inbrengen (DMZ), en als het eerste tegengesproken wordt ertegenin gaan alsof het tweede werd tegengesproken, en dan kan jij weer doen alsof je alles beter snapt dan de rest hier.

Man, man, man, ga toch eens een normale discussie voeren in plaats van dit soort rare spelletjes te spelen. Of geloof je werkelijk dat het belang van een DMZ door wie dan ook hier werd ontkend?
08-03-2020, 14:49 door Anoniem
Door karma4: Lees het betreffende document nog maar eens met de opmerkingen dat het plaatsen van bestand bereikbaar via een url die je kan vinden net zo makkelijk zou zijn. Laat het eens even bezinken …. misschien valt er toch nog dat kwartje.
Tjonge, jonge, jonge. Je zegt dit tegen iemand die dat soort dingen gebouwd heeft. Niet recent, maar de basis waarop de huidige frameworks gebouwd zijn is niet fundamenteel veranderd, het web is nog steeds op HTML en HTTP(S) gebaseerd, er zijn verbeteringen in aangebracht maar de essentie van hoe downloads en uploads worden afgehandeld is niet veranderd.

En voor de duidelijkheid: toen ik het bouwde stonden de betrokken webservers ook in een DMZ en de backend-servers in een ander netwerksegment, keurig in overeenstemming met het plaatje in die richtlijn. Ook dat is niet wezenlijk veranderd.

Dus dat ik zeg dat het makkelijk zou zijn heeft een basis, het is in essentie een makkelijk te bouwen functie. Zo makkelijk dat ik met wat ik toevallig op mijn pc voorhanden heb een Q&D proof-of-concept in elkaar kon flansen om te bevestigen dat je met hedendaagse webontwikkel-hulpmiddelen inderdaad op de beschreven manier stromen kan doorschrijven en zo uploads en downloads kan afhandelen.

Jij maakt meer dan duidelijk dat je hoog van de toren blaast zonder dat je ooit eigenhandig zoiets geïmplementeerd hebt. Als je dat gedaan had zou je namelijk niet van die onzin uitkramen. Dan zou je snappen waar die richtlijn die je aanhaalt eigenlijk over gaat, dan zou je snappen dat niet alleen een DMZ belangrijk is maar dat de servers die erin staan beslist niet "notoir onveilig" mogen zijn wil het geheel veilig zijn, en dan zou je snappen dat file up- en downloads met hetzelfde veiligheidsniveau afgehandeld kunnen worden als elk ander onderdeel van een webapplicatie waaraan mensen aanloggen, gewoon gebruikmakend van dezelfde frameworks die daarvoor gebruikt worden.

Laat het eens even bezinken …. misschien valt er toch nog dat kwartje.
08-03-2020, 15:59 door Aurik
Door karma4:
Door Anoniem:
Door Anoniem: Iedereen die op de een of andere manier achter die URL komt kan dit bestand in principe ophalen.
Dan is zelfs duidelijk veiliger om het te integreren in het aanlogdeel van de website....
Nou nee, een website - webserver is notoir onveilig.
Ik denk dat je beter kunt stellen dat je een webserver niet kunt vertrouwen.

Dit soort tools, er zijn er meer, ontkoppelen dat juist zodat er nergens een url naar dat bestand kan werken. De webserver in een DMZ maar de echte data elders.
En waar denk je dat de Aspera servers staan? Die staan ook gewoon in een DMZ en waarschijnlijk ook nog eens een "webserver" zijn, immers de client kan ook verbinding maken op HTTPS.
08-03-2020, 18:35 door Erik van Straten
Het huidige certificaat voor local.connectme.us en de bijbehorende private key zijn al op 3 december gepubliceerd in https://pastebin.com/1qupxAUv (ruim 90 dagen geleden dus, zie ook https://security.nl/posting/647168).

Bronnen: https://www.theregister.co.uk/2019/12/05/atlassian_zero_day_bug/ en een discussie tussen SwiftOnSecurity, Tavis Ormandy en Tim Stone in https://mobile.twitter.com/taviso/status/1202102617595244544.
08-03-2020, 20:51 door karma4
Door Aurik: ...
En waar denk je dat de Aspera servers staan? Die staan ook gewoon in een DMZ en waarschijnlijk ook nog eens een "webserver" zijn, immers de client kan ook verbinding maken op HTTPS.
Kern van de zaak: je zet geen gevoelige gegevens op wat in de DMZ staat. Net zo min als een RDP naar een willekeurig werkstation of interne server moet willen. Gebruik er iets voor in een DNZ zoals een Citrix gateway.
08-03-2020, 20:55 door karma4
Door Anoniem: ... Dan zou je snappen waar die richtlijn die je aanhaalt eigenlijk over gaat, dan zou je snappen dat niet alleen een DMZ belangrijk is maar dat de servers die erin staan beslist niet "notoir onveilig" mogen zijn wil het geheel veilig zijn, en dan zou je snappen dat file up- en downloads met hetzelfde veiligheidsniveau afgehandeld kunnen worden als elk ander onderdeel van een webapplicatie waaraan mensen aanloggen, gewoon gebruikmakend van dezelfde frameworks die daarvoor gebruikt worden. ...
Laat het eens even bezinken …. misschien valt er toch nog dat kwartje.
Ook daaraan gewerkt en bewust van de risico's en gaten me wat er gebeurde. Niet enkele dat de functie werkt (PM blij) maar dat het echt gecontroleerd veilig werkt, baas niet blij want kost te veel.
Je maakt mee dan duidelijk waar het gebrek een besef van wat veilig is vandaan komt.
09-03-2020, 06:15 door The FOSS - Bijgewerkt: 09-03-2020, 06:18
[verwijderde door misedit geposte tekst]
Zóó handig op een mobiel apparaat, deze site...
09-03-2020, 06:15 door The FOSS - Bijgewerkt: 09-03-2020, 06:47
Door karma4: Jij zou met een USB en algemene locatie waar iedereen van alle in mag dumpen komen. Je hebt weinig begrepen van alle commotie van een falende ICT.

Wat nou weer met 'usb sticks' gaan rondlopen? Hoe kom je erbij dat ik dat zou willen?

Door karma4: Je hangt dat soort basisverwerkingen niet zo maar aan internet. Dat je dat wel zo wilt voorstellen is te gek voor woorden.

Nee, dwaas, ik heb - als reactie op jouw webservers zijn notoir onveilig - niet meer gezegd dan dat de webserver - per definitie - direct aan internet hangt. De rest trek en verzin je er zelf bij! Inclusief je denigrerende commentaren, alsof jij hier de enige zou zijn die het allemaal begrijpt, terwijl - overduidelijk en daar word je door anderen ook op gewezen - jij eerder degene bent die het consequent niet begrijpt! Alsof je een aap een boek geeft. Hij 'leest' het en krijst er van alles over, maar begrijpt er vanzelfsprekend geen snars van. Maar wel eindeloos onzin blijven uitkramen.
09-03-2020, 11:05 door karma4
Door The FOSS:
Wat nou weer met 'usb sticks' gaan rondlopen? Hoe kom je erbij dat ik dat zou willen? ...
Nee, dwaas, ik heb - als reactie op jouw webservers zijn notoir onveilig - niet meer gezegd dan dat de webserver - per definitie - direct aan internet hangt. .....
Maar wel eindeloos onzin blijven uitkramen.
Zodra er maar iets zou zijn wat Open Source of Linux zou kunnen beschadigen dat het niet de ultieme oplossing is dan gaan de evangelisten met beledigingen volledig los. Wel triest en een bedreiging voor de informatieveiligheid.
Dat verhaal met usb sticks in gebruik bij de BD is je kennelijk ontgaan. Wat denk je wat voor alternatief ze daarvoor hebben.

De achterliggende vraag waar het hier om gaat is informatieuitwisseling in een niet gedefinieerd standaard proces.
Het is niet de aangifte of elk ander waarvoor hele ketens zijn opgezet. Hoe je die adhoc oplost is MADS (Mail, Agenda, Digitaal Samenwerken).Als je wat meer weet en meer gezien hebt krijg die keten te zien. ipv van een 3 moet je aan Lotus.
09-03-2020, 15:20 door Anoniem
Door karma4: Niet enkele dat de functie werkt (PM blij) maar dat het echt gecontroleerd veilig werkt, baas niet blij want kost te veel.
Heb jij eigenlijk ooit een professioneel geleid project meegemaakt? Kostenbeheersing valt onder projectmanagement. Als de kosten uit de hand lopen is PM echt niet blij.
09-03-2020, 15:41 door Anoniem
Door karma4: Je maakt mee dan duidelijk waar het gebrek een besef van wat veilig is vandaan komt.
Je moest eens weten... Maar zelfs als je het zou weten zou je het beter denken te weten, dus dat schiet niet op.
12-01-2021, 14:18 door Erik van Straten - Bijgewerkt: 12-01-2021, 15:05
Hoe het ondertussen met de IBM Aspera Connect Client gaat, weet ik niet, maar in "IBM Aspera High-Speed Transfer Server" en in "IBM Aspera High-Speed Transfer Endpoint", beide versie 3.9.6.2 en ouder, is sprake van een deserialization kwetsbaarheid met een CVSS score van 9.8: https://www.ibm.com/support/pages/node/6398290. Fix: stap over op versie 4.

Volgens mijn bron (Duitstalig, https://www.heise.de/news/IBM-veroeffentlicht-wichtige-Sicherheitsupdates-fuer-zahlreiche-Produkte-5021160.html) heeft IBM ook security-patches voor een reeks andere producten uitgebracht.

Ik kan zo snel niet vinden of Accellion Kiteworks (onder water) van dezelfde technologie gebruikmaakt (IBM Aspera, of FasterXML "Jackson-databind" - https://www.ncsc.nl/actueel/advisory?id=NCSC-2021-0012) of dat dit toeval is: https://www.security.nl/posting/685420/Datalek+centrale+bank+Nieuw-Zeeland+door+inbraak+bij+file+sharing+service.

Aanvulling: volgens https://i.stuff.co.nz/business/123921564/reserve-bank-hack-bank-may-not-have-applied-patch-in-time zou het lek bij de Reserve Bank van Nieuw Zeeland niets te maken hebben met KiteWorks van Accellion, maar met 20 jaar oude FTA (File Transfer Application of Appliance?) software waarvoor Accellion in december nog een patch zou hebben uitgebracht. Waarschijnlijk bestaat er dus geen verband tussen de kwetsbaarheid in Faster:XML's "Jackson-Databind" en de hack van de Nieuw Zeelandse bank.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.