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

标签:#cyber

找到 392 篇相关文章

AI 资讯

Sign the message, not the tunnel: Introducing N-AALP for AI agents

Agent security today is inherited from the connection. N-AALP makes the message itself carry identity, authorization, approval and audit, verifiable offline, on any transport. Your agent just deleted a production table. The audit log says the request was approved. Now prove it. Not "show me the log line" - prove it, to someone who does not trust your log, your gateway, or your database. Which key approved it? Were those the exact arguments that were approved, or did something rewrite them after approval? Was that approval already used once? If your answer to any of those starts with "well, our gateway checks that," then the proof lives in your infrastructure, not in the message. Replay the message somewhere else and the proof is gone. This is the gap I have been working on. It has a name worth stating plainly: agent security today is inherited from the connection. TLS tells you the tunnel was private. mTLS tells you which service opened it. A bearer token tells you someone had a credential. None of that survives the message being written to a queue, forwarded by a relay, logged, replayed, or handed to a second agent. The moment a message leaves the connection it arrived on, it is just bytes with no provable origin. N-AALP is my attempt to close that. It is an application-layer object protocol where the message, not the connection, is the unit of security and governance. Full disclosure before you read further: I wrote it. I am the sole editor and maintainer, it is draft-bubblefish-naalp-00, an Independent Submission, and it claims no IETF working-group consensus. I would rather you read the spec and tell me where I am wrong than take my word for anything below. There is a section at the end listing what it does not do. The one-object idea Every N-AALP message is one signed object. Not a request type, not an envelope-plus-payload, not a header format with a body convention. One structure, one signature, one identity model, one authorization model, one audit model, an

2026-07-31 原文 →
开发者

Security Notes for Serving Static Files with StayPresent

What to know about python static file security when using StayPresent's web.html/markdown — directory exposure, path traversal, and URL filtering. Security Notes for Serving Static Files with StayPresent Serving a status dashboard or a rendered README with web.html() / web.markdown() is convenient precisely because it automatically picks up neighboring CSS, JS, and images with no extra configuration. That same convenience has a security dimension worth understanding clearly before you point it at a directory. This covers python static file security as it applies specifically to StayPresent: what's protected automatically, and what's still your responsibility to manage. Table of Contents The Directory-Wide Exposure Behavior Why This Is Intentional Path Traversal Protection The One-Time Directory Warning Markdown-Specific Protections: Escaping Markdown-Specific Protections: URL Scheme Filtering What's Rejected vs What's Allowed Structuring Directories Safely Full Example Best Practices Common Mistakes FAQs Conclusion The Directory-Wide Exposure Behavior When you call web.html("templates/index.html") or web.markdown("docs/guide.md") , StayPresent doesn't just serve that one file — it serves every file in that file's directory , not only the specific CSS/JS/image files actually referenced from the page. This is what makes relative asset links ( href="style.css" , src="images/logo.png" ) work automatically without any extra configuration on your part. The consequence: if a .env file, your bot's own source code, or a .git/ directory happens to sit in that same directory, it becomes downloadable by anyone who requests it by name — whether or not anything on the page actually links to it. templates/ ├── index.html ├── style.css <- intentionally public, referenced from index.html ├── .env <- NOT referenced anywhere, but still reachable Why This Is Intentional This isn't an oversight — it's what makes web.html() / web.markdown() usable with zero configuration for the overwhel

2026-07-30 原文 →
AI 资讯

Measuring the Tendency of AI Agents to Go Rogue

This essay was written with Barath Raghavan, and originally appeared in The Guardian . In July, Hugging Face, a company that hosts much of the world’s AI software and open-source AI models, was hacked. A malicious dataset had been used to run code on one of its servers. Whoever was behind it captured internal security credentials and moved through systems over a weekend, running thousands of actions from a swarm of temporary server environments. It looked like the work of a sophisticated criminal group. It was not. It was one of OpenAI’s new, still unreleased GPT models...

2026-07-30 原文 →
AI 资讯

AI ตรวจจับมัลแวร์เก่งกว่ามนุษย์จริงหรือ? ไขความจริงเบื้องหลังตัวเลขความแม่นยำ

ทุกวันนี้มัลแวร์รูปแบบใหม่ถูกสร้างขึ้นนับพันนับหมื่นชิ้นในแต่ละวัน ปริมาณภัยคุกคามที่เพิ่มขึ้นอย่างรวดเร็วนี้ทำให้การพึ่งพานักวิเคราะห์ความปลอดภัยไซเบอร์ที่เป็นมนุษย์เพียงอย่างเดียวแทบเป็นไปไม่ได้ นี่คือเหตุผลสำคัญที่บริษัทด้านความปลอดภัยไซเบอร์ทั่วโลกหันมาพึ่งพาปัญญาประดิษฐ์และแมชชีนเลิร์นนิงเป็นแนวหน้าในการรับมือกับมัลแวร์ หลายบริษัทโฆษณาว่าโซลูชันของตนตรวจจับมัลแวร์ได้แม่นยำถึง 99% หรือมากกว่านั้น ตัวเลขเหล่านี้ฟังดูน่าประทับใจอย่างยิ่ง แต่คำถามที่ควรถามต่อคือ ตัวเลขเหล่านี้สะท้อนความเป็นจริงมากน้อยเพียงใด และ AI เก่งกว่ามนุษย์จริงหรือไม่ในสมรภูมิการต่อสู้กับมัลแวร์ บทความนี้จะพาไปไขความจริงเบื้องหลังตัวเลขเหล่านั้นอย่างละเอียด กลไกเบื้องหลังการตรวจจับมัลแวร์ด้วย AI ก่อนจะตอบคำถามว่า AI เก่งกว่ามนุษย์หรือไม่ จำเป็นต้องเข้าใจก่อนว่าระบบ AI ตรวจจับมัลแวร์ทำงานอย่างไร โดยทั่วไปมีสองแนวทางหลักที่ใช้กันในอุตสาหกรรมความปลอดภัยไซเบอร์ แนวทางแรกคือการตรวจจับด้วยลายเซ็นดิจิทัล (Signature-Based Detection) ซึ่งเป็นวิธีดั้งเดิมที่ใช้กันมานานหลายทศวรรษ ระบบจะเปรียบเทียบไฟล์ต้องสงสัยกับฐานข้อมูลลายเซ็นของมัลแวร์ที่เคยพบมาก่อน วิธีนี้แม่นยำสูงสำหรับมัลแวร์ที่รู้จักแล้ว แต่ไม่มีประสิทธิภาพเมื่อเจอมัลแวร์ตัวใหม่ที่ไม่เคยถูกบันทึกไว้ในฐานข้อมูล แนวทางที่สองคือการตรวจจับผ่านพฤติกรรมด้วยแมชชีนเลิร์นนิง (Behavior-Based Detection) ซึ่งเป็นจุดแข็งหลักของ AI ยุคใหม่ ระบบจะถูกฝึกฝนด้วยตัวอย่างมัลแวร์และไฟล์ปกตินับล้านไฟล์ เพื่อเรียนรู้รูปแบบพฤติกรรมที่บ่งชี้ความเป็นอันตราย เช่น ความพยายามเข้าถึงไฟล์ระบบโดยไม่ได้รับอนุญาต การเชื่อมต่อไปยังเซิร์ฟเวอร์ต้องสงสัย หรือการเข้ารหัสไฟล์จำนวนมากในเวลาอันสั้นซึ่งเป็นสัญญาณคลาสสิกของแรนซัมแวร์ จุดเด่นของวิธีนี้คือความสามารถในการตรวจจับมัลแวร์ตัวใหม่ที่ไม่เคยพบมาก่อน หรือที่เรียกว่า Zero-Day Malware เพราะไม่ได้พึ่งพาการจดจำลายเซ็นเดิม แต่อาศัยการวิเคราะห์พฤติกรรมและรูปแบบที่ใกล้เคียงกับสิ่งที่เคยเรียนรู้มาแล้ว ตัวเลขความแม่นยำที่โฆษณากันนั้นบอกอะไรจริง ๆ เมื่อบริษัทความปลอดภัยไซเบอร์อ้างว่าผลิตภัณฑ์ของตนมีความแม่นยำ 99% หรือสูงกว่านั้น ผู้บริโภคควรตระหนักว่าตัวเลขเหล่านี้มักมาจากการทดสอบภายใต้สภาพแวดล้อมที่ควบคุมไว้อย่างเข้มงวด ซึ่งอาจไม่สะท้อนสถานกา

2026-07-29 原文 →
AI 资讯

Measuring LLMs’ Ability to Perform Cryptanalysis

There’s new benchmark measuring AI’s ability to perform mathematical cryptanalysis. Anthropic’s frontier model actually found new attacks. The benchmark: “ CryptanalysisBench: Can LLMs do Cryptanalysis? ” The idea is to benchmark the ability of LLMs to discover new mathematical cryptanalytic attacks against a series of historical algorithms. Abstract: Cryptanalysis—the task of finding attacks against cryptographic schemes—its at the intersection of mathematical reasoning and cybersecurity, two areas where LLMs have advanced fastest. Cryptanalysis represents both a clean testbed for frontier reasoning (as practical attacks can be automatically verified) and a domain with unusually high stakes, since the primitives under study underpin our digital security. In this paper we ask whether LLMs can do cryptanalysis, and find that the answer is increasingly yes. We introduce CryptanalysisBench, 191 tasks across six families of cryptographic primitives (block ciphers, hash functions, etc.) drawn primarily from four NIST standardization competitions. Our benchmark consists of three tiers: (i) primitives with known practical breaks; (ii) primitives with no known practical break, evaluated both at full strength and as scaled-down variants; and (iii) a challenge set of production primitives at the frontier of cryptanalysis. Five frontier models (Claude Opus 4.8, Sonnet 5, Mythos 5, GPT-5.5, and the open-weights GLM-5.2) break 65%­86% of Tier 1 schemes, 6­12 Tier-2 schemes at full strength, and 24­61 across all scaled-down variants. Beyond deriving known results, models produce novel cryptanalysis, such as a key-recovery attack that exploits a design flaw in the SpoC AEAD and an error in KINDI’s published CCA-security proof, both to the best of our knowledge not previously known...

2026-07-29 原文 →
AI 资讯

I Built a Security Tool That Proves Its Own Exploits — Then Got a Better Threat Model in the Comments

Automated offense has one embarrassing failure mode: it lies to you about winning. Point a tool at a target, and the naive success check is a substring match — see uid=0(root) in the response, call it a shell. But a service banner can print that. A tarpit can stream it on connect. And the moment your success signal is wrong, everything downstream inherits the lie: the report, the "which hosts are owned" state, the next move. You get a confident engine that's confidently wrong. Here's how I made mine prove it instead — what worked in a live run today, and the sharp reader feedback that already made the design better. The idea: make the target echo a secret it couldn't have guessed Borrow the oldest trick in authentication. Before each attempt, the orchestrator mints an unpredictable per-attempt nonce and injects it. The delivered command has to send that nonce back: import os def make_nonce() -> str: return os.urandom(12).hex() # unpredictable — a target can't guess it A result is only trusted if that exact nonce comes back, in a structured evidence line: HALO-EVIDENCE nonce=c609007176813c9110fccc27 level=shell uid=0 host= exit=0 _EVIDENCE = re.compile(r"HALO-EVIDENCE nonce=(\S+) level=(\S+)") def breach_confirmed(output, ok, *, nonce) -> bool: m = _EVIDENCE.search(output or "") return bool(ok and m and m.group(1) == nonce) Delivery is a ladder, because real hosts are inconsistent Proof is worthless if you can't deliver a payload. So delivery degrades gracefully — all stdlib socket: Reverse shell — target dials back to an ephemeral listener, announces the nonce, hands back /bin/sh. Bind shell — if egress is blocked, the target binds a shell and you connect in. Blind callback — if no interactive channel survives, the target just connects back and sends the nonce. That still proves code execution, with no usable shell. Each rung self-selects the first available interpreter (bash /dev/tcp, python3, perl, nc), so the same primitive works against arbitrary hosts, not one

2026-07-29 原文 →
AI 资讯

How to Start Bug Bounty Hunting in 2026: The Complete Beginner's Guide

Everything you need to know to find your first vulnerability, get paid, and build a real reputation in cybersecurity — without breaking any laws. If you've typed "how to start bug bounty hunting" into Google recently, you're not alone. It's one of the fastest-growing searches in cybersecurity right now, and for good reason: it's one of the only paths in tech where a total beginner with no degree can find a real flaw, report it, and get paid the same week. This guide answers the questions people are actually searching in 2026 — what bug bounty hunting is, which bugs pay the most right now, how AI has changed the game, and how to land your first bounty. What Is Bug Bounty Hunting, Exactly? Companies invite independent researchers to test their websites, apps, and APIs for security flaws — legally. When you find a real vulnerability, you write a report explaining what it is, how to reproduce it, and what damage it could cause. If the company confirms it, they pay you based on severity. It's not hacking in the movie sense. It's structured, permitted testing within a defined scope — the specific domains, apps, or features the company has authorized you to test. Step outside that scope, and you've crossed from "bug bounty hunter" into "unauthorized access," which is a crime in nearly every country. The Best Platforms to Start On in 2026 Three platforms dominate the space: HackerOne — the largest and most beginner-friendly, with the widest range of programs Bugcrowd — strong onboarding and clear scope documentation Immunefi — the go-to platform if you're interested in web3 and smart contract security, which currently pays some of the highest bounties in the industry Start with Vulnerability Disclosure Programs (VDPs) — these often don't pay, but they let you build a track record, earn private invites, and practice on real targets without competing against thousands of other hunters for a bounty. What Bugs Are Actually Paying Right Now The vulnerability landscape has shifte

2026-07-28 原文 →
AI 资讯

How I Built Triage: Turning SigNoz into a Blue Team SOC (And the Deployment Nightmares I Survived)

Most people use OpenTelemetry and SigNoz to watch their CPU usage, find memory leaks, or figure out why their API is taking 400ms instead of 200ms. But for the Agents of SigNoz Hackathon (Track 3: Observe Anything Weird), I wanted to do something completely different. I didn't want to watch hardware. I wanted to watch hackers. That is how Triage was born. It is an OpenTelemetry-powered Blue Team SOC (Security Operations Center) that tracks active cyber attacks instead of just generic application performance. The Original Vision vs. The Reality Building this sounded straightforward on paper: catch bad traffic, wrap it in an OpenTelemetry span, send it to SigNoz, and show it on a custom dashboard. But actually deploying this beast before the deadline was a completely different story. If you have ever tried to deploy a full-stack Next.js app, a Python honeypot, and an OTel pipeline while the clock is ticking, you know exactly what kind of panic I am talking about. Here is what actually happened behind the scenes. 1. The Azure VM & Docker Crash I started by spinning up an Azure virtual machine to self-host the SigNoz backend. I pulled the repo, ran docker compose up -d, and immediately watched my server completely freeze. Turns out, my free tier Azure instance (Standard_B2ats_v2) only had 1 GiB of RAM. You simply cannot run a massive ClickHouse database and a full OTel collector on 1GB of memory without it crashing instantly. I had to pivot fast and rely on the cloud endpoints. 2. The Vercel vs Localhost Trap Once I got the backend running, I hit my next wall. My Vercel Next.js dashboard kept throwing 500 Internal Server Error on the threat simulation API, and the SigNoz connection kept reading OFFLINE (fetch failed). I was staring at my logs losing my mind until it clicked. My Vercel environment variables had SIGNOZ_API_URL set to http://localhost:8080 and my Python script was looking for OTel on localhost:4318. Note to self (and everyone else): Vercel is a cloud serve

2026-07-26 原文 →
开发者

Samba File Sharing on Linux: Setting Up Shares With and Without Authentication

If you've got a Linux box and a Windows machine on the same network, you shouldn't need a USB stick to move files between them. That's the whole reason Samba exists: it makes a Linux server show up as an ordinary network drive to Windows — and to other Linux machines too — so anyone on the network can open, save, and edit files without ever touching a terminal on the other end. I set this up on a Debian server as part of a networking course, and tested it two different ways: once completely open, no login required, and once locked down behind real user accounts and group permissions. This article walks through both, roughly in the order I actually did them, along with the errors that came up and what actually fixed them. By the end you'll have a working guest share, a working authenticated share, and you'll know how to reach either one from a second Linux machine acting as the client. What You'll Need 2 Debian or Ubuntu machines (a VM works fine) with root access A Windows machine on the same network, to test from the client side Enough terminal comfort to edit a file with nano or vi and run a few commands as root What Samba Actually Does Windows shares files over a protocol called SMB/CIFS. Linux doesn't speak that natively, so Samba sits on top of it and translates: it makes a Linux folder look exactly like a normal Windows network share, and lets a Windows folder be mounted from Linux too. Two background processes do the actual work: smbd handles file transfers, permissions, and logins. nmbd handles name resolution — the reason you can type \myserver instead of memorizing an IP address every time. Everything is controlled from a single file, /etc/samba/smb.conf. It's split into sections — global settings, authentication, printing, and so on — but almost everything in this guide happens in the last one, Share Definitions, where each shared folder gets its own block. The exhaustive parameter list lives in Samba's own documentation. ** Installing Samba** Update your

2026-07-25 原文 →