今日已更新 166 条资讯 | 累计 20138 条内容
关于我们

标签:#cybersecurity

找到 166 篇相关文章

AI 资讯

BYOVD Explained — How Attackers Use Signed Drivers to Kill EDRs

Your EDR sees everything. Process launches, thread injections, DLL loads, filesystem writes. It has eyes inside the kernel — little hooks that fire before anything consequential happens, passing information up to the agent, letting it decide whether to block or alert. Now imagine something reaches into that kernel and quietly removes the hooks. No crash. No blue screen. No alert. The EDR process is still running, the dashboard still shows healthy, but the inputs it depends on are just gone. This is part of windows internals I've been exploring — understanding how systems actually behave under the hood, not just how tools interact with them. That's not a Windows bug. That's a trust problem. BYOVD doesn't exploit Windows — it exploits trust. Ring 0 vs Ring 3 — The Boundary That Matters Windows splits execution into privilege levels. Your applications, your malware, your EDR agent — they all run in Ring 3, user mode. The kernel runs in Ring 0. In my previous posts, I focused on how processes and execution work from an attacker's perspective. This goes one layer deeper — into the kernel where those assumptions start to break. This isn't just organizational. The CPU enforces it. Ring 3 code cannot directly read kernel memory. It cannot call kernel functions. Every interaction goes through a controlled interface — syscalls — and the kernel decides whether to honor each request. This is why typical malware stays loud. It has to use syscalls. Syscalls can be intercepted and monitored. At Ring 0, security tools are just data structures. Get code running in the kernel and those data structures become writable. The callback tables EDRs rely on, the hook registrations, the minifilter stack — all of it is reachable, readable, modifiable. A Quick Personal Note on Why This Boundary Matters Early on when I was messing around with kernel concepts, I tried doing something simple from user mode — reading a memory address that I knew belonged to a kernel structure. The kind of thing th

2026-06-09 原文 →
AI 资讯

The Paradox of Vibe Coding - In the Age of LLM-Written Code, Who Protects the LLM?

June 7, 2026. Dennis Kim, ex-CEO of Cyworld, CEO of BetaLabs https://github.com/gameworkerkim/vibe-investing https://github.com/gameworkerkim/CYBER-THREAT-INTELLIGENCE-REPORT Prologue: Two Incidents That Shook South Korea in 2026 In early June 2026, a data breach exposed the personal information of 5 million users of TVING, the largest OTT service in South Korea. The leaked data was extensive: IDs, names, birth dates, gender, CI (connection information), DI (duplicate registration verification information), mobile phone numbers, emails, refund account numbers, passwords, and more. The parent company, CJ ENM, saw its stock price plummet 3.44% in a single day, and investigations by the Personal Information Protection Commission and KISA were launched. But behind this incident hid another shocking fact. TVING's GitHub repository had an AWS access token hardcoded and publicly exposed. It was a stark reminder that a single cloud private key accidentally committed by a developer can jeopardize an entire company's infrastructure. These two events seem like different stories on the surface. Yet here I want to ask one common question: Who protects our generative AI, our LLM systems? Part 1. The Age of Vibe Coding: Security Takes a Backseat Recently, natural language-based programming using LLMs, the so-called "Vibe Coding" trend, has exploded. Generative AI coding assistants dramatically accelerate development speed. But behind this speed lies serious security risks. According to Veracode's 2025 GenAI Code Security report, 45% of code generated by LLMs contained security vulnerabilities. More concerning, developers place excessive trust in AI outputs and show behavior patterns prioritizing speed over vulnerability verification. Kaspersky's 2025 report revealed even more shocking findings. A vulnerability in the popular AI development tool Cursor (CVE-2025-54135) allowed attackers to execute arbitrary commands on a developer's machine, and a vulnerability in the Claude Code a

2026-06-07 原文 →
AI 资讯

AI Code Security: Claude's rsync Bugs; Europe's GNSS Interference & GPS Anomalies

AI Code Security: Claude's rsync Bugs; Europe's GNSS Interference & GPS Anomalies Today's Highlights This week in security, a deep dive explores how AI code generation might introduce new vulnerabilities, with analysis showing Claude increasing bugs in rsync. We also highlight two critical infrastructure concerns: a powerful GNSS interference source over Europe and the mysterious 'numbers station' broadcasts found on GPS frequencies. Did Claude increase bugs in rsync? (Hacker News) Source: https://alexispurslane.github.io/rsync-analysis/ This article presents an intriguing analysis of how large language models (LLMs) might inadvertently introduce bugs into software. Focusing on Claude's contributions to the widely used rsync utility, the author investigates code changes attributed to AI and compares them against human-written code. The study reveals instances where AI-generated code, while appearing plausible, introduced subtle yet significant defects, raising questions about the reliability of AI assistance in critical codebases. The implications extend beyond rsync , pointing to potential supply chain vulnerabilities if AI-generated code is not rigorously audited. This research highlights a new frontier for AI-specific security, emphasizing the need for developers to employ practical hardening guides and thorough review processes when integrating AI into their development workflows to prevent the unintentional introduction of new attack vectors. Comment: As a developer, seeing concrete examples of AI introducing bugs, even subtle ones, in a fundamental tool like rsync is a wake-up call. It's a reminder that AI-generated code requires diligent human review, especially when security or reliability is paramount, highlighting prompt engineering as a defensive technique. Tracing a powerful GNSS interference source over Europe (Hacker News) Source: https://arxiv.org/abs/2606.03673 Researchers have identified and traced a significant source of Global Navigation Satellite

2026-06-06 原文 →
AI 资讯

Applying Checkov to Terraform as Code – A TFSEC Alternative

Static Application Security Testing (SAST) is a critical practice in modern DevSecOps. While tools like SonarQube, Snyk, and Veracode are popular, this article focuses on GitHub CodeQL – a semantic code analysis engine that treats code as a database. We will apply it to a vulnerable Java Spring Boot application to detect SQL Injection and Path Traversal. 🤔 Why CodeQL? Unlike pattern-based scanners, CodeQL builds a relational database of your code, including abstract syntax trees, control flow graphs, and data flow graphs. This allows it to track tainted data across functions, classes, and files, drastically reducing false positives. 🚨 Target Application (Vulnerable Java App) Let's look at a simple REST API with two vulnerable endpoints. File: UserController.java package com.demo.controller ; import com.demo.model.User ; import org.springframework.beans.factory.annotation.Autowired ; import org.springframework.jdbc.core.JdbcTemplate ; import org.springframework.web.bind.annotation.* ; import java.nio.file.Files ; import java.nio.file.Paths ; import java.util.List ; @RestController @RequestMapping ( "/api" ) public class UserController { @Autowired private JdbcTemplate jdbcTemplate ; // Vulnerability 1: SQL Injection @GetMapping ( "/users" ) public List < User > getUsers ( @RequestParam ( "id" ) String userId ) { String sql = "SELECT * FROM users WHERE id = " + userId ; // Dangerous concatenation return jdbcTemplate . query ( sql , ( rs , rowNum ) -> new User ( rs . getString ( "id" ), rs . getString ( "name" ))); } // Vulnerability 2: Path Traversal @GetMapping ( "/file" ) public String readFile ( @RequestParam ( "filename" ) String filename ) throws Exception { return new String ( Files . readAllBytes ( Paths . get ( "/var/data/" + filename ))); } } 🛠️ Installing and Configuring CodeQL CLI You can run CodeQL locally to analyze your code before pushing it to a repository. 1. Download CodeQL from GitHub releases: wget [ https://github.com/github/codeql-cli-binaries/re

2026-06-06 原文 →
AI 资讯

The Website Was Working Fine. The CMS Wasn't: Understanding Drupalgeddon2

Imagine you're responsible for a company's website. Everything seems healthy. Pages load quickly. Users can log in. Content editors publish articles every day. Customers aren't reporting problems. From the outside, everything looks perfect. But then one day you discover something surprising: Attackers don't care whether your website looks healthy. They care whether the software behind it is vulnerable. That's exactly what happened with Drupalgeddon2. One of the most significant CMS vulnerabilities in recent years. And one that still teaches valuable lessons for developers, DevOps engineers, and security professionals today. The Building Manager Analogy Imagine a large office building. The company hires a building manager. The manager handles: Visitors Deliveries Maintenance Schedules Room Access The employees don't worry about these details. They trust the manager. A Content Management System (CMS) works similarly. Instead of manually managing every page and article, organizations rely on a CMS. Website ↓ CMS ↓ Content The CMS becomes the central control system. And that's why it becomes such an attractive target. What Is Drupal? Drupal is an open-source Content Management System. Organizations use it to manage: Corporate websites Government portals Universities Media platforms Enterprise applications A simplified architecture looks like: Visitor ↓ Drupal ↓ Database ↓ Content Every request passes through Drupal. Which means Drupal becomes part of the application's attack surface. Why Attackers Love CMS Platforms Suppose an attacker discovers a vulnerability in: Custom Internal Tool Maybe a few organizations are affected. Now suppose they discover a vulnerability in: Popular CMS Thousands of organizations may be affected. Potentially millions of users. One vulnerability. Many targets. That's why CMS platforms receive so much attention. Understanding Drupalgeddon2 Drupalgeddon2 refers to: CVE-2018-7600 A Remote Code Execution vulnerability affecting Drupal. The import

2026-06-05 原文 →
AI 资讯

Web Security: OWASP Top 10 and How to Fix Them (2026)

Web Security: OWASP Top 10 and How to Fix Them (2026) Security isn't a feature you add later — it's built into every layer. Here's how the top 10 vulnerabilities work and how to prevent them. #1 Broken Access Control // ❌ Vulnerable: User can access anyone's data app . get ( ' /api/users/:id ' , ( req , res ) => { const user = await db . users . findById ( req . params . id ); res . json ( user ); // No check if requester owns this data! }); // ✅ Secure: Always verify ownership app . get ( ' /api/users/:id ' , async ( req , res ) => { // Check: Is the logged-in user requesting their OWN data? if ( req . params . id !== req . user . id && req . user . role !== ' admin ' ) { return res . status ( 403 ). json ({ error : ' Access denied ' }); } const user = await db . users . findById ( req . params . id ); res . json ( user ); }); // ✅ Better: Use middleware for all protected routes const requireOwnership = ( resourceType ) => async ( req , res , next ) => { const resource = await db [ resourceType ]. findById ( req . params . id ); if ( ! resource ) return res . status ( 404 ). json ({ error : ' Not found ' }); if ( resource . userId !== req . user . id && req . user . role !== ' admin ' ) { return res . status ( 403 ). json ({ error : ' Access denied ' }); } req . resource = resource ; // Attach for route handler next (); }; app . get ( ' /api/posts/:id ' , auth , requireOwnership ( ' posts ' ), ( req , res ) => { res . json ( req . resource ); }); #2 Cryptographic Failures // ❌ Storing passwords in plain text or weak hashing const password = " password123 " ; db . users . insert ({ email , password }); // NEVER DO THIS! // ✅ Proper password hashing with bcrypt const bcrypt = require ( ' bcrypt ' ); const SALT_ROUNDS = 12 ; // Higher = slower = more secure (12 is good balance) async function hashPassword ( password ) { return bcrypt . hash ( password , SALT_ROUNDS ); } async function comparePassword ( password , hash ) { return bcrypt . compare ( password , hash ); /

2026-06-05 原文 →