Comments 32
Хабр торт
Дух захватывает!
Делая подобную штуку, тоже хотел защититься от перехвата и изменения пакетов данных. Но судя по тому, что прошивку можно слить и реверснуть алгоритм «шифрования», то выход похоже только один — индивидуальные ключи каждому устройству.
Делая подобную штуку, тоже хотел защититься от перехвата и изменения пакетов данных. Но судя по тому, что прошивку можно слить и реверснуть алгоритм «шифрования», то выход похоже только один — индивидуальные ключи каждому устройству.
Выход есть и попроще: Open Source, где силами сообщества и заинтересованных компаний фиксятся уязвимости.
Почему если ОпенСорс, то значит безопасней продукт? Просто другая модель разработки…
Вопрос в том кому вы больше доверяете: мутной конторе с ужасным кодом или открытой разработке, где спокойно можете адаптировать под себя все что угодно? Нужна аутентификация — добавил, нужно асинхронное шифрование — кто мешает?
Проблему вижу в другом — дебильная сертификация ПО со сложной криптографией! Методика прохождение сертификации взята словно из позапрошлого века. На каждую версию не важно с какими изменениями необходимо проходить повторную сертификацию ПО. В итоге о каком своевременном обновление и фиксе уязвимостейможет идти речь?
Проблему вижу в другом — дебильная сертификация ПО со сложной криптографией! Методика прохождение сертификации взята словно из позапрошлого века. На каждую версию не важно с какими изменениями необходимо проходить повторную сертификацию ПО. В итоге о каком своевременном обновление и фиксе уязвимостейможет идти речь?
Вообще не ответили на мой вопрос. Почему код и архитектура ОпенСорсных приложение безопасней? Ваш ответ: Потому что там НЕТ аутентификации и шифрование, и я могу это привинтить сам (разумеется без ошибок и багов, я то знаю как это делать, а они все нет!) Это не ответ на мой вопрос)
Сертификация чего? СКЗИ в РФ? Или чего — модуля ПО для PA DSS?
Сертификация чего? СКЗИ в РФ? Или чего — модуля ПО для PA DSS?
Вроде бы самоочевидные вещи: OpenSource безопаснее за счет того, что всегда можно посмотреть исходный код и повлиять на ход разработки: можно либо форкнуть, либо отправить коммиты. В случае закрытой разработки нет рычагов влияния и примерами завалено полхабра, где различные компании по полгода и более закрывают критические уязвимости в своих продуктах. Программы по баг хантингу не панацея — тут напрямую зависит от того кто и как из сотрудников компаний курирует это программу.
Ну что программы по баг-хантингу не панацея, я согласен с Вами полностью.
По поводу пол-года — ну ведь эти сроки связанны с QA, множество веток продукта, которые ВСЕ надо проверить и сделать фикс — на это нужно время. Я Вас понимаю, тот факт что исходные код можно «просмотреть» — это бонус. Но никто не делает доскональный аудит системы в любом случае и те же уязвимости появляются с ТАКОЙ ЖЕ регулярностью, как и в не-опенсорсном продукте софте. Ваша вера — этого еще не достаточная причина, для таких утверждений.
Пример 1. ОпенСорсный Struts2 фиксил критичную багу с удаленным выполнением кода 2.5 месяца после репорта в _паблике_ (Пруф линк -http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html)
По этому примеру — Стратсу (только который недавно был, этим летом) хочу напомнить, что например после выхода в паблик инфы о сплойте, Китайцам понадобился 1 день, что бы состряпать бота и запустить по инетам, и уже через пару дней developers.apple.com был похекан. Лично МНЕ, тот факт, что Стратс2 это опен-сорсная тема, НЕ ПОМОГ, мне легче было зафильтровтаь патерн URL запроса в конфигах или настроить мод_сек, чем фиксить КОД жуткого Стратса на продакшене.
Пример 2 MySQL remote Heap Overflow — фиксили 1 год полсе репорта (http://www.zerodayinitiative.com/advisories/ZDI-13-251/). Но тут реальность применимости сплойта довольно мала, поэтому понять лично могу.
Пример 3 Firefox — почти 4 месяца на фикс. www.zerodayinitiative.com/advisories/ZDI-13-039/ (если в паблике бага просочилась, то тогда они фиксят 1 месяц.)
И что нам говорят все эти примеры? А вывода три:
1) Скорость фикса зависит от вендора, как в случае опен-сорца, так и в любом другом случае, а время базируется на критичности баги (реальной, а не той, что пишут в адвайзорах ресерчеры), публичности информации об этой проблеме (см Мозиллу) и оценке рисков в целом, кроме того большая доля делая зависит и от размера проекта (сколько веток, сколько кода), сложности патча (архитектурные проблемы будут фиксить от «долго» до «никогда»).
2) Когда начнет клевать петух, НИКТО не будет фиксить код САМ на продакшн серверах — есть методы вирутал-патчинга, фильтрации трафика, отключения уязвимого функционала — как воркэраунд солюшн. Затем все будут ждать патча от вендора. Если есть умные ребята из опен-сорца, они пишут патч и шлют его куда надо, там его тестят… и… те же 3 месяца и выходят.
3) Базируясь на выводах 1 и 2 получаем финальный вывод — разницы нет.
По поводу пол-года — ну ведь эти сроки связанны с QA, множество веток продукта, которые ВСЕ надо проверить и сделать фикс — на это нужно время. Я Вас понимаю, тот факт что исходные код можно «просмотреть» — это бонус. Но никто не делает доскональный аудит системы в любом случае и те же уязвимости появляются с ТАКОЙ ЖЕ регулярностью, как и в не-опенсорсном продукте софте. Ваша вера — этого еще не достаточная причина, для таких утверждений.
Пример 1. ОпенСорсный Struts2 фиксил критичную багу с удаленным выполнением кода 2.5 месяца после репорта в _паблике_ (Пруф линк -http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote.html)
По этому примеру — Стратсу (только который недавно был, этим летом) хочу напомнить, что например после выхода в паблик инфы о сплойте, Китайцам понадобился 1 день, что бы состряпать бота и запустить по инетам, и уже через пару дней developers.apple.com был похекан. Лично МНЕ, тот факт, что Стратс2 это опен-сорсная тема, НЕ ПОМОГ, мне легче было зафильтровтаь патерн URL запроса в конфигах или настроить мод_сек, чем фиксить КОД жуткого Стратса на продакшене.
Пример 2 MySQL remote Heap Overflow — фиксили 1 год полсе репорта (http://www.zerodayinitiative.com/advisories/ZDI-13-251/). Но тут реальность применимости сплойта довольно мала, поэтому понять лично могу.
Пример 3 Firefox — почти 4 месяца на фикс. www.zerodayinitiative.com/advisories/ZDI-13-039/ (если в паблике бага просочилась, то тогда они фиксят 1 месяц.)
И что нам говорят все эти примеры? А вывода три:
1) Скорость фикса зависит от вендора, как в случае опен-сорца, так и в любом другом случае, а время базируется на критичности баги (реальной, а не той, что пишут в адвайзорах ресерчеры), публичности информации об этой проблеме (см Мозиллу) и оценке рисков в целом, кроме того большая доля делая зависит и от размера проекта (сколько веток, сколько кода), сложности патча (архитектурные проблемы будут фиксить от «долго» до «никогда»).
2) Когда начнет клевать петух, НИКТО не будет фиксить код САМ на продакшн серверах — есть методы вирутал-патчинга, фильтрации трафика, отключения уязвимого функционала — как воркэраунд солюшн. Затем все будут ждать патча от вендора. Если есть умные ребята из опен-сорца, они пишут патч и шлют его куда надо, там его тестят… и… те же 3 месяца и выходят.
3) Базируясь на выводах 1 и 2 получаем финальный вывод — разницы нет.
UFO just landed and posted this here
код утилиты ужасен.
Соглашусь.
Увы, я не программист.
Увы, я не программист.
def lst_print(lst): ##print all packet
all=[]
>>> all
<built-in function all>
all.append(lst[0])
all.append(lst[1])
all.append(lst[2])
all.append(lst[3])
зачем так длинно, если можно
all.extend( lst[:4] )
for x in lst[4]:
all.append(x[0])
all.append(x[1])
all.append(x[2])
all.append(x[3])
all.append(x[4])
all.append(x[5])
all.append(x[6])
all.append(x[7])
аналогично.
for z in all:
str=str+z
return str
можно просто
return ''.join( all )
это быстрее и короче.
UFO just landed and posted this here
1) на это и наткнулись :(
2) SSL хорошо, но опять же все зависит от конкретной реализации. От пассивного прослушивания он спасет, а с активным MiTM-ом уже возможны варианты.
3) как правило она ограничивается белыми списками номеров, которые вполне могут обходиться СМС с подделкой номера
2) SSL хорошо, но опять же все зависит от конкретной реализации. От пассивного прослушивания он спасет, а с активным MiTM-ом уже возможны варианты.
3) как правило она ограничивается белыми списками номеров, которые вполне могут обходиться СМС с подделкой номера
UFO just landed and posted this here
Не могли бы вы привести пример такого трекера, чтоб SSL, JTag прикрытый и несколько паролей. Попробуем глянуть.
UFO just landed and posted this here
Ох, ну и угораздило вас назвать свое изделие — по названию прибора найти официальный сайт удалось только попав сначала на страницу Экслера с обзором, где на фото трекера можно было рассмотреть название фирмы-производителя.
При этом на странице описания (местами даже излишне богатой подробностями вроде «GSM 900/1800» в текстовой части, а не только в таблице характеристик) про SSL и защиту от слива прошивки ничего нет. Зачем скрывать конкурентные преимущества изделия и лишать покупателя возможности найти устройство поиском?
При этом на странице описания (местами даже излишне богатой подробностями вроде «GSM 900/1800» в текстовой части, а не только в таблице характеристик) про SSL и защиту от слива прошивки ничего нет. Зачем скрывать конкурентные преимущества изделия и лишать покупателя возможности найти устройство поиском?
Да много девайсов, например Locarus. На самом деле, те что в России собирают и давно как правило такие огрехи не касаются, да и прошивка в них зашифрованная.
Жду не дождусь интернета вещей. Миллионы багованных, нешифрованных, глючных устройств вокруг нас. Раздолье и цубепунк.
А почему компании не поставить свой, внутренний сервер для сбора статистики, если число машин достаточно велико? Побезопаснее будет, как минимум.
Очень интересно! Когда в ход идёт и хардварный хакинг — это всегда завораживает.
Сегодня же не первое апреля? Это не бумажная газета? Точно?
Друзья, ну что за воды вы тут налили? Зачем уж так сгущать краски то? :)
Сервера для трекинга могут быть кастомными, установленными нормальными админами. Более менее обновляемый дистрибутив с закрытыми наружу портами (кроме 80) и все. Вы вряд ли что-то серьезное с ним сделаете. А если программист профи (или хотя бы пользующийся нетухлыми фреймворками)- то не будет ни иньекций, ни кросс-сайт скриптинга. Ну не сможет человек, имеющий даже среднее представление о том как все устроено в сети что-то сделать с такого уровня (совершенно простого) сервером. А если сможет — то он уже занят чем-то интересным, а не логистическими компаниями.
Отсутствие пароля по умолчанию или простой пароль — все это сделано для удобства пользователя, который с хитрой штукой с первого раза не справится почти наверняка. И ему еще и пароль надо вводить. Поэтому делают простой пароль, но в инструкции пишут — давайте, смените! и еще и жирным отмечают, наверняка. Фирме, производящие трекеры пофигу, какой пароль лить в него при конфигурировании при сборке, согласны?
Теперь о железках. Ага. Видите, когда дело коснулось не чтения протоколов (думаю вам бы их выдали в компании, если бы вы попросили), которые, ищутся через google, а не крадутся с серверов компании :) у вас ничего не получилось. Потому-что биты защиты итд итп. Ну скачаете вы прошивку (забудет программер бит поставить — тогда — повезет), получите мегабайт ассемблера. Удачи с разбором и компиляцией.
Друзья, ну какой биткоин майнер на таком железе? какой DDOS по GPRS?
Тут же вокруг программисты, инженеры… Зачем такое тут писать? Это текст, что выше — для рекламного буклета, чтобы продавать свои услуги :)
Из этой писанины можно сделать следующий вывод: В вашей компании появился новичок, которому поручили написать поп-статью. Потом старших рядом не было и он ее, без утверждения, опубликовал.
Ай-ай-ай. Нехорошо! в угол!
p.s.
Да-да. про фейковую базовую станцию — оценил :)) А че не написать, что можно было бы использовать инсайдеров средит директората сотовых компаниях, но че их беспокоить по ерунде, если и так все на поверхности лежит.
Друзья, ну что за воды вы тут налили? Зачем уж так сгущать краски то? :)
Сервера для трекинга могут быть кастомными, установленными нормальными админами. Более менее обновляемый дистрибутив с закрытыми наружу портами (кроме 80) и все. Вы вряд ли что-то серьезное с ним сделаете. А если программист профи (или хотя бы пользующийся нетухлыми фреймворками)- то не будет ни иньекций, ни кросс-сайт скриптинга. Ну не сможет человек, имеющий даже среднее представление о том как все устроено в сети что-то сделать с такого уровня (совершенно простого) сервером. А если сможет — то он уже занят чем-то интересным, а не логистическими компаниями.
Отсутствие пароля по умолчанию или простой пароль — все это сделано для удобства пользователя, который с хитрой штукой с первого раза не справится почти наверняка. И ему еще и пароль надо вводить. Поэтому делают простой пароль, но в инструкции пишут — давайте, смените! и еще и жирным отмечают, наверняка. Фирме, производящие трекеры пофигу, какой пароль лить в него при конфигурировании при сборке, согласны?
Теперь о железках. Ага. Видите, когда дело коснулось не чтения протоколов (думаю вам бы их выдали в компании, если бы вы попросили), которые, ищутся через google, а не крадутся с серверов компании :) у вас ничего не получилось. Потому-что биты защиты итд итп. Ну скачаете вы прошивку (забудет программер бит поставить — тогда — повезет), получите мегабайт ассемблера. Удачи с разбором и компиляцией.
Друзья, ну какой биткоин майнер на таком железе? какой DDOS по GPRS?
Тут же вокруг программисты, инженеры… Зачем такое тут писать? Это текст, что выше — для рекламного буклета, чтобы продавать свои услуги :)
Из этой писанины можно сделать следующий вывод: В вашей компании появился новичок, которому поручили написать поп-статью. Потом старших рядом не было и он ее, без утверждения, опубликовал.
Ай-ай-ай. Нехорошо! в угол!
p.s.
Да-да. про фейковую базовую станцию — оценил :)) А че не написать, что можно было бы использовать инсайдеров средит директората сотовых компаниях, но че их беспокоить по ерунде, если и так все на поверхности лежит.
.
Отвечая на финальный вопрос: какой вывод можно сделать из этой статьи?
Вывод такой: «на каждую хитрую задницу найдется свой инструмент»
Вывод такой: «на каждую хитрую задницу найдется свой инструмент»
Only those users with full accounts are able to leave comments. Log in, please.
Где моя повозка, сударь? Безопасность GPS-трекинга