👩‍💻 Win11Debloat.

• Очень полезный PowerShell скрипт, который поможет вырезать весь мусор и ускорить Ваш Windows. Возможности:

— Удалить все бесполезные приложения, которые замедляют ОС;
— Отключить рекламу в меню Пуск;
— Вернуть панель задач из Windows 10;
— Вырубить телеметрию и сбор данных;
— Убрать бессмысленные опции в контекстном меню;
— Вырезать Кортану, Copilot и Bing.

• Работает на Windows 11 и 10. Если какие-то изменения не подходят — их легко откатить. Забираем с GitHub:

➡️ https://github.com/Raphire/Win11Debloat

#PowerShell #Windows

📞 Первый трансконтинентальный телефонный звонок.

• А вы знали, что с момента первого трансконтинентального телефонного звонка прошло почти 100 лет? 25 января 1915 года Александр Грейам Белл, один из основоположников телефонии и основатель Bell Labs, поговорил со своим помощником Томасом Ватсоном. При этом Белл находился в Нью-Йорке, а Ватсон – в Сан-Франциско. Это стало знаковым событием в мире коммуникаций.

• За 39 лет до этого Белл совершил первый в мире телефонный разговор с тем же Ватсоном, находившемся всего лишь в другой комнате. Теперь же для разговора через континент потребовалась серьёзная инфраструктура. Старожилы помнят возню с междугородными и международными звонками несколько десятилетий назад, когда приходилось «заказывать разговоры». Но в 1915 году это был практически хакатон.

• В 1915 году на звонок потребовалось 10 минут, так как все операторы станций по пути следования звонка должны были вручную сделать необходимые включения. Связь шла по медным проводам протяжённостью в 11000 километров, которые представляли собой, фактически, единый контур, который мог одновременно поддерживать только один звонок. После этого события официально была запущена услуга коммерческой телефонной связи. Трёхминутный звонок обходился в $20.7, что в нынешних ценах составляет примерно $1100.

#Разное

👩‍💻 "89 things I know about Git commits".

• Объемный чек-лист, который может оказаться полезным при работе с Git: https://www.jvt.iss.one/posts/2024/07/12/things-know-commits/

• Дополнительно:

- Open source игра для изучения GIT;
- Базовый курс по Git;
- Бесплатная книга Pro Git.

#git

🖥 FAR Manager.

• Вероятно Вы слышали, что Евгений Лазаревич Рошал, который является автором формата RAR и архиватора WinRAR, является еще создателем файлового менеджера FAR Manager. История создания FAR начинается через три года после создания WinRAR, а первая общедоступная бета-версия менеджера увидела свет 10 сентября 1996 года.

• В то время FAR начал уверенно конкурировать с другим набиравшим популярность на постсоветском пространстве файловым менеджером: DOS Navigator, но обладал перед ним целым рядом преимуществ. Прежде всего, FAR умел взаимодействовать с файловой системой NTFS, благодаря чему с ним могли работать пользователи Windows NT. Кроме того, он корректно определял кодировки русского языка (в том числе, в именах каталогов и файлов), и позволял устанавливать подключаемые модули — плагины, которые значительно расширяли функциональность программы.

• Первые редакции FAR Manager были проприетарными, но в 2000 году Рошал передал версию 1.64 нескольким авторам наиболее популярных плагинов «за спасибо», после чего программа получила дальнейшее развитие под лицензией BSD, а ее разработчики объединились в организацию под названием FAR Group.

• В 2004 году Евгений передал все коммерческие права на свои разработки старшему брату Александру Рошалу, который впоследствии стал самостоятельно контролировать вопросы распространения его программных продуктов, а сам покинул Россию. Евгений Лазаревич ведет очень замкнутый образ жизни, поэтому о его нынешнем роде занятий практически ничего не известно. По слухам, он обосновался в Германии, а позже перебрался в США.

• В настоящий момент архиватором Рошала продолжают пользоваться миллионы людей по всему миру, а FAR Manager до сих пор установлен на многих компьютерах под управлением Microsoft Windows — эту программу предпочитают те, кто привык к «двухппанельному» интерфейсу классического Norton Commander.

#Разное

📶 Алгоритм установления соединения в протоколе SSH.

• Алгоритм протокола SSH можно разделить на три уровня, каждый из которых располагается над предыдущим: транспорт (открытие защищённого канала), аутентификация, подключение. Для целостности картины добавим сюда уровень установки сетевого соединения, хотя официально этот уровень находится ниже SSH.

🟢 Установка TCP-соединения: на этом этапе происходит сетевое подключение клиента к серверу на TCP-порт, указанный в опции Port (по умолчанию: 22) в файле конфигурации сервера /etc/ssh/sshd_config

🟢 Открытие защищенного канала:

- Обмен идентификационными данными: после установки TCP-соединения, клиент и сервер обмениваются версиями SSH-протокола и другими вспомогательными данными, необходимыми для выяснения совместимости протоколов и для выбора алгоритмов работы.

- Выбор алгоритмов (обмена ключами, шифрования, сжатия и т.п.): на этом шаге стороны отсылают друг другу списки поддерживаемых алгоритмов, наибольший приоритет имеют алгоритмы в начале каждого списка. Затем сравнивают алгоритмы в полученных списках с алгоритмами, имеющимися в системе, и выбирают первый совпавший в каждом списке. Список доступных алгоритмов обмена ключами на стороне клиента (используются для получения сессионного ключа) можно посмотреть командой: ssh -Q kex

- Получение сессионного ключа шифрования: Процесс получения сессионного ключа может отличаться в зависимости от версии алгоритма, но в общих чертах сводится к следующему: Сервер отсылает клиенту свой ключ (DSA, RSA или т.п.), если клиент производит соединение с данным сервером впервые, то пользователю будет задан вопрос о доверии ключу сервера. Если же соединение с данным сервером уже устанавливалось ранее, то клиент сравнивает присланный ключ с ключом, записанным в /home/username/.ssh/known_hosts. Если ключи не совпадают, то пользователь получит предупреждение о возможной попытке взлома. Как только клиент определился с доверием к ключу сервера, с помощью одной из реализаций алгоритма Диффи-Хеллмана клиент и сервер генерируют сеансовый ключ, который будет использоваться для симметричного шифрования канала.

🟢 Аутентификация клиента: только теперь, когда клиент и сервер установили канал для зашифрованной передачи данных, они могут произвести аутентификацию по паролю или ключам.

- В общих чертах, аутентификация посредством ключей происходит следующим образом: клиент отсылает серверу имя пользователя и свой публичный ключ. Сервер проверяет в файле /home/username/.ssh/authorized_keys наличие присланного клиентом открытого ключа. Если открытый ключ найден, то сервер генерирует случайное число и шифрует его открытым ключом клиента, после чего результат отправляется клиенту. Клиент расшифровывает сообщение своим приватным ключом и отправляет результат серверу. Сервер проверяет полученный результат на совпадение с тем числом, которое он изначально зашифровал открытым ключом клиента, и в случае совпадения считает аутентификацию успешной.

🟢 Уровень подключения: после проведения всех вышеперечисленных процедур, пользователь получает возможность передавать команды серверу или копировать файлы.

#SSH

🖥 Gopher. Протокол, который поддерживается энтузиастами по сей день.

• Когда в 90-х годах к сети начали подключать все больше ПК, то появился спрос на специальный инструмент для поиска и считывания данных. Из-за этого и возник так называемый «Internet Gopher Protocol». В спецификации протокола RFC1436 мы можем встретить многие понятия, используемые и по сей день: соединение TCP/IP, модель «клиент-сервер» и т. п. Если коротко, то Gopher был своего рода протоколом «раннего веба» в простом текстовом виде, оптимизированным для медленных соединений.

• На самом деле, Gopher был активен не так долго, его создали в 1991 году, а популярность начала снижаться в 1994 году. Проблемы были не только техническими, но и юридическими — лицензия на сервер Gopher была платной (её перелицензировали под GNU License только в 2000 году). Кроме того, компьютеры стали мощнее, и люди стали предпочитать более красивые страницы WWW вместо текстовых. Любопытно, что Internet Explorer в Windows 95 мог открывать ссылки Gopher, но уже в Windows XP этой функции больше не было.

• Но всё-таки некоторые серверы Gopher поддерживаются энтузиастами и по сей день. Бесплатный клиент можно скачать со страницы https://github.com/jankammerath/gophie/releases, а потом попробовать открыть страницу gopher://gopherddit.com:70, обеспечивающую доступ к группам Reddit, ну или адресу gopher://gopherpedia.com:70 можно читать Википедию.

#Разное

🛡 Аппаратное шифрование.

• Шифрование – тема бездонная. Всегда найдется тема, которую либо не раскрыли, либо раскрыли чрезвычайно узко. Вот сегодня мы и поговорим про вот такую узкую тему в шифровании – а именно про аппаратное шифрование.

• Итак, аппаратное шифрование. Его смысл в том, что если при обычном шифровании вся крипто-магия идет на вашем компьютере, то в аппаратном шифровании – на вашем устройства (например, на отделяемом жестком диске). Поэтому оно не требует специального софта: нужно только пустое гнездо для USB. Обычно, на таком аппарате есть клавиши для ввода числового пароля. Подключил диск, набрал комбинацию, он открылся. Набрал неправильную комбинацию – открылся шиш с маслом.

• Какие ваши преимущества? Да очень простые. Во-первых, не нужен никакой софт. Во-вторых, цифровой пароль запоминается проще, чем численный и буквенный. В-третьих, аппаратный диск специально защищен от дешифровки софтовыми методами. Ну и физическим перебором его не возьмешь – заблокируется и все тут. В-четвертых, его не вытащить физически: весь диск залит эпоксидкой. Попытка его извлечь гарантированно убьет все данные.

• Но это все цветочки. Самая главная ягодка – это пароль под давлением. Проблема вот в чем: когда оперативник видит архив, то он понимает, что в нем 2 гигабайта вещдоков, поэтому если ты вводишь пароль под давлением и он открывается пустым – значит ты уничтожил улики. А это уже срок. Аппаратное хранилище не показывает, есть на нем данные или нет. И поэтому тут пароль самоуничтожения работает. Наличие улик на этом жестком диске доказать невозможно. Так что я могу рекомендовать.

• А что по минусам? Цена. Такие девайсы стоят много-много шекелей. Но они того стоят.

#Шифрование

👨‍💻 Прорываемся к домен контроллеру через розетку.

• Занимательная история про внутренний пентест, в ходе которого специалистам удалось добраться до администратора домена не имея учетной записи.

• В этом проекте использовались много разнообразных техник: от декомпиляции приложения и расшифровки извлеченных учетных данных, до повышения привилегий через базу данных на сервере и сбора информации от имени учетной записи компьютера. В рассказе подробно разобрано, как они сложились в успешный вектор атаки.

➡ https://habr.com/ru/post/767706/

#Пентест

Доброе утро... 🫠

#Понедельник

🤔 Почему возникли GNOME 3 и Unity?

• В 2006 году корпорация Microsoft пригрозила подать в суд на всех разработчиков #Linux с интерфейсом, похожим на Windows 95. Сейчас Microsoft позиционирует себя как дружелюбную компанию, но тогда было иначе. Это была серьёзная угроза.

• Microsoft разработала Win95 с нуля. Её интерфейс кардинально отличался от всех предыдущих систем (например, Windows для рабочих групп 3.11, Windows NT 3.51 и OS/2 1.x). Панель задач, меню «Пуск», системный трей, «Мой компьютер», «Сетевое окружение», всё это — оригинальные, запатентованные разработки Microsoft. До этого не было ничего подобного.

• На этот запатентованный интерфейс больше всего похожа RISC OS от Acorn, с «панелью иконок» на компьютерах Archimedes, но она работала совсем иначе. Несколько таких компьютеров импортировали в Северную Америку, и сразу после этого NeXT «изобрела» Dock, а Microsoft придумала гораздо более сложную панель задач.

• В общем, SUSE (крупнейшая немецкая Linux-компания, так что KDE — это немецкий проект. Разработчики SUSE проделали основную работу по созданию KDE) подписала с Microsoft соглашение о совместном использовании патентов, то есть по сути получила разрешение на использование этого интерфейса. Поэтому когда SUSE подписала соглашение, KDE был в безопасности. Чего нельзя сказать про GNOME.

• Red Hat и Ubuntu отказались подписывать договор с Microsoft на использование её интеллектуальной собственности. Эти компании попали в трудное положение. Обеим был нужен рабочий стол не как в Windows, и как можно скорее — без меню «Пуск», без панели задач, без значков «свернуть/развернуть/закрыть окно» справа вверху, без оконного меню в левом верхнем углу и так далее по списку майкрософтовских патентов.

• Red Hat — основной спонсор разработки GNOME. Когда KDE только появилась, библиотека Qt для создания GUI распространялась не под GPL, а под другой лицензией. Поэтому Red Hat пришлось отказаться от её распространения и поддержки, а вместо этого писать собственную среду.

• Ubuntu пыталась поучаствовать в разработке GNOME 3, но получила отказ. Поэтому пошла своим путём и выпустила Unity — по сути, подражание Mac OS X, только получше (на мой вкус).

• Так что и Red Hat, и Ubuntu по умолчанию перешли на рабочие столы, отличные от Windows. В итоге Microsoft ни на кого не подавала в суд… но добилась именно того, чего хотела — полного хаоса в десктопном Линуксе.

• До этих угроз со стороны Microsoft почти все использовали GNOME 2. Даже SUSE поставляла GNOME в комплекте, потому что её корпоративный владелец купил Ximian (основных сторонних разработчиков GNOME), и насильно объединил компанию с SUSE.

• Затем Microsoft помахала саблей — и мир FOSS UNIX раскололся на части. В итоге Red Hat перешла на GNOME 3, а Ubuntu — на Unity, оттолкнув многих людей, которые умели пользоваться только Windows-подобными рабочими столами. Это обеспечило огромный успех дистрибутиву Mint.

• GNOME 2 форкнули как MATE, и Mint принял его, что очень помогло его успеху. Он также выпустил собственный форк GNOME 3 под названием Cinnamon. Крошечные нишевые десктопы типа Xfce и LXDE получили огромный буст. Debian сделал выбор в пользу GNOME 3 и systemd, взбесив многих своих разработчиков и приведя к форку Devuan.

• Да, Unity развился из рабочего стола Ubuntu для нетбуков. Но это произошло потому, что сама компания Ubuntu оказалась в опасности. Xubuntu, Lubuntu и Kubuntu — не официальные дистрибутивы и не установлены по умолчанию, поэтому не представляют угрозы.

➡️ https://liam-on-linux.dreamwidth.org/85359.html

#Разное

👩‍💻 История создания PowerShell.

• Вчера был опубликован пост, в котором описан очень крутой PowerShell-модуль для Blue Team. Давайте сегодня поговорим об истории создания этого инструмента и его авторе:

• Сразу нужно отметить, что создателем PowerShell является Джеффри Сновер. Для продвижения своего проекта ему пришлось преодолеть много трудностей внутри компании, так как Microsoft была против создания Unix-подобного инструмента и включению его в состав Windows.

• А началось все с 1999 года, когда Бил Гейтс начал беспокоиться о том, что Windows никак не совместима с дата-центрами, хотя он прекрасно понимал, что этом рынке крутятся огромные деньги. Хуже того, руководство Microsoft привыкло жить в старых реалиях, они разбирались в персональных компьютерах, но не понимали серверный рынок. Вот тогда они и нашли Джеффри и пригласили его на работу.

• Цель была следующая: установить Windows NT как реального конкурента для вендоров Unix-систем, таких как Sun, IBM и HP. Теоретически, у Microsoft было стратегическое преимущество благодаря сотрудничеству с Intel, оставалось только выпустить годный софт, и они могли предложить услуги за меньшую цену, чем конкуренты.

• Проблемой ещё были системные интеграторы вроде IBM Professional Services, которые сильно накручивали цены на установку софта от Microsoft. На каждую машину программы надо было ставить вручную через графический интерфейс. А как избавиться от системных интеграторов? Разработать встроенный механизм системной интеграции. В Unix такое было, там клиенты сами настраивали системы и не обращаясь к системным интеграторам. Вот что нужно было Microsoft!

• Джеффри присоединился к отделу Windows Server, чтобы решить эту задачу. Сотрудникам Microsoft было нелегко принять новую логику и думать о дата-цетрах и системном администрировании в Unix-стиле. Сервисы на серверах запускали из командной строки или через удалённый рабочий стол. То есть каждый раз при загрузке Windows кто-то должен был залогиниться туда и ввести команду.

• Единственным средством настройки Windows были Windows Managemet Instrumention (WMI), но пользователи мало их использовали, и Джеффри увидел в этом возможность: создать текстовую консоль для управления всем: настройками пользователя, сетевой конфигурацией, установкой приложений — всё через WMI.

• Если считать по количеству объектов в WMI, то эта консоль должна поддерживать тысячи команд. Интересно, что для разработки пришлось нанимать программистов по контракту, потому что штатные разработчики Microsoft не смогли осилить такую задачу.

• Дедлайн ему поставили через десять недель. Логика была такая, что нужно выпустить хоть какую-то глючную версию программы, а потом исправлять баги. Джеффри оплатил работу контрактным программистам, и они успели реализовать примерно 70 функций (команд). Это было только начало.

• Но затем оказалось, что никакая программа не может выйти без одобрения отдела тестирования. А это очень долгая бюрократическая процедура, они хотели буквально проверить каждую команду. Джеффри не мог допустить такой задержки, поэтому придумал другую процедуру с составлением файла метаданных, который проверяет корректность работы программы, а не проходит по всем функциям. Так вышла первая версия PowerShell с поддержкой 72 команд. Это было практически одновременно с выходом Windows XP на ядре NT.

• Потом оказалось, что в Microsoft есть ещё одна группа, которая разрабатывает консоль. Но они просто взяли K-shell и портировали её. Тогда Джеффри буквально заперся в комнате и собственноручно написал то, что станет первым прототипом PowerShell, это было демо на 10 000 строк кода. Он показал его коллегам из того отдела, впечатлил их, и они стали работать вместе, а Джеффри удалось получить финансирование под проект. Так родился PowerShell (хотя изначально он назывался Monad), а самого Джеффри понизили в должности, потому что отдел PowerShell насчитывал всего несколько человек. Вот такие дела...

➡ https://corecursive.com/building-powershell-with-jeffrey-snover/

#Разное

🔓 Взлом через NPM: удаленное выполнение кода и повышение привилегии в Windows после подключения к определенной SSID Wi-Fi.

• ИБ эксперты обнаружили критическую уязвимость CVE-2024–56334 в npm‑пакете systeminformation, которая позволяет удалённо выполнить код и повышать привилегии в среде Windows после подключения к определённому SSID Wi‑Fi, у которого вместо имени задан список специальных команд.

• Уязвимость затрагивает функцию getWindowsIEEE8021x в версиях пакета systeminformation 5.23.6 и более поздних. Суть уязвимости заключается в проверке данных из поля SSID Wi‑Fi, которые передаются напрямую в командную строку ОС Windows.

• Согласно данным из пояснения экспертов на GitHub, SSID передаётся через команды netsh wlan show interface и cmd.exe /d /s /c netsh wlan show profiles без надлежащей проверки строк. Атакующие могут создать специальные имена SSID (пример на фото), содержащие вредоносный код, чтобы получить полный контроль над системой жертвы.

• Атакующий может настроить точку доступа с SSID, включающий команды типа a" | ping /t 127.0.0.1 & или a" | %SystemDrive%\a\a.exe &. Если пользователь подключается к такой точке, то злоумышленник может выполнить произвольный код в системе жертвы.

• Для устранения уязвимости разработчик пакета systeminformation выпустил обновление 5.23.7, в котором реализована проверка и очистка входных данных SSID.

➡️ https://github.com/sebhildebrandt/systeminformation

#Новости #NPM

🖥 37 лет DNS, системе доменных имён.

• В 1987 году произошло много событий, так или иначе повлиявших на развитие информационных технологий: CompuServe разработала GIF-изображения, Стив Возняк покинул Apple, а IBM представила персональный компьютер PS/2 с улучшенной графикой и 3,5-дюймовым дисководом. В это же время незаметно обретала форму ещё одна важная часть интернет-инфраструктуры, которая помогла создать Интернет таким, каким мы знаем его сегодня. В конце 1987 года в качестве интернет-стандартов был установлен набор протоколов системы доменных имен (DNS). Это было событием которое не только открыло Интернет для отдельных лиц и компаний во всем мире, но и предопределило возможности коммуникации, торговли и доступа к информации на поколения вперёд.

• История этого конкретного протокола восходит к 1970-м годам. DNS следовал схеме, используемой многими другими сетевыми протоколами того времени, в том смысле, что он был открытым (не зашифрованным). Он также не устанавливал подлинность того, с кем коннектился, и клиент просто верил в любые ответы, полученные в результате запроса. Как выяснилось, 37 лет назад протокол DNS был доверчив до наивности, и любой решительный злоумышленник мог вторгнуться в трафик запросов DNS. Но тогда DNS был всего лишь небольшим экспериментом.

• До 1987 года Интернет в основном использовался военными, государственными учреждениями и представителями научных кругов. В то время Сетевой информационный центр, управляемый SRI International, вручную поддерживал каталог хостов и сетей. Хоть ранний Интернет и был революционным и дальновидным, не у всех был к нему доступ.

• В тот же период сеть Агентства перспективных исследовательских проектов США, предтеча Интернета, который мы сейчас знаем, превратилась в быстрорастущую среду, в связи с чем предлагались новые схемы именования и адресации. Увидев тысячи заинтересованных учреждений и компаний, желавших изучить возможности сетевых вычислений, группа исследователей ARPANET поняла, что им необходим более современный автоматизированный подход к организации системы именования сети для ожидаемого быстрого роста.

• Два пронумерованных информационных документа RFC 1034 и RFC 1035, были опубликованы в 1987 году неофициальной сетевой рабочей группой, которая вскоре после этого превратилась в Инженерный совет Интернета (IETF). Эти RFC, автором которых являлся специалист по информатике Пол В. Мокапетрис, стали стандартами, на основе которых была построена реализация DNS. Именно Мокапетрис, занесённый в 2012 году в Зал славы Интернета, конкретно предложил пространство имён, в котором администрирование базы данных было чётко распределено, но могло также и развиваться по мере необходимости.

• Помимо предоставления организациям возможности вести свои собственные базы данных, DNS упростила процесс соединения имени, которое могли запомнить пользователи, с уникальным набором чисел — IP-адресом, — который необходим веб-браузерам для перехода на веб-сайт с использованием доменного имени. Благодаря тому, что не нужно было запоминать, казалось бы, случайную последовательность чисел, пользователи могли легко перейти на нужный сайт, и всё больше людей по всему миру могли получить доступ к сети.

• Благодаря совместной работе этих двух аспектов — широкого распространения и сопоставления имен и адресов — DNS быстро приобрела свою конечную форму и превратилась в ту систему, которую мы знаем сегодня.

#Разное