gan SeerLight
Mae adeiladu unrhyw wasanaeth o reidrwydd yn cynnwys gwaith cyson ar ddiogelwch. Mae diogelwch yn broses barhaus sy'n cynnwys dadansoddiad cyson a gwella diogelwch cynnyrch, monitro newyddion am wendidau a llawer mwy. Gan gynnwys archwiliadau. Cynhelir archwiliadau mewnol a chan arbenigwyr allanol, a all helpu'n sylweddol gyda diogelwch oherwydd nad ydynt wedi ymgolli yn y prosiect a bod ganddynt feddwl agored.
Mae'r erthygl yn ymwneud â'r farn fwyaf syml hon o arbenigwyr allanol a helpodd dîm Mail.ru Cloud Solutions (MCS) i brofi'r gwasanaeth cwmwl, ac am yr hyn a ddarganfuwyd ganddynt. Fel “llu allanol,” dewisodd MCS y cwmni Diogelwch Digidol, sy'n adnabyddus am ei arbenigedd uchel mewn cylchoedd diogelwch gwybodaeth. Ac yn yr erthygl hon byddwn yn dadansoddi rhai gwendidau diddorol a ddarganfuwyd fel rhan o archwiliad allanol - fel eich bod yn osgoi'r un rhaca pan fyddwch chi'n creu eich gwasanaeth cwmwl eich hun.
Описание продукта
yn llwyfan ar gyfer adeiladu seilwaith rhithwir yn y cwmwl. Mae'n cynnwys IaaS, PaaS, a marchnad o ddelweddau cais parod ar gyfer datblygwyr. Gan ystyried pensaernïaeth MCS, roedd angen gwirio diogelwch y cynnyrch yn y meysydd canlynol:
- diogelu seilwaith yr amgylchedd rhithwiroli: hypervisors, llwybro, waliau tân;
- diogelu seilwaith rhithwir cwsmeriaid: ynysu oddi wrth ei gilydd, gan gynnwys rhwydwaith, rhwydweithiau preifat yn SDN;
- OpenStack a'i gydrannau agored;
- S3 ein dyluniad ein hunain;
- IAM: prosiectau aml-denant gyda model rôl;
- Gweledigaeth (gweledigaeth cyfrifiadur): APIs a gwendidau wrth weithio gyda delweddau;
- rhyngwyneb gwe ac ymosodiadau gwe clasurol;
- gwendidau cydrannau PaaS;
- API o'r holl gydrannau.
Efallai mai dyna’r cyfan sy’n hanfodol ar gyfer hanes pellach.
Pa fath o waith a wnaed a pham yr oedd ei angen?
Nod archwiliad diogelwch yw nodi gwendidau a gwallau cyfluniad a allai arwain at ollwng data personol, addasu gwybodaeth sensitif, neu amharu ar argaeledd gwasanaeth.
Yn ystod y gwaith, sy'n para 1-2 mis ar gyfartaledd, mae archwilwyr yn ailadrodd gweithredoedd ymosodwyr posibl ac yn edrych am wendidau yn rhannau cleient a gweinydd y gwasanaeth a ddewiswyd. Yng nghyd-destun yr archwiliad o lwyfan cwmwl MCS, nodwyd y nodau canlynol:
- Dadansoddiad o ddilysu yn y gwasanaeth. Byddai gwendidau yn y gydran hon yn helpu i fynd i mewn i gyfrifon pobl eraill ar unwaith.
- Astudio'r model rôl a rheolaeth mynediad rhwng gwahanol gyfrifon. Ar gyfer ymosodwr, mae'r gallu i gael mynediad at beiriant rhithwir rhywun arall yn nod dymunol.
- Gwendidau ochr y cleient. XSS/CSRF/CRLF/etc. A yw'n bosibl ymosod ar ddefnyddwyr eraill trwy ddolenni maleisus?
- Gwendidau ochr y gweinydd: RCE a phob math o chwistrelliadau (SQL / XXE / SSRF ac yn y blaen). Yn gyffredinol, mae gwendidau gweinydd yn fwy anodd eu darganfod, ond maent yn arwain at gyfaddawd llawer o ddefnyddwyr ar unwaith.
- Dadansoddiad o ynysu segment defnyddwyr ar lefel rhwydwaith. Ar gyfer ymosodwr, mae'r diffyg ynysu yn cynyddu'r wyneb ymosodiad yn fawr yn erbyn defnyddwyr eraill.
- Dadansoddiad rhesymeg busnes. A yw'n bosibl twyllo busnesau a chreu peiriannau rhithwir am ddim?
Yn y prosiect hwn, gwnaed gwaith yn unol â'r model "Gray-box": roedd yr archwilwyr yn rhyngweithio â'r gwasanaeth gyda breintiau defnyddwyr cyffredin, ond yn rhannol yn meddu ar god ffynhonnell yr API a chawsant gyfle i egluro'r manylion gyda'r datblygwyr. Dyma'r model gwaith mwyaf cyfleus fel arfer, ac ar yr un pryd yn eithaf realistig: gall ymosodwr gasglu gwybodaeth fewnol o hyd, dim ond mater o amser ydyw.
Darganfuwyd gwendidau
Cyn i'r archwilydd ddechrau anfon llwythi tâl amrywiol (y llwyth tâl a ddefnyddir i gyflawni'r ymosodiad) i leoedd ar hap, mae angen deall sut mae pethau'n gweithio a pha ymarferoldeb a ddarperir. Efallai ei bod yn ymddangos bod hwn yn ymarfer diwerth, oherwydd yn y rhan fwyaf o'r lleoedd a astudiwyd ni fydd unrhyw wendidau. Ond dim ond deall strwythur y cais a rhesymeg ei weithrediad fydd yn ei gwneud hi'n bosibl dod o hyd i'r fectorau ymosodiad mwyaf cymhleth.
Mae'n bwysig dod o hyd i leoedd sy'n ymddangos yn amheus neu'n wahanol iawn i eraill mewn rhyw ffordd. A'r bregusrwydd peryglus cyntaf a ganfuwyd fel hyn.
IDOR
Gwendidau IDOR (Cyfeirnod Gwrthrych Uniongyrchol Anniogel) yw un o'r gwendidau mwyaf cyffredin mewn rhesymeg busnes, sy'n caniatáu i'r naill neu'r llall gael mynediad at wrthrychau na chaniateir mynediad iddynt mewn gwirionedd. Mae gwendidau IDOR yn creu'r posibilrwydd o gael gwybodaeth am ddefnyddiwr o wahanol raddau o bwysigrwydd.
Un o'r opsiynau IDOR yw cyflawni gweithredoedd gyda gwrthrychau system (defnyddwyr, cyfrifon banc, eitemau yn y drol siopa) trwy drin dynodwyr mynediad i'r gwrthrychau hyn. Mae hyn yn arwain at y canlyniadau mwyaf anrhagweladwy. Er enghraifft, y posibilrwydd o ddisodli cyfrif yr anfonwr arian, lle gallwch chi eu dwyn oddi wrth ddefnyddwyr eraill.
Yn achos MCS, mae archwilwyr newydd ddarganfod bregusrwydd IDOR sy'n gysylltiedig â dynodwyr nad ydynt yn ddiogel. Yng nghyfrif personol y defnyddiwr, defnyddiwyd dynodwyr UUID i gyrchu unrhyw wrthrychau, a oedd yn ymddangos, fel y dywed arbenigwyr diogelwch, yn hynod ansicr (hynny yw, wedi'u hamddiffyn rhag ymosodiadau grym 'n ysgrublaidd). Ond ar gyfer rhai endidau, darganfuwyd bod niferoedd rhagweladwy rheolaidd yn cael eu defnyddio i gael gwybodaeth am ddefnyddwyr y rhaglen. Rwy'n meddwl y gallwch chi ddyfalu ei bod yn bosibl newid yr ID defnyddiwr fesul un, anfon y cais eto a thrwy hynny gael gwybodaeth gan osgoi'r ACL (rhestr rheoli mynediad, rheolau mynediad data ar gyfer prosesau a defnyddwyr).
Ffugio Cais Ochr Gweinydd (SSRF)
Y peth da am gynhyrchion OpenSource yw bod ganddyn nhw nifer enfawr o fforymau gyda disgrifiadau technegol manwl o'r problemau sy'n codi ac, os ydych chi'n ffodus, disgrifiad o'r ateb. Ond mae gan y darn arian hwn ochr fflip: disgrifir gwendidau hysbys hefyd yn fanwl. Er enghraifft, mae yna ddisgrifiadau gwych o wendidau ar y fforwm OpenStack и , sydd am ryw reswm nad oes neb ar frys i'w drwsio.
Un o swyddogaethau cyffredin cymwysiadau yw'r gallu i'r defnyddiwr anfon dolen i'r gweinydd, y mae'r gweinydd yn clicio arno (er enghraifft, i lawrlwytho delwedd o ffynhonnell benodol). Os nad yw offer diogelwch yn hidlo'r dolenni eu hunain neu'r ymatebion a ddychwelir o'r gweinydd i ddefnyddwyr, gall ymosodwyr ddefnyddio'r swyddogaethau hyn yn hawdd.
Gall gwendidau SSRF hybu datblygiad ymosodiad yn fawr. Gall ymosodwr gael:
- mynediad cyfyngedig i'r rhwydwaith lleol yr ymosodwyd arno, er enghraifft, dim ond trwy rai segmentau rhwydwaith a defnyddio protocol penodol;
- mynediad llawn i'r rhwydwaith lleol, os yw'n bosibl israddio o lefel y cais i'r lefel drafnidiaeth ac, o ganlyniad, rheoli llwyth llawn ar lefel y cais;
- mynediad i ddarllen ffeiliau lleol ar y gweinydd (os cefnogir y cynllun ffeil:///);
- a llawer mwy.
Mae bregusrwydd SSRF wedi bod yn hysbys ers amser maith yn OpenStack, sy'n “ddall” ei natur: pan fyddwch chi'n cysylltu â'r gweinydd, nid ydych chi'n derbyn ymateb ganddo, ond rydych chi'n derbyn gwahanol fathau o wallau / oedi, yn dibynnu ar ganlyniad y cais . Yn seiliedig ar hyn, gallwch chi berfformio sgan porthladd ar westeion ar y rhwydwaith mewnol, gyda'r holl ganlyniadau dilynol na ddylid eu tanamcangyfrif. Er enghraifft, efallai y bydd gan gynnyrch API cefn swyddfa sydd ond yn hygyrch o'r rhwydwaith corfforaethol. Gyda dogfennaeth (peidiwch ag anghofio am fewnwyr), gall ymosodwr ddefnyddio SSRF i gael mynediad at ddulliau mewnol. Er enghraifft, os oeddech chi rywsut yn gallu cael rhestr fras o URLau defnyddiol, yna gan ddefnyddio SSRF gallwch chi fynd trwyddynt a gweithredu cais - yn gymharol siarad, trosglwyddo arian o gyfrif i gyfrif neu newid terfynau.
Nid dyma'r tro cyntaf i fregusrwydd SSRF gael ei ddarganfod yn OpenStack. Yn y gorffennol, roedd yn bosibl lawrlwytho delweddau VM ISO o ddolen uniongyrchol, a arweiniodd hefyd at ganlyniadau tebyg. Mae'r nodwedd hon bellach wedi'i thynnu o OpenStack. Yn ôl pob tebyg, roedd y gymuned yn ystyried mai dyma'r ateb symlaf a mwyaf dibynadwy i'r broblem.
Ac yn adroddiad sydd ar gael i'r cyhoedd gan wasanaeth HackerOne (h1), ymelwa ar SSRF nad yw bellach yn ddall gyda'r gallu i ddarllen metadata enghreifftiol yn arwain at fynediad gwraidd i'r seilwaith Shopify cyfan.
Yn MCS, darganfuwyd gwendidau SSRF mewn dau le gyda swyddogaethau tebyg, ond roedd bron yn amhosibl manteisio arnynt oherwydd waliau tân ac amddiffyniadau eraill. Un ffordd neu'r llall, datrysodd tîm MCS y broblem hon beth bynnag, heb aros am y gymuned.
XSS yn lle llwytho cregyn
Er gwaethaf cannoedd o astudiaethau a ysgrifennwyd, mae ymosodiad XSS (sgriptio traws-safle) flwyddyn ar ôl blwyddyn yn dal i fod fwyaf bregusrwydd gwe (neu ?).
Mae uwchlwythiadau ffeil yn hoff le i unrhyw ymchwilydd diogelwch. Mae'n aml yn troi allan y gallwch chi lwytho sgript mympwyol (asp / jsp / php) a gweithredu gorchmynion OS, yn nherminoleg pentesters - "load shell". Ond mae poblogrwydd gwendidau o'r fath yn gweithio i'r ddau gyfeiriad: cânt eu cofio a datblygir rhwymedïau yn eu herbyn, fel bod y tebygolrwydd o “lwytho cragen” yn ddiweddar yn tueddu i ddim.
Roedd y tîm ymosod (a gynrychiolir gan Digital Security) yn ffodus. Iawn, yn MCS ar ochr y gweinydd gwiriwyd cynnwys y ffeiliau a lawrlwythwyd, dim ond delweddau a ganiateir. Ond mae SVG hefyd yn llun. Sut gall delweddau SVG fod yn beryglus? Oherwydd gallwch chi fewnosod pytiau JavaScript ynddynt!
Mae'n troi allan bod y ffeiliau wedi'u llwytho i lawr ar gael i holl ddefnyddwyr y gwasanaeth MCS, sy'n golygu ei bod yn bosibl i ymosod ar ddefnyddwyr cwmwl eraill, sef gweinyddwyr.
Enghraifft o ymosodiad XSS ar ffurflen mewngofnodi gwe-rwydo
Enghreifftiau o ecsbloetio ymosodiad XSS:
- Pam ceisio dwyn sesiwn (yn enwedig ers nawr mae cwcis HTTP-Yn unig ym mhobman, wedi'u hamddiffyn rhag lladrad gan ddefnyddio sgriptiau js), os gall y sgript wedi'i lwytho gael mynediad i'r API adnodd ar unwaith? Yn yr achos hwn, gall y llwyth tâl ddefnyddio ceisiadau XHR i newid cyfluniad y gweinydd, er enghraifft, ychwanegu allwedd SSH cyhoeddus yr ymosodwr a chael mynediad SSH i'r gweinydd.
- Os yw polisi'r CSP (polisi diogelu cynnwys) yn gwahardd chwistrellu JavaScript, gall ymosodwr fynd heibio hebddo. Gan ddefnyddio HTML pur, crëwch ffurflen mewngofnodi ffug ar gyfer y wefan a dwyn cyfrinair y gweinyddwr trwy'r gwe-rwydo datblygedig hwn: mae'r dudalen gwe-rwydo ar gyfer y defnyddiwr yn gorffen gyda'r un URL, ac mae'n anoddach i'r defnyddiwr ei ganfod.
- Yn olaf, gall yr ymosodwr drefnu — gosod Cwcis mwy na 4 KB. Dim ond unwaith y mae angen i'r defnyddiwr agor y ddolen, ac mae'r wefan gyfan yn dod yn anhygyrch nes bod y defnyddiwr yn meddwl glanhau'r porwr yn benodol: yn y mwyafrif helaeth o achosion, bydd y gweinydd gwe yn gwrthod derbyn cleient o'r fath.
Edrychwn ar enghraifft o XSS arall a ganfuwyd, y tro hwn gyda chamfanteisio mwy clyfar. Mae gwasanaeth MCS yn caniatáu ichi gyfuno gosodiadau wal dân yn grwpiau. Enw'r grŵp oedd lle canfuwyd yr XSS. Ei hynodrwydd oedd na chafodd y fector ei sbarduno ar unwaith, nid wrth edrych ar y rhestr o reolau, ond wrth ddileu grŵp:
Hynny yw, y senario oedd y canlynol: mae ymosodwr yn creu rheol wal dân gyda “llwyth” yn yr enw, mae'r gweinyddwr yn sylwi arno ar ôl ychydig ac yn cychwyn y broses ddileu. A dyma lle mae'r JS maleisus yn gweithio.
Er mwyn i ddatblygwyr MCS amddiffyn rhag XSS mewn delweddau SVG wedi'u llwytho i fyny (os na ellir eu hepgor), argymhellodd y tîm Diogelwch Digidol:
- Rhowch ffeiliau a uwchlwythwyd gan ddefnyddwyr ar barth ar wahân nad oes ganddo unrhyw beth i'w wneud â “cwcis”. Bydd y sgript yn cael ei gweithredu yng nghyd-destun parth gwahanol ac ni fydd yn fygythiad i MCS.
- Yn ymateb HTTP y gweinydd, anfonwch y pennawd “Content-disposition: attachment”. Yna bydd y ffeiliau'n cael eu llwytho i lawr gan y porwr ac ni fyddant yn cael eu gweithredu.
Yn ogystal, erbyn hyn mae llawer o ffyrdd ar gael i ddatblygwyr liniaru risgiau ecsbloetio XSS:
- gan ddefnyddio'r faner “HTTP yn Unig”, gallwch wneud penawdau “Cwcis” sesiwn yn anhygyrch i JavaScript maleisus;
- yn ei gwneud hi'n llawer anoddach i ymosodwr ecsbloetio XSS;
- mae peiriannau templed modern fel Angular neu React yn diheintio data defnyddwyr yn awtomatig cyn ei allbynnu i borwr y defnyddiwr.
Gwendidau dilysu dau ffactor
Er mwyn gwella diogelwch cyfrif, cynghorir defnyddwyr bob amser i alluogi 2FA (dilysu dau ffactor). Yn wir, mae hon yn ffordd effeithiol o atal ymosodwr rhag cael mynediad at wasanaeth os yw rhinweddau'r defnyddiwr wedi'u peryglu.
Ond a yw defnyddio ail ffactor dilysu bob amser yn gwarantu diogelwch cyfrif? Mae’r materion diogelwch canlynol wrth weithredu 2FA:
- Chwiliad cryf o'r cod OTP (codau un-amser). Er gwaethaf symlrwydd gweithredu, mae cwmnïau mawr hefyd yn dod ar draws gwallau fel diffyg amddiffyniad rhag grym ysgarol OTP: , .
- Algorithm cenhedlaeth wan, er enghraifft y gallu i ragweld y cod nesaf.
- Gwallau rhesymegol, fel y gallu i ofyn am OTP rhywun arall ar eich ffôn, fel hyn gan Shopify.
Yn achos MCS, gweithredir 2FA yn seiliedig ar Google Authenticator a . Mae'r protocol ei hun eisoes wedi'i brofi gan amser, ond mae'n werth gwirio gweithredu dilysu cod ar ochr y cais.
Defnyddir MCS 2FA mewn sawl man:
- Wrth ddilysu'r defnyddiwr. Mae amddiffyniad yn erbyn grym ysgaredig: dim ond ychydig o ymdrechion y mae gan y defnyddiwr i nodi cyfrinair un-amser, yna mae'r mewnbwn yn cael ei rwystro am ychydig. Mae hyn yn rhwystro'r posibilrwydd o ddewis OTP 'n Ysgrublaidd.
- Wrth gynhyrchu codau wrth gefn all-lein i berfformio 2FA, yn ogystal â'i analluogi. Yma, ni weithredwyd unrhyw amddiffyniad grym ysgarol, a oedd yn ei gwneud hi'n bosibl, pe bai gennych gyfrinair ar gyfer y cyfrif a sesiwn weithredol, i adfywio codau wrth gefn neu analluogi 2FA yn llwyr.
O ystyried bod y codau wrth gefn wedi'u lleoli yn yr un ystod o werthoedd llinynnol â'r rhai a gynhyrchir gan y cais OTP, roedd y siawns o ddod o hyd i'r cod mewn amser byr yn llawer uwch.
Y broses o ddewis OTP i analluogi 2FA gan ddefnyddio'r offeryn “Burp: Intruder”.
Canlyniad
Yn gyffredinol, mae'n ymddangos bod MCS yn ddiogel fel cynnyrch. Yn ystod yr archwiliad, nid oedd y tîm treiddgar yn gallu cael mynediad at VMs cleientiaid a'u data, a chafodd y gwendidau a ganfuwyd eu cywiro'n gyflym gan dîm yr MCS.
Ond yma mae'n bwysig nodi bod diogelwch yn waith parhaus. Nid yw gwasanaethau'n sefydlog, maent yn esblygu'n barhaus. Ac mae'n amhosibl datblygu cynnyrch yn gyfan gwbl heb wendidau. Ond gallwch ddod o hyd iddynt mewn pryd a lleihau'r siawns y byddant yn digwydd eto.
Nawr mae'r holl wendidau a grybwyllwyd yn MCS eisoes wedi'u trwsio. Ac er mwyn cadw nifer y rhai newydd mor isel â phosibl a lleihau eu hoes, mae tîm y platfform yn parhau i wneud hyn:
- cynnal archwiliadau rheolaidd gan gwmnïau allanol;
- cefnogi a datblygu cyfranogiad;
- cymryd rhan mewn diogelwch. 🙂
Ffynhonnell: hab.com