Ցանցի պաշտպանություն dns կեղծ հարձակումներից: Ի՞նչ է DNS վարակը կամ DNS կեղծումը: Կեղծիքի անցյալն ու ներկան
IDN-ի կեղծում- սա ընտրվածին «նման» տիրույթի անունների սերունդ է, որը սովորաբար օգտագործվում է օգտագործողին ստիպելու համար հետևել հարձակվողի ռեսուրսի հղմանը: Հաջորդը, հաշվի առեք հարձակման ավելի կոնկրետ տարբերակը:
Պատկերացնենք, որ հարձակման ենթարկված ընկերությանը պատկանում է organisation.org տիրույթը, և portal.organization.org ներքին ռեսուրսը օգտագործվում է այս ընկերության ներսում։ Հարձակվողի նպատակն է ստանալ օգտատիրոջ հավատարմագրերը, և դրա համար նա հղում է ուղարկում էլեկտրոնային փոստի կամ ընկերության կողմից օգտագործվող մեսենջերի միջոցով:
Նման հաղորդագրություն ստանալով՝ մեծ է հավանականությունը, որ դուք չեք նկատի, որ հղումը սխալ տեղ է տանում։ Հղման վրա սեղմելուց հետո կպահանջվի մուտք/գաղտնաբառ, և տուժողը, կարծելով, որ գտնվում է ներքին ռեսուրսի վրա, մուտքագրելու է իր տվյալները։ հաշիվ. Հարձակվողի հավանականությունը հատկապես մեծ է, եթե նա արդեն ներթափանցել է պարագծով, վտանգի ենթարկելով ցանկացած աշխատակցի համակարգը և այժմ պայքարում է համակարգի ադմինիստրատորի արտոնությունների համար։
Այստեղ դուք չեք կարող բացարձակ «հիմար ապացույց» գտնել, բայց կարող եք փորձել կասեցնել այս հարձակումը անվան լուծման փուլում՝ dns հարցման միջոցով:
Պաշտպանության համար մենք պետք է հետևողականորեն հիշենք այն անունները, որոնց հանդիպում ենք գաղտնալսված dns հարցումներում: Ընկերությունն օգտագործում է իր ներքին ռեսուրսները, ինչը նշանակում է, որ մենք արագ կիմանանք portal.organization.org-ի հարցումով: Հենց որ հանդիպեցինք նախկինում հանդիպածի «նման» անունին, մենք կարող ենք փոխարինել dns պատասխանը՝ հարձակվողի IP հասցեի փոխարեն սխալ վերադարձնելով:
Որո՞նք են «նմանությունը» որոշելու ալգորիթմները:
- UTS39 Confusable Detection (http://www.unicode.org/reports/tr39/#Confusable_Detection) Unicode-ը ոչ միայն արժեքավոր մեխանիկական նիշերի աղյուսակ է, այլ նաև ստանդարտների և ուղեցույցների մի խումբ: UTS39-ը սահմանում է unicode տողերի նորմալացման ալգորիթմ, որի դեպքում տողերը, որոնք տարբերվում են հոմոգլիֆներով (օրինակ՝ ռուսերեն «a» և լատիներեն «a») կվերածվեն նույն ձևի։
- Բառեր, որոնք տարբերվում են ներքին տառերի փոխարկումներով: Բավականին հեշտ է շփոթել organisation.org-ը orgainzation.org-ի հետ
- Առաջին մակարդակի տիրույթի փոխարինում: Անվան առաջին մակարդակը սովորաբար իմաստ չունի, և «կազմակերպություն» տեսնելով ընկերության աշխատակիցը կարող է անտեսել .org կամ .net տարբերությունը, թեև կարող են լինել բացառություններ:
Մեթոդաբանությունը հասկանալու համար ձեզ հարկավոր է գիտելիքներ PE ձևաչափի մասին, կարող եք կարդալ ավելին, օրինակ. Գործարկվող ֆայլը բաղկացած է վերնագրերից, բաժնի աղյուսակից և հենց բաժիններից: Բաժիններն իրենք տվյալների բլոկ են, որոնք բեռնիչը պետք է հիշի հարաբերական հասցեով (Relative Virtual Address - RVA), և բոլոր ռեսուրսները, կոդը և այլ տվյալները պարունակվում են բաժիններում: Նաև վերնագրի ներսում կան հղումներ (RVA) մի շարք աղյուսակների, որոնք անհրաժեշտ են հավելվածի աշխատանքի համար, այս հոդվածի շրջանակներում կարևոր կլինի երկուսը` ներմուծման աղյուսակը և արտահանման աղյուսակը: Ներմուծման աղյուսակը պարունակում է գործառույթների ցանկ, որոնք անհրաժեշտ են հավելվածի աշխատանքի համար, բայց գտնվում են այլ ֆայլերում: Արտահանման աղյուսակը «հակադարձ» աղյուսակ է, որը պարունակում է գործառույթների ցանկ, որոնք արտահանվում են այս ֆայլից, կամ, արտահանման վերահասցեավորման դեպքում, ֆայլի անունը և ֆունկցիայի անվանումը՝ կախվածությունը լուծելու համար:
Մենք կկատարենք dll-ի ներարկումն առանց անհանգստացնող CreateRemoteThread-ի: Ես որոշեցի օգտագործել PE արտահանման վերահասցեավորում. սա հայտնի տեխնիկա է, երբ ցանկալի գործընթացում բեռնելու համար գրացուցակում ստեղծվում է dll exe ֆայլով, որի անունը հավասար է exe-ից ցանկացած dll-ի անվանմանը: ֆայլերի ներմուծման աղյուսակ (հիմնականը չօգտագործել HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs): Ստեղծված dll-ում արտահանման աղյուսակը պատճենվում է թիրախային dll-ից, սակայն արտահանվող ֆունկցիայի կոդի ցուցիչի փոխարեն անհրաժեշտ է գրել RVA առաջընթաց տողի վրա, ինչպես «endpoint! sendto»: Microsoft dns սերվերն ինքնին ներդրված է որպես ծառայություն HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS, որը գտնվում է %systemroot%\system32\dns.exe-ում:
Վերջնական ներարկման ալգորիթմը dns սերվերկլինի այսպես.
- Ստեղծեք %systemroot%\system32\dnsflt գրացուցակը (կարող եք օգտագործել ցանկացած այլ գրացուցակ, պարտադիր չէ համակարգ32-ում գտնել գրացուցակը):
- Մենք այնտեղ պատճենում ենք %systemroot%\system32\dnsapi.dll - սա այն dll-ն է, որտեղից dns.exe-ն ինչ-որ բան ներմուծում է, կարող եք ընտրել ցանկացած այլ «չճանաչվածdll»:
- Վերանվանեք պատճենված dll-ը endpoint.dll-ի - մենք կօգտագործենք այս անունը առաջի տողում:
- Մենք վերցնում ենք մեր ներարկված dll-ը և ավելացնում ենք ճիշտ արտահանման աղյուսակը, պատճենում ենք մեր dll-ը %systemroot%\system32\dnsflt-ում:
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS բանալի գրանցամատյանում փոխեք ImagePath-ը նոր երկուական հասցեով %systemroot%\system32\dnsflt\dns.exe:
- Ստեղծեք սիմհղում %systemroot%\system32\dnsflt\dns.exe-ից մինչև %systemroot%\system32\dns.exe
DllMain-ից պրոցեսի ներսում բեռնվելուց հետո հնարավոր կլինի ստեղծել թեմա և տեղադրել ընդհատումը: Ի շատ պարզ դեպքմեր dns ծառայությունը հաճախորդին կհայտնի անվան ip հասցեն՝ ուղարկելով UDP փաթեթ 53 նավահանգստից sendto ֆունկցիայի միջոցով ws2_32.dll-ից: Ստանդարտը առաջարկում է, որ TCP պորտը 53-ը կարող է օգտագործվել, եթե պատասխանը չափազանց մեծ է, և ակնհայտ է, որ sendto intercept-ն այս դեպքում անօգուտ կլինի։ Այնուամենայնիվ, tcp-ով գործը վարելը, թեև ավելի շատ ժամանակ է պահանջում, կարող է իրականացվել նույն ձևով: Առայժմ ես ձեզ կասեմ UDP-ի ամենապարզ դեպքը: Այսպիսով, մենք գիտենք, որ dns.exe-ի կոդը ներմուծում է sendto ֆունկցիան ws2_32.dll-ից և այն կօգտագործի dns հարցումին պատասխանելու համար: Կան նաև բավականին շատ գործառույթներ ընդհատելու համար տարբեր ճանապարհներ, սա դասական միացում է, երբ առաջին sendto հրահանգները փոխարինվում են jmp-ով իրենց ֆունկցիայի մեջ, իսկ այն ավարտելուց հետո անցում է կատարվում նախկինում պահպանված sendto հրահանգներին և այնուհետև sendto ֆունկցիայի ներսում։ Splicing-ը կաշխատի նույնիսկ այն դեպքում, եթե GetProcAddress-ն օգտագործվում է sendto կանչելու համար, այլ ոչ թե ներմուծման աղյուսակ, բայց եթե ներմուծման աղյուսակն օգտագործվում է, ավելի հեշտ է օգտագործել IAT կեռիկը միացման փոխարեն: Դա անելու համար դուք պետք է գտնեք ներմուծման աղյուսակը ներբեռնված dns.exe պատկերում: Աղյուսակն ինքնին ունի մի փոքր շփոթեցնող կառուցվածք, և մանրամասների համար ստիպված կլինեք գնալ PE ձևաչափի նկարագրությանը:
Հիմնական բանը այն է, որ պատկերը բեռնելու գործընթացում համակարգը ներմուծման աղյուսակում կգրի ցուցիչ sendto ֆունկցիայի սկզբին: Սա նշանակում է, որ sendto-ի զանգը ընդհատելու համար պարզապես անհրաժեշտ է ներմուծման աղյուսակում սկզբնական sendto-ի հասցեն փոխարինել ձեր ֆունկցիայի հասցեով։
Այսպիսով, մենք տեղադրեցինք գաղտնալսումը և սկսեցինք ստանալ տվյալներ։ Sendto ֆունկցիայի նախատիպն ունի հետևյալ տեսքը.
Int sendto(_In_ SOCKET s, _In_ const char *buf, _In_ int len, _In_ int flags, _In_ const struct sockaddr *to, _In_ int tolen);
Եթե s-ը 53 պորտի վարդակից է, ապա buf ցուցիչը կպարունակի len dns պատասխան: Ձևաչափն ինքնին նկարագրված է RFC1035-ում, ես համառոտ նկարագրելու եմ, թե ինչ է պետք անել, որպեսզի հասնենք հետաքրքրող տվյալներին:
Ստանդարտում հաղորդագրության կառուցվածքը նկարագրված է հետևյալ կերպ.
Ուղևորվելով անհրաժեշտ տեղեկատվությունհաղորդագրության տեսակը, սխալի կոդը և տարրերի քանակը բաժիններում: Վերնագիրն ինքնին այսպիսի տեսք ունի.
Կառուցվածք DNS_HEADER ( uint16_t id; // նույնականացման համարը uint8_t rd: 1; // ցանկալի ռեկուրսիա uint8_t tc: 1; // կրճատված հաղորդագրություն uint8_t aa: 1; // հեղինակավոր պատասխանի uint8_t օպերատիվ կոդը՝ 4; // qr: uint8_ հաղորդագրության նպատակը 1; // հարցում/պատասխանի դրոշ uint8_t կոդ՝ 4; // պատասխանի կոդը uint8_t cd՝ 1; // ստուգում է անջատված uint8_t գովազդը՝ 1; // վավերացված տվյալները uint8_t z: 1; // դրա z! վերապահված uint8_t ra: 1 ; // հասանելի ռեկուրսիա uint16_t q_count; // հարցերի մուտքերի քանակը uint16_t ans_count; // պատասխանների մուտքերի քանակը uint16_t auth_count; // հեղինակային մուտքերի քանակը uint16_t add_count; // ռեսուրսների մուտքերի քանակը );
Հարցի բաժինը պետք է վերլուծվի՝ պատասխանին հասնելու համար: Բաժինն ինքնին բաղկացած է վերնագրում նշված բլոկների քանակից (q_count): Յուրաքանչյուր բլոկ բաղկացած է անունից, տեսակից և հարցումների դասից: Անունը կոդավորված է որպես տողերի հաջորդականություն, որոնցից յուրաքանչյուրը սկսվում է տողի երկարությամբ բայտով: Վերջում զրոյական երկարությամբ շարան է։ Օրինակ, homedomain2008.ru անունը կունենա հետևյալ տեսքը.
Պատասխաններ բաժինը նման տեսք ունի՝ բլոկը բաղկացած է անունից, տեսակից, դասից, ttl-ից և լրացուցիչ տվյալներից: IP հասցեն կպարունակվի հավելումում: տվյալները։ Անվան վերլուծության հետ կապված ևս մեկ դժվարություն կա. Ըստ երևույթին, հաղորդագրության չափը նվազեցնելու համար, պիտակի երկարության փոխարեն, կարող եք հղում գտնել տվյալների այլ տարածքի: Այն կոդավորվում է հետևյալ կերպ. եթե երկարության 2 ամենակարևոր բիթերը հավասար են 11-ի, ապա հաջորդ բայթը, ինչպես նաև երկարության ամենանվազ նշանակալի բիթերը, պետք է մեկնաբանվեն որպես բայթերով օֆսեթ՝ բայթերի սկզբի համեմատ։ հաղորդագրություն։ Անվան հետագա վերլուծությունը պետք է կատարվի՝ անցնելով այս օֆսեթին:
Այսպիսով, մենք ընդհատեցինք պահանջվող API-ն, վերլուծեցինք dns-ի պատասխանը, այժմ մենք պետք է որոշում կայացնենք՝ բաց թողնել այս պատասխանը կամ վերադարձնել սխալ: Յուրաքանչյուր անուն, որը դեռ չկա տվյալների բազայում, պատասխանից պետք է ստուգել՝ «կասկածելի» է, թե ոչ։
Մենք «կասկածելի» կհամարենք այն անունները, որոնց համար Unicode տեխնիկական ստանդարտի tr39 կմախքի ֆունկցիայի արդյունքը համընկնում է բազային անուններից որևէ մեկի արդյունքի հետ, կամ այն անունները, որոնք տարբերվում են բազայում առկաներից՝ փոխակերպմամբ: ներքին տառեր. Ստուգումներ իրականացնելու համար մենք կպահենք 2 աղյուսակ։ Առաջինը բաղկացած կլինի հիմքից բոլոր անունների կմախքի արդյունքներից, երկրորդ աղյուսակում մենք կգրենք այն տողերը, որոնք ստացվել են հիմքի տողերից՝ յուրաքանչյուր պիտակից հեռացնելով առաջին և վերջին նիշը, բացառությամբ առաջին մակարդակի, և ապա տեսակավորելով յուրաքանչյուր պիտակի մնացած նիշերը: Հիմա, եթե նոր անունը ներառված է երկու աղյուսակներից մեկում, ապա մենք դա համարում ենք կասկածելի։
Կմախքի ֆունկցիայի իմաստը երկու տողերի նմանությունը որոշելն է, դրա համար յուրաքանչյուր տողի համար նիշերը նորմալացվում են: Օրինակ, Xlœ-ը կվերածվի Xloe-ի, և այդպիսով, համեմատելով ֆունկցիայի արդյունքը, կարելի է որոշել unicode տողերի նմանությունը։
Վերոնշյալի իրականացման օրինակ կարելի է գտնել github-ում:
Ակնհայտ է, որ վերը նշված լուծումը գործնականում չի կարող ապահովել նորմալ պաշտպանություն, քանի որ բացի գաղտնալսման հետ կապված մանր տեխնիկական խնդիրներից, կա էլ ավելի մեծ խնդիր «նման» անունների հայտնաբերման հետ կապված։ Լավ կլիներ մշակել.
- Փոխակերպումների և հոմոգլիֆների համակցություններ.
- Կմախքի կողմից հաշվի չառնված նիշերի ավելացում/փոխարինում:
- UTS tr39-ը չի սահմանափակվում միայն կմախքով, դուք դեռ կարող եք սահմանափակել նիշերի հավաքածուների խառնումը մեկ պիտակի մեջ:
- Ճապոնական ամբողջ լայնությամբ կետ և այլ պիտակների բաժանիչներ:
- Եվ նման հրաշալի բաներ
Խաբեությունը բավականին հետաքրքիր հարձակման մեթոդ է, որն անտեսված է անվտանգության շատ մասնագետների կողմից: Եվ իզուր, շատ նույնիսկ ապարդյուն։ Այս հոդվածից դուք կհասկանաք, թե որքան խաբուսիկ կարող է լինել այս բազմազան աշխարհը: Մի հավատացեք ձեր աչքերին!
ԶԳՈՒՇԱՑՈՒՄ
Ամբողջ տեղեկատվությունը տրամադրվում է միայն տեղեկատվական նպատակներով: Ոչ խմբագիրները, ոչ հեղինակը պատասխանատվություն չեն կրում սույն հոդվածի նյութերի պատճառած հնարավոր վնասի համար:
ներածություն
Ես հաճախ եմ լսում սեմինարի գործընկերներից, որ կեղծելը որպես հարձակման վեկտոր նույնիսկ չարժե մտածել: Այնուամենայնիվ, ես կարող եմ ձեզ վստահեցնել, որ եթե խարդախության մեթոդները մանրակրկիտ մտածված են, ապա դրանք կարող են օգտագործվել շատ, շատ: Ավելին, նման հարձակումների մասշտաբներն ու արդյունքները երբեմն աղետալի են լինում։ Չէ՞ որ մի անգամ աչքերդ խաբելով՝ էլի կխաբեմ։ Ամենակարևոր փաստարկը այն փաստի օգտին, որ կեղծ հարձակումները իրական վտանգ են ներկայացնում, այն է, որ ոչ մի մարդ, այդ թվում՝ մասնագետները, անձեռնմխելի չեն դրանցից: Այստեղ պետք է նշել, որ խարդախությունն ինքնին ոչինչ չի տալիս. իսկապես հաքերային հարձակում իրականացնելու համար դուք պետք է օգտագործեք հետշահագործում (հետշահագործում): Շատ դեպքերում, հետշահագործման նպատակներն են ստանդարտ գրավումը, արտոնությունների մեծացումը, զանգվածային բաշխումը չարամիտ ծրագիրև, որպես հետևանք, բանկային համակարգերի անձնական տվյալների և էլեկտրոնային թվային բանալիների գողություն՝ հետագա փողերի լվացմամբ։ Այս հոդվածում, նախ, ես ուզում եմ խոսել այն մասին, թե ընդհանրապես ինչ են կեղծման մեթոդները, և երկրորդ՝ մանրամասն պատմել որոշ ժամանակակից մոտեցումների մասին։ Բնականաբար, բոլոր տեղեկությունները ձեզ տրամադրվում են միայն այն նպատակով, որ օգնեն ձեզ պաշտպանվել նման հարձակումներից:
Կեղծիքի անցյալն ու ներկան
Սկզբում «սփոֆինգ» տերմինն օգտագործվում էր որպես ցանցի անվտանգության տերմին, որը ենթադրում էր որոշակի տվյալների հաջող կեղծում` որոշակի ցանցային ռեսուրսի չարտոնված մուտք ստանալու նպատակով: Ժամանակի ընթացքում այս տերմինը սկսեց գործածվել տեղեկատվական անվտանգության այլ ոլորտներում, չնայած, այսպես կոչված, հին դպրոցի մասնագետների մեծ մասն այսօր շարունակում է օգտագործել «սփոֆինգ» բառը միայն ցանցային հարձակումների տեսակը պարզաբանելու համար:
Առաջին IDN կլոնները
IDN հոմոգրաֆների օգտագործմամբ հարձակումն առաջին անգամ նկարագրվել է 2001 թվականին Եվգենի Գաբրիլովիչի և Ալեքս Գոնտմախերի կողմից Իսրայելի Տեխնիոն տեխնոլոգիական ինստիտուտից: Այս մեթոդի կիրառմամբ հաջող հարձակման առաջին հայտնի դեպքը հրապարակվեց 2005 թվականին ShmooCon հաքերների համաժողովում: Հաքերներին հաջողվել է գրանցել paypal.com կեղծ դոմենը (xn--pypal-4ve.com Punycode-ում), որտեղ առաջին a տառը կիրիլիցա է։ Slashdot.org-ում հրապարակված մի հրապարակում այս խնդիրը հանրության ուշադրությանն է արժանացել, որից հետո և՛ բրաուզերները, և՛ բազմաթիվ տիրույթների ադմինիստրատորները բարձր մակարդակմշակել և իրականացրել է հակաքայլեր։
Այսպիսով, երբ Ցանցն իր սկզբնական փուլում էր, ծրագրավորողների և մշակողների ջանքերի մեծ մասը հիմնականում ուղղված էր ցանցային արձանագրությունների ալգորիթմների օպտիմալացմանը: Անվտանգությունն այնքան էլ կարևոր չէր, որքան այսօր, և, ինչպես հաճախ է պատահում, շատ քիչ ուշադրության արժանացավ: Արդյունքում, մենք ստանում ենք սովորական և հիմնարար սխալներ ցանցային արձանագրություններում, որոնք շարունակում են գոյություն ունենալ այսօր՝ չնայած տարբեր patches-ներին (որովհետև ոչ մի կարկատել չի կարող կարկատել տրամաբանական արձանագրության սխալը): Այստեղ անհրաժեշտ են տոտալ փոփոխություններ, որոնք առկա ներկայացուցչությունում Ցանցը պարզապես չի գոյատևի։ Օրինակ, «DNS հարձակումներ. երեկ, այսօր, վաղը» հոդվածում (][ #5 2012 թ.), Ես խոսեցի DNS համակարգերի աղետալի հիմնարար խոցելիության մասին՝ UDP արձանագրության օգտագործումը (որը, ի տարբերություն TCP/IP-ի, անապահով է, քանի որ չունի ներկառուցված մեխանիզմ՝ խաբեությունը կանխելու համար) և տեղական քեշ:
Վեկտորներ
Կախված նպատակներից և խնդիրներից՝ խարդախության վեկտորները կարելի է բաժանել տեղական (տեղական) և ցանցային (զուտ) վեկտորների: Հենց դրանք էլ մենք կքննարկենք այս հոդվածում։ Տեղական վեկտորի դեպքում օպերացիոն համակարգն ինքը՝ տեղադրված տուժողի համակարգչում, ինչպես նաև որոշ տեսակի հավելվածներ, որոնք հաճախ պահանջում են լրացուցիչ վերլուծություն՝ կախված իրավիճակից, առավել հաճախ համարվում են տեղական վեկտորի գրոհների առարկա: Ցանցային վեկտորում գրոհների օբյեկտները, ընդհակառակը, ավելի վերացական են։ Հիմնականը բաղադրիչներն են տեղեկատվական համակարգերներկայացված են ինչպես տեղական, այնպես էլ համաշխարհային ցանցերով: Դիտարկենք կեղծիքի հիմնական տեսակները:
- Խարդախություն TCP/IP և UDP - տրանսպորտային շերտերի հարձակումներ: TCP և UDP արձանագրությունների տրանսպորտային ներդրման հիմնարար սխալների պատճառով հնարավոր են հարձակումների հետևյալ տեսակները.
- IP-ի կեղծում. գաղափարն այն է, որ կեղծել IP հասցեն՝ փոխելով աղբյուրի դաշտի արժեքը IP փաթեթի մարմնում: Այն օգտագործվում է հարձակվողի հասցեն փոխելու համար, օրինակ՝ ցանկալի հասցեին պատասխան փաթեթ առաջացնելու համար.
- ARP խարդախությունը Ethernet ցանցերում հարձակման տեխնիկա է, որը թույլ է տալիս գաղտնալսել թրաֆիկը հոսթերների միջև: ARP արձանագրության օգտագործման հիման վրա;
- DNS Cache Poisoning - սերվերի DNS քեշի թունավորում;
- NetBIOS/NBNS խարդախություն – հիմնված է Microsoft-ի ցանցերում տեղական մեքենաների անունների լուծման առանձնահատկությունների վրա:
- Ուղղորդող խաբեություն - ուղղորդողի փոխարինում:
- Ֆայլերի փոխանակման ցանցերի թունավորում - ֆիշինգ ֆայլերի փոխանակման ցանցերում:
- Caller ID-ի կեղծում - VoIP ցանցերում զանգահարողի հեռախոսահամարի կեղծում
- Էլեկտրոնային փոստի հասցեի կեղծում - խաբեություն էլփոստի հասցեներըուղարկող.
- GPS Spoofing - փաթեթների կեղծում արբանյակից՝ GPS սարքը շփոթեցնելու նպատակով:
- Ձայնային փոստի կեղծում - թվերի կեղծում ձայնային փոստզոհի գաղտնաբառերը ֆիշացնելու համար։
- SMS խաբեությունը կեղծելու մեթոդ է, որը հիմնված է SMS ուղարկողի համարների փոխարինման վրա:
Սպոֆինգի ոլորտում վերջին զարգացումները
Ամենատարածված տեխնիկան արդեն բավականին հին է և ծեծված: Համաշխարհային ցանցբառացիորեն լցված տեղեկություններով դրանց գործունեության հնարավոր տատանումների և դրանցից պաշտպանվելու մասին: Այսօր մենք կանդրադառնանք մի քանիսին վերջին մեթոդներըխաբեություն, որի կիրառումը միայն թափ է հավաքում՝ սկսած լոկալ վեկտորներից, վերջացրած ցանցային վեկտորներով։ Այսպիսով, ամեն ինչ կարգին է։
Բոցավառ և սկանդալային Microsoft-ի վկայականի կեղծում
Microsoft Security Advisory (2718704) - Չլիազորված թվային վկայականները կարող են թույլ տալ կեղծում: Բավական հետաքրքիր բանհայտնաբերվել է տխրահռչակ Flamer լրտեսական բոտի պատճեններում. այս չարամիտ ծրագրակազմի բաղադրիչների հակադարձ ճարտարագիտության արդյունքների հիման վրա հայտնաբերվել է ծածկագրի բաժին, որը պատասխանատու է կեղծ հարձակումների իրականացման համար, ինչպիսին է ֆիշինգը: Մոդելավորելով խոշոր ընկերությունների բնօրինակ վկայագրերի տրամադրումը, բոտը իրականացրել է MITM հարձակում, որի նպատակն է եղել գաղտնալսել օգտատերերի անձնական տվյալները։ կորպորատիվ ցանցծրագրավորողների սերվերին հետագա ուղարկմամբ: Խարդախության այս միջադեպը ստացել է Անվտանգության խորհրդատվություն #2718704՝ բարձր գնահատականով:
ՕՀ-ի կեղծում
1. Extension Spoofing - ֆայլի ընդլայնման կեղծում
Տեխնիկա, որը լույս տեսավ ոլորտում չինացի հետազոտողի զարգացումների շնորհիվ տեղեկատվական անվտանգությունԺիտաո Չժոու. Այս տեխնիկայի էությունը ֆայլի անվանման մեջ 0x202E (RLO) կառավարման նիշի օգտագործումն է, որը թույլ է տալիս փոխել նիշերի հերթականությունը ֆայլի անունը ցուցադրելիս: Windows Explorer(explorer.exe) Ահա այս պարզ տեխնիկայի օգտագործման օրինակ.
Սուպեր երաժշտություն՝ վերբեռնված մինչև ժամը 15.00.SCR
3pm.SCR ֆայլը ոչ այլ ինչ է, քան գործարկվող ֆայլ, որն իրականացնում է որոշակի գործառույթներ (Տրոյական. - Խմբագրի նշում): Եթե «3pm.SRC» ֆայլի անվան սկզբում տեղադրվում է կառավարման նիշը 0x202E (տես նկ. 1), ապա նիշերի հերթականությունը փոխվում է, և ֆայլի անունը այլ կերպ է ցուցադրվում Windows Explorer-ում.
Սուպեր երաժշտություն՝ վերբեռնված RCS.mp3-ի կողմից
Ֆայլի պատկերակը փոխելու համար օգտագործեք ցանկացած ռեսուրսի խմբագրիչ (Restorator, Resource Hacker): Այս տեխնիկան նախատեսված է անզգույշ օգտատիրոջ համար, ով կարող է այս ֆայլը սխալմամբ երգել և բացել այն կրկնակի սեղմումով, դրանով իսկ գործարկելով վնասակար ծրագիր: Ցավոք, այս տեխնիկան չի աշխատի Unicode-ի նման Explorer ծրագրերում: Հետևյալը C# կոդը է, որը կատարում է ֆայլի անվան փոփոխություն՝ նախադրելով 0x202E կառավարման նիշը.
Public Sub U_202E (ֆայլը որպես տող, ընդլայնում որպես տող) Dim d Որպես ամբողջ թիվ = ֆայլ: Երկարություն - 4 Dim u Որպես Char = ChrW(823) Dim t Որպես Char() = extension.ToCharArray() Array.Reverse(t) Dim dest As String = file.Substring(0, d) & u & New String(t) & file.Substring(d) System.IO.File.Move(file, dest) End Sub
2. Ֆայլի անվան կեղծում - ֆայլի անվան կլոնավորում
Այս տեխնիկան ներկայացրել է ճապոնացի հետազոտող Յոսուկե Հասեգավան Security-Momiji կոնֆերանսում: Այն հիմնված է զրոյական երկարությամբ նիշերի (ZERO WIDTH Նիշերի) օգտագործման վրա, որոնք ոչ մի կերպ չեն ազդում ֆայլի անվան ցուցադրման վրա (տես նկ. 2): Ստորև ներկայացված են այս կատեգորիայի բոլոր նշանները.
U+200B (ZERO WIDTH SPACE) - U+200C (ZERO WIDTH NON-JOINER) - U+200D (ZERO WIDTH JOINER) - U+FEFF (ZERO WIDTH NO-BREAK SPACE) - U+202A (ձախից աջ ներդրում)
Բացի այդ, հնարավոր է օգտագործել UTF կոդավորումը՝ գոյություն ունեցող ֆայլերի անունները կեղծելու համար։ Այս տեխնիկան հաճախ օգտագործվում է ժամանակակից չարամիտ ծրագրերի կողմից: Իմ տեսադաշտում հանդիպեցի չարամիտ ծրագրերի նմուշներ, որոնք իրականացնում էին նման հարձակումներ: Օրինակ, TrojanDropper:Win32/Vundo.L չարամիտ ծրագիրը (օգտագործվում է phish vk.com, vkontakte.ru, *odnoklassniki.ru կայքերը) օգտագործում է հենց այս տեխնիկան:
%SystemRoot%\system32\drivers\etc\hosts ֆայլը պատճենվել է «clone» hosts ֆայլում՝ UTF «o» (0x043E) նիշով, որից հետո բնօրինակը hosts ֆայլըհատկանիշ թաքնված ֆայլև դրա բովանդակությունը վերագրվել է հետևյալ գրառումներով.
92.38.66.111 odnoklassniki.ru 92.38.66.111 vk.com 92.38.66.111 vkontakte.ru
Վեբ բրաուզերի կեղծում
1. Կարգավիճակի գիծ / Հղում խաբեբա
Մեթոդը this.href=" :
Մեթոդի location.replace(""):
Methon location.assign("") :
Մեթոդ window.location.assign(""):
Մեթոդ window.location.replace(""):
Մեթոդ window.location.href="" :
Վերոնշյալ HTML կոդը դինամիկ կերպով փոխարինում է նշված հասցեն ( www.google.com) կայքի հասցեին ][ () տարբեր մեթոդների միջոցով՝ հիմնված onclick="" JavaScript իրադարձության վրա:
2. URL Bar Spoofing - բրաուզերի հասցեների տողում հղումների փոխարինում
Առաջին հայացքից սա անհնարին է թվում, բայց հավատացեք, սա ընդամենը հնարամտություն զարգացնելու խնդիր է: Դիտարկենք CVE-2011-1452 խոցելիությունը, որը խաբում է հասցեագոտին անպարտելի Google Chrome-ում մինչև 11.0.696.57 տարբերակը:
սեղմիր ինձ
- բացվում է նոր պատուհան (spoofing.php)՝ հանձնարարելով «a» փոփոխականին;
- 4500 միկրովայրկյան (4,5 վայրկյան) հետո (window.setTimeout ֆունկցիա), նավիգացիայի պատմությունը հետ է վերադարձվում, որի համար պատասխանատու է «a» փոփոխականին վերագրված a.history.back() ֆունկցիան.
- 5000 միկրովայրկյան հետո «a» փոփոխականը տեղադրվում է spoofing.php-ի նոր վայրում, որը գտնվում է նույն գրացուցակում:
Այսպիսով, հասցեի տողը վերագրվում է նոր URL-ի «ծնող»-ի առաջին էջի համատեքստում:
Հաջորդ խոցելիությունը CVE-2010-4045 է (Opera<= 10.62):
Հայեցակարգի ապացույց - OPERA High Location Bar Spoofing
Երբ սեղմում եք կոճակը, որը ներկայացված է նկարով (), էջը ավտոմատ կերպով վերաբեռնվում է (location.reload ()), մինչդեռ հնարավոր է վերագրանցել հասցեի տողը ընթացիկ ներդիրի համատեքստում:
"); myWindow.focus(); return false; }
Երբ սեղմվում է Դեմո կոճակը, և՛ փոփոխականը, և՛ myWindow օբյեկտը սահմանվում են ֆունկցիայի արժեքով, որը բացում է apple.com-ը 200 × 100 չափերով, որը շարժական սարքերի համար նախատեսված Safari բրաուզերի ընդլայնման շրջանակն է: Հաջորդը, myWindow-ը ներարկում է լրացուցիչ HTML (JavaScript/VB/etc) կոդ՝ օգտագործելով document.write() ֆունկցիան: Վերջին քայլը Safari բրաուզերի ուշադրության կենտրոնում myWindow օբյեկտի վրա դնելն է:
Բրաուզերի հասցեագոտում հասցեների կեղծման մեջ ոչ մի բարդ բան չկա, միակ բանն այն է, որ դուք պետք է ճիշտ կիրառեք ձեր հնարամտությունը այնտեղ, որտեղ դա պահանջվում է ;-):
3. Source Code Spoofing - էջի բովանդակության և սկզբնական կոդի փոխարինում
Գործողությունն իրականացվում է մեզ արդեն հայտնի UTF-8 կառավարման նիշի 0x202E (RLO) շնորհիվ: Մեթոդը հայտնաբերել է Virginia Tech-ի ուսանող Ջոն Կուրլակը: Տեխնիկան ցուցադրելու համար նա օգտագործել է History.replaceState() JavaScript ֆունկցիան, որը թույլ է տալիս դինամիկ կերպով փոխել էջի հասցեն հասցեագոտում։ Հայեցակարգի ապացույց (source.html):
Կարո՞ղ եք դիտել իմ աղբյուրը Chrome-ից:
Source.html[%20%2E] Դուք կարող եք, բայց ոչ այդքան հեշտ...
Այս մեթոդի էությունն այն է, որ էջի սկզբնական կոդի բովանդակությունը հնարքի միջոցով փոխարինվի ֆայլի վերջում RLO կառավարման նիշով (տես Նկար 4): Երբ փորձում ենք դիտել source.html էջի սկզբնական կոդը, մենք ստանում ենք երկրորդ ֆայլի բովանդակությունը source.html%20%2E: Բավականին հետաքրքիր և էկզոտիկ խարդախության մեթոդ՝ շատ տարօրինակ շահույթով, ինչպես դա կարող է թվալ ձեզ առաջին հայացքից։ Ինչն է ամենահետաքրքիրը՝ այս սկրիպտը թույլ է տալիս «թաքցնել» էջի սկզբնական կոդը՝ քողարկելով այն ոչ միայն հասցեի, այլև հյուրընկալողի անվան համատեքստում։
4. IDN Clones - տեխնիկա, որը հիմնված է դոմենների անունների ցուցադրման արտաքին նմանության վրա
Այստեղ նորարարական ոչինչ չկա, տեխնիկան կիրառվել է DNS համակարգի հենց սկզբից, բայց դա IDN-ի (Internationalized Domain Names - միջազգայնացված տիրույթի անուններ) օգտագործումն էր, որը հնարավորություն տվեց ստեղծել դոմեյնների գրեթե չտարբերվող «կլոններ»: . Ֆիշինգի հարձակման տեխնիկական իրականացումը հետևյալն է.
- Գրանցված է տիրույթի անուն, որն ուղղագրությամբ հնարավորինս մոտ է հարձակման ենթարկված տիրույթին: Սովորաբար օգտագործվում են տառերի նմանությունը որոշ տառատեսակներում թվերի հետ (l տառը և 1 թիվը, O տառը և 0 թիվը), տառերի համակցությունների նմանությունը (rn և m, cl և d):
- Ստեղծվում է օրիգինալ կայքի կեղծիք, որը տեղադրվում է ստեղծված «կլոնի» վրա։
- Ֆիշինգ տիրույթի հղումները բաշխվում են (փոստի սպամ, սպամ սոցիալական ցանցերում, հանրահայտ ծառայությունների միջոցով, ինչպիսիք են Twitter-ը, iframes-ի օգտագործումը, դռների մուտքերը):
- Ստացվում է շահույթ :):
Դոմենների անունների նմանության վրա հիմնված այս հարձակման հիմնական տարբերությունը կեղծ վեբ էջերի օգտագործմամբ ֆիշինգի այլ տեսակների համեմատ այն է, որ այն չի պահանջում միջամտություն ցանցային արձանագրություններին. տեխնիկական տեսանկյունից կեղծ տիրույթը օրինական է:
IDN-ի հարձակումներից պաշտպանվելու մեթոդները սկսեցին ներդրվել 2005 թվականի կեսերին, երբ դոմենային անունների ռեգիստրատորների կողմից ընդունվեցին համաձայնագրեր, որոնք սահմանափակում էին ցանկացած IDN տիրույթ գրանցելու հնարավորությունը։ Այսպիսով, միջազգային domain.org-ը սահմանափակում է թույլատրելի նիշերի քանակը ընդլայնված լատիներենի այս կամ այն ենթաբազմությամբ: Բայց որոշ անբարեխիղճ ռեգիստրների և հնարամտության շնորհիվ նույնիսկ այսօր բոլոր հնարավորությունները կան ֆիշինգ տիրույթ գրանցելու համար։
Հոմոգրաֆիկ սպառնալիքի դեմ ամենաարմատական պաշտպանությունը կլինի ցուցադրված IDN-ների վերծանումից ամբողջությամբ հրաժարվելը: Այնուհետև կեղծանունը միշտ սկսվում էր «xn»-ով և ավարտվում նիշերի անընթեռնելի հաջորդականությամբ, որը կտրուկ կտարբերեր այն բնօրինակից։ Ցավոք, այս տարբերակը ժխտում է IDN-ի գրեթե բոլոր առավելությունները:
Հաճախորդի կողմից IDN-ի կեղծման դեմ հիմնական պաշտպանությունը բրաուզերի կարգավիճակի տողն է: Երբ սավառնում եք կարգավիճակի տողում գտնվող հղման վրա, ցուցադրվում է IDN տիրույթի punycode համարժեքը, որն անմիջապես հուշում է հնարավոր ֆիշինգի մասին: Բայց սա էլ համադարման չէ, դուք կարող եք խաբել ամեն ինչ, եթե օգտագործեք ձեր հնարամտությունը ;-): Տես իմ ունիվերսալ շահագործումը բոլոր բրաուզերի շարժիչների համար:
Եզրակացություն
Խարդախությունը միշտ եղել է և կլինի պահանջարկ, քանի որ այն հիմքն ու երաշխիքն է բազմաթիվ ուղղություններով հաջող հարձակումների համար։ Հուսով եմ, որ դուք ճիշտ եզրակացություններ եք արել: Զգույշ եղեք ինտերնետում.