Joomla! en Mambo kwetsbaar door recyclen code
Onderzoekers hebben de afgelopen weken tientallen ernstige beveiligingslekken in uitbreidingen van de populaire content management systemen (CMS) Joomla! en Mambo ontdekt. De 30 SQL-injectie lekken werden allemaal door dezelfde parameter veroorzaakt en dat komt door het open karakter van de software. Beide systemen zijn open source, waardoor het publiek zelf uitbreidingen kan ontwikkelen.
Heeft men code nodig voor een bepaalde functie, dan is de kans groot dat die al een keer ontwikkeld is. Het enige dat men dan hoeft te doen is die code te kopiëren, waarmee ook eventuele problemen worden overgenomen en dat is iets waar de ontwikkelaars waarschijnlijk geen rekening mee hebben gehouden, zegt Debbie Mazurek van Symantec. In dit geval geven de kwetsbaarheden een aanvaller toegang tot de applicatie of database, wat aangeeft hoe gevaarlijk het kopiëren van andermans code kan zijn.
je zoiets doet, moet je inderdaad wel zeker zijn van het feit of de code veilig
is.
Ikzelf gebruik ook joomla op enkele websites. Maar zorg er wel voor dat de
site zelf zo veilig mogelijk is, door zo min mogelijk componenten actief te
houden, en de componenten die je gebruikt zoveel mogelijk te (laten)
controleren op beveiligingslekken.
Al mijn websites bestaan volledig uit eigen code. Code die ik
kan vertrouwen.
En wie controleert jouw code?
vraagt...... NATUURLIJK is het implementeren van
'verkeerde' code.... verkeerd.
Maar zou zou je ook kunnen stellen:
Vista en MS Office kwetsbaar door MS Update / downloaden
vanaf 'onbetrouwbare' locatie (URL)
Dus Redactie werk aan de winkel, ik zal de aanzet doen;
gebruikers hebben de afgelopen periode tientallen ernstige
beveiligingslekken voor hun kiezen gekregen door...... ;)
fatsoenlijke DB klasse zou laten gaan maar neeeeee elke module lult
natuurlijk zelf met de database.
[disclaimer: nog nooit gebruikt dat hele joomla/mambo maar ik zie zo snel
even geen andere reden]
Dus Redactie werk aan de winkel, ik zal de aanzet doen;
gebruikers hebben de afgelopen periode tientallen ernstige
beveiligingslekken voor hun kiezen gekregen door...... ;)
Open source. Denk maar aan de vele andere php rommel.
Precies de reden waarom ik NOOIT zo'n CMS zou gebruiken. Al
mijn websites bestaan volledig uit eigen code. Code die ik
kan vertrouwen.
Wij van WC-Eend vertrouwen alleen WC-Eend. Whahahaha....
Hugo,
doe eens een linkje naar een website van jou dan?
Goed bezig.
Overigens, als hergebruik werkelijk aan de basis van het
probleem ligt - en het hergebruik is goed gedaan - dan is 1
fix genoeg. Zo niet, dan heb je tot 30 gelijke fixes nodig.
Maakt natuurlijk geen moer uit of het open of gesloten is.
Hoe vaak wordt in de gesloten wereld niet net zo goed 'oh,
daar heb ik nog wat voor liggen' en 'hmm, dat lijkt op'
toegepast?
Als je zo zeker van je zaak bent moet je gewoon je URLs hier
neer pleuren , en de scriptkiddies ook een pleziertje geven.
geschreven op de dag van de exploit releases ruim 2 weken
geleden: http://www.0x000000.com/index.php?i=506
:)
Hugo Leisink? schrijver van Hiawatha?
hint: integer overflows zitten niet alleen in ints.
code ziet er nice uit, maar secure is anders.
dezelfde parameter veroorzaakt en dat komt door het open
karakter van de software.
assuming: request size 24K content-length: 4294935296
(dat is -32000) komt door jou checks heen en zorgt voor totale
lengte van -8000 oid.
met recv geeft dat een error, met SSL_read geeft dat -8000
terug,
een error die je niet opvangt en je gaat 0 bytes schrijven
op plaatsen
waar het niet hoort (eerder op de heap).
(zie exploit vudo/hudo om te zien dat dat inderdaad
exploitable is)
stel je voor: content-length: 4294935296
(ja dat wrapped naar -32000 via str2int) die komt door al je
'controles' heen.
niet direct exploitable via recv, maar wel via een ssl
connectie (SSL_read(x,y, -aaa) returned -aaaa;)
die error vang je niet af, en je gaat op door een aanvaller
gecontroleerde plaats 0 bytes schrijven op de heap.
"Joomla Core". Dit houdt in dat als ik een "lekke" module
schrijf voor applicatie X dan niet ik de schuld krijg maar
de applicatie X. Niet helemaal terecht dus dat Joomla en
Mambo weer de schuld krijgt.
Ik heb de afgelopen weken ook diverse malen XOOP, PHP-Nuke en
Workdpress lekken langs zien komen. De tel van die ben ik
ook kwijtgeraakt.
Eigenlijk is hoofd boosdoener niet Joomla of de
module/component maar PHP.
Ik draai meerdere websites met Joomla. En ik weet zeker dat
daar ergens een lek in zit. Ik vertrouw geen enkel stukje
software, zoals alle security mensen zouden moeten doen.
@Hugo: Laat ons maar eens zien hoe goed jij bent.
@Hugo: Laat ons maar eens zien hoe goed jij bent.
Zo werkt dat niet.
Je hebt de beschikking over broncode en executables. Als je vind dat er
iets niet goed is, moet jij dat zelf aantonen.
assuming: request size 24K content-length: 4294935296 (dat is -32000) komt door jou checks heen en zorgt voor totale lengte van -8000 oid.
met recv geeft dat een error, met SSL_read geeft dat -8000 terug, een error die je niet opvangt en je gaat 0 bytes schrijven op plaatsen waar het niet hoort (eerder op de heap).
Niet slecht ;-)
update, verder gekeken naar je code. en je kan mijn SSL_read
remark vergeten, daar komt hij niet met een negatieve
lengte. (mijn excuses
snel code auditen en dan een exploiteerbaar pad vinden is
wat lastig :(
Maar via een keep-alive connectie, dan in de tweede
connectie een grote content-length en dan via reset_session
is een aanvaller er wel.
(Zal straks controleren of ik niet weer een fout heb gemaakt
door te snel
te lezen, maar volgens mij niet :)
Bedankt dat je in een hobby project een fout hebt ontdekt,
maar het ging om de websites. Dat is namelijk hetgeen ik bij
klanten plaats.
Waarom zou je wel fouten maken in je hobbyproject en niet in je websites?
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
