Cookies op Tweakers

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

Meer informatie

Door , , 17 reacties

Symantec raadt gebruikers van zijn Endpoint Protection-software, SEP, aan om hun systemen te upgraden. Er zijn drie kwetsbaarheden aan het licht gekomen in het pakket voor centraal beheer van beveiligingssoftware voor bedrijfsomgevingen.

Symantec Endpoint protectionTwee van de bugs, een cross-site-scripting- en een sql-injectie-kwetsbaarheid, zitten in het beheerpaneel van SEP. Dat is via een browser benaderbaar, waarmee over een netwerk of lokaal op de SEP-managementserver ingelogd kan worden. Als een gebruiker ingelogd is via de console, kunnen hogere rechten verkregen worden via xss of sql-injectie.

De andere bug betreft een driver, SysPlant.sys. Via de bug in de driver is het mogelijk de beveiligingscontroles van SEP te omzeilen. Het gaat om beveiliging tegen het draaien van slechte of niet vertrouwde code op pc's binnen het netwerk waar SEP op actief is. Als de driver niet meer werkt, kan kwaadaardige code uitgevoerd worden.

Het advies van Symantec luidt zo snel mogelijk te upgraden naar versie 12.1 RU6 MP4 van Symantec Endpoint Protection. In deze versie zijn de kwetsbaarheden opgelost. Daarnaast adviseert het bedrijf de adminstrator-toegang tot de SEP-console zo veel mogelijk te beperken. Vooralsnog is niet bekend dat er misbruik gemaakt is van de kwetsbaarheden.

Moderatie-faq Wijzig weergave

Reacties (17)

Je ziet tegenwoordig steeds meer berichten verschijnen waarbij beveiligingspakketten in twijfel worden getroffen. Ze zitten vaak vol met lekken waardoor juist aanvallen mogelijk zijn, ze installeren een eigen certificaat om https verkeer te kunnen monitoren en vergroten daarmee juist de risico's. En dan hebben we het nog maar niet over wat ze missen, de false positives (onschuldige) en de false positives die het os om zeep helpen.

En dan mag je voor bovenstaande nog betalen ook, ik hou het wel bij defender, een adblocker en gezond verstand. Voor zakelijk omgevingen is dat gezonde verstand wat lastiger, daar zou ik derhalve eerder kiezen voor een goede netwerkbeveiling inclusief AV op zowel firewall als mailserver/spamfirewall.

[Reactie gewijzigd door Alexander_v_H op 18 maart 2016 16:12]

Dat laatste wat je beschrijft is wat dit pakket doet.
Het is 2016 en nog zijn SQL injecties mogelijk? En dat van een bedrijf als Symantec? ok...
Je hebt SQL injecties en SQL injecties. In dit geval was het de wat minder erge variant.

Om het even in context te plaatsen: je hebt de mogelijkheid om bijvoorbeeld een injection te doen in de vorm van de huidige query 'afsluiten' om vervolgens je malafide payload toe te voegen. Zover ik kan vinden met alle summiere informatie die beschikbaar is ging het in dit geval anders.

Ten eerste moest je al ingelogd zijn, om vervolgens middels een injectie jezelf extra rechten te geven. Wat ik dus denk is dat er een parameter veranderd kon worden zonder dat deze werd gecheckt. Hierdoor veranderde je de query (injection) maar kon je zeker niet een jimmy drop tables uitvoeren.
SQL injectie is SQL injectie, die zijn af te vangen. Als de front-end een fout maakt door het wijzigen van settings of privileges toe te staan is dat niet bepaald een SQL injectie. Dat Drop table niet werkt is vrij logisch, een beetje SQL server heeft dat op een productie omgeving uitstaan. Ik vind SQL injecties kinderfouten en onderdeel van security 101 want gebruikers moeten ten aller tijde nooit zelf toegang hebben tot de queries of deze kunnen manipuleren. Maar goed, dat ben ik.
Prima als gebruikers zelf custom queries kunnen maken, maar niet ongelimiteerd. Zorg dat die queries via een building mechanisme gemaakt worden zodat er niets ongewenst in kan komen, alleen is dat buildingmechanisme maken best wel wat werk en error-prone. Ik zie het in ieder geval geen gebruikelijke optie worden.
Stel de simpele vraag aan elke fatsoenlijke programmeur: Kun jij een applicatie maken die bug free is? Het antwoord moet gewoon consequent nee zijn. Zoiets bestaat niet. Iemand die anders beweerd heeft geen verstand van zaken. Nogmaals lees je de woordjes 'sql injections' een beetje scheef. Plaatst het in de juiste context :) Indien het een volledige sql injection was dan had het wel een hogere score gekregen en waren de gevolgen een factor 100 erger.

Hoewel je mening klopt dat sql injections zijn af te vangen, wilt dit nog niet per definitie zeggen dat je een applicatie hebt waar dit nooit kan gebeuren. Je hebt geen heilige graal die je include en alles voor je regelt. Iemand zal het toch zelf moeten programmeren. Zelfs met prepared statements kun je een foutje maken, én zelfs met 100% correcte prepared statements kun je sql injections krijgen.

Dat gezegd hebbende heeft symantec alles netjes opgelost. De juiste procedures gevolgd en zijn naar mijn mening de bugs niet schikbarend te noemen. We moeten gewoon accepteren dat bugs, hoe vervelend dan ook, gewoon voorkomen. Dit gebeurd bij iedereen: Google, MS, Apple en je standaard beunhaas. Het belangrijkste is om te weten hoe hier mee wordt omgegaan: Is de code goed leesbaar, beheerbaar en wordt er adequaat gereageerd op een bug?
...Je zou idd denken dat een bedrijf als Symantec een architectuur gebruikt die SQL injectie in beginsel onmogelijk maakt.
Ja, erg dom van Symantec. Maar ze zijn nog steeds mensen. En mensen maken fouten. :)
Je zou ook verwachten dat een programmeur geen fout maakt, helaas ook dat zijn gewoon mensen... :)

Waarschijnlijk gebruiken / vertrouwen ze op OTAP manier echter is dit niet altijd waterdicht, aangezien een Test ook altijd nog door een mens geschreven wordt.

[Reactie gewijzigd door xleeuwx op 18 maart 2016 16:01]

Wat heeft een OTAP straat hier nou weer mee te maken. Dit zou bij elke test opgemerkt moeten worden... Slecht programmeerwerk
Nee, dit zou je kunnen vinden met een code review. Testen van alle fout situaties kan niet met tijd. Zeker omdat er ook snel nieuwe features en nieuwe bescherming moeten worden gemaakt.
Ik dacht precies hetzelfde. Je zou anno nu verwachten dat het een van de eerste dingen is dat men controleert/blokkeert.
Je kan ze eigenlijk als beveiligsbedrijf niet geheel serieus nemen als ze dat soort "kinderlijke fouten" er nog in hebben zitten. Tis 2016, je zou verwachten dat een bedrijf als Symantec ook van andermans fouten al wel geleerd zou hebben.
Voor de bug op de console moet je al ingelogd zijn (= al een account hebben).

De bug in de client is enkel van toepassing als je een bepaalde feature gebruikt (Application and Device Control). Niet elk bedrijf zal deze feature gebruiken.

Er duiken wel vaker bugs op gerelateerd aan SEP(M). Symantec communiceert er altijd netjes over. Waarom deze nu net de frontpage halen? Gaan jullie voortaan ook elke week de bugs in Chrome breed uitsmeren? :)

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True