BSides Sofia 2022: Decrypting IPTV

1:22↗Има някаква интерактивност. Там можете да превъртате, да спешите. се спири на пауза, да се пуска, което е прави така по-привлекателна като услуга с прямо тази телевизия, ефирната. И всъщност това, което е много важно с отгледна точка на секьюрити е, че обикновено се деливърва с сет от боксове,

1:45↗за които ще говоря малко по-късно. И се така се използват

1:51↗различен сет от различен набор от протоколи. Различите доставчици ползват

1:57↗различни неща, но в общия случай се ползва IGNP, RTP, RTSP, UDP.

2:04↗В тази презентация всъщност ще покажа... всъщност фокуса ще е върху IPTV услуги, които се достават в България, но като цяло тия неща са валидни in general, понеже софтуерния стек, който се ползва тук, се ползва и на много други места.

2:23↗Как изглежда IPTV диплайната най-общо? Имаме някакъв set-up box, който е свързан към доставчика по LAN и към телевизора по HDMI. И може да се управлява с някакво истинно чурално. Е 1, 2, 3, 1, 2, 3. Сега тук правя предположението, че IPTV провайдъра е същия като интернет сервис провайдъра, който в повечето случаи е така. Понеже е...

2:52↗Повечето случаи контента се деливърва на Multicast, както ще видим. Така че,

2:58↗тук правим асъмпшена, че IPTV и ISP провайдъра е един и същ.

3:07↗Какъв е, ощето къв е секьюрити модела на това нещо? Ами, според мен, от user experience гледно точка, от толкова време имам IPTV, според мен, сърщита на предимно

3:26↗предимно на това, че едва ли не само след топ-боксовете знаят как да плейват този контент. И че след топ-боксовете могат единствения юзер интерфейс, който има потребителя, реално е някакво дистанционно, което клика. И като цяло, ако трябва въобще да се речи на security, true obscurity, това е такъв антипатърн.

3:51↗което всеки знае, че принципно това нещо не работи.

3:57↗И в тази презентация ще ви покажа какви са проблемите.

4:04↗Като цяло проблемите са, че примерно не е нужно да се плаща за някакви допълнителни канали. Повечето на IPTV провайдери имат някакви пакети с телевизионни канали и може да доплащаш да гледаш още.

4:22↗Също това да добавяш още set-то боксове, също не е така безплатно. И като цяло, ще стая ясно, че в общия случай даже не е необходимо да се плаща за IPTV. Но така, първо, какво представлява set-то бокса, който се използва за от IPTV провайдерите. В най-вощия случай е някакво ефтино устройство, произведено в Китай, което въобщето е

4:58↗максимално рязано с цел да е максимално ефтино, което няма нищо лошо в това няма.

5:06↗Почти със сигурност рънба Linux с някакъв ARM систем на чип.

5:12↗И саме интересът е какъв фармулера има. Фармулера също представлява един HTML браузър,

5:19↗и един видеоплеер. И този видеоплеер въобще случай се управлява с някакъв JavaScript. Тук не е типичен видеоплеер, който го има в модерните интернет браузъри. В интернет браузърите вече така е, майче не имаме пев видеоплеер. Не, тук е нещо друго. Този видеоплеер е такъв специално направен за

5:43↗тия девайси. Управлява се от JavaScript и И има някакви там харддверни видеодекодери. Разчитано маха някакви харддверни видеодекодери в общия случай.

5:55↗И другото нещо е всъщност какво представлява юзер интерфейса на това цялото нещо. Оказва се, че представлява всъщност HTML и JavaScript. Тоест това нещо, което го виждате, това всъщност е HTML страница и като цъкаме там с дистанционното, това всъщност е

6:13↗интеракцината с някакъв JavaScript.

6:19↗И понеже започна с малко история, понеже доста време е след да какво... През времето ми е било интересно как работа цялото нещо, както и интернет в началото, голяма част не беше криптиран. Така и през

6:36↗2016-та, когато реших да видя какво върви по мрежата, също се оказа, че реално всичко върви в plaintext. Тук на този скриншот се вижда някакъв дъмп на Large Shark, в който може ясно да видиме, че какво праща след Top Box. Праща някакви команди по RTSP. RTSP е Real Time Streaming Protocol и просто казва, тук е малко транкетното, но казва Play,

7:08↗някакво IP, CH и някакво ID, което е 20 цифра.

7:17↗И всъщност какво се оказва? Ами оказва, че няма никаква сервер сайт-ауторизация. Значи този проблем въобще беше във всяка една презентация от тук. Пропочваме с школа ОБГ, където там може да се оказва, че като сменим някакво ID на подзаявка, може да получим достъп до някакви данни, които не са наши. И после с CV-чарджерите видяхме, че като смениме нещо в рекуеста, може пак да получиме... Общето проблема е, че

7:44↗много често няма сервер с сайта-ауторизация. Това, че си е аутентикиран, означава, че имаш права нещо да правиш. И тук в случая не е

7:57↗точно API, значи в случая IPTV провайдър разчита на това, че само

8:04↗някакви девайси с определени MAC адреси могат да го достъпват. От там нататък всичко е... няма authorization, т.е. ако реша, примерно, да прата заявка за някакъв друг канал, достатъчно е да знам неговото ID. А тези ID-та всичките ги има в JavaScript-та, който върви по мрежите, който също е plain text. Включително и на разни платени канали. И в този момент, въобщето, почнах да си мисля какво може да се направи. Първата ми идея беше просто да смена асет топ-бокса с някакъв мой девайс, който говоря този протокол и който може да плейва целия асет

8:57↗от канали, припочвен, че знам всичките има ID-та. Но това нещо не е много интересно и отнема някакво време. И всъщност

9:09↗това, което е по-лесно да се направи, е просто тези ID-та

9:15↗да ги сменяме с някакъв Man in the middle. Тоест да променяме трафика и просто да реплейсваме ние ID-та с други ID-та. Понеже така или иначе в повечето до IPTV доставщи, примерно 200 канала, 80% така или иначе не стават загледане. Може просто да реплейснеме някакви някакви канали, които не стават с някакви по-интересни, които са платени в общия случай.

9:44↗И за това нещо така направих един малък тул, който се е наречен FQSET, който ползва NetFilter Q библиотеката на Linux. Това е библиотека, която може да интерсептва и модифицира network traffic. И това нещо цялото може да се диплойна на едно Raspberry Pi. Тоест... Имаме едно Raspberry Pi, което стои между доставчика и сетто от бокса, рънва моята програма и реплейсва някакви стрингови. И тук същественото е, че тия ID-та са с фиксирана дължина. Тоест винаги са CH и някакво 20-цифринно число, което до някъде улесня нещата. Изглежда по този начин. Тук на тази снимка някакво Raspberry, което е включено. Билдин на адаптера, нетворк адаптера му е включен към провайдера и има някакъв USB нетворк адаптер, който е включен към сеталбокса. Двата адаптера са бриджнати и рънва тази моята програма, която реално реплейсва някакви стрингове с ченалайдитата. Но всичко това нещо беше преди 6

11:00↗години, не е че толкова интересно, Как работят нещата днес? В момента повечето IPTV доставчици използват Multicast за лайвстримовете. Защо Multicast?

11:19↗Multicast е ефективен заради това, че може един пакет да не пращаш копия до всички абонати, да го изпратиш венъж и мрежвата инфраструктура да го отдаде на всички. И реално се използва IGMP протокола, за да

11:39↗се джойваме към различни Multicast групи, т.е. там се прави Join и Leave, когато случваме някакви канали, реално след ТОП-бок се прави IGMP рекуести.

11:51↗И затова нещо, мали има dedicated Multicast-та има dedicated IP range от 224.0 до 239.255.

12:03↗И всъщност първото нещо, което бихме се опитали да направим е по същия начин да видим какво вари по мрежата. Може да видим, че IP-то, което е от Multicast Range, порта, протокол е RTP. И сега примерно да видим какво става, ако го пленем с VLC и виждаме, че

12:29↗не се вижда нищо. Равно стрима не гледаем.

12:37↗Обаче VOSITO ни дава някаква информация за него.

12:43↗Виждам, всъщност знам колко добре виждате, но VOSITO казва, има аудио стрим, който е MPEG 2, има видео стрим, който е MPEG 2 и същото интересото е, тук показва някакви данни за този стрим. И метът данните са, че Примерно програмата се казва 24 Kitchen и най-интересно което е, че е scrambled. Тоест по някакъв начин криптирана.

13:14↗Това нещо... От къде идват тия метаданни?

13:21↗Използва се MPEG Transport Stream, който представлява мултиплексиране на много така наречени elementary streams. Elementary Stream е Video Stream, Audio Stream и разни Metadata Streamове, от които примерно един от тях е програм Map Table. Този

13:39↗от там може да се вземе името на програмата, както го виждаме, VLC-то не казва, че това е 24 Kitchen. И другите интересни метът данни, които всъщност

13:50↗са най-интересни, е така наречените Entitlement Control Messages or ECM пакети.

13:57↗които участват в декриптирането на контента.

14:04↗Ето по този начин изглежда един MPEG Transport Stream пакет. Общо е 188

14:11↗байта дълъг. Започва с 4 байта header. В началото има SYN byte. И тук интересното е, има два бита в този header, които се наричат Transport Scrambling Control. И те казват дали payload-а който е 184 байта, е скрэмблт, т.е. скриптиран. И всъщност VLC-то, когато ни казва, че

14:36↗е скрэмблт стрим, а всъщност това са тия два бита в хедер, които го показват.

14:44↗Така, и почнат да правим ресурс, че въобще това нещо как работи, каква достъпна информация има за него. Оказва се, че има така нареченото Conditional Access System, or CAS, които представляват стандартни методи за оплоскиране на цифрови стримове и които всъщност най-често се ползват за сателитна телевизия. Има ги листнати в Лукипедия, тук съм извадил някаква много малка част от тях. Идеята е да се дава достъп само на потребители, които са ауторизнати по някакъв начин.

15:27↗И всъщност това, което ползват сателитните телевизии, които ползват Agenda National Access System, е, че има такъв алгоритъм, как казва се, DB Commons Screaming алгоритъм, който реално прави това криптиране. Да, обаче се оказва, че всъщност IPTV IPTV, conditional access системите, всъщност не работят още така. И примерно, тук големите

15:57↗IPTV доставчици, разни телекоми, ползват VeriMatrix вендор, който... Всяка такава система също изима и ID, което също може да се види от мета-даните на стрима. И примерно, аз видях, че ID-то е 5601, по този начин, разбрах, че става въпрос за VeryMatrix,

16:20↗някаква система за криптиране. И сега, нали, в общеседното няма никаква налична информация как работа това нещо. Същност единствената публична информация е това, което съм качив в GitHub, освен някакъв маркетинг там, bullshit. И всъщност,

16:40↗точно това е нещо, че всъщност цялото това нещо работи на базата на това, че хората не знаят какво точно става. И всъщност,

16:52↗ако трябва да погледнем как работи стелитната телевизия, имаме някаква антена, която приема сигнал от спътник. Пак има след това бокс, обаче тук разликата е, че след това бокса има смарт-карта, която си купуваш, за да гледаш някаква услуга. И начинът по който работи това нещо е, че

17:18↗Тези ECM пакети носят така наречените кодворци, които са криптирани и след то боксът ги декриптира с помощта на смарт картата. И съответно получава

17:29↗декриптираните кодворци и с тях декриптира стрима с този алгоритм, който там Common Scrabling алгоритема. Така и сега за IPTV нещата са много подобни. Нямаме сателитна чиния, имаме някакъв провайдър, който пак едно посочно доставя някакъв стрим само че по мултикаст. И имаме C-top box, който няма смарт карти и съответно за да се декриптира този стрим сигурно има някакви ключове някъде, които го декриптират и може вече да се гледа на телевизор. И сега почнах как да разберем от къде издат тия ключове. Единствения начин е да да рутнем бокса и да ревърс инжинирнаме формуера. Така има добре известни начини как може да се рутне някакъв Linux девайс. Най-популярният е да намерим оставена

18:34↗серия на конзола, която на реално са някакви пинова на платката,

18:41↗които може да получим които може да свържеме и да получим достъп до Bootloader или директно RootShell. Това нещо върви на 3PIN, RX, TX и MASA. Единствено трябва да знаем BALDRAID, който също са там разни фиксирани стоености. И повечето такива хардверни вендори оставят

19:06↗такава конзола отворена. и това е най-честия метод за рутване на Linux Device. Другия метод е с JTAG. JTAG е low-level дебъгък интерфейс, който пак вендорите оставят за дебъгване след като девайсът е произведен. С него реално може

19:30↗да тресваме на много ниско ниво, може да променяме execution floor, може да променяме памет, И за тези двата начина,

19:41↗първият, трябва да намерим някакви три пина на платката, за JTAG са повече. Има един туго, който се назва, че JTAG ULator, който може просто да го закачиш към някакви пинове и той да намери тия интерфейс, да каже тия три пина са серия на конзола или тия четири пина са JTAG. Тоест автоматизира до някаква степен това нещо.

20:11↗Най-адвансата начина е с така наречената Power glitch атака. Това е когато подадеме някакъв transient voltage

20:23↗на девайса за няколко nanosecundi, което го кара да си, примерно да скипне някакви инструкции във формуэра или да прескочи някакви чекове.

20:35↗Това е доста advanced. Съзнателя на този JTAGULATOR, Джо Грант,

20:41↗наскоро публикуе едно видео, как при него идва някакъв човек с някакъв хардуер-волет, на който държи ключове за биткоин за няколко милиона долара, на който му е забравил PIN-а. И Джо Грант успява с такава power glitch, така да го отвори доста интересно. Може да го гледате много...

21:08↗Това, което ползвам мас и което работи от 10 години за тия боксът, които ги има в България е... Зимата е на Arduino, махът е му процесора и поставя само като USB to serial converter. Зимата е 3 жици, значи масата се намира много лесно, от граунда се намира много лесно и единствено RX и TX трябва да намерите къде е на платката. Обслед това нещо работи.

21:38↗И получаваме Root Shell. Трябва да погледнем какво има на статалбокса. Има някакъв процесор ARMv6 на О100 МГц. Рънва някакъв много стар керния от 2635. И това нещо има 512 МБ РАМ.

22:03↗И сега въпросът е как да ревърснем формуера. Значи трябва или защо ни е да ревърснем формуера, трябва да отговорим на два основни въпроса. От къде идват ключовете, които декриптират стрима и как се използват. Понеже очевидно не е този Common Screaming algorithm, а нещо друго. В моят случай и двете неща се правиха в една shared library, което се нарича LibVM Client. И тук VM най-често, според мен е скритен от VeryMatrix. Туловета, които използвам аз са

22:39↗за reverse engineering, са Gidra, това е на NSA Tool, Disassembly Deck Compiler

22:45↗и GDB, стандартният дебъггер. Gidra е използвана с статичен анализ, GDB за runtime анализ. Това, което всъщност ви трябва да пуснете GDB сервер на бокса, да го атащнете

23:03↗към процеса на видеоплеера, който всъщност линква това library и на вашата машина да се атащате вече ремонтли към GDB сервера и вече може да слагате breakpoint и да гледате памет и така нататък. Значи,

23:21↗всяко нещо, което по някакъв начин ползва някаква криптография, е много вероятно да ползва OpenSSL. И в случаят още такъв, ако грепнем OpenSSL в стринговете на това лайбрари, ще видим, че се използва OpenSSL версия

23:39↗1.0.0.d. И всъщност метода, който използваме аз, който работи не само за... Като като цяло, нали... според мен е най-популярният, понеже OpenSSL, така очевидно, е статично литнат към това лайбрари, трябва да идентифицираме къде в това лайбрари са OpenSSL функциите, за криптиране, подписване и вече като ги знаем тях, може да сложиме breakpoint-ти с GDB, да видим какви са ключовете и как работа цялото нещо.

24:17↗Всъщност това е някаква част от декомпилирана функция с гидра.

24:22↗Получава се някакъв псевдо си код, който е доста четим. И примерно тук в тази функция може да видим, че някаква функция с 4 параметра. Примерно алокираме някакви данни на стека. На рече 16 сетваме 3-я параметр да е 0. После викаме някаква функция с данните от стека. След това викваме някаква друга функция пак с тия данни, приема на ред 18

24:51↗и с първия параметр. И след това следващата част е,

24:57↗която всъщност е така жокера. Нали на ред 29 виждаме някаква константа п подчертавка sine.c. И след това 0xrmd. А на ред 35

25:09↗п подчертавка sine.c 0x83. Това много прилича да е именно source файл и линия, и линия, нономерна линия. И ако погледнем source-а на OpenSSL, вече знаем версията, че е 00D, просто идем в GitHub, отворим така 00D, намерим файла psign.si и примерно погледнем функцията SignFinal, която се използва за подписване.

25:39↗Ще видим, че тя приема 4 параметра. В началото алокира там някакъв контекст в стека. На ред лос 76 и сетва третия параметр да е 0.

25:51↗И после този контекст вика някакви други функции с него.

25:57↗И по-нататък има някакво utility, което се нарича EVP Error, което всъщност е Macros, който използва File и Line макроса, за да викне някаква функция, която се етва някакви error кодове. И е тук, не знам дали се вижда нещо, но отляло стои декомпилираната функция в Hydra, отясно стои и сорса на EVP Sign Final и може е много ясно така да матчнем. Примерно 0x7d, където беше след P-Sign, е точно 16-тично, е точно 125-ти десетично, както виждаме.

26:36↗0x83 съответства на ред 130.0 в коза на OpenSSL. Т.е. това наистина е така. И по този начин реално можем да видим функциите на OpenSSL, къде са в това library. Можем да сетнем breakpoint и да гледаме какво става. Подписването с OpenSSL се прави с тези три функции. Първо се инициализираме някакъв контекст и някакъв дайджест алгоритъм, после викаме апдейт с някакви данни и накрая казваме Sign Final, като подаваме частния ключ. И нас съобщето ни интересува този частен ключ. След като сме идентифицирали коя функция е Sign Final, може да сложим breakpoint и да видиме какъв е частния ключ и съответно какво се подписва с него. И първо След като имаме този RSA Key, което също се използва за Authentication,

27:33↗вече какъв е протокола за да вземеме самите Channel Key, с които е критиран стрима. И тук има някакъв много Basic протокол, което някой е дизайнвал през 90-те години сигурно.

27:47↗Този Key Server, който аз наричам VCAS. Първо, бокса

27:55↗му казва, нали, дай ми сешен ключ, това ми е MAC адреса, той връща някакъв RC4, това е такъв стрим, Cypher ключ и някакъв таймстамп,

28:07↗и после боксът казва, дай ми всички ключове,

28:13↗и прави MD5 на този таймстамп, подписва го с RSA ключа и го криптира с RC4 и сешен ключа, и в резултат на това получава всички ченалки, един ченалки представлява 128 битов симметричен IS-ключ.

28:32↗И това цялото нещо, понеже провайдерите реално разрешават този кейс сервер да го аксесва само след това боксовете, т.е. направили някакви firewall проява само за техните MAC адреси. Това, което правя аз е да използвам S-Sage и да и бокса като JumpHost.

28:56↗Пускаме порт-форвардинг с SSH на това IP и на тия портове. Вече може да викаме, може да, приема с скрипта, който тегли ключовете, да го равнаме срещу localhost. По този начин заобикаляме този

29:16↗firewall на провайдера. Как се ползват тези channel keys?

29:25↗Чанал Киа декриптира ECM пакетите. ECM пакетите декриптират два ключа,

29:33↗четен и нечетен, и тези ключа декриптират TS пакетите. Като

29:39↗чанал Киовете се сменят на всеки 24 час, другите два ключа се ротейтват на всеки 10 секунди и това нещо е достатъчно. Цялото това нещо съм го имплементирал в една малка програмка на моя GitHub, каза се VND Crypt.

29:57↗Проблема с цялото нещо е, че тези channel kill-ве, те се ротейтват на 24

30:03↗часи и може много лесно да се share-ват. Тоест достатъчно

30:11↗някой, който ги е изтеглил, да ги качи някъде и после всеки

30:17↗всеки, който има достъп до Multicast стримовете, може да ги декриптира. А всъщност се оказва, че тия криптирани Multicast стримове стигат до абсолютно всички клиенти на провайдера. Не само тези, които се плащат за IPTV, ами до всички. Тоест достатъчно е един човек да ги публикува веднъж на 24 части ключове и въобще всички могат да гледат free. Този...

30:44↗Същия хак го има и за сателитната телевизия, там със шерването на ключовето с смарт картите. И като накрая, какво трябва да обобщи, Security, True Obscurity

31:00↗обикновено не работи. Както видяхме, трябва ни освен на authentication също и authorization.

31:07↗Това нещо с този проблем, някакви някакъв контент да се деливърва на Multicast криптиран и разни хостове да го декриптират. Същност се нарича Multicast Encryption. Няки хора са го изследвали, има писани стати по въпроса. Не е прост проблем.

31:25↗И според мен е едно от потенциалните решения на това нещо, за да стане Secure с Confidential Computing. Това въобщето представлява използването на

31:38↗на това, което съвремените процесори имат като Secure Enclaves, примерно ARM имат, Тразон, Intel имат SGX, AMD имат SEV. Общото това е някаква технология, която позволява някакъв код да се рънва в изолация и да не може просто да започиш и дебагер към него, нищо, че си рулт. И това е всичко, което имам, ако имате въпроси.

32:33↗Ами не. Всъщност това, което наблюдавам аз е, че абсолютно всички канали, платени, тези, които се доплащат, те върват на Multicast. Просто Провайдър, който прави е просто да каже на все то бокса вече да ги плейва и тях. Тоест, ако нищо не ти пречи, ако имаш киловете, да гледаш абсолютно всички канали, които този доставчик предлага.

33:12↗Да. Да, като етикейшно става по макът, раз така че би трябва да работи. Да.

33:27↗Да.

33:47↗Да, за всяк филионукс устройство работа.

33:54↗Ок бъдаря.