13 Antworten in diesem Thema

[Xenos88]

Hallo,

 

habe so eben eine Amazon Phishing Mail bekommen.

 

 

Wer hat lust was zu machen, ich hasse es.

 

 

ACHTUNG keine Daten angeben!!!

Please Login HERE or Register HERE to see this link!

 

Have Fun

Xenos

[B1nary]

CloudFlare springt an, sagt ja schon alles...

Glaube nicht, dass man diese Site defacen kann. Daten werden gesammelt an eine Emailadresse gesendet. HTML -> PHP-Mailer, klassische Phishing-Page halt. Was will man da defacen?

 

Was mir einfallen würde, wäre ein Programm, um massenweise Posts abzusetzen mit schwachsinnigem Inhalt. Dann könnte man das Postfach flooden. Aber sonst....?!

[Cranky]

Warum denkt ihr nie weiter als einen Schritt voraus?

 

Hier der Vorgang:

 

1. Das Form ist vuln gegen CSRF.
2. CSRF script schreiben (HTML)
3. Per AJAX Refresh immer wieder absenden lassen.
4. Server so abusen.
5. Wenn kein abuse reinkommt -> Da dann einfach mal die mailfunktion des servers gesperrt werden sollte, wird auch sonst nichts mehr gephished.

[FalkE]

 

Warum denkt ihr nie weiter als einen Schritt voraus?

 

Hier der Vorgang:

 

1. Das Form ist vuln gegen CSRF.
2. CSRF script schreiben (HTML)
3. Per AJAX Refresh immer wieder absenden lassen.
4. Server so abusen.
5. Wenn kein abuse reinkommt -> Da dann einfach mal die mailfunktion des servers gesperrt werden sollte, wird auch sonst nichts mehr gephished.

 

das ist doch absolut nicht weitergedacht. abused wird dadurch garnichts.

desweiteren braucht man dafür auch keine CSRF vulnerability (die hier schlichtweg nicht existiert), sondern einfach nur den POST request zb mit nem for loop (python) flooden.

 

der server kann ja soviel mails versenden wie er möchte (suspended wird er dadurch nicht..), die frage ist auch ob das per mail versendet wird. kann genauso als log.txt gespeichert werden (den unterschied merkst du als "nutzer" nicht) oder in einer mysql db.

 

die letzten 2 methoden wären da schon eher von vorteil, dadurch könnte man den speicherplatz über nullbytes maximieren und so ein festgelegtes ressource limit überschreiten was zu einer suspension führen könnte.

 

das war kein schritt vorrausgedacht...

[B1nary]

 

Warum denkt ihr nie weiter als einen Schritt voraus?

 

Irgendwie jetzt auch sinngemäß ungefähr das, was ich schon geschrieben habe, wo ist da der weitergedachte Schritt -.- 

Flooding wird ggf. wegen CF nicht funktionieren, müsste man halt probieren. Bräuchte man auch kein extra Script dafür, kann man auch per cURL Iteration laufen lassen.

 

z.B.

watch -n2 curl --data "Post-Header Parameter" https://domain.com

Bearbeitet von B1nary, 03 March 2015 - 19:49 Uhr.

[Cranky]

das ist doch absolut nicht weitergedacht. abused wird dadurch garnichts.

desweiteren braucht man dafür auch keine CSRF vulnerability (die hier schlichtweg nicht existiert), sondern einfach nur den POST request zb mit nem for loop (python) flooden.

 

der server kann ja soviel mails versenden wie er möchte (suspended wird er dadurch nicht..), die frage ist auch ob das per mail versendet wird. kann genauso als log.txt gespeichert werden (den unterschied merkst du als "nutzer" nicht) oder in einer mysql db.

 

die letzten 2 methoden wären da schon eher von vorteil, dadurch könnte man den speicherplatz über nullbytes maximieren und so ein festgelegtes ressource limit überschreiten was zu einer suspension führen könnte.

 

das war kein schritt vorrausgedacht...

 

Natürlich kommt es da zu einer CSRF - Du kannst die formdaten automatisiert absenden lassen ohne dass sie mit einem unique token validiert werden.

 

 

 

Irgendwie jetzt auch sinngemäß ungefähr das, was ich schon geschrieben habe, wo ist da der weitergedachte Schritt -.- 

Flooding wird ggf. wegen CF nicht funktionieren, müsste man halt probieren. Bräuchte man auch kein extra Script dafür, kann man auch per cURL Iteration laufen lassen.

 

z.B.

watch -n2 curl --data "Post-Header Parameter" https://domain.com

Ansich schon richtig, läuft halt einfacher per html form da man das ebenfalls auf vicseiten laden könnte und somit "anonymer" und "schneller" arbeitet.

[FalkE]

durchlesen, verstehen, unnütze und falsche praktizierung/interpretation vermeiden.

Please Login HERE or Register HERE to see this link!

Bearbeitet von FalkE, 04 March 2015 - 13:19 Uhr.

[Cranky]

durchlesen, verstehen, unnütze und falsche praktizierung/interpretation vermeiden.

Please Login HERE or Register HERE to see this link!

 

Damit du endlich mal aufhörst den klugscheißer zu spielen:

 

 

Cross-Site Request Forgery (CSRF) is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.

 

 

Ansich schon richtig, läuft halt einfacher per html form da man das ebenfalls auf vicseiten laden könnte und somit "anonymer" und "schneller" arbeitet.

 

 

Aha falke. aha.

[FalkE]

und selbst in den fettnapf getreten:

 

 

end user to execute unwanted actions

so und ich hab keine lust auf den kindergarten hier.

was das zitat hier angeht:

 

 

läuft halt einfacher per html form da man das ebenfalls auf vicseiten laden könnte und somit "anonymer" und "schneller" arbeitet.

kann ich und jeder webdev hier wohl nur den kopf schütteln.

wenn man nur die grundlagen beherrscht sollte man das doch zu geben als den unnützen versuch zu starten auf halbwissen zu debatieren.

 

in diesem sinne, bye ~

[pdr0]

OT:

 

Sry Cranky aber FalkE hat recht.

 

Fuer CSRF brauchst du 2 Seiten, eine angrefende Seite (die du kontrollierst) und eine Seite auf der dein Opfer angemeldet ist. Besucht das Opfer deine angreifende Seite, kannst du z.B. ueber JS einen Request mit seinem Token(Session, Cookie,...) an die Seite auf der das Opfer angemeldet senden, solange diese keine Schutzmassnahmen wie Captcha o. so einsetzt. Siehe Bank Beispiel aus dem OWASP Link.

 

Also kann es nur zwei Varianten geben, Phishing-Seite angreifen oder mit der Phishing-Seite angreifen.

 

Phishing-Seite angreifen:

Du bist der Phishing-Seite gegenueber nicht "currently authenticated" also kannst du von keiner anderen Seite mit CSRF angreifen (es gibt einfach keine Session zu klauen) . Das wuerde auch wenig Sinn machen, denn das Opfer muesste sich auf deine "Angreifferseite" (!=dieser Phishing-Seite) bewegen um dann die Phishing Seite angreifen zu koennen. Das ist sinnlos, weil du auch direkt, wie bereits geschrieben, POST Requests senden kannst.

 

 

Mit der Phishing-Seite angreifen:

Angenommen du haettest die Kontrolle ueber die Phishing-Seite dann koenntest du andere Dienste damit angreiffen auf denen dein Opfer sich aktuell befindet. Macht aber keinen Sinn, weil du die Phishing-Seite angreifen willst und auch keine Kontrolle ueber diese Seite hast.

Bearbeitet von pdr0, 04 March 2015 - 16:12 Uhr.

[Cranky]

Für CSRF braucht man nicht eingelogged sein. Man kann auch OHNE das man eingelogged ist gezwungen werden etwas durchzuführen, dass man nicht durchführen möchte, selbst wenn man nicht auf der seite unterwegs ist auf der das geschieht.

               <form method="Post" action="http://amazon.de-member.com/5161512/gp/deflex/UTF8/hp_ln_muerg/webcs-yourorder/index2.php">

                  <div id="ap_signin1a_pagelet" class="ap_table ap_pagelet">
                     <div id="ap_signin1a_pagelet_title" class="ap_row ap_pagelet_title">
                        <h1>Anmelden</h1>
                     </div>
                     <div id="ap_signin1a_email_section_title" class="ap_row ap_section_title">
                        <h2>
                           Wie lautet Ihre E-Mail-Adresse? 
                        </h2>
                     </div>
                     <div id="ap_signin1a_email_row" class="ap_row">
                        <span class="ap_col1 ap_bold ap_right ap_no_collapse">
                        <label for="ap_email">
                        Meine E-Mail-Adresse:
                        </label>
                        </span>
                        <span class="ap_col2 ap_left">
                        <input id="ap_email" name="Mail" value="" type="email" size="30" maxlength="128" tabindex="1" autocorrect="off" autocapitalize="off" required>   
                        </span>
                     </div>
                    <div id="ap_signin_custom_message" class="center clear-both">
                    </div>
                    <div id="ap_signin1a_password_section_title" class="ap_row ap_section_title">
                        <h2> Haben Sie ein Passwort für Amazon.de? </h2>
                     </div>
                     <div id="ap_signin1a_new_cust_radio_row" class="ap_row">
                        <span id="" class="ap_col1 ap_right ap_no_collapse">
                        <input type="radio" onclick="setElementAvailability(&#39;ap_password&#39;, false);jQuery(&#39;#ap_captcha_table&#39;).hide();" name="create" id="ap_signin_create_radio" value="1" tabindex="6">
                        </span>
                        <span id="" class="ap_col2 bold ap_radio_label">
                           <label for="ap_signin_create_radio">Nein, ich bin ein neuer Kunde.</label>
                           <div class="small"></div>
                        </span>
                     </div>
                     <div id="ap_signin1a_exist_cust_radio_row" class="ap_row">
                        <span class="ap_col1 ap_right">
                        <input type="radio" name="create" onclick="setElementAvailability(&#39;ap_password&#39;, true);jQuery(&#39;#ap_captcha_table&#39;).show();" id="ap_signin_existing_radio" value="0" tabindex="7" checked="checked">
                        </span>
                        <span class="ap_col2 bold ap_radio_label"><label for="ap_signin_existing_radio">Ja, ich habe ein Passwort:</label></span>
                     </div>
                     <div id="ap_signin1a_password_row" class="ap_row">
                        <span class="ap_col1">&nbsp;</span>
                        <span class="ap_col2">
                        <input id="ap_password" name="Passwort" type="password" maxlength="1024" size="20" tabindex="2" class="password" required>
                        </span>
                        <span id="ap_caps_warn_span">
                           <div id="ap_caps_warning" class="ap_caps_warn ap_col3_caps_warn" style="visibility:hidden;">
                              <b>Die Feststelltaste (Caps Lock) ist aktiviert.</b> <font color="black">Möglicherweise<br> können Sie deshalb Ihr Passwort nicht korrekt eingeben. </font>
                           </div>
                        </span>
                     </div>
                     <div id="ap_small_forgot_password_link">
                              <span class="small" id="ap_small_forgot_password_span">
                              <a href="#">Haben Sie Ihr Passwort vergessen?</a>
                              </span>
                    </div>
                           <div id="ap_signin1a_signin_button_row" class="ap_row">
                              <span class="ap_col1">&nbsp;</span>
                              <span class="ap_col2">
                              <span class="in-amzn-btn btn-prim-med-ra" id="signInSubmit" unselectable="on">
                              <span>
                              <input type="submit" id="signInSubmit-input" value="Weiter (über den Sicherheitsserver)" tabindex="5">
                              </span>
                              </span>
                              </span>
                              <div class="ap_csm_marker" style="display:none;">
                              </div>
                           </div>
                           <div id="ap_signin1a_notification_row" class="ap_row">
                              <span id="sign_in_notification_row">
                              Mit Ihrer Anmeldung erklären Sie sich mit <a href="#">Unseren AGB</a>, unserer <a href="#">Datenschutzerklärung</a> sowie den <a href="#">Bestimmungen zu Cookies &amp; Internet-Werbung</a> einverstanden.
                              </span>
                           </div>
                           <div id="ap_signin1a_forgot_password_row" class="ap_row">
                              <span class="ap_col1">&nbsp;</span>
                              <span class="ap_col2">
                              <a href="#">Haben Sie Ihr Passwort vergessen?</a>
                              </span>
                           </div>
                           <div id="ap_signin1a_cnep_row" class="ap_row">
                              <span class="ap_col1">&nbsp;</span>
                              <span id="ap_signin1a_cnep_row_col2" class="ap_col2">
                              <a href="#">Hat sich Ihre E-Mail-Adresse geändert?</a>
                              </span>
                           </div>
                 </div>
               </form>

Da einfach mal randomwerte einfüllen, das ganze in ein html script packen und ne funktion bauen per js die das automatisert absendet. Das dann auf einer "vicseite" einbinden und absenden lassen von jedem user der die seite aufruft.

 

Voila. CSRF. Ungewollte Handlungen eines Vics auf einer Seite auf der er weder eingelogged ist noch die er wissentlich besucht hat.

[Laggy]

Cranky hat da schon recht, da die Form kein zb an eine Session-gebundenes Token benutzt kann man eine CSRF-Attacke ausführen, generell ist aber das Risiko eines erfolgreichen Angriffs bei Post based CSRF oder auch XSS  Angriffen deutlich geringer als beit Get Angriffen, da man immer eine präperierte Seite brauch die das Opfer besucht

Bearbeitet von Laggy, 04 March 2015 - 18:09 Uhr.

[FalkE]

schön das sich die anfängliche unsachlichkeit jetzt geklärt hat. trotzdem ist dieses modell mehr als fraglich.

 

A. werden die besucher der jeweiligen seite (wo das script eingebunden ist) zu victims, das eigentliche target wird eher passiv "angegriffen"

B. hinterlässt das eine menge an logs (samt IP adresse und redirect)

C. wird ein server nicht suspended weil er mails verschickt

D. handelt es sich hier um inputs ohne token wie bei den restlichen 99 % des word wide webs (ergo alles ist auf CSRF vulnerable, nur man sollte mal "einen schritt weiter denken" und sich fragen was das F für "Forgery" im kürzel zu suchen hat. irgendwelche POST/GET requests, extern absenden zu lassen zählt für mich einfach nicht als CSRF. da gehen die meinungen halt auseinander, aber ich orientiere mich da an der originalen definition, laut OWASP nochmal zitiert "to execute unwanted actions", "web application in which he/she is currently authenticated", "CSRF is an attack that tricks the victim into submitting a malicious request", "that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf"), das kann ich nämlich auch:

E. mit einem python/perl/php script und zwar um einiges einfacher und effizienter.

[XoiL]

 

Warum denkt ihr nie weiter als einen Schritt voraus?

 

Hier der Vorgang:

 

1. Server so abusen.
2. Wenn kein abuse reinkommt -> Da dann einfach mal die mailfunktion des servers gesperrt werden sollte, wird auch sonst nichts mehr gephished.

 

Ich möchte hier jetzt keinen angreifen (Ich war im der letzten Zeit etwas "rude" zu den Usern und möchte mich da bessern was auch Ironie und so betrifft) , aber @ Cranky das was du da geschrieben hast stimmt einfach nicht und es erschliesst sich fuer mich auch kein Sinn an dem was du geschrieben hast. @ FalkE gibt dir hier Brief und Siegel in die Hand und wiederlegt das was du schreibst.

Ich weiss nicht was man noch machen soll?!

Du hast ja schon verstanden und auch bewiesen das du weiss was Cross-Site-Request-Forgery  ist aber es funktioniert nur im teil so wie du es beschrieben hast.

Alles in einem hast du in 5 Posts 30% funktinsweise erklaert und 70% Mist dazu geschrieben , das sagen dir hier 3 Leute.

 

Wie gesagt is net boese gemeint aber lass ma die Kirche im Dorf.

 

Lg XoiL

 

Ps @Laggy : das Graffiti by XoiL sieht man kaum

Bearbeitet von XoiL, 05 March 2015 - 14:10 Uhr.