Привет всем. Как можно сграббить пароли и куки фф без использования nss3? Подкачивать - не вариант. Спасибо.
-
XSS.stack #1 – первый литературный журнал от юзеров форума
Граббинг паролей и куки фф.
- Автор темы winload
- Дата начала
Ну можно подгружать из папки firefox если там есть нужные .dll'ки для работы.
А так только подгружать.
Как вариант можно в ресурсы засунуть необходимые .dll - после извлечь.
А так только подгружать.
Как вариант можно в ресурсы засунуть необходимые .dll - после извлечь.
- Автор темы
- Добавить закладку
- #3
В первом случае нужно будет использовать heavens gate, чего делать не особо хочется. Второе - костыль.
Куки, формы, история на сколько я помню там вроде бы открытые лежат, вытащить не трудно
Если делаешь для себя и не хочешь заморачиваться, можешь стащить logins.json и key3/key4 и расшифровывать через прогу PasswordFox
Кода меньше, действий меньше, но это не готовый текстовик
Спроси у автора крота, у него вроде парсинг всей этой хуеты без nss
Только эта хуета сломалась на новых фф. (LaZagne с таким парсингом тому пример, а issues нет, потому что код покрыт эксепшенами и тупо нет ошибок) И чето я понял, что это нестабильная вещь и лучше сделать на nss с одним нюансом. Не трогать его на клиенте. Вообще. И ничего не тащить с собой.
Не обязательно подкачивать. Я решил расшифровку фф сделать сервер сайд, дамплю профиль просто с клиента. Профили у мозиллы платформонезависимы и там нет dpapi и подобной х#йни. А дальше на сервере инициализирую nss бекенд языком и дамплю ним же(выпилил с линуксового firefox libnss3.so и его зависимости, там где то 10 библиотек). В итоге код ужался в разы и работает для всех версий фф и не тащу ниче на клиент + все так же ахуительно автоматизируется(расшифровка) и пишется в дб плейнтекстом.
UPD.
в чем прикол. Профиль может остаться, а фф выпилили давно допустим с либами нсс. И если у тебя расшифровщик на клиенте, то хрен тебе, а не логи. А тащить на клиент либы нсс и их зависимости - ну такое.
Последнее редактирование:
https://github.com/nss-dev/nss
такой же есть и для NSPR4
Оттуда выцепить nss3.h/nss3.c и зависимости.
такой же есть и для NSPR4
Оттуда выцепить nss3.h/nss3.c и зависимости.
нет и нет
тебе ничего не мешает подгрузить дллку из памяти, а перед этим реквестнуть ее со своего сервака по любому удобному тебе транспортному протоколу
Ты что тут такое предлагаешь.. тутнет и нет
тебе ничего не мешает подгрузить дллку из памяти, а перед этим реквестнуть ее со своего сервака по любому удобному тебе транспортному протоколу
шареды у людей, не дай бог не выдержат нагрузки?
- Автор темы
- Добавить закладку
- #10
Это костыльно. Лишнее сетевое взаимодействие. Давайте тогда сразу WebBrowserPassview в памяти запускать, чего уж там. Нормальным вариантом будет собрать всё в один модуль и работать уже непосредственно с ним.нет и нет
тебе ничего не мешает подгрузить дллку из памяти, а перед этим реквестнуть ее со своего сервака по любому удобному тебе транспортному протоколу
Не, любая статическая линковка модулей в одну исполняемую сущность(монолит) или зависимостей это габелла и подход лоу скиллов. И сетевое взаимодействие не так пагубно, как это. Костыльно как раз таки тащить сразу все в доставляемом билде. А упрешься в эту проблему ты все равно рано или поздно. Если не уперся, значит в твоей малвари просто ещё мало модулей.
- Автор темы
- Добавить закладку
- #12
Бред, имхо. Твоё высказывание актуально сугубо в контексте банкботов. Вот там - да, есть нужда в куче third-party. Zlib, http2 и куча другого стаффа, несущего мегабайты кода. В других случаях от такого подхода смысла нет, это бессмысленно.
При такой архитектуре возможно сделать доставляемый билд пару кб в независимости от контента под капотом, который в динамике доставляется и инвокается. Лично я разрабатываю так. То что могу на сервер вынести - выношу. Могу фф на сервере расшифровать - выношу. Не могу что то сделать на сервере в силу технических ограничений или етсвественных(то что на пк холдера надо исполнить ) доставляю и инвокаю в динамике. Схема работает как часы, когда ты кодишь на уровне интерфейсов по сути, а не на уровне реализаций. Имхо это критично в той части, которая и берет на себя первичный удар при доставке на борт юзеру. А имея в статике это все - получаешь кучу декларативного кода, который в твоём билде вторичен, но, за который более чем реально зацепиться при анализе аверами твоего билда. Ну то есть морфить к примеру ты будешь рабочую часть, где дампишь пассы, а остальное, «на что ты не влияешь в данный момент» напрямую и (остальные модули, которые поленился динамически грузить или зависимости) дают отличный индикатор компрометации для авера, который только на основе анализа «внешне» - уже понимает, на что примерно софт ориентирован. Софт юзает nss, который не изменяется, в отличии от основного кода и виден «сразу» и дергает дпапи? Понятно сразу что перед тобой кредс дампер,а тобой написанные ифы и элсы нуждаются в более тщательной проверке)
В 2020 году софт с маленьким весом стриггерит любой эвристик, мало смысла делать такое.
Мы говорим за статический анализ? Как тогда авер определит что у меня юзается nss3? Мы же не плейнтекстом храним модуль, а в покриптованном блобе который расшифруется и загрузится в память загрузчиком во время инициализации. Давно за тобой наблюдаю, в последнее время ты откровенную х#йню несешь честно говоря.
Смотря какой язык и подход. Я ж на пш бахаю где все завязано на рефлексии и то, ради чего в нейтиве приходится чутка заморочиться - в пш получается из коробки и нормально. Элементарно лаунчер с iex webclient downloadstring не триггерит. Хотя может в контексте данной дискуссии пример не особо удачный, но 8 килобайтами кода можно прогрузить все что хочешь. И на эти 8кб не триггерит. В нативе мб принципы другие. Но я утверждаю только о том, чем я занимаюсь и что видел. И что есть вообще такая возможность.
->
->
->
Может я дурак, но речи о модульности вообще не шло. Точнее как. Я как раз топил за модульность и за подход, который ты говоришь, за исключением одного но - блоб хранить не в билде, а подтягивать с сервера , ради уменьшения веса. Мне начали говорить что это костыли. И только для больших проектов. Если бы мне написали за загрузчик в памяти из блоба модулей, я бы разве начал говорить за монолиты? И разве не логично блоб тащить с сервера?
ну я даж хз что тебе ответить на это, х#йня так х#йня)
Последнее редактирование:
Видать мы друг друга не правильно поняли. Какой смысл тянуть дополнительные зависимости для софта который изначально спроектирован в виде модуля? Какая разница как качать, если все равно придется качать данные такого же размера? Или мы говорим о разном?
Я лишь хотел донести, что с моей точки зрения плохо в софте тащить хэлперы и модули в виде открытого кода, будь то это явные палевные импорты, которые касаются разного рода хэлперов, для выполнения конкретной задачи или куски кода хэлперов типо sqlite3helper в сорцах или модулей для расшифровки типо nss, которые идут копипастой при компиляции в сорц, потому что их можно и нужно собрать и грузить из блоба в памяти. Поскольку если так не делать, то вот этот менеджмент код может быть зацепкой для авера. Но если мы их грузим из блоба в памяти - то для чего хранить сам блоб в билде, тем самым раздувая билд на размер этого хэлпера/зависимости, если для всего этого дела можно определить только интерфейс для будущего взаимодействия, а конкретику получать с сервера, уже на рантайме. Избегая при этом и лишнего веса и сигнатур в статик тайме именно с открытого кода. Но мне начали говорить что это все костыль для крупных проектов с крупными зависимостями которые измеряются в мегабайтах.
В целом согласен, да. пш удобный инструмент для кодинга школомалвари на уровне скачать запустить, больше от него и не требуется. Для более серьезных задач конечно не подходит, например там не получится установить классические перехваты, только через аппаратные точки останова с триггером на выполнение, которые кстати медленее обычных транзишнов в 100 раз(в прямом смысле). В местах в которых нужно постоянно транслировать данные(граберы/инжекты) такое будет избыточным.
Не согласен) конкретно в том, что использование пш для школомалвари. Пш в целом иначе анализируется аверами и там проще их обойти. Иначе говоря, даже удроченные техники в нейтиве там можно сделать с чистым выполнением. Вин апи инвокается через p/invoke, .net тоже. Никакой метаинфы о самом файле. Легко сделать fileless всю движуху(оно и так живет все в памяти по сути). Многие, если не все техники повторимы из дефолтной СИ малвари. (Не берём в счёт кернел движуху). Проще работать с СОМ.
Ну перечислять можно долго. Но работает конечно все это дело дольше. Глупо сравнивать интерпретатор пш и плюсы те же или си. Разное вообще.