Я думаю антифрод не очень обрадуется транзакциям, выполненным через curl 🌚.
Что касается security through obscurity. Давайте возьмем, например, WAF. Он мешает атакующим исследовать веб-приложение: слать на него подозрительные запросы, искать на сервере xss, sqli и логические уязвимости. Если его убрать, то атакующему будет сильно легче фаззить сервер и в конце концов найти пропущенную уязвимость.
Считать ли использование WAF реализацией паттерна security through obscurity? Кажется что нет. Его использование не исключает работу команды appsec по обеспечению безопасности веб-приложения. И вот с обфускацией то же самое.
Такие инструменты как WAF, обфускация, RASP призваны фрустрировать атакующего, увеличивать стоимость атаки и вынуждать его искать другую жертву. Если вы когда-нибудь пытались искать уязвимости в веб-приложениях за WAF или в мобильных приложениях под протектором, вы понимаете, о чем я. Вся эта защита применяется не вместо, а вместе с другими подходами по обеспечению безопасности.
Так опенсорс - это единичные приложения. Какой опенсорс вы хотите привести в пример? Сигнал, телеграм? Не думаю, что опенсорсом балуются финтех, госы и так далее. Да, отдельные проекты могут быть, но это совершенно не массовая история.
Я тут ни в коем случае не пытаюсь сказать, что безопасно сделать невозможно или что не нужно проектировать безопасную архитектуру. Но вот тезис "сделали бы безопасно, защита была бы не нужна" очень сильно далек от реальности.
Недавно коллеги из dr web публиковали новость и вредоносной кампании. Если кратко, для внедрения вредоносов использовали реальные приложения, то есть фактически репакали популярные приложения. И распространяли тоже через сторы. Проверки в play market, appstore и других - дело хорошее, но это вообще не гарантия защиты, просто еще один важный этап. Да, это немного не про обфускацию, а больше про RASP, но современная защита обычно включает и то и другое, иначе нет смысла.
Вообще примеров можно найти много: это моды с читами, с отклюенной / ворованной рекламой, скрапперы и какие-то более нишевые истории типа приложений для курьеров, таксистов и так далее.
Согласен, что грамотная архитектура решит 99% проблем с безопасностью. Но грамотная архитектура бывает только в фантазиях инженеров. На деле имеем - тонны уязвимостей, включая примитивные в виде оставленных в коде ключей. Если приложение с уязвимостями все же опубликовали, то в случае наличия защиты от реверса у команды разработки будет банально больше времени выкатить исправления, потому что злоумышленник потратит больше времени на то, чтобы до этих уязвимостей добраться.
Если все это учитывать, бедный разработчик будет работать х2. Не удивительно, что большинство пугается и забивает на такую защиту, что на руку всяким мамкиным хакерам.
С такой позиции да. Но не думаю что злоумышленники будут пользоваться подобным сервисом, у них свои разработки. Но да, из-за такой проблемы очень непросто сделать подобную защиту, разрешенную для публикации в сторах, они как раз боятся криптованных вредоносов
Вы абсолютно правы: и по части виртуализации, и по части разнообразного применения различных техник. Но если первое вызывает огромные сложности при проходе ревью, то остается пользоваться вторым принципом. Так мы и делаем) но в сторону виртуализации смотрим. Реализовать сложно - не значит невозможно)
Но обфускация - это не одна техника, а целый набор защит в статике. Виртуализация - спорный момент именно в мобилках: магазины приложений очень не любят, когда виртуализируют код. Приходится выкручиваться.
Помимо защиты в статике крайне желательно использовать еще и защиту в динамике - RASP - runtime application self protection. В комплексе набор техник защит в статике и динамике дают эффект синергии, когда одна защита препятствует отлому другой.
Поэтому коммерческое решение должно предлагать полный спектр проверок и техник для противодействия реверс инжинирингу, тут я с вами согласен.
Важное уточнение: pt maze работает без исходных кодов, а ровно с теми сборками, которые и так попадают в магазины приложений. Открытые алгоритмы обфускации - это хорошо, но открытость упрощает их изучение и, как следствие, обход.
Что касается кардинального решения проблемы на уровне ОС - все это уже применяется и увы, никак не мешает атакующим. Зашифрованные приложения дампятся, перепаковываются. Контроль подписи не защищает от перепаковки, потому что предназначен в первую очередь для доверенной установки и обновления. В общем кажется, что в текущей ситуации без протектора все же не обойтись
Все так. Вопрос только какой ценой. Хороший протектор должен сравнять шансы в пользу защиты в плане денежных, экспертных и временных затрат атакующего. Даже опытные багхантеры не любят иметь дело с приложениями под обфускацией и RASP
В случае защиты от реверс инжиниринга это единственный способ. Но полагаться только на него не стоит. Тут в комментариях уже написали, что подобная защита должна использоваться в рамках принципа эшелонированной защиты, но не как единственный инструмент.
Я думаю антифрод не очень обрадуется транзакциям, выполненным через curl 🌚.
Что касается security through obscurity. Давайте возьмем, например, WAF. Он мешает атакующим исследовать веб-приложение: слать на него подозрительные запросы, искать на сервере xss, sqli и логические уязвимости. Если его убрать, то атакующему будет сильно легче фаззить сервер и в конце концов найти пропущенную уязвимость.
Считать ли использование WAF реализацией паттерна security through obscurity? Кажется что нет. Его использование не исключает работу команды appsec по обеспечению безопасности веб-приложения. И вот с обфускацией то же самое.
Такие инструменты как WAF, обфускация, RASP призваны фрустрировать атакующего, увеличивать стоимость атаки и вынуждать его искать другую жертву. Если вы когда-нибудь пытались искать уязвимости в веб-приложениях за WAF или в мобильных приложениях под протектором, вы понимаете, о чем я. Вся эта защита применяется не вместо, а вместе с другими подходами по обеспечению безопасности.
Так опенсорс - это единичные приложения. Какой опенсорс вы хотите привести в пример? Сигнал, телеграм? Не думаю, что опенсорсом балуются финтех, госы и так далее. Да, отдельные проекты могут быть, но это совершенно не массовая история.
Я тут ни в коем случае не пытаюсь сказать, что безопасно сделать невозможно или что не нужно проектировать безопасную архитектуру. Но вот тезис "сделали бы безопасно, защита была бы не нужна" очень сильно далек от реальности.
Недавно коллеги из dr web публиковали новость и вредоносной кампании. Если кратко, для внедрения вредоносов использовали реальные приложения, то есть фактически репакали популярные приложения. И распространяли тоже через сторы. Проверки в play market, appstore и других - дело хорошее, но это вообще не гарантия защиты, просто еще один важный этап. Да, это немного не про обфускацию, а больше про RASP, но современная защита обычно включает и то и другое, иначе нет смысла.
Вообще примеров можно найти много: это моды с читами, с отклюенной / ворованной рекламой, скрапперы и какие-то более нишевые истории типа приложений для курьеров, таксистов и так далее.
Согласен, что грамотная архитектура решит 99% проблем с безопасностью. Но грамотная архитектура бывает только в фантазиях инженеров. На деле имеем - тонны уязвимостей, включая примитивные в виде оставленных в коде ключей. Если приложение с уязвимостями все же опубликовали, то в случае наличия защиты от реверса у команды разработки будет банально больше времени выкатить исправления, потому что злоумышленник потратит больше времени на то, чтобы до этих уязвимостей добраться.
Если все это учитывать, бедный разработчик будет работать х2. Не удивительно, что большинство пугается и забивает на такую защиту, что на руку всяким мамкиным хакерам.
С такой позиции да. Но не думаю что злоумышленники будут пользоваться подобным сервисом, у них свои разработки. Но да, из-за такой проблемы очень непросто сделать подобную защиту, разрешенную для публикации в сторах, они как раз боятся криптованных вредоносов
Так вроде инструмент как раз против тех, кто реверсит приложения, то есть против тех самых хакеров, разве нет?)
Вы абсолютно правы: и по части виртуализации, и по части разнообразного применения различных техник. Но если первое вызывает огромные сложности при проходе ревью, то остается пользоваться вторым принципом. Так мы и делаем) но в сторону виртуализации смотрим. Реализовать сложно - не значит невозможно)
Предложите ваш способ, с удовольствием изучим и внедрим как новый модуль в pt maze
Но обфускация - это не одна техника, а целый набор защит в статике. Виртуализация - спорный момент именно в мобилках: магазины приложений очень не любят, когда виртуализируют код. Приходится выкручиваться.
Помимо защиты в статике крайне желательно использовать еще и защиту в динамике - RASP - runtime application self protection. В комплексе набор техник защит в статике и динамике дают эффект синергии, когда одна защита препятствует отлому другой.
Поэтому коммерческое решение должно предлагать полный спектр проверок и техник для противодействия реверс инжинирингу, тут я с вами согласен.
Важное уточнение: pt maze работает без исходных кодов, а ровно с теми сборками, которые и так попадают в магазины приложений. Открытые алгоритмы обфускации - это хорошо, но открытость упрощает их изучение и, как следствие, обход.
Что касается кардинального решения проблемы на уровне ОС - все это уже применяется и увы, никак не мешает атакующим. Зашифрованные приложения дампятся, перепаковываются. Контроль подписи не защищает от перепаковки, потому что предназначен в первую очередь для доверенной установки и обновления. В общем кажется, что в текущей ситуации без протектора все же не обойтись
Все так. Вопрос только какой ценой. Хороший протектор должен сравнять шансы в пользу защиты в плане денежных, экспертных и временных затрат атакующего. Даже опытные багхантеры не любят иметь дело с приложениями под обфускацией и RASP
В случае защиты от реверс инжиниринга это единственный способ. Но полагаться только на него не стоит. Тут в комментариях уже написали, что подобная защита должна использоваться в рамках принципа эшелонированной защиты, но не как единственный инструмент.