{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Заметки Андрея Гейна: posts tagged csv", "_rss_description": "Блог Андрея Гейна: заметки о жизни, программировании, преподавании и дизайне", "_rss_language": "en", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/andgein.ru\/blog\/tags\/csv\/", "feed_url": "https:\/\/andgein.ru\/blog\/tags\/csv\/json\/", "icon": "https:\/\/andgein.ru\/blog\/pictures\/userpic\/userpic@2x.jpg?1631100411", "authors": [ { "name": "Андрей Гейн", "url": "https:\/\/andgein.ru\/blog\/", "avatar": "https:\/\/andgein.ru\/blog\/pictures\/userpic\/userpic@2x.jpg?1631100411" } ], "items": [ { "id": "2", "url": "https:\/\/andgein.ru\/blog\/all\/2-phdays-ctf-2017-service\/", "title": "Заметка вторая. О сервисе на PHDays CTF", "content_html": "

Продолжение истории о необычном поведении<\/a> юникода и CSV в питоне<\/i><\/p>\n

Для тех, кому лень читать предыдущую заметку или вспоминать, о чём там было<\/h2>\n
Если использовать стандартные питоновские codecs.open<\/a>, csv.DictWriter<\/a> и csv.DictReader<\/a>, то можно столкнуться с интересным поведением. Создаём в программе файл в кодировке UTF-8, пишем туда с помощью DictWriter, а затем читаем через DictReader. Если в данных встречались юникодные символы Pararaph separator или Line separator, то мы считаем больше записей, чем было записано, а их CSV-структура будет поломана.<\/p>\n
Читайте первую заметку<\/a> для подробностей.<\/p>\n
Как из этого получился сервис для классического CTF<\/h2>\n
В апреле мы с ребятами из Хакердома как раз готовили онлайновый CTF для форума PHDays<\/a>. Темой был выбран интернет вещей, а сервисами были умный чайник, термометр, дверной замок, телевизор и даже холодильник. Мне достался последний, потому что я слишком люблю еду.<\/p>\n
Чтобы органично встроить уязвимость в сервис, мне нужно было сделать так, чтобы кто-то писал в CSV-файл, а кто-то другой — читал. В итоге сервис состоял из двух частей — веб-приложения для удобного управления человеком и API для других умных кухонных гаджетов, которым нужна информация от холодильника.<\/p>\n
Веб-интерфейс позволял пользователям регистрироваться и создавать холодильные камеры или просто холодильники. У каждого холодильника был владелец, и увидеть чужие просто так нельзя. В холодильники можно добавлять еду. Для этого сначала было необходимо зарегистрировать новый продукт (например, картошку или молоко) и указать, в чём он измеряется — в граммах, пачках или литрах. Выглядело это так:<\/p>\n
\n
\n $\"\"$ \n $\"\"$ \n $\"\"$ \n $\"\"$ \n $\"\"$ \n<\/div>\n<\/div>\n
Кроме холодильников можно было создавать рецепты. Про каждый ингредиент рецепта известно, сколько и какого продукты нужно положить, а также что с ним надо сделать и сколько после этого подождать.<\/p>\n
\n $\"\"$ \n<\/div>\n
Рецепты были очень важны для функционирования сервиса, ведь в том самом API было всего две команды — получить список твоих холодильников и получить список рецептов, которые можно приготовить из еды, лежащей в одном из твоих холодильников. Звучит сложно, но идея очень простая — если у вас есть умная мультиварка, то она хочет узнать, какие блюда можно сегодня приготовить из продуктов, лежащих у вас в холодильнике.<\/p>\n
Принадлежность выдаваемых рецептов владельцу холодильника в API не проверялась, но должно было работать само: в рецепте должен присутствовать хотя бы один продукт из холодильника, а в холодильник мы можем добавлять только принадлежащие нам продукты. Моё молоко и молоко Васи — два разных продукта, я могу добавить в холодильники и рецепты только первое, а про второе даже не смогу узнать.<\/p>\n
Уязвимость<\/h2>\n
Итак, где же тут наши подозреваемые — юникод и CSV?<\/p>\n
Сервис API не имеет доступа к базе данных, поэтому информация для него складывалась веб-приложением в специальные CSV-файлы, откуда считывались API-приложением раз в секунду. Вот пример такого файла:<\/p>\n
id,recipe_id,food_type_id,what_to_do,count,pause_after\n1,10,15,Yhws aqx vpjhtlyhw ruv tbcyis,11,7\n2,11,16,Ok jbso gtpzs ndgoz udeksmvk,10,16\n3,12,17,Y ap mculltvedfwwabbnnnco um,6,19\n4,13,18,cniyvdjsyuctaamupp zm qj nwvm,10,9\n5,14,19,Kfdvm ref wtb pdtitb,14,15<\/code><\/pre>В нём хранятся ингредиенты рецептов. Столбцы, соответственно — id ингредиента, id рецепта (сами рецепты лежат в другом файле), id продукта, что нужно сделать, сколько взять продукта и какую выдержать после этого паузу.<\/p>\n Давайте посмотрим, что будет, если в поле what_to_do добавить тот самый Paragraph separator:<\/p>\n
`6,15,20,blablabla\u202913503,14,20<\/code><\/pre>При чтении этот файл будет выглядеть для DictReader’а как<\/p>\n`
6,15,20,blablabla\u2029\n13503,14,20<\/code><\/pre>То есть так, будто мы добавили продукт №20 в рецепт №14. Продукт №20 принадлежит нам, значит, мы смогли добавить нашу еду в чужой рецепт №14! Теперь API сможет вывести этот рецепт, если в каком-нибудь из наших холодильников будет лежать продукт №20.<\/p>\n Для полноты картины покажу, как выглядели сохранение и загрузка данных в CSV.<\/p>\nСохранение:<\/h3>\ndef dump_model_to_file(model, filename):\n # Use Django API to get all model fields\n columns = [field.attname for field in model._meta.fields]\n\n with codecs.open(filename, 'w', encoding='utf-8') as opened_file:\n # Open csv writer and dump header: special row with columns names\n writer = csv.DictWriter(opened_file, fieldnames=columns)\n writer.writeheader()\n\n # Iterate over all objects of the model\n for obj in model.objects.all():\n object_dict = {}\n for column in columns:\n # Don't worry about newlines (\\n and \\r): csv.DictWriter will enclose such strings in quotes (")\n # So I think there is no vulnerability here\n object_dict[column] = str(getattr(obj, column, ''))\n\n # Dump dictionary for current object\n writer.writerow(object_dict)<\/code><\/pre>Загрузка:<\/h3>\nclass Model:\n def init(self, dictionary):\n for key, value in dictionary.items():\n if value is None:\n value = '0'\n if value.isnumeric():\n value = int(value)\n setattr(self, key, value)\n\n\ndef load_models_from_file(filename):\n objects = {}\n with codecs.open(filename, 'r', encoding='utf-8') as opened_file:\n reader = csv.DictReader(opened_file)\n for row in reader:\n objects[model.id] = Model(row)\n return objects<\/code><\/pre>Ещё две уязвимости<\/h2>\nВ Холодильнике мной была заложена ещё одна уязвимость. Но так получилось, что в итоге уязвимостей оказалось не две, а три. Так бывает на CTF, и в этом нет ничего страшного. Иногда бывает обидно, что ты заложил сложную уязвимость, а случайно оставил простую. Но в данном случае всё случилось удачно: незапланированная уязвимость была проще первой, а запланированная — совсем элементарной (правда, позволяла украсть только 20% флагов). Так как в целом соревнование получилось очень сложным, то появление одной незапланированной уязвимости средней сложности сыграло нам на руку.<\/p>\n Итак, сначала о запланированной уязвимости. Каждый сервис находился в своём докер-контейнере. Докер (docker) — это удобный способ изолировать своё приложение от других, в линуксе работает за счёт его фирменных LXC-контейнеров и ограничений в cgroup. Подробнее о докере можно почитать на официальном сайте<\/a>.<\/p>\n Мой сервис состоял из четырёх докер-контейнеров: для веб-приложения, для API-приложения, для базы данных и для веб-сервера nginx. Во время старта первого накатывались миграции, собиралась статика и выполнялись другие служебные команды. В том числе такая:<\/p>\n # DON'T RUN IT IN PRODUCTION. SOME EVIL GUYS CAN BRUTEFORCE PASSWORD AND WHO KNOW WHAT HAPPENS...\necho "[+] [DEBUG] Django setup, executing: add superuser"\nPGPASSWORD=${POSTGRES_PASSWORD} psql -U ${POSTGRES_USER} -h ${POSTGRES_HOST} -c "INSERT INTO auth_user (password, last_login, is_superuser, username, first_name, last_name, email, is_staff, is_active, date_joined) VALUES ('pbkdf2_sha256\\$36000\\$k36V24q60mNo\\$v5og9qcgc2sqkVwGjZDKNK+wcJy60ix8DIt9E8Yg48c=', '1970-01-01 00:00:00.000000', true, 'admin', 'admin', 'admin', 'admin@admin', true, true, '1970-01-01 00:00:00.000000') ON CONFLICT (username) DO NOTHING"<\/code><\/pre>Эта команда добавляет напрямую в базу данных супер-пользователя с логином admin. Его пароль мы не знаем, так что сразу зайти под ним не можем, но доступен хеш от пароля: ‘pbkdf2_sha256$36000$k36V24q60mNo$v5og9qcgc2sqkVwGjZDKNK+wcJy60ix8DIt9E8Yg48c=’. Подбор пароля не занимает много времени, так как он словарный и встречается во всех списках самых частых паролей.<\/p>\n Попрактикуйтесь — сможете ли вы подобрать пароль? pbkdf2_sha256 — это тип хеша и подписи, а 36000 — количество итераций. Справиться с задачей поможет hashcat, john the ripper или любой другой подборщик прообразов хешей.<\/p>\n Незапланированная уязвимость<\/h2>\nПоследняя уязвимость нашлась в функции добавлении продукта в холодильник. Здесь не проверялось, что вы являетесь владельцем добавляемого продукта. Можно было создать супер-холодильник, содержащий все продукты с номерами от 1 до 1000, а затем попросить API выдать рецепты, содержащие хотя бы какой-нибудь продукт из этого холодильника. Конечно, он находил и чужие рецепты, а вместе с ними выдавал и флаги, хранящиеся в описаниях этих рецептов.<\/p>\n Выводы<\/h2>\nНикогда не используйте csv.DictReader\/csv.DictWriter вместе с файлами, открытыми модулем codecs. В новых питонах открывайте CSV-файлы с помощью стандартной функции open, передавая ей аргументы encoding и newline.<\/p>\nБонус для дочитавших до конца<\/h2>\nВсе исходники сервиса, докер-файлы, чекер для проверяющей системы и мой авторский эксплойт для первой уязвимости можно найти в репозитории разработки<\/a>, который мы открыли сразу после окончания соревнования.<\/p>\n", "date_published": "2017-05-17T15:23:38+01:00", "date_modified": "2017-08-17T19:24:59+01:00", "tags": [ "csv", "CTF", "PHDays", "python", "unicode", "программирование" ], "image": "https:\/\/andgein.ru\/blog\/pictures\/2017-05-16_20-58-25.png", "_date_published_rfc2822": "Wed, 17 May 2017 15:23:38 +0100", "_rss_guid_is_permalink": "false", "_rss_guid": "2", "_e2_data": { "is_favourite": false, "links_required": [ "jquery\/jquery.js", "fotorama\/fotorama.css", "fotorama\/fotorama.js", "highlight\/highlight.js", "highlight\/highlight.css" ], "og_images": [ "https:\/\/andgein.ru\/blog\/pictures\/2017-05-16_20-58-25.png", "https:\/\/andgein.ru\/blog\/pictures\/2017-05-16_17-12-56-(2).png", "https:\/\/andgein.ru\/blog\/pictures\/2017-05-16_17-14-21.png", "https:\/\/andgein.ru\/blog\/pictures\/2017-05-16_17-23-56.png", "https:\/\/andgein.ru\/blog\/pictures\/2017-05-16_20-56-37.png", "https:\/\/andgein.ru\/blog\/pictures\/2017-05-16_20-58-25-(2).png", "https:\/\/andgein.ru\/blog\/pictures\/2017-05-16_21-07-14.png" ] } }, { "id": "1", "url": "https:\/\/andgein.ru\/blog\/all\/1-unicode-and-csv-in-python\/", "title": "Заметка первая. Про необычное поведение юникода и CSV в питоне", "content_html": " Посвящается Полине, которая рассказала мне про странное поведение своей питоновской программы и тем самым подсказала потрясающую идею для сервиса на CTF. <\/i><\/p>\n Всё началось месяца полтора назад. Полина рассказала мне, как она со своим начальником долго искала проблему в скрипте, который всего-навсего читал большой юникодный файл и как-то его обрабатывал. Проблема заключалась в том, что в файле было, например, 4 миллиона строк, а объектов в итоге оказывалось на два больше — 4 000 002. Это при том, что файл обрабатывался стандартной для питона конструкцией:<\/p>\n import codecs\n\nwith codecs.open('file.txt', 'r', 'utf-8') as f:\n for line in f:\n # Обрабатываем строчку line<\/code><\/pre>Я никак не мог за такое не ухватиться. Расспросил Полину подробно, выяснил, что ничего стороннего для работы с файлом не использовалось, и вообще конструкция была проста как топор. Откуда она берёт лишние строчки?<\/p>\n Пришёл домой и сразу сел проверять:<\/p>\nimport codecs\n\nwith codecs.open('file.txt', 'r', 'utf-8') as f:\n print(len(f.readlines()))<\/code><\/pre>Попробовал на нескольких файлах и всё, конечно, работает верно. Но Полина упоминала, что в её файле были какие-то плохие символы<\/i>, из-за которых и возникали лишние строчки. Я решил сгенерировать файл с кучей случайных юникодных символов:<\/p>\nimport codecs\nimport random\n\ndef generate_string():\n """\n Генерируем строчку случайных символов длины 100.\n Специально обходим символы с кодами 10 и 13, чтобы строка не содержала переводов строк\n """\n return ''.join(chr(random.randint(20, 10000)) for _ in range(100))\n\nwith codecs.open('file.txt', 'w', 'utf-8') as f:\n # Печатаем в файл 1000 строк\n for i in range(1000):\n f.write(generate_string() + '\\n')<\/code><\/pre>На всякий случай открываю файл в Фаре. Его немножко корёжит, но строчек он показывает ровно 1001, что абсолютно верно, ведь в файле 1000 переводов строк:<\/p>\n\n\n<\/div>\nЗапустил скрипт и удивился: он видит в файле 1076 строчек, а вовсе не 1000 и не 1001, как можно было бы предположить. Разобравшись и сгенерировав файл поменьше, нашёл тот самый символ, который всё портит. Им оказался символ с кодом 8233 — Paragraph Separator<\/a>. Рядом с ним есть ещё один такой же символ — Line Separator<\/a>, он имеет код 8232. И если подумать, то нет ничего странного, что с точки зрения модуля codecs в файле за этими символами начинаются новые строки.<\/p>\n Кстати, новый open() в третьем питоне сам умеет читать файлы в UTF-8, модуль codecs можно не использовать. Но в данном случае он ведёт себя иначе:<\/p>\n with open('file.txt', 'r', encoding='utf-8') as f:\n print(len(f.readlines()))<\/code><\/pre>На том же самом файле этот код выводет 1000. Такая разница в поведении уже кажется странной и неприятной, но давайте вернёмся к коду с модулем codecs и копнём поглубже.<\/p>\nВ юникоде есть символы, которые заставляют модуль codecs думать, что в файле началась новая строка. Это же отличное место для модифицированной CRLF-инъекции<\/a>! Правда, в данном случае она будет скорее ParagraphSeparator-инъекцией, но сути это не меняет. Представим код, который сохраняет пользовательские строчки в файл, одну за другой. Чтобы злоумышленник не мог повлиять на структуру файла, из строчек выкидываются все символы ‘\\r’ и ‘\\n’. Раньше мы могли думать, что мы в безопасности, но теперь мы знаем — злоумышленник может использовать Paragraph Separator или Line Separator, чтобы повлиять на структуру файла.<\/p>\n Приглашаем на наш праздник CSV<\/h2>\nНу что ж, разобрались с Paragraph Separator. Теперь пора на основе этой фичи<\/i> вытворить что-нибудь совсем интересное. Наш следующий скрипт будет сохранять юникодные данные в CSV-файл, а другой — считывать эти данные строчка за строчкой. Включаем питоновский модуль csv<\/a> и экспериментируем:<\/p>\n import codecs\nimport csv\n\nwith codecs.open('file.txt', 'w', 'utf-8') as f:\n writer = csv.DictWriter(f, fieldnames=['first', 'second'])\n writer.writeheader()\n writer.writerow({'first': 'Hello world', 'second': 'Text with\\n newline'})<\/code><\/pre>В полученном файле оказывается три строки:<\/p>\nfirst,second\nHello world,"Text with\n newline"<\/code><\/pre>Умный DictWriter поставил кавычки в нужных местах, и теперь симметричный ему DictReader отлично считает эти данные:<\/p>\nimport codecs\nimport csv\n\nwith codecs.open('file.txt', 'r', 'utf-8') as f:\n reader = csv.DictReader(f)\n for row in reader:\n print(row)<\/code><\/pre>Выводит то, что надо, отлично:<\/p>\n{'first': 'Hello world', 'second': 'Text with\\n newline'}<\/code><\/pre>Начинаем вставлять везде где ни попадя Paragraph Separator:<\/p>\nwriter.writerow({'first': 'Hello world', 'second': 'Text with' + chr(8233) + ' paragraph separator'})<\/code><\/pre>Внезапно на выходе получаем файл без кавычек. DictWriter не считает этот символ чем-то опасным:<\/p>\nfirst,second\nHello world,Text with\u2029 paragraph separator<\/code><\/pre>Ну что ж, натравим теперь на этот файл DictReader. В первый раз не мог поверить своим глазам, если честно:<\/p>\n{'first': 'Hello world', 'second': 'Text with\\u2029'}\n{'first': ' paragraph separator', 'second': None}<\/code><\/pre>То есть DictReader повёл себя несимметрично по отношению к DictWriter’у — сохраняли одну строчку, а получили две! Пользователь, влияющий на данные во втором поле первой строки, смог повлиять на первое поле во второй строке.<\/p>\nКульминация<\/h2>\nСобираем всё вместе и задаём вопрос знатокам питона:<\/p>\nimport codecs\nimport csv\n\ndata = {'first': '...', 'second': '...'}\n\nwith codecs.open('file.txt', 'w', 'utf-8') as f:\n writer = csv.DictWriter(f, fieldnames=data.keys())\n writer.writeheader()\n writer.writerow(data)\n\ncount = 0\nwith codecs.open('file.txt', 'r', 'utf-8') as f:\n reader = csv.DictReader(f)\n for row in reader:\n count += 1\n\nprint(count)<\/code><\/pre>Каким может быть вывод переменной count в конце программы?<\/p>\n Теперь-то мы знаем, что абсолютно любым — хоть 1, хоть 30, хоть 100. Например, инициализировав переменную data так:<\/p>\n P_SEP = chr(8233)\ndata = {'first': P_SEP * 10, 'second': P_SEP * 10}<\/code><\/pre>получим ответ 20.<\/p>\n Известно ли про это что-нибудь миру?<\/h2>\nВ документации к модулю csv написано: если вы используете csv.reader(), открывайте файл с опцией newline=’’:<\/p>\n \n\n<\/div>\n\n\n<\/div>\nНо, во-первых, мы используем не простой csv.reader(), а более умный csv.DictReader(), а, во-вторых, модуль codecs не поддерживает опцию newline, мы просто не сможем открыть файл с ней.<\/p>\n Интернет про эту проблему мне тоже ничего не рассказал. Но, может, я просто плохо искал?..<\/p>\n В следующей заметке<\/a> я рассказал, как из этого получился отличный сервис для PHDays CTF.<\/i><\/p>\n", "date_published": "2017-05-14T19:49:57+01:00", "date_modified": "2017-11-19T14:00:40+01:00", "tags": [ "csv", "python", "unicode", "программирование" ], "image": "https:\/\/andgein.ru\/blog\/pictures\/2017-05-14_23-42-40.png", "_date_published_rfc2822": "Sun, 14 May 2017 19:49:57 +0100", "_rss_guid_is_permalink": "false", "_rss_guid": "1", "_e2_data": { "is_favourite": true, "links_required": [ "highlight\/highlight.js", "highlight\/highlight.css" ], "og_images": [ "https:\/\/andgein.ru\/blog\/pictures\/2017-05-14_23-42-40.png", "https:\/\/andgein.ru\/blog\/pictures\/2017-05-15_00-49-29.png", "https:\/\/andgein.ru\/blog\/pictures\/2017-05-15_01-09-05.png" ] } } ], "_e2_version": 4134, "_e2_ua_string": "Aegea 11.3 (v4134)" }