Содержание. __ от редакции. Биография сетевого периметра в картинках
 Скачать 5.92 Mb.
|
|
35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101 103 проБлемы управления доСтупом Такие проблемы возникают главным образом при реализации таких механизмов управления доступом, как идентификация, аутентифи- кация (в том числе двухфакторная) и авторизация. Аудиты безопас- ности постоянно выявляют ошибки: недостаточное разграничение доступа, возможность получения доступа к различным backend- и администраторским системам. Самые распространенные из таких уязвимостей встречаются практически в каждом банке и банковском приложении. Часто корень проблем кроется в неверном использовании крипто- протоколов и реализаций криптопримитивов (средств криптографии, встроенных в стандартные библиотеки .NET, Java и т. п.). Здесь также важно отметить, что использование низкоуровневых криптоприми- тивов в принципе нежелательно, поскольку очень легко допустить ошибку в их конфигурации и тем самым свести на нет все усилия по внедрению криптографии в отдельно взятом приложении. Одним из самых ярких последствий таких ошибок является уязви- мость для атак Padding Oracle, возникающая при использовании слабых режимов работы блочных шифров. Вместо использования низкоуровневых средств всегда нужно стремиться к использованию высокоуровневых библиотек типа KeyCzar, libsodium. Еще один пласт проблем связан с подходом security through obscurity. Каждый банк использует криптографию (SSL, TLS и т. п.) и нередко шифрует данные на уровне приложений (L7). Это дает фи- нансовым организациям иллюзию защищенности, и возникает мысль, что на серверной части теперь ничего защищать не надо: все ведь «обернуто» криптографией и атакующий попросту не сможет ничего злонамеренно послать на сервер. Это, конечно же, не так. Криптография поддается обратной разра- ботке, проверки в мобильных приложениях обходятся, если злоу- мышленник имеет физический доступ к устройству с установленным банковским приложением. Другими словами, осуществить MitM- атаку на SSL-трафик можно всегда. Более того, иногда уязвимости удается эксплуатировать даже «поверх» криптографии — например, из форм на сайте. проБлемы управления потоками операций Среди наиболее популярных и опасных ошибок управления потока- ми операций — и возможных атак на их основе — можно выделить: + недостаточные проверки процесса; + race condition и прочие атаки на атомарность; + другие уязвимости бизнес-логики; + атаки CSRF. Данный тип проблем является вторым по частоте обнаружения в банковских приложениях. Для того чтобы свести вероятность их появления к минимуму и обеспечить защиту бизнес-логики, не- обходимо четко формализовать каждый бизнес-процесс. Вообще, бизнес-логика — это баззворд-синоним понятия «логика функци- ональной предметной области». Предметная область же — набор сущностей, их инвариантов и правил взаимодействия друг с другом. Чтобы избежать возникновения уязвимостей в некоей абстракт- ной предметной области, достаточно: а) иметь формализованное и непротиворечивое описание инвариантов сущностей и правил их взаимодействия; б) реализовать строгий (принудительный, без разрешающих умолчаний) контроль соблюдения всех инвариантов и правил предметной области при прохождении сущностей через границы доверия. Часто логику предметной области можно выразить в виде неко- торого workflow (потока операций либо конечного автомата), со- стояниями которого являются наборы допустимых инвариантов разраБотка защищенных БанковСких приложений: гЛАВНыЕ ПРОБЛЕМы И КАК ИХ ИЗБЕЖАТь Владимир Кочетков habrahabr.ru/company/pt/blog/271287/ В 2014 году злоумышленники совершили на 30% больше атак на рос- сийские банки, чем годом ранее. Пытались вывести около 6 млрд рублей. Часто атака становится возможной из-за недостаточной за- щищенности финансовых приложений. По нашей статистике, более половины систем дистанционного бан- ковского обслуживания (54%) содержали XSS-уязвимости, которые позволяют осуществить MitM-атаку и перехватить доступ к интер- нет-банкингу. С мобильными банковскими приложениями ситуация выглядит не лучше: 70% «кошельков» для Android и 50% для iOS в 2014 году содержали уязвимости, достаточные для получения до- ступа к счету. Выявлять уязвимости на ранней стадии гораздо дешевле, чем потом расхлебывать последствия их эксплуатации. В октябре 2015 года эксперты Positive Technologies Тимур Юнусов и Владимир Кочетков провели двухдневный мастер-класс по безопасной разработке бан- ковских приложений. Представляем краткий пересказ. Разговор о проблемах безопасности и их возможных решениях следует начать с типичных проблем защищенности банковских приложений. positive research 2016 36 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 сущностей предметной области, а переход между состояниями яв- ляется единственным способом их взаимодействия друг с другом. В этом случае можно сформулировать несколько конкретных правил по обеспечению защищенности реализации предметной области: 1. Следует избегать появления в потоке операций рекурсивных путей и циклов. 2. Необходимо учитывать возможное нарушение целостности данных, разделяемых различными потоками. 3. Текущее состояние потока необходимо хранить перед границей доверия, а не за ней (применительно к «двухзвенке» — на сер- вере, а не на клиенте). 4. Необходимо реализовать строгий контроль аутентичности инициатора перехода между состояниями workflow (неэффек- тивный контроль приводит, например в случае с Вебом, к уязви- мости для атак CSRF); 5. В случае если несколько потоков операций, разделяющих дан- ные, могут работать одновременно, необходимо обеспечить гранулированный доступ ко всем таким данным из всех таких потоков. проБлемы управления потоками данных Ошибки в организации управления потоками данных могут приво- дить к возникновению следующих серьезных проблем: + инъекции (SQL, XSS, XML, XXE, XPath, XQuery, Linq и т. п.), + внедрение и выполнение произвольного кода на серверной стороне. Третий по частоте обнаружения тип проблем банковских приложе- ний, хотя и наиболее обширный. главный недостаток здесь — неэф- фективная предварительная обработка данных. Он приводит к мно- гочисленным атакам и уязвимостям: от XSS, которая в банковском приложении может свести на нет все механизмы защиты (одноразо- вые пароли и т. п.), до SQL-инъекций, наличие которых в финансовых приложениях позволяет получить абсолютный доступ к критически важной информации — счетам, паролям (в т. ч. одноразовым) — и осуществлять хищения средств. Существует три подхода к организации предварительной обработ- ки данных: + типизация — приведение строковых данных к конкретным типам в терминах ООП и дальнейшее использование в коде уже этих типов (параметризация SQL-запросов, например, является неявной реализацией типизации SQL-литералов); + санитизация — преобразование входных строковых данных в вид, безопасный для их использования в качестве выходных (примерами являются всевозможные HtmlEncode, UrlEncode, addslashes и т. п.); + валидация — проверка данных на соответствие каким-либо критериям; возможна валидация двух видов: синтаксическая (например, проверка на соответствие регулярному выраже- нию) и семантическая (например, проверка числа на вхожде- ние в определенный диапазон). Порядок предпочтения этих подходов именно таков. То есть, там, где невозможна типизация, следует рассмотреть возможность са- нитизации, а там, где невозможна и санитизация, — следует вне- дрять валидацию. Это необходимо для того, чтобы максимально дистанцироваться от изменения семантики кода. Кроме того, стоит по возможности придерживаться правила: «типизация / валидация на входе (как можно ближе к началу потока выполнения кода), сани- тизация — на выходе (как можно ближе к месту в коде, в котором данные уходят наружу)». Рассмотрим несколько примеров применения описанных выше подходов. типизация Предположим, у нас есть следующий код: 1 var parm = Request.Params[ "parm1" ]; 2 if (Request.Params[ "cond1" ] == "true" ) 3 { 4 return; 5 } 6 7 if (Request.Params[ "cond2" ] == "true" ) 8 { 9 parm = Request.Params[ "parm2" ]; 10 } else { 11 parm = " Harmless value "; 12 } 13 14 Response.Write( " + parm + "\">" ); Здесь в parm записывается опасное значение, что приводит к возник- новению уязвимости для атак класса XSS, но контекст его использо- вания позволяет осуществить типизацию. + 1 var typedParm = new Uri(Request.Params[ "parm2" ]); + 2 3 var parm = Request.Params[ "parm1" ]; 4 if (Request.Params[ "cond1" ] == "true" ) 5 { 6 return; 7 } 8 9 if (Request.Params[ "cond2" ] == "true" ) 10 { - parm = Request.Params[ "parm2" ]; + 11 parm = typedParm.GetComponents( + 12 UriComponents.HttpRequestUrl, UriFormat.UriEscaped); 13 } else { 14 parm = " Harmless value "; 15 } 16 17 Response.Write( " + parm + "\">" ); Санитизация У нас есть следующий код: 1 var parm = Request.Params[ "parm1" ]; 2 if (Request.Params[ "cond1" ] == "true" ) 3 { 4 return; 5 } 6 7 if (Request.Params[ "cond2" ] == "true" ) 8 { 9 parm = Request.Params[ "parm2" ]; 10 } else { 11 parm = " Harmless value "; 12 } 13 14 Response.Write( "Selected parameter: " + parm); Нетрудно заметить, что в parm здесь также записывается опасное значение. В данном случае невозможна типизация, но возможно при- менение санитизации в контексте опасной операции. 37 // ВЕБ-БЕзопасность 03 05 07 09 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 99 101 103 1 var parm = Request.Params[ "parm1" ]; 2 if (Request.Params[ "cond1" ] == "true" ) 3 { 4 return; 5 } 6 7 if (Request.Params[ "cond2" ] == "true" ) 8 { - parm = Request.Params[ "parm2" ]; + 9 parm = HttpUtility.HtmlEncode(Request.Params[ "parm2" ]); 10 } else { 11 parm = " Harmless value "; 12 } 13 14 Response.Write( "Selected parameter: " + parm); валидация В примере ниже (уязвимость для атак переполнения буфера) осуще- ствить типизацию и санитизацию невозможно, а значит, нужно при- менить валидацию: 1 const int BufferSize = 16 ; 2 3 public unsafe struct Buffer 4 { 5 public fixed char Items [BufferSize]; 6 } 7 8 static void Main ( string [] args) 9 { 10 var buffer = new Buffer(); 11 12 var argument = args[ 0 ].ToCharArray(); 13 14 if (argument.Length < BufferSize) { return; } 15 16 for (var i = 0 ; i < argument.Length; i++) 17 { 18 unsafe 19 { 20 buffer.Items[i] = argument[i]; 21 } 22 } 23 } Код с валидацией будет выглядеть так: 1 const int BufferSize = 16 ; 2 3 public unsafe struct Buffer 4 { 5 public fixed char Items [BufferSize]; 6 } 7 8 static void Main ( string [] args) 9 { + 10 Func<int, int> __ai_bkfoepld_validator = index => + 11 { + 12 if (index >= BufferSize) + 13 { + 14 throw new IndexOutOfRangeException(); + 15 } + 16 return index; + 17 }; + 18 19 var buffer = new Buffer(); 20 21 var argument = args[ 0 ].ToCharArray(); 22 23 if (argument.Length < BufferSize) { return; } 24 25 for (var i = 0 ; i < argument.Length; i++) 26 { 27 unsafe 28 { - buffer.Items[i] = argument[i]; + 29 buffer.Items[__ai_bkfoepld_validator(i)] = argument[i]; 30 } 31 } 32 } инфраСтруктурные проБлемы и методы их реШения Существует и целый ряд инфраструктурных проблем, которые могут приводить к успешным атакам на банковские системы. Среди них: + application DoS, + проблемы окружения, + стороннее ПО, модули и плагины. Случаются и успешные атаки с помощью куда более тривиальных не- закрытых FTP, или админок IBM/Tomcat и т. п. И вот что следует делать, чтобы повысить безопасность банковских приложений на этапе их разработки и развертывания: 1. Нужно рассматривать каждый компонент инфраструктуры как скомпрометированный. 2. TLS (не SSL) должен применяться везде, даже внутри инфраструктуры. 3. Каждый компонент инфраструктуры должен быть развернут и настроен в соответствии с официальным security guide (если есть) или лучшими практиками. 4. Использование специализированных средств для анализа защищенности и соответствия стандартам (например, MaxPatrol) также позволяет серьезно повысить уровень безопасности. 5. Весь код должен быть подписан, даже если инфраструктура этого не требует. 6. Все плагины и сторонние недоверенные модули должны выполняться в выделенных песочницах. предметные оБлаСти БанковСких приложений Отдельно стоит отметить возможные проблемы различных банков- ских приложений, не относящиеся к серверной части систем ДБО: + Ошибки безопасности различных плагинов и клиентских прило- жений, изначально не связанных с банкингом, могут приводить к проблемам. + Как правило, мобильные приложения защищены хуже десктоп- ных собратьев. Вообще говоря, серверная часть должна быть одинаково унифицированной для приложений любого типа, но часто это не так. + Операторские станции (и сами операторы): часто хакерам даже не приходится взламывать сложные системы безопасности, что- бы пробиться во внутреннюю сеть, достаточно лишь обмануть сотрудников предприятия. + Развитие клиентских атак — украсть деньги у клиентов банка можно с помощью целенаправленных атак на самих клиентов. positive research 2016 38 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 кто потерял ключи: ПО СЛЕДАМ SSH Артур Гарипов habrahabr.ru/company/pt/blog/281445/ В 2015 году поднялась большая шумиха, когда по всему миру на раз- личных узлах были обнаружены одинаковые SSH-отпечатки ( blog. shodan.io/duplicate-ssh-keys-everywhere ). Далее шума дело не пошло, но осадок остался. Попробуем разобраться, в чем основная опас- ность таких «дублей». Большая часть собранных данных актуальна для 2015 года. что такое отпечаток SSH-отпечаток — это число, которое вычисляется от открытого ключа, который хранится по пути /etc/ssh в файле с разрешени- ем pub. Когда вы впервые подключаетесь к узлу, вам предлагается его аутентифицировать. И в качестве валидатора выступает строка вида 56:ca:17:72:0b:d4:3c:fd:5e:23:fb:7b:9e:9a:c8:42 — MD5- сумма от открытого ключа. The authenticity of host '192.168.100.124 (192.168.100.124)' can't be established. RSA key fingerprint is 56:ca:17:72:0b:d4:3c:fd:5e:23:fb:7b:9e:9a:c8:42. Are you sure you want to continue connecting (yes/no)? Если вы впервые подключаетесь к узлу, то увидеть такое сообщение естественно. Но если вы уже аутентифицировали этот узел и под- ключались к нему прежде, то стоит задуматься: «Почему произошло изменение отпечатка?». Возможно, вы переустанавливали целевую систему или сгенерировали новый ключ? А может, вы подключаетесь совсем не к той машине, к которой собирались?.. как СчитаетСя отпечаток Итак, SSH-отпечаток — это хеш-сумма. В нашем случае это MD5- сумма от открытой части RSA-ключа. Открытая часть ключа: root@ubuntu:/etc/ssh # cat /etc/ssh/ssh_host_rsa_key.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCrID5HFOZiQlq6DDUCsLOG5xJFOMbxtqPT tgL0BfEyRVQ1AGD9kwSWnAU7bm/uFmfkfG5ff/8S02PKaQo26sYIWi8/NyOGMyLNn CLpMJkJ+CT12qrqpD+3Q749DpVzBBbCUaYiDNg7RbKxbbnSZUe9k69P4FE0itS4MQ DFAnD0XY78aQuxNpIQUexTIP0b4QuIaShV0c6FXmpHHqr85uZ9t1cTdLtl3Kphv3 yu6Z+bkGBd+c80pdV+islTUGa+YJse0rvi/qP8AU67KNXscAc4UDe1yaMG5Y3eUs hvt3OTCXliYQKw3NIw/KzXbbY6s/sB49LAvDOal4FK6ZAA+HUP root@ubuntu Декодируем строку AAAAB....A+HUP из base64 и подсчитаем MD5- сумму получившейся строки: root@ubuntu:/etc/ssh # awk '{print $2}' ssh_host_rsa_key.pub | base64 -d | md5sum 56ca17720bd43cfd5e23fb7b9e9ac842 Мы получили исходный отпечаток. В трафике ключ передается так: Вместо RSA могут использоваться и другие ключи, например ECDSA, ED25519. При помощи утилиты ssh-keyscan мы можем получить от- крытую часть ключа SSH сервера целевой машины. root@ubuntu:/etc/ssh # ssh-keyscan -t ED25519 192.168.100.124 # 192.168.100.124 SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.6 192.168.100.124 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF8GXOsOnWBf1NY6Px6upViTXX0ZOw9txOEjwxMORafZ root@ubuntu:/etc/ssh # ssh-keyscan -t RSA 192.168.100.124 # 192.168.100.124 SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.6 192.168.100.124 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCrID5HFOZiQlq6DDUCsLOG5xJFOMbxtqPT tgL0BfEyRVQ1AGD9kwSWnAU7bm/uFmfkfG5ff/8S02PKaQo26sYIWi8/NyOGMyLNn CLpMJkJ+CT12qrqpD+3Q749DpVzBBbCUaYiDNg7RbKxbbnSZUe9k69P4FE0itS4MQD FAnD0XY78aQuxNpIQUexTIP0b4QuIaShV0c6FXmpHHqr85uZ9t1cTdLtl3Kphv3yu 6Z+bkGBd+c80pdV+islTUGa+YJse0rvi/qP8AU67KNXscAc4UDe1yaMG5Y3eUshvt3 OTCXliYQKw3NIw/KzXbbY6s/sB49LAvDOal4FK6ZAA+HUP Также мы можем видеть баннер, который сообщает нам версию сер- вера, номер протокола и версию ОС: # 192.168.100.124 SSH-2.0- OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.6. |