[gelöst] HTTPMOD - Website hat login-Verfahren geändert

Begonnen von Vize, 05 März 2017, 11:49:32

Vorheriges Thema - Nächstes Thema

Vize

OK,

sobald Zeit da ist, werde ich das machen.

Soll ich die (Roh)Daten aus burp dann einfach hier posten, oder wie kommen wir am besten weiter?

Dank und Gruß
Andreas

Vize

So,

anbei mal eine Textdatei mit allen Rohdaten aus burp vom Aufruf der homepage über login bis zur Seite mit den Daten.
Die einzelnen Seiten habe ich jeweils mit =========================== getrennt.

Kann man nun daraus einen Ansatz für entsprechendes HTTPMOD-Device ableiten?

Bin für jede Hilfe dankbar...

Gruß
Andreas

StefanStrobel

Hallo Andreas,

Vielen Dank für den Mtschnitt. Das sieht doch gleich viel brauchbarer aus.
Ich fürchte aber, Du hast einen Request zwischendrin vergessen.
Es müsste noch ein Post auf /endkunde/auth/authenticate erfolgt sein. Den habe ich in Deinem File nicht gefunden.

Gruß / Thanx
    Stefan

Vize

Hallo Stefan,

jau, hast wohl recht...

Liefere ich heute Abend nach.

Gruß
Andreas

Vize

Ahoi,

so, den Post auf /endkunde/auth/authenticate habe ich entsprechend in der Datei ergänzt und diese nochmal angehängt.

Jetzt bin ich gespannt, was daraus gebaut werden kann...  :-[

Danke schonmal/nochmal!!!

Gruß
Andreas

StefanStrobel

Also ...

Der Mitschnitt ist jetzt leider etwas inkonsistent - zumindest passen die Cookies nicht mehr zueinander, da Du einen Teil am Sonntag und einen Teil am Montag aufgezeichnet hast. Ich würde es aber mal so zusammenfassen:

Für die Anmeldung macht man zunächst einen GET Request auf
/

In der Response auf den ersten Request wird das Cookie JSESSIONID mit dem Wert VelYNe6v_HUcGAas73kelwHIFYuNDJpYjjMpuNGT.application01
und der Option path=/
gesetzt und ein Login-Formular angeboten.

Der Anwender füllt das aus und beim Abschicken geht ein zweiter Request als POST an
/auth/authenticate
Darin steht in den POST-Daten
username=email%40email.de&passwort=geheim
im Header wird das vorher vom Server gesetzte Cookie natürlich auch mitgeschickt.

Die Antwort auf den zweiten Request enthält die eingegebenen Login-Daten im Javascript Code und per Javascript wird das ganze gleich wieder per POST als dritter Request an die nächste URL geschickt:
/endkunde/auth/authenticate
Auch hier ist das gesetzte erste Cookie natürlich wieder mit drin.
In den Daten steht nochmal
username=email%40email.de&passwort=geheim

Die Antwort auf den dritten Request ist die Bestätigung des Logins. Sie setzt das Cookie JSESSIONID neu, diesmal mit dem Wert 10xvITNZrHRtu63K1Rq-gjaao9MKvWuDTh-vBvAf.application01
und den Optionen path=/endkunde
und
HttpOnly

inhaltlich ist die Antwort ein Redirect auf
/endkunde

Die folgenden Requests lesen dann die Daten und schicken dabei beide Cookies mit.

Wenn man es exakt so mit HTTPMOD umsetzen möchte, muss also die Haupt-URL auf die Seite mit den Daten zeigen, also zum Beispiel
/endkunde/api/status/getstatusoverview.php?anlageNummer=0

Für das Login müssen drei Schritte definiert werden.
Zuerst ein Request auf /
dann einer auf
/auth/authenticate
dann auf
/endkunde/auth/authenticate

eventuell ist der mittlere Request überflüssig. Das müsste man ausprobieren.
dabei müssen die Cookies berücksichtigt werden. Normalerweise kann HTTPMOD das automatisch wenn Cookie-Handling aktiviert ist. Hier könnte es aber sein, dass es nicht klappt, da JSESSIONID gleich zweimal mit verschiedenen Path-Optionen verwendet wird. Möglicherweise ist das aber auch nicht schlimm und nur das zweite Cookie ist relevant.

Zudem müsste man noch testen, welche Header tatsächlich benötigt werden.

Also sind folgende Attribute nötig:
sid01URL
sid01Header

sid02URL
sid02Header
sid02Data

sid03URL
sid03Header
sid03Data

wenn alles klappt, sollte HTTPMOD die Haupt-URL mit den Daten abrufen können.

Wenn Du es zunächst in Burp probieren möchtest, kannst Du die einzelnen Requests im Burp-Repeater neu auslösen, aus der Response das Cookie kopieren und in den nächsten Request einfügen und dann diesen ausführen. Nach dem dritten Request sollte die Response das für den Abruf der Daten gültige Session-Cooke mit Pfad-Option /enkunde enthalten.

Im Burp Repeater kannst Du dann auch immer wieder eine Header-zeile entfernen und testen ob der Request noch zu einer gültigen Antwort führt, oder ob ein Fehler vom Server kommt. So findest Du am einfachsten heraus, welche Header-Zeilen überflüssig sind.

Wenn Du es nicht mit Burp probieren möchtest, solltest Du lieber ein paar Header mehr mitschicken als zu wenige, also z.B.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: application/json, text/plain, */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Referer: https://mein-senec.de/endkunde/
If-Modified-Since: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-cache
Pragma: no-cache

bei mehreren Header-Zeilen musst Du die jeweils als sid01Header1, sid01Header2, sid01Header3 und dann beim nächsten Request als sid02Header1 etc. angeben.
Mit enableCookies 1 kümmert sich HTTPMOD selbst um die Cookie-Header, sofern JSESSIONID nicht tatsächlich zwei mal benötigt wird. Glaube ich aber eigentlich nicht.

Vermutlich brauchst Du die meisten Header gar nicht, aber das muss man eben ausprobieren.

Probier es doch mal, poste die komplette Konfig und das Ergebnis bzw. den relevanten Auszug aus dem Log mit Verbose 5.

Gruss
   Stefan


Vize

Hallo Stefan,

super, vielen Dank für die ausführliche Antwort.

Eine konkrete Frage habe ich aber erstmal noch.
Ist in deiner Beschreibung sid01URL die Hauptseite, also /, oder geht es bei /auth/authenticate los?

Gruß
Andreas

StefanStrobel

Ich würde zunächst mal versuchen sid01URL auf / zu setzen, damit beim nächsten Request schon eine erste SessionID vorhanden ist. Wenn es mal funktioniert kann man immer noch versuchen es zu vereinfachen...

Gruß
   Stefan

Vize

Hab gerade mal versucht den GET Request manuell in burp zur Hauptseite abzusetzen.
Im Repeater muss ja auch ein Port angegeben werden. Aus meinen alten screenshots habe ich entnommen, dass es wohl Port 443 ist.

Wenn ich nun dieses in burp auf https://mein-senec.de:443 abschicke:
GET / HTTP/1.1
Host: mein-senec.de
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate, br
Upgrade-Insecure-Requests: 1
Connection: close


erhalte ich als Antwort:
HTTP/1.1 408 Request Timeout
Date: Tue, 14 Mar 2017 20:23:50 GMT
Server: Apache/2.4.23 (Fedora) OpenSSL/1.0.2j-fips PHP/5.6.29
Content-Length: 221
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>408 Request Timeout</title>
</head><body>
<h1>Request Timeout</h1>
<p>Server timeout waiting for the HTTP request from the client.</p>
</body></html>


Will sagen, ich scheitere schon am Anfang...

Gruß
Andreas

Vize

Hallo Stefan,

anbei ein erster Versuch mit "minimalen" Headern...leider erfolglos.   :-\
Einmal Log-Auszug mit verbose 5 und ein list des Devices.

Kannst du daraus erkennen, ob es mit fehlenden Headern zu tun hat, oder hast du noch weitere Tipps?

Gruß
Andreas

StefanStrobel

Hallo Andreas,

zum Absenden von Requests in Burp:
Ich würde den Request zuerst aufzeichnen und dann im History-Fenster mit einem rechten Mausklick und "Send to repeater" den Request in den Repeater schicken. Da musst Du keine Ports definieren und es muss eigentlich auch funktionieren. Allerdings müssen die Cookie-Werte zu diesem Zeitpunkt gültig sein. Du musst also die Requests in der richtigen Reihenfolge senden und die Werte passend ändern...

Zu Deinem Versuch mit HTTPMOD:
es scheitert hier:

2017.03.15 18:23:29 4: HttpUtils url=https://mein-senec.de/endkunde/auth/authenticate
2017.03.15 18:23:30 4: https://mein-senec.de/endkunde/auth/authenticate: HTTP response code 302
2017.03.15 18:23:30 4: HttpUtils https://mein-senec.de/endkunde/auth/authenticate: Redirect to https://mein-senec.de/endkunde/
2017.03.15 18:23:30 4: HttpUtils url=https://mein-senec.de/endkunde/
2017.03.15 18:23:30 4: https://mein-senec.de/endkunde/: HTTP response code 302
2017.03.15 18:23:30 4: HttpUtils https://mein-senec.de/endkunde/: Redirect to https://mein-senec.de/endkunde/auth/login
2017.03.15 18:23:30 4: HttpUtils url=https://mein-senec.de/endkunde/auth/login


Die Antwort auf den Request an https://mein-senec.de/endkunde/auth/authenticate ist ein Redirect. Darin steht aber das gültige Session-Cookie. Ohne zusätzliche Anweisungen folgt aber HttpUtils gleich dem Redirect und so hat HTTPMOD keine Chance das neue Cookie zu extrahieren. Die Lösung ist ein attr sid3IgnoreRedirects 1 (Siehe Doku / Wiki). Dann solltest Du einen Schritt weiter kommen.

Gruss
    Stefan

Vize

Hallo Stefan,

danke für den weiteren Tipp!

Ich glaube, ich bin auch schon etwas schlauer geworden bzw. habe noch etwas herausgefunden...

Das mit dem Repeater in burp hat jetzt soweit geklappt.
Nach ein paar Versuchen konnte ich die Prozedur auf folgendes eindampfen:

Diese Requests werden benötigt:

GET auf /  -> dort wird im Response cookie 1 gesetzt/erzeugt
POST auf /endkunde/auth/authenticate  -> dort wird cookie 2 gesetzt/erzeugt
BEIDE Cookies müssen nun mitgenommen werden
GET auf /endkunde/

Danach Aufruf der Seite mit den Daten.

Ein Minimieren der Header habe ich noch nicht getestet...

Hilft das noch weiter, bzw. gibt das neuen Aufschluss für dich?

IgnoreRedirects teste ich mal.

Danke!

Gruß
Andreas

Vize

Ich werd bekloppt...der geht!!!!

Der Tipp mit IgnoreRedirects war der Jackpot.

Vielen, vielen Dank Stefan!

Hier nun ein list des funktionierenden Devices:
Internals:
   BUSY       0
   CFGFN
   DEF        https://mein-senec.de/endkunde/api/status/getstatusoverview.php?anlageNummer=0 300
   HTTPCookies JSESSIONID=eOnp8eyUzAKLy1e9C4tMxZ7hv2sePRQU8qRNHhim.application01
   Interval   300
   JSONEnabled 1
   LASTSEND   1489697931.9306
   LastAuthTry 2017-03-16 21:58:48
   MainURL    https://mein-senec.de/endkunde/api/status/getstatusoverview.php?anlageNummer=0
   ModuleVersion 3.3.5 - 29.9.2016
   NAME       httpmod_senec_neu_login
   NR         117009
   STATE      16
   TRIGGERTIME 1489698228.46336
   TRIGGERTIME_FMT 2017-03-16 22:03:48
   TYPE       HTTPMOD
   addr       https://mein-senec.de:443
   buf
   code       200
   conn
   data
   displayurl https://mein-senec.de/endkunde/api/status/getstatusoverview.php?anlageNummer=0
   header     Cookie: JSESSIONID=eOnp8eyUzAKLy1e9C4tMxZ7hv2sePRQU8qRNHhim.application01
   host       mein-senec.de
   httpheader HTTP/1.1 200 OK

Date: Thu, 16 Mar 2017 20:58:52 GMT

Server: WildFly/10

Expires: 0

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

X-Powered-By: Undertow/1

X-XSS-Protection: 1; mode=block

Pragma: no-cache

X-Frame-Options: SAMEORIGIN

X-Content-Type-Options: nosniff

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

Content-Type: application/json;charset=UTF-8

Connection: close

Transfer-Encoding: chunked
   httpversion 1.1
   hu_blocking 0
   hu_filecount 288
   hu_portSfx
   ignoreredirects 0
   loglevel   4
   path       /endkunde/api/status/getstatusoverview.php?anlageNummer=0
   protocol   https
   redirects  0
   timeout    20
   url        https://mein-senec.de/endkunde/api/status/getstatusoverview.php?anlageNummer=0
   value      0
   Httpcookiehash:
     Jsessionid:
       Options    path=/endkunde; HttpOnly

       Value      eOnp8eyUzAKLy1e9C4tMxZ7hv2sePRQU8qRNHhim.application01
   QUEUE:
   Readings:
     2017-03-16 21:58:52   accuexport_now  0
     2017-03-16 21:58:52   accuexport_today 3.6065
     2017-03-16 21:58:52   accuimport_now  0.57
     2017-03-16 21:58:52   accuimport_today 2.8951
     2017-03-16 21:58:52   consumption_now 0.56
     2017-03-16 21:58:52   consumption_today 21.2676
     2017-03-16 21:58:52   gridexport_now  0.02
     2017-03-16 21:58:52   gridexport_today 29.2798
     2017-03-16 21:58:52   gridimport_now  0
     2017-03-16 21:58:52   gridimport_today 0.7738
     2017-03-16 21:58:52   lastupdated     1489697698
     2017-03-16 21:58:52   machine         MCU
     2017-03-16 21:58:52   powergenerated_now 0
     2017-03-16 21:58:52   powergenerated_today 47.8423
     2017-03-16 21:58:52   readable_state  ?com.senecies.meinsenec.senec.model.SteuereinheitState.ENTLADEN?
     2017-03-16 21:58:52   state           16
     2017-03-16 21:58:52   wartungNotwendig false
   Request:
     data
     header
     ignoreredirects 0
     retryCount 1
     type       update
     url        https://mein-senec.de/endkunde/api/status/getstatusoverview.php?anlageNummer=0
     value      0
   Defptr:
     Readingbase:
       accuexport_now reading
       accuexport_today reading
       accuimport_now reading
       accuimport_today reading
       consumption_now reading
       consumption_today reading
       errorCode  reading
       gridexport_now reading
       gridexport_today reading
       gridimport_now reading
       gridimport_today reading
       lastupdated reading
       machine    reading
       powergenerated_now reading
       powergenerated_today reading
       readable_state reading
       state      reading
       wartungNotwendig reading
     Readingnum:
       accuexport_now
       accuexport_today
       accuimport_now
       accuimport_today
       consumption_now
       consumption_today
       errorCode
       gridexport_now
       gridexport_today
       gridimport_now
       gridimport_today
       lastupdated
       machine
       powergenerated_now
       powergenerated_today
       readable_state
       state
       wartungNotwendig
     Readingoutdated:
     Requestreadings:
       Update:
         accuexport_now reading
         accuexport_today reading
         accuimport_now reading
         accuimport_today reading
         consumption_now reading
         consumption_today reading
         errorCode  reading
         gridexport_now reading
         gridexport_today reading
         gridimport_now reading
         gridimport_today reading
         lastupdated reading
         machine    reading
         powergenerated_now reading
         powergenerated_today reading
         readable_state reading
         state      reading
         wartungNotwendig reading
   Powermap:
   Readingsdesc:
     Pm_consumption:
       rtype      w
     Pm_energy:
       rtype      whr
   Sslargs:
Attributes:
   disable    0
   enableCookies 1
   extractAllJSON 1
   httpVersion 1.1
   reAuthRegex .*Error.*
   sid1Header1 Content-Type: text/html
   sid1Header2 Accept: */*
   sid1URL    https://mein-senec.de/
   sid2Data   username=email@email.de&passwort=geheim
   sid2Header1 Accept: */*
   sid2Header2 Content-Type: application/x-www-form-urlencoded
   sid2IgnoreRedirects 1
   sid2URL    https://mein-senec.de/endkunde/auth/authenticate
   sid3Header1 Accept: */*
   sid3Header2 Content-Type: text/html
   sid3URL    https://mein-senec.de/endkunde
   timeout    20
   userattr   sid1Data sid1Header1 sid1Header2 sid1URL sid2Data sid2Header1 sid2Header2 sid2IgnoreRedirects:0,1 sid2URL sid3Data sid3Header1 sid3Header2 sid3URL sid4Header1 sid4Header2 sid4URL
   verbose    5


Was für eine Geburt...  ;)

Vielen Dank nochmal!

Gruß
Andreas

Vize

#28
Moin,

hier dann nochmal (zur besseren Übersicht) die entsprechende Konfiguration des Devices:

DEF:
https://mein-senec.de/endkunde/api/status/getstatusoverview.php?anlageNummer=0 300

Attribute:
enableCookies 1
extractAllJSON 1
httpVersion 1.1
reAuthRegex .*Error.*

sid1Header1 Content-Type: text/html
sid1Header2 Accept: */*
sid1URL https://mein-senec.de/

sid2Data username=<email>&passwort=<passwort>
sid2Header1 Accept: */*
sid2Header2 Content-Type: application/x-www-form-urlencoded
sid2IgnoreRedirects 1
sid2URL https://mein-senec.de/endkunde/auth/authenticate

sid3Header1 Accept: */*
sid3Header2 Content-Type: text/html
sid3URL https://mein-senec.de/endkunde


Ob man den ersten Request auf die Hauptseite (sid1XXX) wirklich braucht, weiß ich nicht...Vielleicht braucht man sid3XXX auch nicht...habe ich noch nicht getestet.

EDIT: Habe es mal an einem weiteren Device getestet...es reicht den POST-Request auf https://mein-senec.de/endkunde/auth/authenticate auszuführen. Die Sachen bei sid1XXX und sid3XXX sind nicht nötig. Das Attribut httpVersion braucht man auch nicht.

Viel Spaß!
Andreas

brembs

Bei mir funktioniert es auch wieder! Spitzenklasse, ganz vielen Dank für die Arbeit und sorry, dass ich keine Zeit hatte, mit zu helfen!