Съвременните бази данни съхраняват всички видове данни. От тривиални до силно чувствителни. Ресторантите, които посещаваме, нашите местоположения на картата, нашите идентификационни данни (например социалноосигурителни номера, адреси, медицински досиета, банкова информация и т.н.) и всичко между тях е повече от вероятно да се съхранява някъде в база данни. Нищо чудно, че данните са толкова ценни.
Технологиите за бази данни напредват с главоломна скорост. Иновациите, прогресът, почтеността и подобренията са в изобилие на преден план като пряк резултат от труда на интелигентни и отдадени инженери, разработчици и стабилни общности, подкрепящи тези доставчици.
Но има и друга страна на монетата. Това, за съжаление, съществува съвместно в този свят, управляван от данни, под формата на злонамерен софтуер, вируси и експлоати в огромен, завинаги висок мащаб.
Данните са ценни и за страните от тази страна на операцията. Но по различни причини. Всеки от тях може да бъде, но не се ограничава до власт, изнудване, финансова печалба и достъп, контрол, забавление, шеги, злоба, кражба, отмъщение... Разбирате идеята. Списъкът е безкраен.
Уви, трябва да работим с нагласа за сигурност. Без този начин на мислене оставяме системите си уязвими за тези видове атаки. PostgreSQL е също толкова податлив на компрометиране, злоупотреба, кражба, неоторизиран достъп/контрол, както и други форми на софтуер.
И така, какви мерки можем да предприемем, за да намалим броя на рисковете за нашите инсталирания на PostgreSQL?
Силно смятам, че насърчаването на осведомеността за известните заплахи е също толкова добро място за начало. Знанието е сила и трябва да използваме всичко, с което разполагаме. Освен това, как можем да контролираме това, за което дори не сме наясно, за да засилим сигурността на тези екземпляри на PostgreSQL и да защитим данните, които се намират там?
Наскоро потърсих известни „притеснения“ и „заплахи“ за сигурността, насочени към PostgreSQL средата. Търсенето ми обхващаше скорошни доклади, статии и публикации в блогове през първото тримесечие на 2018 г. В допълнение към този специфичен период от време, проучих добре известни дългогодишни опасения, които все още са жизнеспособни заплахи днес (а именно SQL инжекция), но не са изчистени или се размахва като „наскоро открит '.
Възможност за снимки
Дълбоко гмуркане в атаките на бази данни [Част III]:Защо снимката на Скарлет Йохансон получи моята база данни Postgres, за да започне копаене на Monero
Мълвата за тази хитра атака със злонамерен софтуер върна най-много „попадения“ от обективните ми резултати от търсене.
Ще посетим една от няколкото страхотни публикации в блога и кратко описание на съдържанието му. Включих и допълнителни публикации в блога към края на този раздел, така че не забравяйте да посетете и тези, които описват подробно това нахлуване.
Наблюдения
Информация от Imperva, съобщава, че тяхната база данни honeypot (StickyDB) е открила атака на зловреден софтуер на един от техните PostgreSQL сървъри. Мрежата honeypot, както Imperva нарича системата, е предназначена да подмами нападателите да атакуват базата данни, за да могат те (Imperva) да научат за нея и да станат по-сигурни. В този конкретен случай полезният товар е зловреден софтуер, който криптоминира Monero, вграден в снимка на Скарлет Йохансон.
Полезният товар се изхвърля на диск по време на изпълнение с функцията lo_export. Но очевидно това се случва, защото lo_export е запис в pg_proc спрямо нормално директно извикване (lo_export).
Интересни подробности директно от публикацията в блога тук за изключителна яснота (вижте цитираната статия),
Сега нападателят може да изпълнява локални системни команди с помощта на една проста функция – fun6440002537. Тази SQL функция е обвивка за извикване на функция на C-език, „sys_eval“, малка експортирана функция в „tmp406001440“ (двоичен файл, базиран на sqlmapproject), който основно действа като прокси за извикване на команди на shell от SQL клиент.
И така, какви ще бъдат следващите стъпки на атаката? Малко разузнаване. Така че започна с получаване на подробности за графичния процесор чрез изпълнение на lshw -c video и продължи да cat /proc/cpuinfo, за да получи подробностите за процесора (фигури 3-4). Макар че в началото това изглежда странно, има пълен смисъл, когато крайната ви цел е да копаете повече от любимата си криптовалута, нали?
С комбинация от достъп до база данни и възможност за дистанционно изпълнение на код, докато „летя под радара “ на решения за наблюдение, след това нарушителят изтегля полезния товар чрез снимка на Скарлет Йохансон.
(Забележка:Оттогава снимката е премахната от хостваното й местоположение. Вижте статията за връзка за споменаването.)
Според доклада полезният товар е в двоичен формат. Този двоичен код беше добавен към снимката, за да премине за действителна снимка по време на качване, позволявайки видима картина.
Вижте Фигура 6 от публикацията за SQL, отговорен за използването на wget, dd и изпълнение на chmod за разрешения за изтегления файл. След това този изтеглен файл създава друг изпълним файл, който е отговорен за действителното копаене на Monero. Разбира се, домакинството и почистването са необходими след цялата тази подла работа.
Фигура 7 изобразява изпълняващия SQL.
Imperva препоръчва да наблюдавате този списък с потенциални зони за нарушение в заключителния раздел:
- Пазете се от директни извиквания на PostgreSQL към lo_export или непреки извиквания чрез записи в pg_proc.
- Пазете се от функциите на PostgreSQL, извикващи двоични файлове на C-език.
- Използвайте защитна стена, за да блокирате изходящия мрежов трафик от вашата база данни към Интернет.
- Уверете се, че на вашата база данни не е присвоен публичен IP адрес. Ако е така, ограничете достъпа само до хостовете, които взаимодействат с него (сървър на приложения или клиенти, собственост на DBA).
Imperva също така извърши различни антивирусни тестове, заедно с подробности за това как нападателите могат потенциално да намерят уязвими PostgreSQL сървъри. Въпреки че не ги включих тук за краткост, вижте статията за пълни подробности относно техните констатации.
Препоръчително четене
- Imperva има 2 предходни статии, които придружават част 3 (обсъдената тук). Въпреки че те не са насочени силно към PostgreSQL като това, което току-що премълчахме, те са много информативни чети:
- Част 1
- Част 2
- Атаката със злонамерен софтуер на Scarlett Johansson PostgreSQL
- Хакерите се насочват към PostgreSQL DBs с Coinminer, скрит в изображението на Scarlett Johannsson
- Нишка от хакерски новини за експлойта.
Подробности за CVE, отчет и уязвимости
Посетих този сайт, който публикува най-новите заплахи за сигурността за всеки доставчик и открих 4 уязвимости през първото тримесечие на 2018 г. Страницата с информация за сигурността на PostgreSQL също ги има изброени, така че не се колебайте да се консултирате с този ресурс.
Въпреки че повечето от тях бяха разгледани, смятах, че е важно да ги включа в тази публикация, за да осведомя читателите, които може да не са знаели за тях. Чувствам, че можем да се поучим от всички тях. Особено в различните начини на откриване на уязвимости.
Те са изброени по-долу в реда на датата на публикуване:
И. CVE-2018-1052 дата на публикуване 2018-02-09 :Дата на актуализиране 3/10/2018
Общ преглед:
Уязвимостта при разкриване на паметта при разделянето на таблици беше открита в PostgreSQL 10.x преди 10.2, което позволява на удостоверен нападател да чете произволни байтове от паметта на сървъра чрез специално създадено вмъкване в разделена таблица.
Тази уязвимост беше отстранена с пускането на PostgreSQL 10.2, потвърдено тук. По-стара версия 9.x също е поправена, така че посетете тази връзка, за да проверите вашата конкретна версия.
II. CVE-2018-1053 дата на публикуване 2018-02-09 :Дата на актуализация 15.3.2018
Общ преглед:
В PostgreSQL 9.3.x преди 9.3.21, 9.4.x преди 9.4.16, 9.5.x преди 9.5.11, 9.6.x преди 9.6.7 и 10.x преди 10.2, pg_upgrade създава файл в текущата работна директория, съдържащ изхода на `pg_dumpall -g` под umask, който е бил в сила, когато потребителят е извикал pg_upgrade, а не под 0077, който обикновено се използва за други временни файлове. Това може да позволи на удостоверен нападател да прочете или модифицира един файл, който може да съдържа криптирани или некриптирани пароли за база данни. Атаката е неосъществима, ако режим на директория блокира нападателя да търси текущата работна директория или ако преобладаващата umask блокира отварянето на файла на атакуващия.
Както при предишния CVE-2018-1052, PostgreSQL 10.2 коригира тази част от уязвимостта:
Уверете се, че всички временни файлове, направени с "pg_upgrade", не са четими от цял свят
Много по-стари версии на PostgreSQL са засегнати от тази уязвимост. Уверете се и посетете предоставената връзка за всички тези изброени версии.
III. CVE-2017-14798 дата на публикуване 2018-03-01 :Дата на актуализиране 26.03.2018 г.
Общ преглед:
Състояние на състезание в скрипта за иницииране на PostgreSQL може да се използва от нападателите, които имат достъп до акаунта на PostgreSQL, за да ескалират своите привилегии до root.
Въпреки че не можах да намеря никъде на страницата за свързване, че е спомената PostgreSQL версия 10, много по-стари версии са, така че посетете тази връзка, ако използвате по-стари версии.
Потребителите на Suse Linux Enterprise Server може да се интересуват от 2 свързани статии тук и тук, където тази уязвимост е отстранена за версия 9.4 init скрипт.
IV. CVE-2018-1058 дата на публикуване 2018-03-02 :Дата на актуализация 22.3.2018
Общ преглед:
Открит е недостатък в начина, по който PostgreSQL позволява на потребителя да променя поведението на заявка за други потребители. Нападател с потребителски акаунт може да използва този недостатък, за да изпълни код с разрешенията на суперпотребител в базата данни. Засегнати са версии от 9.3 до 10.
Тази актуализация споменава тази уязвимост с интересен свързан документ, който всички потребители трябва да посетят.
Статията предоставя фантастично ръководство от общността, озаглавено Ръководство за CVE-2018-1058:Защитете своя път за търсене, което съдържа невероятно количество информация относно уязвимостта, рисковете и най-добрите практики за борба с нея.
Ще направя всичко възможно да обобщя, но посетете ръководството за ваша собствена полза, разбиране и разбиране.
Общ преглед:
С появата на PostgreSQL версия 7.3, схемите бяха въведени в екосистемата. Това подобрение позволява на потребителите да създават обекти в отделни пространства от имена. По подразбиране, когато потребителят създава база данни, PostgreSQL създава и публична схема, в която се създават всички нови обекти. Потребителите, които могат да се свързват с база данни, могат също да създават обекти в публичната схема на тази база данни.
Този раздел директно от ръководството е много важен (вижте цитираната статия):
Схемите позволяват на потребителите да поставят обекти на пространство от имена, така че обекти с едно и също име могат да съществуват в различни схеми в една и съща база данни. Ако има обекти с едно и също име в различни схеми и конкретната двойка схема/обект не е посочена (т.е. schema.object), PostgreSQL решава кой обект да използва въз основа на настройката search_path. Настройката search_path определя реда, в който се търсят схемите, когато се търси обект. Стойността по подразбиране за search_path е $user,public, където $user се отнася до името на свързания потребител (което може да се определи чрез изпълнение на SELECT SESSION_USER;).
Друг ключов момент е тук:
Проблемът, описан в CVE-2018-1058, се съсредоточава около "публичната" схема по подразбиране и как PostgreSQL използва настройката search_path. Възможността за създаване на обекти с едни и същи имена в различни схеми, съчетана с начина, по който PostgreSQL търси обекти в схемите, предоставя възможност за потребителя да промени поведението на заявка за други потребители.
По-долу е даден списък на високо ниво, в което ръководството препоръчва прилагането на тези практики, както е предвидено, за намаляване на риска от тази уязвимост:
- Не позволявайте на потребителите да създават нови обекти в публичната схема
- Задайте пътя за търсене по подразбиране за потребители на база данни
- Задайте пътя за търсене по подразбиране в конфигурационния файл на PostgreSQL (postgresql.conf)
SQL инжекция
Всяка „тема на сигурността ' SQL публикация или статия в блога не могат да се обозначават като такива без споменаване на SQL инжекция. Въпреки че този метод на атака не е кой знае колко от въображението „новото дете в блока “, трябва да бъде включено.
SQL инжекцията винаги е заплаха и може би дори повече в пространството на уеб приложенията. Всяка база данни на SQL – включително PostgreSQL – е потенциално уязвима към нея.
Въпреки че нямам задълбочена база от знания за SQL инжекцията - известна още като SQLi - ще направя всичко възможно да дам кратко обобщение как може потенциално да повлияе на вашия PostgreSQL сървър и в крайна сметка как да намалим рисковете от попадане в жертва към него.
Обърнете се към връзките, предоставени в края на този раздел, всички от които съдържат изобилие от информация, обяснения и примери в тези области, които не мога да комуникирам адекватно.
За съжаление съществуват няколко типа SQL инжекции и всички те споделят общата цел за вмъкване на обиден SQL в заявки за изпълнение в базата данни, може би не първоначално предназначени, нито проектирани от разработчика.
Неочистеното потребителско въвеждане, лошо проектирана или несъществуваща проверка на типа (AKA валидиране), заедно с непропуснато потребителско въвеждане, всички потенциално могат да оставят вратата широко отворена за потенциални нападатели. Много API за уеб програмиране осигуряват известна защита срещу SQLi:например ORM (Object Relational Mapper), параметризирани заявки, проверка на типове и т.н.... Въпреки това, отговорността на разработчика е да положи всички усилия и да намали основните сценарии за SQL инжектиране чрез внедряване тези отклонения и механизми, с които разполагат.
Ето забележителни предложения за намаляване на риска от SQL инжекция от Cheat Sheet OWASP SQL Injection Prevention. Уверете се и го посетете за пълен подробен пример за използване на практика (вижте цитираната статия).
Основни защити:
- Вариант 1:Използване на подготвени изявления (с параметризирани заявки)
- Вариант 2:Използване на съхранени процедури
- Опция 3:Проверка на входа в бял списък
- Опция 4:Изключване на всички въведени от потребителя данни
Допълнителни защити:
- Още:Налагане на най-малко привилегии
- Също така:Извършване на проверка на въведеното в бял списък като вторична защита
Препоръчително четене:
Включих допълнителни статии с много информация за по-нататъшно проучване и информираност:
- Какво е SQL инжектиране? Това старо, но добро нещо може да нарани вашите уеб приложения
- SQL инжекция (Уикипедия)
- SQL инжекция (CLOUDFLARE)
- SQL инжекция (w3schools.com)
- Шамба за предотвратяване на инжектиране на SQL
- Тестване за SQL инжекция
- Уязвимости при инжектиране на SQL и как да ги предотвратим
- Шамба за инжектиране на SQL
Привилегии за ролята на Postgres
Имаме поговорка за нещо от рода на „Ние сме най-големият си враг ."
Определено можем да го приложим за работа в PostgreSQL среда. Пренебрегването, неразбирането или липсата на старание са също толкова възможност за атаки и неоторизирана употреба, колкото и тези, които се стартират нарочно.
Може би дори повече, позволявайки по невнимание по-лесен достъп, маршрути и канали за нарушителите, до които да се докоснат.
Ще спомена област, която винаги се нуждае от преоценка или преоценка от време на време.
Неоправдани или извънредни привилегии на роли.
- СУПЕРПОЛЗВАТЕЛ
- CREATROLE
- CREATEDB
- ПРЕДОСТАВЯ
Това обединяване на привилегии определено си заслужава да бъде разгледано. SUPERUSER и CREATROLE са изключително мощни команди и биха били по-добре обслужвани в ръцете на DBA, отколкото на анализатор или разработчик, не мислите ли?
Наистина ли ролята се нуждае от атрибута CREATEDB? Ами GRANT? Този атрибут има потенциал за злоупотреба в грешни ръце.
Претеглете силно всички опции, преди да разрешите ролите на тези атрибути във вашата среда.
Стратегии, най-добри практики и втвърдяване
По-долу е даден списък с полезни публикации в блогове, статии, контролни списъци и ръководства, които са се върнали за „предна година“ (по време на писането) на резултатите от търсенето. Те не са изброени в никакъв ред по важност и всяко предлага забележителни предложения.
- Прости начини за защита на вашите Postgres сървъри от малко вероятен вектор на атака:измамна снимка на Скарлет Йохансон
- Помагане за защитата на вашата PostgreSQL база данни
- Не бъдете упорити... Укрепете своята PostgreSQL база данни, за да гарантирате сигурност
- Как да защитите своята PostgreSQL база данни – 10 съвета
- Обезопасяване на PostgreSQL от външна атака
- Привилегии и сигурност на PostgreSQL – Заключване на публичната схема
Заключение
В този блог преминахме през проблемите със сигурността, които вълнуват администраторите на PostgreSQL по целия свят:те включват SQL инжектиране, което е светият граал на всички инциденти със сигурността, пропуски в основните подходи за обработка данни сигурно, като например неуспешно затягане на разрешенията във вашата инфраструктура, както и някои по-малко известни проблеми със сигурността, които може да бъдат пренебрегнати. Когато става въпрос за сигурността на нашите данни, от решаващо значение е да приемаме и прилагаме съвети от доверени страни като Imperva и други подобни, които ни предоставят начини да се защитим както от основни атаки, така и от 0-дни (експлоати, които все още не са били познати преди), тъй като реномираните съвети означават добро бъдеще за нашите бази данни и инфраструктура като цяло.
Имайте предвид, че мерките за сигурност, които трябва да предприемем, ще зависят до голяма степен от уязвимостите, които искаме да отстраним, но като цяло, познаването на всички необходими защити за предотвратяване на SQL инжекция, правилно използване привилегии и винаги да се опитваме да намалим нивото на риска, свързан с уязвимостите, е от решаващо значение. Да бъдем в крак с това, което се случва в пространството за сигурност на PostgreSQL, също ще ни направи чудеса:можем да защитим нашите сървъри (и следователно нашите данни) добре само ако знаем какво могат да търсят нападателите.
Ако търсите още най-добри практики за подобряване на сигурността или производителността на вашите PostgreSQL инсталации, обърнете се към ClusterControl:тъй като инструментът е разработен от първокласни експерти по бази данни от цял свят, той ще накара базите ви да пеят за нула време. Продуктът се предлага и с 30-дневна безплатна пробна версия, така че не пропускайте да изпробвате всички функции, които ClusterControl може да предложи за вашия бизнес, и опитайте днес.
За повече съдържание относно това как трябва да се грижите за защитата на вашите екземпляри на база данни PostgreSQL, обърнете се към блога Severalnines за съвет:научаването как да автоматизирате одитите на сигурността за PostgreSQL със сигурност ще бъде стъпка в правилната посока. Не забравяйте да ни последвате в Twitter, LinkedIn и да се абонирате за нашата RSS емисия за още актуализации и ще се видим в следващата.
