Random Gmail leak

HUP cikkturkáló

https://www.google.hu/search?q=inurl%3A%22hu%22+site%3Agmail.com&ie=&oe…

Találatok a inurl:"hu" site:mail.google.com keresésre:

  • Dorin Florea: Marosvásárhely kell legyen a központ - Gmail - Google
  • Beérkező levelek (30) - sandorszegedi1@gmail.com
  • Kézzelfogható történelem (régészet) - Gmail - Google

Semmi komoly, de vajon hogyan történhetett ez? A Google a spiderezésen kívül a Chrome-ban megnyitott oldalak tartalmat is atkuldi a szerverekre?

via https://twitter.com/ihackbanme/status/820561407779291136

  • 5995 megtekintés

( dotnetlinux | 2017. 01. 15., v – 23:41 )

Pár hete én is akartam 95%-ban ezzel kapcsolatban írni, de féltem, hogy hülyének néztek. Adott egy URL, amit csak én ismerek, csak én használok (www.xy.hu/admin). Csak egy IP címről megy, a többi ipről lekérve az url routing miatt 404-es hibára fut és bekerül a hibás URL-ek közé (nem portál, hanem üzleti alkalmazás, fontos tudni, ha benne maradt valahol egy rossz url). Semmilyen sitemapban nincs benne, az oldal maga sincs beküldve sehova.

Minden nap kapok 2-8 hibajelzést erre a /admin/ URI-ra és az IP egy google proxy (Chrome v44-es böngészőnek jelzi, amely egy MAC-en fut???). Szóval nekem is az a sejtésem, hogy a Chrome-ban használt URL-ekre rápróbál/előtölti/megnézihogyváltozotte/kipróbálja "valami".

Még az eszembe jutott, hogy a telefonomon megnyitva a Chrome-ot az töltené le az utolsó/MRU 8 oldalt, hogy a favicon-t kinyerje vagy mifene? De az sem google proxy, hanem itthoni fix ip...

( thxer v | 2017. 01. 16., h – 00:42 )

Több évvel ezelőtt tapasztaltam hasonlót, egy sehol nem publikált, base auth-al védett oldal tartalma bekerült a googleba, akkor arra a következtetésre jutottam, hogy a Chrome küldte el. Hasonló lehet itt is.

Pár éve én is belefutottam ilyenbe, bár nem jöttem rá hogy chrome és/vagy google dns lehet-e a ludas. Az is igaz hogy nagyon nem is néztem utána, csak csináltam egy robots-ot. De gyanítom mindkettőt használja ilyen célra, bár azzal nem értek egyet hogy az url-en kívül mást is felhasznál (pl mint jelen esetben a fejléc)

( hnsz2002 v | 2017. 01. 16., h – 18:40 )

Mit kéne látni?
--
"Sose a gép a hülye."

( Proci85 v | 2017. 01. 17., k – 20:32 )

Gyanakvó lettem a topik után.
Kiraktam a netre egy http://domainem.hu/{64_random_karakter}/ link alá személyes tartalmat. Megosztottam pár emberrel mailben.
1 nappal rá a logban gyanúsat találtam az IP-k lekérdezése után:
150.93.249.66.in-addr.arpa domain name pointer google-proxy-66-249-93-150.google.com.
151.93.249.66.in-addr.arpa domain name pointer google-proxy-66-249-93-151.google.com.
152.93.249.66.in-addr.arpa domain name pointer google-proxy-66-249-93-152.google.com.

Az IP-ről ilyen az apache log: 


66.249.93.151 - - [17/Jan/2017:06:30:54 +0100] "GET /XXXXX HTTP/1.1" 200 2850 "http://XXXXX/" "Mozilla/5.0 (Linux; Android 5.1.1; Redmi 3 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Mobile Safari/537.36"
66.249.93.152 - - [17/Jan/2017:06:30:54 +0100] "GET /XXXXX HTTP/1.1" 200 2425 "http://XXXXX/" "Mozilla/5.0 (Linux; Android 5.1.1; Redmi 3 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Mobile Safari/537.36"
66.249.93.150 - - [17/Jan/2017:06:30:54 +0100] "GET /XXXXX HTTP/1.1" 200 2395 "http://XXXXX/" "Mozilla/5.0 (Linux; Android 5.1.1; Redmi 3 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Mobile Safari/537.36"
66.249.93.152 - - [17/Jan/2017:06:30:54 +0100] "GET /XXXXX HTTP/1.1" 200 3300 "http://XXXXX/" "Mozilla/5.0 (Linux; Android 5.1.1; Redmi 3 Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.91 Mobile Safari/537.36"

Szóval mobilról megnézték, ami előbb átzavarta a google szerverén? Miért?
Egyelőre ezt találtam magyarázatként:
http://www.zdnet.com/article/google-proxy-used-for-chromes-mobile-data-…

Kerestem a neten user agent alapján tíltó megoldásokat, de a fenti alapján hasztalan, meg ugye bármit be lehet hazudni.
Következő lépés a .htaccess+htpasswd, kérdés ér-e valamit? Igen, itt megjelenik a bizalmatlanság és eljutunk oda, hogy VPN...de egy csoportnak szánt infót nem rejthetsz mindig VPN alá. Közben mem szeretnéd, ha a csoporton kívül kikerüljön, pl. keresőbe.

Reggel agyaltam és már ilyenek is eszembe jutottak, hogyha van egy megosztandó tartalmad amit weben terítesz szét a csoportban, akkor az átküldött link előbb egy php-ra ugrik, ami htaccessbe hozzáadja az IP-t engedélyezve az almappába való bejutást, majd az almappába irányítja a böngészőt. Így ha a böngészővel az almappában tallózod a tartalmat, _talán_ csak azt jegyzi meg és nem a redirect php-dat. Így ha visszajönne szétnézni a bot, lyukra fut, mert IP szinten nem fér hozzá.
Persze ez csak ötletelés, ami lehet, hogy hamvában halna, ha a redirect.php-t is felnyalja a böngésző...

Azért érdekelne, hogy kinek milyen (akár elborult) ötlete lenne tartalom átküldésére kisebb-nagyobb csoportok számára az e-mailen kívül. Nem minősített és bizalmas anyagokról van szó, de olyanokról amik mégsem tartoznak a nagyvilág számára.

Ha szabványos HTTP AUTH mögé teszed, vagy valamilyen HTTP POST + COOKIE megoldást használsz, az normális körülmények között biztosan nem fog bekerülni a keresőkbe. Szándékosan nem kerül meg beléptetést egyetlen legális keresőrobot sem.

AZ IP alapú szűrést semmiképpen nem javaslom. A Google-féle chrome tömörítő proxy esetében nem hogy a bot, de bárki más a világon aki szintén tömörítő proxyt használ, simán azonos IP-re kerülhet.

A másik ami fontos lehet, hogy ha valakinek valamit nem szabad megnézni, arra érdemes tisztességes HTTP 403-at visszaadni, így a robotok is megértik hogy nem látják őket szívesen, és nem jönnek vissza.

( joco01 v | 2017. 01. 18., sze – 11:27 )

Egy lehetséges magyarázat: "Elküldött levelek - vakumgate@gmail.com - Google" -> http://nadorpeter.blogspot.co.uk/2011/05/gmail-elkuldott-levelek.html . Nyilvánvalóan valami hülye bot spammel, de hogy ez mire jó, azt nem tudom elképzelni. Ezeket az oldalakat gondolom egy idő után automatikusan törlik, illetve jelenteni is lehet őket. Vagy valaki véletlen megosztja. Ha tényleg valami óriási leak lenne, akkor nem 50 találat lenne, hanem 50 milliárd.

--

Ez sajnos nem magyarázat, ebben az esetben a keresésnél a cím alatt megjelenő URL nem a gmailre mutatna.

Amit el tudtam volna képzelni, hogy letiltott cookiek mellett a munkamenet azonosító az URL-be kerülhet. (Ez régen szokás volt.) Egy ilyen URL aztán ha véletlenül a googlebothoz kerül, akkor indexeléskor "be lesz jelentkezve".

A Gmail esetében ez nem magyarázat, mert nem működik cookiek nélkül. Esetleg lehet hogy régen működött, és az érintett oldalak még akkor kerültek a találati listába.

Tudsz jobb magyarázatot? Mivel nem tudhatod biztosan, hogy a Google kereső belül hogy működik, ezért nem fogom elhinni, ha azt állítod, hogy hogyan kellene működnie :). A lapon van egy link+szöveg a Gmailre, miért ne jelenhetne meg ugyanaz a link+szöveg a keresőben? Köztudott, hogy a Google a linkek szövegét is figyelembe veszi. Furcsának furcsa, de mivel az adatot valaki nyilvánosan megosztotta, ez nem igazán leak.

--

Azért arra hogy a "title" értéket atírja a Google, még soha nem volt példa, arra pedig konkrétan garanciát vállal hogy a zölden jelölt URL cím az a cím, ahonnan a tartalom származik.

Szóval ennél bármi más jobb magyarázat. ;-)

El tudom képzelni azt is pl, hogy a Google Translate, a lefordítással együtt indexel is, mert miért ne, és így mentette le az adott leveleket.

A gmail.com-on robots.txt van. Nem tölti le, nem ír át semmit. Se a Chrome-hoz, se a Translate-hez nincs köze, bármennyire is divatos ilyen elméleteket gyártani.

Lásd https://support.google.com/webmasters/answer/6062608, https://yoast.com/prevent-site-being-indexed/, és egyéb oldalak.

Nagyon szépen leírják, hogy robots.txt ellenére maga a weboldal cím megjelenhet a keresőben a rá mutató linkek alapján. Pontosan ez történik.

--

( Proci85 v | 2017. 01. 31., k – 01:18 )

Egy privát körben ismét megosztottam egy oldalt, ahol gyors hivatkozásokkal elérnek különféle felületeket. Ez egy htaccess+htpasswd-vel védett titkos oldal, de a gyors linkek között van pár külső direkt link.
Az egyik külső privát linket évente 1x használtam, akkor is ezen oldalról nyitva, tehát a referből látszik.

Kb 1 hete osztottam meg, gondolom kipróbálták a privát kör tagjai. Most viszont a logban látom, hogy ezt a külső privát linket ilyenek nyitották meg idegen hostról, no referer: 


46.246.45.26 - - [30/Jan/2017:16:03:52 +0100] "GET /xxxxx.php HTTP/1.1" 200 485 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36"
46.246.45.26 - - [30/Jan/2017:16:05:28 +0100] "GET /xxxxx.php HTTP/1.1" 200 485 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36"
46.246.45.26 - - [30/Jan/2017:16:10:02 +0100] "GET /xxxxx.php HTTP/1.1" 200 485 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.34 Safari/537.36"
46.246.45.26 - - [30/Jan/2017:16:11:43 +0100] "GET /xxxxx.php HTTP/1.1" 200 485 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.34 Safari/537.36"
46.246.45.26 - - [30/Jan/2017:16:15:36 +0100] "GET /xxxxx.php HTTP/1.1" 200 485 "-" "Mozilla/5.0 (X11; OpenBSD i386; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40"
46.246.45.26 - - [30/Jan/2017:16:24:01 +0100] "GET /xxxxx.php HTTP/1.1" 200 485 "-" "sqlmap/1.1.1.17#dev (http://sqlmap.org)"
46.246.45.26 - - [30/Jan/2017:16:24:01 +0100] "GET /xxxxx.php?PReP%3D8502%20AND%201%3D1%20UNION%20ALL%20SELECT%201%2CNULL%2C%27%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E%27%2Ctable_name%20FROM%20information_schema.tables%20WHERE%202%3E1--%2F%2A%2A%2F%3B%20EXEC%20xp_cmdshell%28%27cat%20..%2F..%2F..%2Fetc%2Fpasswd%27%29%23 HTTP/1.1" 200 485 "-" "sqlmap/1.1.1.17#dev (http://sqlmap.org)"
46.246.45.26 - - [30/Jan/2017:16:24:01 +0100] "GET /xxxxx.php HTTP/1.1" 200 485 "-" "sqlmap/1.1.1.17#dev (http://sqlmap.org)"

$ host 46.246.45.26
26.45.246.46.in-addr.arpa domain name pointer anon-45-26.vpn.ipredator.se.

Most akkor az van, hogy egyes böngészők kipofázzák a linket vagy számítógépen futó vírus csendben lehallgatja a forgalmat?!

Ezek után tényleg ott tartunk, hogy vpn...

A logokban HTTP 200-as státusz látszik, ergo ha tényleg van működő HTTP hitelesítés az adott PHP oldalra, az csak megfelelő hitelesítés után kerülhet oda.

Ergo az alábbiak valamelyike történhetett:

  • mégis az egyik ismerősöd volt (valami VPN-en)
  • valamelyiküktől ellopták a hitelesítési adatokat (amit nem-HTTPS elérés esetén az adatforgalom sniffelésével (például Wi-Fi) triviális), és úgy léptek be
  • triviális a jelszó, könnyen törhető

    Ne próbálj többet látni a jelenségbe, mint ami.

Lehet, hogy félreérthető voltam, elnézést.
A megosztott (nevezzük) vezérlőpultnak van htpasswd auth-ja, de több linket fog össze és az egyik innen hivatkozott külső linknek nem volt. Na ezt a külső linket buzerálták úgy, hogy évekig semmi. Most elmondtam 5 embernek, abból 3 kipróbálta és a fenti jelenség játszódott le.
Igen, lehetett volna auth ezen is, anno így lett megcsinálva, így maradt. Tanulságos, igen, kell rá. A link egyébként egy al-alfájl, ami csak paraméterezve fut le (kb jelszó GET-tel, előző fejlesztő így kókányolta). Az logban helyes paraméterrel láttam, mi több arra is figyelt a bot, hogy xxxx.php?parameterem&o_parametere formában tegye az enyém után.

"triviális a jelszó, könnyen törhető"

Feltételezi, hogy tudja az URL-t, de nem tudhatja, mert nem default login page, nincs kint sehol, nem használja senki, nem triviális az url.

Ismerős kizárva, mert támadó jellegű az URL paraméterezése. Vagy sniffelés vagy böngésző, esetleg annak egy retkes pluginja. A böngészőket megpróbálom tesztelni tiszta környezetben.