По-миналата седмица попаднах на статия в Капитал как SPAM регистърът на КЗП получил дарение. Определено се зарадвах, че са направили нещо, което да опростява справките в регистъра и следователно да го направи по-ефективен. Когато погледнах отблизо зъбите на харизания кон обаче, ми стана ясно, че стъпката е отново в страни. Технологичното решение, което колегите са предложили е .NET desktop приложение, към което се сваля криптиран файл със съдържанието на регистъра. Проверката става, като потребителя изготви файл с електронните адреси на получателите, а приложението го филтрира в съответствие със съдържанието на регистъра.
От това веднага трябва да е станало ясно, че ключа за декриптиране вероятно е забит в самото приложение. След прилагането на не-чак-вуду-техники (strings and friends), нямащи нищо общо с reverse engineering, става ясно, че регистърът е криптиран с DES-CBC, а 20 минути по-късно декриптирането се свежда до една команда с OpenSSL:
alex@volatile:~$ openssl des-cbc -d -K [find_it_youself] -iv 00f00ab00bc00cf0 -in 29112010.TXT -out spam.txt
Разбира се, изпратих поща на КЗП за проблема, описвайки и възможността недоброжелател да декриптира регистъра и да го постне по руските и китайските спам форуми. След това резултатът е ясен, а действието ефективно ще подкопае и без това крехките устои на SPAM регистъра.
Отговор вече повече от седмица няма.
[…] This post was mentioned on Twitter by Vasil Kolev, Marian Ignev. Marian Ignev said: RT @krokodilerian: Идиотизма на българския spam регистър: http://alex.stanev.org/blog/?p=267 […]
Евала за цялата работа, само рециплиент не разбрах съвсем какво значи :D
Жалко е, че отговорните си траят за това, че си им посочил проблема.. Човек ще трябва да си застане на главъта, за да накара някой да си свърши работата като хората :/
:-D Доста странно наистина – аз съм правил примерно и в нея се въвеждат булстати, егн или IBAN един под друг и PHP ги проверява за коректност. Обаче в случая според мен, искат да изнесат цялата изчислителна задача на компютъра на потребителя, който ще проверява списъка. И по този начин реализирано, наистина е доста лошо решение.
Не мисля, че чак толкова ще им се претоварят системите, от някакво уеб решение. Могат да се измислят различни “хитринки” за да не се претоварва и да не се злоупотребява с него.
Определено един WebService или REST или каквото друго им дойде на ума ще е по-добро решение. Интеграцията във външни приложения ще е тривиална, а както сами виждате текущия обем на регистъра е нищожен. Компаниите изпращащи “непоискани търговски съобщения” (aka SPAM), ще трябва да се регистрират, за да използват API-то, а за да се спести трафик, може да се ограничи броя на заявките от една система в рамките на деня. Странични ефекти: списък на спамърите (публичен, за да могат някои администратори да си пипнат firewall-а ;) + ограничение на броя на законно изпратения боклук.
Мечтиииии…
Ми то аз като гледам от всичките 309 ентрита към днешна дата, голяма част са домейни, а не имейл адреси.
Което е и добър подход, стига домейнът да не се използва споделен – примрено с пощенска услуга. Защото по презумпция, може и да искаш да си получаваш “далаверите”.
Замислял ли се е някой, защо да не е обратното – ако искаш да получаваш непоискани – пишеш да те включат в регистъра, а по подразбиране – забранено ;) Подозирам, че доста работа ще им се отвори в такъв случай на КЗП :)