Коли Apple випустила macOS 26 Tahoe 15 вересня 2025 року, користувачі очікували на чергову еволюцію улюбленої операційної системи. Проте вже через три тижні після релізу стає зрозуміло: цей запуск виявився одним із найпроблемніших за останні роки.

Проблеми з встановленням та оновленням

Перші проблеми почалися ще на етапі встановлення. Власники Mac Studio з процесором M3 Ultra зіткнулися з критичним багом, який повністю блокує можливість оновлення до Tahoe. За даними MacRumors, інсталятор завантажує драйвер для Apple Neural Engine, але потім перевірка обладнання провалюється і процес установки аварійно завершується.

Інші користувачі скаржаться на проблеми з нестачею вільного місця та зависання під час підготовки оновлення. Деякі додатки, такі як Adobe та OBS Studio, взагалі відмовляються запускатися після апгрейду системи.

Нестабільна робота додатків

Сумісність програмного забезпечення стала справжнім головним болем. На форумах Apple Community користувачі повідомляють про випадкові збої та дивну поведінку програм. Firefox раптово втрачає збережені автозаповнення, Linear Mouse відмовляється запускатися навіть при ручному запуску, а деякі вікна браузерів стають повністю недоступними.

Додаток Preview несподівано вилітає при використанні, а нова заміна Launchpad — додаток Apps — не показує всі встановлені програми. Spotlight тепер часто повертає лише результати веб-пошуку, ігноруючи локальні файли.

Liquid Glass: краса чи каламутність?

Новий дизайн Liquid Glass, який Apple позиціонує як революційний, викликав неоднозначну реакцію. Прозорі панелі та ефекти заломлення світла виглядають вражаюче на маркетингових матеріалах, але в реальному використанні створюють проблеми з читабельністю та навігацією.

На форумі Apple Community один користувач зазначає численні проблеми з дизайном та інтерфейсом, включно з некоректним відображенням елементів та складністю орієнтації в оновленому середовищі.

Прощавай, FireWire та інші технології

Apple офіційно поховала підтримку FireWire у Tahoe, що стало неприємною несподіванкою для користувачів професійного обладнання. Хоча технологія застаріла, багато студій звукозапису та відеомонтажу все ще покладаються на пристрої з цим інтерфейсом.

Підтримка AFS теж йде в минуле — хоч і не відразу, а в наступній версії, але попередження вже прозвучало.

Time Machine та проблеми з резервним копіюванням

Користувачі повідомляють про серйозні проблеми з Time Machine. Зовнішні диски для резервного копіювання, які ідеально працювали в macOS Sequoia, тепер не відображаються у Finder після оновлення до Tahoe. При цьому diskutil підтверджує, що диски присутні та не пошкоджені.

Батарея та продуктивність

Як і після багатьох великих оновлень, користувачі скаржаться на погіршення часу автономної роботи та тимчасові просідання продуктивності. Поки незрозуміло, чи це стандартна поведінка після індексування системи, чи справжні баги macOS Tahoe.

Чому експерти радять зачекати

Технічний блог OSXDaily прямо заявляє про рішення відкласти оновлення до виходу перших патчів. Автор зазначає, що хоча деякі скарги можуть бути типовими для будь-якого великого оновлення, кількість та серйозність проблем у Tahoe перевищує звичайний рівень.

На форумі MacRumors користувачі називають це “найбагатішим на баги оновленням macOS за весь час”, порівнюючи з легендарно проблемними Mac OS 8 та OS X Lion.

Що робить Apple?

Apple випустила перше оновлення, яке виправило критичний баг з Mac Studio M3 Ultra, але більшість фундаментальних проблем залишаються невирішеними. Компанія продовжує збирати звіти про помилки через офіційні канали та форуми.

Рекомендації

Якщо ваш Mac зараз працює стабільно на попередній версії системи — краще зачекайте з оновленням до виходу macOS Tahoe 26.1 або навіть 26.2. Для тих, хто вже встановив систему і зіткнувся з проблемами, існує можливість відкату до попередньої версії через Time Machine.

macOS Tahoe нагадує, що навіть Apple не застрахована від поспішних релізів. Амбітний редизайн та нові функції виявилися недостатньо протестованими, а користувачі змушені виконувати роль бета-тестерів. Залишається сподіватися, що наступні оновлення виправлять ситуацію та Tahoe стане такою системою, якою мала бути з самого початку.

Ця стаття macOS Tahoe: що з нею не так? раніше була опублікована на сайті CyberCalm, її автор — Побокін Максим

Програмне забезпечення керує критичною інфраструктурою — від банківських систем до ядерних об’єктів, отже питання безпеки коду стає надважливим. Кожен рік кіберзлочинці завдають мільярдних збитків, експлуатуючи вразливості, які часто виникають через прості помилки програмування.

Ця стаття розглядає найбільш критичні помилки, які роблять розробники, створюючи потенційні “чорні ходи” для хакерів. Розуміння цих помилок — перший крок до написання безпечного коду.

1. SQL-ін’єкції: коли база даних стає зброєю проти вас

SQL-ін’єкція залишається однією з найпоширеніших та найнебезпечніших вразливостей. Вона виникає, коли програма формує SQL-запити, безпосередньо підставляючи в них дані від користувача без належної перевірки.

Як це працює

Уявіть просту форму входу, де програма перевіряє логін та пароль таким чином:

SELECT * FROM users WHERE username = '$username' AND password = '$password'

Якщо зловмисник введе як ім’я користувача рядок admin' --, запит перетвориться на:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

Символи -- в SQL означають початок коментаря, тому перевірка пароля просто ігнорується. Атакуючий отримує доступ до облікового запису адміністратора без знання пароля.

Наслідки

SQL-ін’єкції можуть призвести до:

• Крадіжки всієї бази даних
• Видалення критичних даних
• Модифікації записів (наприклад, зміни балансів рахунків)
• Отримання повного контролю над сервером бази даних

Як запобігти

Головне правило — ніколи не довіряйте даним від користувача. Використовуйте параметризовані запити або підготовлені вирази (prepared statements), які розділяють SQL-код від даних:

# Правильно
cursor.execute("SELECT * FROM users WHERE username = ? AND password = ?", (username, password))

# Неправильно
cursor.execute(f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'")

2. Переповнення буфера: коли пам’ять виходить з-під контролю

Переповнення буфера — це класична вразливість, особливо характерна для мов програмування низького рівня, таких як C та C++. Вона виникає, коли програма записує дані за межі виділеного буфера пам’яті.

Механізм експлуатації

Коли програма виділяє буфер фіксованого розміру, але не перевіряє розмір даних, що записуються:

char buffer[10];
strcpy(buffer, user_input); // Небезпечно!

Якщо user_input містить більше 10 символів, зайві дані перезапишуть сусідні ділянки пам’яті. Це може включати адреси повернення функцій, що дозволяє атакуючому перенаправити виконання програми на свій код.

Чому це критично

Переповнення буфера може дозволити:

• Виконання довільного коду з правами програми
• Обхід механізмів аутентифікації
• Крах програми (DoS-атака)
• Ескалацію привілеїв до рівня системного адміністратора

Методи захисту

Використовуйте безпечні функції, які враховують розмір буфера:

// Замість strcpy використовуйте strncpy
strncpy(buffer, user_input, sizeof(buffer) - 1);
buffer[sizeof(buffer) - 1] = '\0';

// Або ще краще - безпечні функції з перевіркою меж
strlcpy(buffer, user_input, sizeof(buffer));

Також важливо використовувати сучасні механізми захисту на рівні компілятора та операційної системи: DEP (Data Execution Prevention), ASLR (Address Space Layout Randomization), та canary values.

3. Cross-Site Scripting (XSS): коли браузер стає ворогом

XSS-атаки дозволяють зловмисникам впроваджувати JavaScript-код на веб-сторінки, які переглядають інші користувачі. Це одна з найпоширеніших вразливостей веб-додатків.

Види XSS

Reflected XSS: зловмисний скрипт передається через URL або форму і одразу виконується:

<!-- Вразливий код -->
<p>Результати пошуку для: <?php echo $_GET['search']; ?></p>

<!-- Атака через URL -->
site.com/search?q=<script>steal_cookies()</script>

Stored XSS: зловмисний код зберігається на сервері (наприклад, у коментарях) і виконується кожного разу, коли хтось переглядає сторінку.

DOM-based XSS: атака відбувається повністю на стороні клієнта через маніпуляції з DOM.

Потенційна шкода

XSS може призвести до:

• Крадіжки сесійних cookies та викрадення облікових записів
• Фішингових атак від імені довіреного сайту
• Встановлення кейлогерів для крадіжки паролів
• Поширення хробаків через соціальні мережі

Захист від XSS

Основний принцип — екранування всіх даних перед виведенням:

// Функція для безпечного виведення тексту
function escapeHtml(text) {
    const map = {
        '&': '&',
        '<': '&lt;',
        '>': '&gt;',
        '"': '&quot;',
        "'": '&#039;'
    };
    return text.replace(/[&<>"']/g, m => map[m]);
}

// Використання
document.getElementById('output').textContent = userInput; // Безпечно
// АБО
document.getElementById('output').innerHTML = escapeHtml(userInput);

Також важливо використовувати Content Security Policy (CSP) заголовки для обмеження виконання скриптів.

4. Небезпечна десеріалізація: коли дані стають кодом

Десеріалізація — це процес перетворення даних (наприклад, JSON, XML, бінарних форматів) назад в об’єкти програми. Небезпечна десеріалізація виникає, коли програма десеріалізує дані з ненадійних джерел без належної перевірки.

Приклад атаки

У багатьох мовах програмування (Java, Python, PHP) десеріалізація може викликати виконання коду:

import pickle
# НІКОЛИ не робіть так з даними від користувача!
user_data = request.get_data()
obj = pickle.loads(user_data)  # Небезпечно!

Атакуючий може створити спеціально сформований об’єкт, який при десеріалізації виконає довільний код.

Масштаб проблеми

Небезпечна десеріалізація може дозволити:

• Віддалене виконання коду (RCE)
• Повний контроль над сервером
• Обхід логіки додатку
• DoS-атаки через створення ресурсомістких об’єктів

Рекомендації щодо захисту

Найкращий захист — уникати десеріалізації даних від користувачів. Якщо це неможливо:

# Використовуйте безпечні формати даних
import json
user_data = request.get_json()  # JSON безпечніший за pickle

# Валідуйте структуру даних
schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "age": {"type": "number"}
    }
}
validate(user_data, schema)

5. Облікові дані зашиті в код: відкриті двері для атакуючих

Зберігання паролів, API-ключів та інших секретів прямо в коді — це як залишити ключі під килимком. Це одна з найпростіших для виявлення, але досі дуже поширена помилка.

Чому це проблема

# НІКОЛИ не робіть так!
DATABASE_PASSWORD = "SuperSecret123"
API_KEY = "sk-1234567890abcdef"

def connect_to_database():
    return psycopg2.connect(
        host="db.example.com",
        password=DATABASE_PASSWORD
    )

Проблеми:

• Секрети потрапляють у систему контролю версій (Git)
• Будь-хто з доступом до коду отримує доступ до ресурсів
• Неможливо змінити паролі без зміни коду
• Складно використовувати різні облікові дані для різних середовищ

Наслідки витоку

Жорстко закодовані секрети можуть призвести до:

• Несанкціонованого доступу до баз даних
• Використання платних API за ваш рахунок
• Компрометації всієї інфраструктури
• Витоку конфіденційних даних клієнтів

Правильний підхід

Використовуйте змінні середовища або спеціалізовані сервіси управління секретами:

import os
from dotenv import load_dotenv

# Завантаження з файлу .env (не комітіть його!)
load_dotenv()

DATABASE_PASSWORD = os.environ.get('DATABASE_PASSWORD')
API_KEY = os.environ.get('API_KEY')

# Або використовуйте сервіси управління секретами
# AWS Secrets Manager, HashiCorp Vault, Azure Key Vault

6. Відсутність перевірки та валідації вхідних даних

“Ніколи не довіряйте даним від користувача” — це мантра безпечного програмування. Відсутність належної валідації вхідних даних є коренем багатьох вразливостей.

Типові помилки

// Поганий приклад
app.post('/transfer', (req, res) => {
    const amount = req.body.amount;
    const toAccount = req.body.toAccount;
    
    // Прямо використовуємо дані без перевірки
    transferMoney(amount, toAccount);
});

Проблеми:

• Що якщо amount = -1000? (негативний переказ = крадіжка)
• Що якщо amount = “not_a_number”?
• Що якщо toAccount не існує або має неправильний формат?

Комплексний підхід до валідації

// Правильний підхід
app.post('/transfer', (req, res) => {
    const amount = parseFloat(req.body.amount);
    const toAccount = req.body.toAccount;
    
    // Валідація типу та діапазону
    if (isNaN(amount) || amount <= 0 || amount > 10000) {
        return res.status(400).json({error: "Invalid amount"});
    }
    
    // Валідація формату
    if (!/^\d{10}$/.test(toAccount)) {
        return res.status(400).json({error: "Invalid account number"});
    }
    
    // Додаткова бізнес-логіка
    if (amount > getUserBalance(req.user)) {
        return res.status(400).json({error: "Insufficient funds"});
    }
    
    transferMoney(amount, toAccount);
});

Принципи безпечної валідації

Завжди перевіряйте:

• Тип даних (число, рядок, масив)
• Діапазон значень (мінімум, максимум)
• Формат (регулярні вирази для email, телефонів)
• Довжину рядків
• Наявність обов’язкових полів
• Бізнес-правила (чи має користувач право на цю операцію)

7. Небезпечне використання криптографії

Криптографія — це складно. Навіть досвідчені розробники часто роблять помилки, які повністю нівелюють захист.

Типові помилки

Використання слабких алгоритмів:

import hashlib
# НЕ використовуйте MD5 або SHA1 для паролів!
password_hash = hashlib.md5(password.encode()).hexdigest()

Власні криптографічні рішення:

# НІКОЛИ не придумуйте власну криптографію!
def my_encrypt(text):
    return ''.join(chr(ord(c) + 3) for c in text)  # Це НЕ шифрування!

Неправильне зберігання паролів:

# Погано - просте хешування
password_hash = hashlib.sha256(password.encode()).hexdigest()

# Добре - з сіллю та повільним алгоритмом
import bcrypt
password_hash = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

Наслідки поганої криптографії

• Паролі можуть бути зламані за лічені хвилини
• “Зашифровані” дані легко розшифровуються
• Підробка цифрових підписів
• Man-in-the-middle атаки

Правильний підхід

# Для паролів використовуйте bcrypt, scrypt або Argon2
import bcrypt

def hash_password(password):
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

def verify_password(password, hash):
    return bcrypt.checkpw(password.encode(), hash)

# Для шифрування використовуйте перевірені бібліотеки
from cryptography.fernet import Fernet

key = Fernet.generate_key()
cipher = Fernet(key)
encrypted = cipher.encrypt(data.encode())
decrypted = cipher.decrypt(encrypted).decode()

8. Проблеми з аутентифікацією та управлінням сесіями

Навіть якщо ви правильно перевіряєте паролі, помилки в управлінні сесіями можуть звести нанівець всі зусилля з безпеки.

Поширені вразливості

Передбачувані токени сесій:

# Погано - передбачуваний ID
session_id = str(user_id) + str(int(time.time()))

# Добре - криптографічно стійкий випадковий токен
import secrets
session_id = secrets.token_urlsafe(32)

Відсутність таймаутів:

# Сесії повинні мати обмежений термін дії
SESSION_TIMEOUT = 3600  # 1 година
if time.time() - session['created_at'] > SESSION_TIMEOUT:
    invalidate_session(session_id)

Незахищена передача:

• Використання HTTP замість HTTPS
• Відсутність флагів Secure та HttpOnly для cookies
• Передача токенів у URL

Комплексний захист сесій

# Правильне налаштування cookies
response.set_cookie(
    'session_id',
    session_token,
    secure=True,        # Тільки через HTTPS
    httponly=True,      # Недоступний для JavaScript
    samesite='Strict',  # Захист від CSRF
    max_age=3600        # Термін дії
)

# Регенерація ID сесії після входу
def login_user(username, password):
    if verify_credentials(username, password):
        # Створюємо нову сесію для запобігання session fixation
        old_session_data = get_session_data()
        invalidate_current_session()
        new_session_id = create_new_session()
        restore_session_data(new_session_id, old_session_data)

9. Race Conditions: коли час має значення

Race conditions виникають, коли результат виконання програми залежить від порядку або часу виконання операцій. У багатопоточних або розподілених системах це може призвести до серйозних проблем безпеки.

Класичний приклад

# Вразливий код для зняття грошей
def withdraw(amount):
    balance = get_balance()
    if balance >= amount:
        # Між перевіркою та оновленням може пройти час!
        time.sleep(0.1)  # Імітація затримки
        new_balance = balance - amount
        update_balance(new_balance)
        return True
    return False

Якщо два запити прийдуть одночасно, обидва можуть пройти перевірку до того, як баланс буде оновлений, дозволяючи зняти більше грошей, ніж є на рахунку.

Експлуатація в реальному світі

Race conditions можуть дозволити:

• Подвійне використання промокодів або купонів
• Перевищення лімітів (наприклад, кількості спроб входу)
• Обхід перевірок безпеки
• Дублювання транзакцій

Методи захисту

import threading

# Використання блокувань
balance_lock = threading.Lock()

def withdraw_safe(amount):
    with balance_lock:
        balance = get_balance()
        if balance >= amount:
            new_balance = balance - amount
            update_balance(new_balance)
            return True
    return False

# Або використання транзакцій бази даних
def withdraw_atomic(amount):
    with database.transaction():
        # База даних гарантує атомарність
        cursor.execute("""
            UPDATE accounts 
            SET balance = balance - %s 
            WHERE id = %s AND balance >= %s
        """, (amount, account_id, amount))
        return cursor.rowcount > 0

10. Недостатнє логування та моніторинг

Відсутність належного логування — це як керувати автомобілем із зав’язаними очима. Ви не знаєте, що відбувається, поки не станеться катастрофа.

Чому це критично

Без логування ви не можете:

• Виявити атаки в реальному часі
• Розслідувати інциденти
• Зрозуміти масштаб компрометації
• Довести факт атаки для правоохоронних органів

Що потрібно логувати

import logging
from datetime import datetime

# Налаштування логування
logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    handlers=[
        logging.FileHandler('security.log'),
        logging.StreamHandler()
    ]
)

security_logger = logging.getLogger('security')

# Логування спроб аутентифікації
def login(username, password, ip_address):
    if verify_credentials(username, password):
        security_logger.info(f"Successful login: user={username}, ip={ip_address}")
        return create_session(username)
    else:
        security_logger.warning(f"Failed login attempt: user={username}, ip={ip_address}")
        # Додаткова логіка для виявлення брутфорсу
        check_brute_force(username, ip_address)
        return None

# Логування критичних операцій
def delete_user_data(user_id, admin_id):
    security_logger.critical(
        f"Data deletion: target_user={user_id}, admin={admin_id}, "
        f"timestamp={datetime.utcnow().isoformat()}"
    )
    # Виконання операції

Що НЕ логувати

Ніколи не записуйте в логи:

• Паролі (навіть хешовані)
• Номери кредитних карток
• Персональні дані без необхідності
• Токени доступу та API-ключі

Моніторинг та алерти

# Автоматичне виявлення аномалій
def check_suspicious_activity(user_id):
    recent_actions = get_user_actions(user_id, last_hour=1)
    
    if len(recent_actions) > 100:
        alert_security_team(f"Unusual activity: {len(recent_actions)} actions in 1 hour")
    
    failed_logins = count_failed_logins(user_id, last_minutes=10)
    if failed_logins > 5:
        temporary_block_user(user_id)
        alert_security_team(f"Possible brute force attack on user {user_id}")

Висновки та рекомендації

Безпека програмного забезпечення — це не одноразова дія, а постійний процес. Кожна з розглянутих помилок може стати критичною вразливістю, але знання про них — це перший крок до створення безпечного коду.

Ключові принципи безпечного програмування:

1. Принцип найменших привілеїв: надавайте мінімально необхідні права доступу
2. Захист в глибину: використовуйте кілька рівнів захисту
3. Fail securely: у разі помилки система повинна залишатися в безпечному стані
4. Не довіряйте нікому: перевіряйте всі вхідні дані
5. Простота: складний код важче захистити

План дій для розробників:

1. Проведіть аудит існуючого коду на наявність описаних вразливостей
2. Впровадьте автоматизовані інструменти перевірки безпеки (SAST, DAST)
3. Організуйте регулярне навчання команди з питань безпеки
4. Включіть тестування безпеки в процес розробки (DevSecOps)
5. Створіть та дотримуйтесь coding standards з урахуванням безпеки

Пам’ятайте: безпека — це не витрата, а інвестиція. Вартість усунення вразливості зростає експоненційно з часом її існування. Краще запобігти проблемі на етапі написання коду, ніж виправляти наслідки злому.

Безпечний код — це не просто технічна вимога, це відповідальність перед користувачами, які довіряють нам свої дані та своє цифрове життя.

Ця стаття ТОП-10 найбільш небезпечних помилок програмування раніше була опублікована на сайті CyberCalm, її автор — Семенюк Валентин

Експерти відібрали 75 додатків з топ-100 найбільш завантажуваних в категоріях “спосіб життя” і “Соціальні мережі” для користувачів 17+.

Apple недавно зробила кроки для боротьби з наругою над дітьми та пошуку фотографій із зображенням дитячої порнографії на iPhone. Однак, як показало нове дослідження Tech Transparency Project (TTP), у самого магазину додатків Apple App Store є проблеми із забезпеченням безпеки дітей.

Експерти відібрали 75 додатків з топ-100 найбільш завантажуваних в категоріях “спосіб життя” і “Соціальні мережі” для користувачів 17+. Далі вони перевірили в кожному додатку можливість реєстрації малолітніх дітей через Apple ID і обліковий запис Facebook, а в разі, коли реєстрація дитини через Apple ID і Facebook була неможлива, – за допомогою електронної адреси та номера телефону. Потім дослідники вивчили ці додатки в пошуках інших загроз безпеці малолітніх користувачів. Для чистоти експерименту механізми батьківського контролю не були ввімкнені (в iPhone вони відключені за замовчуванням).

Як виявилося, в більшості випадків малолітні користувачі можуть без зусиль обійти обмеження за віком.

Особливе побоювання викликають:

Додатки для знайомств (зокрема, UberHoney), що відкривають порноматеріали до того, як запитати вік користувача;

Наповнені еротичними зображеннями чати “для дорослих” (Anonymous, Hippo – Random Live Video Chat), які ніколи не питають вік користувача;

Додатки online-казино, які дозволяли неповнолітнім реєструватися, робити депозити і виводити гроші.

37 вивчених додатків допускали реєстрацію дітей в віці 14 років і молодше за допомогою Apple ID, хоча Apple знала, що ідентифікатор був зареєстрований на неповнолітнього. Якщо додатки запитували вік користувача, неповнолітній міг просто ввести 18, і знову ж таки, Apple не перешкоджала цьому. Серед додатків були HOO – Adult Hook Up & Friend Finder, Hahanono – Chat&Get Naughty і Tinder.

Дослідники також відзначили, що в низці випадків Apple дозволяла показ реклами більше 17 додатків казино в тестовому обліковому записі неповнолітнього, в тому числі в грі “Тетріс”, яка не є додатком до вікових обмежень.

Радимо звернути увагу на поради, про які писав Cybercalm, а саме:

Чому три випадкових слова – це найкращий пароль? ІНСТРУКЦІЯ

Як не стати жертвою програм-вимагачів? ПОРАДИ

Навіщо інші антивіруси, якщо у Вас є Windows Defender? ПОРАДИ

Нагадаємо, ізраїльський виробник рішень для верифікації та забезпечення прозорості в мобільних та online-екосистемах GeoEdge повідомив про виявлення першої у світі кібератаки на домашні IoT-пристрої з використанням шкідливої реклами.

Також баг на офіційному сайті виробника автомобілів Ford Motor відкривав конфіденційні дані, доступ до яких міг отримати будь-який хакер. Серед інформації були бази даних клієнтів, відомості про співробітників тощо.

Окрім цього, американська трубопровідна компанія Colonial Pipeline виплатила 4,4 мільйона доларів хакерам, які викрали особисті дані майже 6 тисячам нинішніх та колишніх працівників компанії. Colonial Pipeline була вимушена сплатити викуп через ймовірність загрози газової кризи.

І майже анекдотична ситуація трапилася із розробником шкідливих програм, який розпочав їх тестування у своїй системі, щоб випробувати нові функції, а згодом дані потрапили на розвідувальну платформу хакерів. Мова йде про розробника Raccoon – трояна-викрадача інформації, який може збирати дані з десятків програм.

Ця стаття В App Store є купа додатків для дорослих, які дозволяють реєструватися в них дітям раніше була опублікована на сайті CyberCalm, її автор — Семенюк Валентин

Спеціаліст Trustwave SpiderLabs виявив спосіб, що дозволяє користувачам Telegram для Mac назавжди зберігати повідомлення, які повинні самі знищуватися і переглядати їх без відома відправника.

Для забезпечення більшої конфіденційності користувачів в месенджері Telegram передбачена можливість створювати свої власні приватні бесіди з додатковими функціями приватності. Коли користувач спілкується в закритому чаті з іншим користувачем, трафік між ними захищений за допомогою наскрізного шифрування, а всі повідомлення, вкладення і медіафайли стають такими, які повинні самі знищуватися і через деякий час видаляються з усіх пристроїв автоматично. Однак виявлена ​​експертом уразливість дозволяє зберігати ці повідомлення і вкладення.

Медіафайли та інші вкладення зберігаються в папці кеша, що знаходиться в директорії /Users/Admin/Library/Group Containers/  XXXXXXX.ru.keepcoder.Telegram/appstore  account-1271742300XXXXXX/postbox/media, де XXXXXX – унікальний номер облікової записи.

Telegram не завантажує вкладені в повідомлення файли (текстові документи text, doc, і pdf, аудіо- та відеофайли), поки абонент не спробує їх відкрити. Швидше за все, це пов’язано з великим розміром документів.

Коли одержувач читає повідомлення або переглядає вкладення, запускається таймер самознищення, і коли користувач перестає читати, контент автоматично видаляється. Проте, спеціаліст виявив, що файли не видаляються з папки кешу, і користувачі можуть зберегти їх звідти в будь-яке місце на жорсткому диску.

Дослідник в належному порядку повідомив Telegram про уразливість, і вона була виправлена ​​у версії Telegram для macOS 7.7 (215786) та пізніших. Однак є ще один баг, що дозволяє зберігати такі повідомлення.

Коли голосові і відеоповідомлення, зображення або геолокація автоматично завантажуються в кеш, користувач може просто скопіювати їх з папки кешу до того, як відкриє в самому Telegram. Крім того, одержувач може прочитати повідомлення в кеші, не відкриваючи в месенджері. В такому випадку відправник не буде знати, що користувач вже прочитав повідомлення.

Як повідомили представники Telegram, другу уразливість виправити неможливо, оскільки немає ніякої можливості захистити папку додатки від безпосереднього доступу. Однак дослідник не згоден з цим. На його думку, Telegram може виправити помилку, обробляючи всі медіа так само, як вкладення, і не завантажувати їх в локальну файлову систему, поки вони не будуть відкриті.

Радимо звернути увагу на поради, про які писав Cybercalm, а саме:

Як перевірити шкідливий чи безпечний сайт? – ПОРАДИ

Як змусити AirPods повідомляти про дзвінки та сповіщення на iPhone? – ІНСТРУКЦІЯ

Як перевірити, які програми на iPhone Ви використовуєте найчастіше? – ІНСТРУКЦІЯ

До речі, користувачі ніколи не зможуть встановити Windows 11 на несумісні пристрої. Групова політика не дозволить Вам обійти обмеження апаратного забезпечення для установки Windows 11.

Apple має намір додати підтримку системи розпізнавання осіб Face ID на комп’ютери Mac протягом наступних двох років. Про це повідомив оглядач Bloomberg.

Зловмисники все частіше використовують безкоштовний месенджер Discord як канал для поширення шкідливих програм.

Окрім цього, стало відомо про великий витік даних учасників Clubhouse. Провідний експерт з кібербезпеки Джіт Джайн повідомив, що повна база телефонних номерів Clubhouse виставлена ​​на продаж в Darknet.

Також стало відомо, що операційна система Windows 11, яка ще офіційно не вийшла, але вже доступна для скачування і попереднього знайомства, використовується зловмисниками, які намагаються підсунути користувачеві шкідливе ПЗ під виглядом нової ОС.

Ця стаття В Telegram для Mac є баг, що дозволяє назавжди зберігати повідомлення, які повинні самі знищуватися раніше була опублікована на сайті CyberCalm, її автор — Семенюк Валентин

Браузер вилітає випадковим чином, і користувач просто бачить робочий стіл. Іноді система надсилає повідомлення про аварійне завершення Google Chrome. Користувачам не вдається закрити браузер, не працюють деякі вкладки і розширення.

Закономірності виявленої помилки браузера постраждалі поки не виявили. Експерти прийшли до висновку, що проблема виникає на останній версії Chrome 90 для Windows 10 і у деяких користувачів Linux, при цьому нова версія браузера для macOS продовжує функціонувати коректно.

Google опублікувало рішення виявленої проблеми:

21 травня ми почали отримувати повідомлення про несподівані збої Chrome для деяких користувачів Windows і Linux. Провівши розслідування, ми визначили основну причину і випустили оновлення, що усуває проблему.

Щоб отримати оновлення для Chrome і усунути проблеми необхідно виконати всього три кроки:

• Закрити всі вікна Chrome.
• Перезапустіть Chrome і залиште його відкритим близько 5 хвилин, навіть якщо він не працює.
• Через 5 хвилин вийти і перезапустити Chrome.

Радимо звернути увагу на поради, про які писав Cybercalm, а саме:

Як завантажити дані Google Maps? ІНСТРУКЦІЯ

Психічне здоров’я у дітей від соцмереж і смартфонів не страждає – ДОСЛІДЖЕННЯ

Як створити надійний пароль? ПОРАДИ

Як вберегти свої банківські рахунки від кіберзлочинців? ПОРАДИ

До речі, пандемія спричинила нову хвилю цифрової трансформації у всьому світі. І державні установи не залишилися осторонь цього процесу. Завдяки розширенню цифрової інфраструктури, зокрема створенню нових додатків та сервісів, віддалених робочих місць та переходу в хмарне середовище, кількість потенційних векторів атак збільшилася.

Також повністю модульний ноутбук з ОС Windows від Framework тепер готовий до попереднього замовлення за базовою ціною у $999. Клієнти можуть розміщувати замовлення на веб-сайті Framework. 13,5-дюймовий ноутбук складається повністю з модульних деталей, включаючи материнську плату, яку ви можете легко поміняти та замінити.

Кілька редакцій Windows 10 версій 1803, 1809 та 1909 досягли кінця обслуговування (EOS), починаючи з травня , про що Microsoft нагадала нещодавно. Пристрої з випусками Windows 10, які досягли EoS, більше не отримуватимуть технічну підтримку, а також щомісячні виправлення помилок та безпеки, щоб захистити їх від останніх виявлених загроз безпеки.

Окрім цього, після вступу в силу нової політики Google в описі додатків з’явиться додатковий розділ з інформацією про те, до яких даними має доступ продукт. У розробників буде можливість розповісти користувачам про те, для чого додаткам потрібен доступ до тих або інших даних і як їх обробка впливає на загальну функціональність.

Ця стаття В Windows 10 виявлені серйозні проблеми з Google Chrome раніше була опублікована на сайті CyberCalm, її автор — Семенюк Валентин