标签

 security 

相关的文章:

了解Web3安全研究的最新进展,以及数据库安全的最佳实践。

The Verge

The Verge -

Microsoft left internal passwords exposed in latest security blunder

Cath Virginia / The Verge | Photo from Getty Images Microsoft reportedly locked down a server last month that exposed passwords, keys, and credentials of Microsoft employees to the open internet, as the company faces mounting pressure to bolster its software security. According to Techcrunch, three security researchers at SOCRadar — a company specializing in detecting corporate cybersecurity weaknesses — discovered that an Azure-hosted server storing sensitive data linked to Microsoft’s Bing search engine was left open with no password protection, meaning it could be accessed by anyone online. The server contained a variety of security credentials used by Microsoft employees to access internal systems, housed within various scripts, code, and configuration files. The exposed credentials... Continue reading…

上个月,微软的一个服务器在公网上暴露了微软员工的敏感凭证,可能导致更严重的数据泄露和服务危险。托管在Azure上的服务器存储了与Bing搜索引擎相关的数据,没有密码保护,任何人都可以访问。黑客有可能利用这些暴露的数据访问微软存储内部数据的其他区域。

相关推荐 去reddit讨论
Rust Blog

Rust Blog -

Security advisory for the standard library (CVE-2024-24576)

The Rust Security Response WG was notified that the Rust standard library did not properly escape arguments when invoking batch files (with the bat and cmd extensions) on Windows using the Command API. An attacker able to control the arguments passed to the spawned process could execute arbitrary shell commands by bypassing the escaping. The severity of this vulnerability is critical if you are invoking batch files on Windows with untrusted arguments. No other platform or use is affected. This vulnerability is identified by CVE-2024-24576. Overview The Command::arg and Command::args APIs state in their documentation that the arguments will be passed to the spawned process as-is, regardless of the content of the arguments, and will not be evaluated by a shell. This means it should be safe to pass untrusted input as an argument. On Windows, the implementation of this is more complex than other platforms, because the Windows API only provides a single string containing all the arguments to the spawned process, and it's up to the spawned process to split them. Most programs use the standard C run-time argv, which in practice results in a mostly consistent way arguments are splitted. One exception though is cmd.exe (used among other things to execute batch files), which has its own argument splitting logic. That forces the standard library to implement custom escaping for arguments passed to batch files. Unfortunately it was reported that our escaping logic was not thorough enough, and it was possible to pass malicious arguments that would result in arbitrary shell execution. Mitigations Due to the complexity of cmd.exe, we didn't identify a solution that would correctly escape arguments in all cases. To maintain our API guarantees, we improved the robustness of the escaping code, and changed the Command API to return an InvalidInput error when it cannot safely escape an argument. This error will be emitted when spawning the process. The fix will be included in Rust 1.77.2, to be released later today. If you implement the escaping yourself or only handle trusted inputs, on Windows you can also use the CommandExt::raw_arg method to bypass the standard library's escaping logic. Affected Versions All Rust versions before 1.77.2 on Windows are affected, if your code or one of your dependencies executes batch files with untrusted arguments. Other platforms or other uses on Windows are not affected. Acknowledgments We want to thank RyotaK for responsibly disclosing this to us according to the Rust security policy, and Simon Sawicki (Grub4K) for identifying some of the escaping rules we adopted in our fix. We also want to thank the members of the Rust project who helped us disclose the vulnerability: Chris Denton for developing the fix; Mara Bos for reviewing the fix; Pietro Albini for writing this advisory; Pietro Albini, Manish Goregaokar and Josh Stone for coordinating this disclosure; Amanieu d'Antras for advising during the disclosure.

Rust标准库在Windows上使用Command API调用批处理文件时存在漏洞,攻击者可以通过绕过转义来执行任意命令。修复将在Rust 1.77.2中发布。

相关推荐 去reddit讨论
GitLab

GitLab -

Integrate external security scanners into your DevSecOps workflow

Each day you build software there is another opportunity for security vulnerabilities to creep into production. So it is becoming more important than ever to shift security left and put security tests and the vulnerabilities they detect at the forefront of your software development lifecycle. While GitLab offers a wide range of different security scanners, our AI-powered DevSecOps platform provides full visibility into the security of your software. We seek to allow you to not only run scans, but also to view results, bake in approval processes via merge request policies, and display current vulnerabilities in your default branch for future triage in our Vulnerability Report. How do security scans run? GitLab Ultimate displays your vulnerabilities directly in the merge request widget and it updates on every commit. These scans typically run via jobs in a pipeline, whether in the project’s .gitlab-ci.yml pipeline or in a separately-controlled compliance pipeline, security policy, or included pipeline configuration from a separate .yml file. You can run GitLab’s native security scanners or you can run an external scanner. For this blog post, I took running Snyk scans for a spin to see how I could feed the dependency scan results as vulnerability records back into GitLab. Additionally, I utilized the Static Analysis Results Interchange Format (SARIF) converter to read SAST results directly from Snyk without custom scripting. Using external scanners GitLab is highly extensible, and the platform allows for you to integrate myriad tools. You can use one of our built-in security scanners, or use an external scanner via a job in a pipeline or policy. GitLab serves as a single platform for governance and enforcement, allowing you to bring your own scanners and see the results early in the DevSecOps lifecycle. All you have to do to get started is run a security job, and from there you can obtain the results in the merge request and the vulnerability report. Run an external scan from GitLab CI In this example pipeline, I run a Snyk scan externally in the test stage in a job I overrode called gemnasium-maven-dependency_scanning. First, I install the required packages (npm, Maven, Python3, and Snyk) and then I authorize with my SNYK_TOKEN variable saved in the variables section of my project. Finally, I run a snyk test command with the Snyk CLI and output the results to the JSON. This saves my results to the snyk_data_file.json, which I will parse in a script detailed in the next section and save to the required artifact file gl-dependency-scanning-report.json. stages: - test variables: include: - template: Jobs/Dependency-Scanning.gitlab-ci.yml gemnasium-maven-dependency_scanning: image: node:latest stage: test services: - openjdk:11-jre-slim-buster before_script: - apt-get update - apt-get install default-jdk -y script: # Install npm, snyk, and maven - npm install -g npm@latest - npm install -g snyk - npm install maven - npm install python3 # Run snyk auth, snyk monitor, snyk test to break build and out report - snyk auth $SNYK_TOKEN - chmod +x mvnw - snyk test --all-projects --json-file-output=snyk_data_file.json || true - python3 convert-snyk-to-gitlab.py # Save report to artifacts artifacts: when: always paths: - gl-dependency-scanning-report.json Parse the JSON You can see scan results in the merge request widget from any external scanner as long as the artifact of the successful security job is named appropriately, for example, gl-dependency-scanning-report.json. Here is an example script that converts the Snyk JSON output to the GitLab JSON output. In this example, I open the Snyk data file and load the vulnerability data. I create a new list of dependency files and a new list of vulnerabilities that contain data GitLab needs to display in the vulnerability records, such as the identifier, severity, category, description, and location. I added a few placeholder sections for required fields that I did not need to display in my record. Finally, I saved the contents I parsed out to a new JSON file called gl-dependency-scanning-report.json, which is the required name for the file to be read by GitLab and have its contents displayed in the widget. import json from types import SimpleNamespace with open("snyk_data_file.json") as snyk_data_file: snyk_data = json.load(snyk_data_file, object_hook=lambda d: SimpleNamespace(**d)) gitlab_vulns = [] dependency_files = [] for i in snyk_data: dependency_files.append({"path": i.path, "package_manager": i.packageManager, "dependencies": []}) for v in i.vulnerabilities: gitlab_identifiers = [] for vuln_type, vuln_names in v.identifiers.__dict__.items(): if vuln_names: for vuln_name in vuln_names: gitlab_identifiers.append({"type": vuln_type, "name": vuln_name, "value": vuln_name.partition("-")[2]}) gitlab_vulns.append({"id": v.id, "category": "dependency_scanning", "severity": v.severity.capitalize(), "identifiers": gitlab_identifiers, "description": v.description, "location": {"file": i.displayTargetFile, "dependency": {"package": {"name": "PLACEHOLDER"}, "version": "PLACEHOLDER"}}}) # Dummy data for scan and dependency files full_json = {"version": "15.0.6", "dependency_files": dependency_files, "scan": {"analyzer": {"id": "snyk", "name": "Snyk", "vendor": {"name": "Snyk"}, "version": "1.0.2"}, "scanner": {"id": "my-snyk-scanner", "name": "My Snyk Scanner", "version": "1.0.2", "vendor": {"name": "Snyk"}}, "end_time": "2022-01-28T03:26:02", "start_time": "2020-01-28T03:26:02", "status": "success", "type": "dependency_scanning"}, "vulnerabilities": gitlab_vulns} with open("gl-dependency-scanning-report.json", "w") as gitlab_file: json.dump(full_json, gitlab_file, default=vars) Now, the vulnerability findings are visible in the merge request widget. What are SARIF and the SARIF converter? SARIF is a file format for the output of static analysis tools. It is incredibly useful when leveraging different security scanners, as all of their output is formatted the same way. This allows for a generic, repeatable, and scalable approach to application security. GitLab has a SARIF converter, which takes SARIF files and converts them into ingestible reports. It supports many scanners, including Snyk. Our converter works for both SAST and code quality findings. We are going to focus on SAST for this blog. Use a SARIF converter to get SAST results To leverage the SARIF results, first I trigger a Snyk scan as we did in the previous example, but I save the output to a SARIF file. After this, I use the converter to create a new JSON file that I save as a report. snyk: image: node:latest stage: test services: - openjdk:11-jre-slim-buster before_script: - apt-get update - apt-get install default-jdk -y - wget -O sarif-converter https://gitlab.com/ignis-build/sarif-converter/-/releases/permalink/latest/downloads/bin/sarif-converter-linux - chmod +x sarif-converter script: Install npm, snyk, and maven - npm install -g npm@latest - npm install -g snyk - npm install maven # Run snyk auth, snyk monitor, snyk test to break build and out report - snyk auth $SNYK_TOKEN - chmod +x mvnw - snyk test --all-projects --sarif-file-output=snyk.sarif || true - ./sarif-converter --type sast snyk_sam.sarif snyk.json artifacts: reports: sast: snyk.json After saving the JSON as an artifact, the results are visible in the merge request widget. Get started In this blog post, you learned how to use both custom scripting and the SARIF converter to view external scanner vulnerabilities in the GitLab merge request widget. These operations can be completed from the pipeline as shown, but also from compliance pipelines and pipeline execution policies, which allow for the enforcement of external scanners. With GitLab Ultimate. you have access to a full DevSecOps platform that allows you to use our scanners or bring your own, but build a shift-left workflow that empowers developers to remediate vulnerabilities before they hit production. Trial GitLab Ultimate today to begin merging external scanners. More security scanning resources Security scanner integration documentation How to integrate custom security scanners into GitLab GitLab Trust Center

GitLab's AI-powered DevSecOps platform offers security scanners and full visibility into software security. It allows running scans, viewing results, and displaying vulnerabilities. External scanners can be integrated, and scan results can be viewed in the merge request widget. A script can convert Snyk scan results to GitLab JSON output. SARIF converter converts SARIF files to ingestible reports. The SARIF results can be used to view SAST findings. GitLab Ultimate provides a full DevSecOps platform for merging external scanners and shifting security left.

相关推荐 去reddit讨论
GitLab

GitLab -

Building GitLab with GitLab: Expanding our security certification portfolio

We recently expanded our compliance certification portfolio to include the automotive industry's TISAX and to support the issuance of the first GitLab Dedicated SOC 2 Type 2. GitLab's Security Compliance team is a proponent of dogfooding our platform, including our integrated project management and security features, so we accomplished this expansion using the GitLab DevSecOps Platform. In this blog, we'll share the details of how we successfully leveraged GitLab's native features to implement security controls, enabling us to scale our compliance efforts and deliver results faster. You'll also learn how you can put these features to work in your own organization. Start using GitLab for compliance today with a free trial. Agile planning Our security certifications structure is built upon GitLab's Agile planning features, allowing us to deliver results faster by managing requirements centrally and streamlining our workflows. Using Agile planning features also enables end-to-end visibility throughout compliance audits. Epics, issues, and labels. We leverage a parent epic to outline all the external certifications that are ongoing, and child epics for each individual certification. Each child epic contains issues for each work stream related to the certification, as well as evidence requests from the external auditor. Parent and child epics allow for project management and visibility across the organization on the audit cycle's current status. Recurring issues. Every audit has standard request items and tasks that need to be performed. Therefore, to increase efficiency, we have a variety of recurring issues that are automatically created for each audit cycle that populate the task and/or request details, assignee, and due date. Recurring issues can be configured in a CI pipeline. Labels and issue boards. Labels and issue boards are used to plan, organize, and visualize workflows. The Security Compliance team leverages issue boards to not only track status, but also to track and group identified deficiencies relating to our compliance requirements. Issue boards allow for visibility of all issues related to a given program by their risk classification and current remediation status. These Agile planning features ensure that compliance teams are able to leverage the same platform as their engineers, promoting transparency and efficient delivery of results. Security Each of GitLab’s security certifications has security and compliance requirements that must be operating effectively to achieve certification. GitLab offers native features within the platform that enable security and the achievement of industry-standard requirements. We leveraged these key security features for our certifications and you can, too: Merge request approval settings. These settings can be configured to limit merge request approvals, enforce segregation of duties responsibilities, and force password authentication. For our certifications, merge request approval settings were inspected for relevant projects to support the following requirements: AICPA Trust Service Critieria (TSC) CC8.1 ISO 27001:2022 5.3, 8.32 TISAX 5.2.1 Protected branch settings. These configuration settings allow administrators to set branch protections and limit what users can do based on their configured permissions. For our certifications, protected branches were inspected for relevant projects to support the following requirements: AICPA TSC CC8.1 ISO 27001:2022 8.32 TISAX 5.2.1, 5.2.2 Code owners. This feature specifies the users or groups responsible for specific files and directories in a repository. The CODEOWNERS file can be enabled to identify owners of a file or directory and require owners to approve changes. Code owners can be implemented in conjunction with your approval rules. For our certifications, CODEOWNERS files were inspected for relevant projects to support the following requirements: AICPA TSC CC8.1 ISO 27001:2022 8.32 TISAX 5.2.1 Static application security testing (SAST)/dynamic application security testing (DAST). A part of using GitLab CI/CD, SAST and DAST are available to check your source code for known vulnerabilities. For our certifications, We leveraged SAST/DAST to support the following requirements: AICPA TSC CC3.2, CC7.1, CC9.2 ISO 27001:2022 8.28, 8.29 TISAX 5.2.5 Audit events. This feature is used to track important events, including who performed what action and when. Audit events can be used to support the following requirements: AICPA TSC CC8.1 ISO 27001:2022 8.15, 8.16 TISAX 5.2.4 Get started today GitLab makes compliance easier than ever. Agile planning enables end-to-end visibility throughout the audit. and security is integrated into the design of the product, leading to faster, more comprehensive achievement of compliance requirements. Here at GitLab we are always pursuing the expansion of our security certification portfolio to give our customers and community additional assurance as well as additional transparency into our information security practices. Have a certification you’d like to see us work towards? Have questions about how your organization can set up your GitLab instance to utilize our compliance features? Drop us a line by emailing customer-assurance@gitlab.com, we’d love to hear from you! More Building GitLab with GitLab Building GitLab with GitLab: How GitLab.com inspired Dedicated Building GitLab with GitLab: Web API Fuzz Testing Building GitLab with GitLab: Why there is no MLOps without DevSecOps Building GitLab with GitLab: Stress-testing Product Analytics

GitLab扩展了其合规认证组合,包括TISAX和SOC 2 Type 2。他们利用自己平台的功能实施安全控制和简化工作流程。敏捷计划、重复问题、标签和问题板用于项目管理和可见性。GitLab的安全功能,如合并请求批准设置、受保护分支设置、代码所有者、SAST/DAST和审计事件,被用于认证。GitLab旨在使合规更容易,并提供对其信息安全实践的透明度。

相关推荐 去reddit讨论
The GitHub Blog

The GitHub Blog -

Security research without ever leaving GitHub: From code scanning to CVE via Codespaces and private vulnerability reporting

This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces. The post Security research without ever leaving GitHub: From code scanning to CVE via Codespaces and private vulnerability reporting appeared first on The GitHub Blog.

GitHub Security Lab利用GitHub产品和功能进行安全研究,使用代码扫描、CodeQL、Codespaces和私有漏洞报告等工具发现、验证和披露开源软件中的漏洞。他们还介绍了代码搜索功能和OpenSSF的关键性评分,以及Code scanning、CodeQL和GitHub Codespaces的使用。GitHub作为安全研究的重要资源,提供一站式解决方案来识别和解决潜在的安全威胁。

相关推荐 去reddit讨论
Planet PostgreSQL

Planet PostgreSQL -

Craig Kerstiens: Row Level Security for Tenants in Postgres

Row-level security (RLS) in Postgres is a feature that allows you to control which rows a user is allowed to access in a particular table. It enables you to define security policies at the row level based on certain conditions, such as user roles or specific attributes in the data. Most commonly this is used to limit access based on the database user connecting, but it can also be handy to ensure data safety for multi-tenant applications. Creating tables with row level security We're going to assume our tenants in this case are part of an organization, and we have an events table with events that always correspond to an organization: CREATE TABLE organization ( org_id UUID DEFAULT uuid_generate_v4() PRIMARY KEY, name VARCHAR(255) UNIQUE, created_at TIMESTAMPTZ default now(), deleted_at TIMESTAMPTZ default now(), ); CREATE TABLE events ( org_id UUID, event_type TEXT, event_value INT, occurred_at TIMESTAMPTZ default now(), ); We're going to turn on RLS on our events table. ALTER TABLE events ENABLE ROW LEVEL SECURITY; And then set a policy that is enforced based on the connected database user. CREATE POLICY event_isolation_policy ON events USING (org_id::TEXT = current_user); Now if you had a org id of c4062d63-335e-4631-b03c-504d0eb88122 and created a database user with that login, when they connected to the database and queried the events table they'd only receive their events. Using Session Variables The above works great when you're giving out raw database access. But creating a new database user and connecting with that unique user for each new request that comes in is a lot of overhead and takes away many of the tools that exist for managing and scaling Postgres connections. Instead of a user per customer, what we're going to do is set a session variable when we connect. CREATE POLICY event_session_user ON events TO application USING (org_id = NULLIF(current_setting('rls.org_id', TRUE), '')::uuid); Now when you connect in your sessi[...]

Postgres的行级安全(RLS)功能允许您控制用户在特定表中可以访问的行。它可以根据用户角色或数据中的特定属性定义行级安全策略。使用Postgres的RLS功能可以增强应用程序的安全性。

相关推荐 去reddit讨论
The GitHub Blog

The GitHub Blog -

Bringing enterprise-level security and even more power to GitHub-hosted runners

GitHub-hosted runners now support Azure private networking. Plus, we've added 2 vCPU Linux, 4 vCPU Windows, macOS L, macOS XL, and GPU hosted runners to our runner fleet. The post Bringing enterprise-level security and even more power to GitHub-hosted runners appeared first on The GitHub Blog.

GitHub推出Azure私有网络功能,增强GitHub Actions的企业级准备性,满足企业客户的网络和安全需求。托管运行器最大化编码时间,减少管理和维护计算基础设施的时间和成本。新增macOS和GPU运行器,简化GitHub Actions的采用,成为自动化和CI/CD平台的标准选择。

相关推荐 去reddit讨论
The Verge

The Verge -

Will the Apple antitrust case affect your phone’s security?

Image: Cath Virginia / The Verge Of all the allegations that the Department of Justice has laid at Apple’s door, the most contentious is perhaps its salvo over security and privacy. Apple has warned that if the DOJ gets its way, Apple products — especially the iPhone — will be less secure for users. Meanwhile, the DOJ claims that Apple’s much-touted privacy features are pretextual. The complaint in the DOJ’s antitrust lawsuit against Apple says that the company “wraps itself in a cloak of privacy, security, and consumer preferences to justify its anti-competitive behavior.” In the press conference announcing the lawsuit, Assistant Attorney General Jonathan Kanter said Apple’s choices have actually made its system “less private and less secure.” “Apple selectively... Continue reading…

苹果公司与美国司法部就安全和隐私问题存在争议。苹果警告称,司法部得逞将使苹果产品更不安全,而司法部声称苹果的隐私功能是虚假的。苹果的品牌战略强调隐私设计,而司法部对其品牌核心原则的攻击是非常激进的。诉状强调,与iMessage不同,iPhone用户与Android用户的短信通信缺乏加密。苹果的App Store比安卓手机上的应用商店更安全。

相关推荐 去reddit讨论
FreeBuf网络安全行业门户

FreeBuf网络安全行业门户 -

相关推荐 去reddit讨论
Fernweh

Fernweh -

Research Advancement of Web3 Security

Introduction Web3 security has been a popular research field of information security in recent years. In this report, we collect, categorize, and briefly summarize 16 Web3-security-related papers from ACM CCS, NDSS, IEEE S&P, and USENIX Security conferences in 2023 and 2024, to identify common patterns and trends in this field. Note that I omit theoretical studies, which are out of my research scope. The papers are categorized into four topics: vulnerability detection, novel attack & defense, optimization and privacy issues as shown in the following table. These topics provide a systemic view of Web3 security. Topic Research Vulnerability Detection Crush [1], VetEOS [3], SmartInv [4],Nyx [5], FuzzDelSol [6], Phoenix [8],ESCORT [10], LOKI [11], BlockScope [12],Panda [16] Novel Attacks & Defenses Ma et al. [2], TxPhishScope [7], Sting [14],Ape [15] Optimization POSE [9] Privacy Issues Torres et al. [13] Topic 1: Vulnerability Detection 10 out of 16 collected studies aim to detect bugs or vulnerabilities in Web3 ecosystem. VetEOS [3] is a static analysis tool for the Groundhog Day vulnerabilities in EOSIO contracts. In a Groundhog Day attack, attackers leverage the rollback issue in EOSIO contracts to persistently execute identical contract code with varying inputs. By using the information exposed in prior executions, attackers can accumulate insights about the target contract and figure out a reliable method to generate unauthorized profits. The authors formally define this vulnerability as a control and data dependency problem. The insight is that the vulnerability lies in intrinsic data and control dependencies among key contract constructs, such as user inputs, global states, database tables, API return values and inlined action calls. VetEOS performs context-sensitive flow-sensitive interprocedural dataflow analysis on EOSIO WebAssembly bytecode. Ultimately, VetEOS detected 735 new vulnerabilities in the wild. Crush [1] is an analysis system to detect and investigate a type of cross-contract vulnerability known as a storage collision at scale, which is resulted from the different understandings of the types/semantics of two contracts’ shared storage. Storage collision vulnerabilities may cause unexpected behavior such as denial of service (frozen funds), privilege escalation, and theft of financial assets. The approach is divided into three stages: component discovery, collision discovery, and vulnerability discovery, leveraging program analysis techniques. Crush performs a large-scale analysis of 14,237,696 smart contracts deployed on the Ethereum blockchain, identifies 14,891 potentially vulnerable contracts, and automatically synthesizes an end-to-end exploit for 956 of them. SmartInv [4] is an accurate and fast smart contract invariant inference framework, which is used to detect machine un-auditable bugs. Such bugs cannot be reliably detected using existing automated tools that rely on pre-defined bug patterns. The insight is that the expected behavior of smart contracts, as specified by invariants, relies on understanding and reasoning across multimodal information, such as source code and natural language. The authors propose a new finetuning and prompting strategy to foundation models, Tier of Thought (ToT), to reason across multiple modalities of smart contracts and to generate invariants. FuzzDelSol [6] is the first binary-only coverage-guided fuzzing architecture for Solana smart contracts. The authors extract low-level program and state information to develop a diverse set of bug oracles covering all major bug classes in Solana. LOKI [11] is a blockchain consensus protocol fuzzing framework, which detects consensus memory-related and logic bugs. LOKI fetches consensus states in realtime by masquerading as a node. First, LOKI dynamically builds a state model that records the state transition of each node. After that, LOKI adaptively generates the input targets, types, and contents according to the state model. With a bug analyzer, LOKI detects the consensus protocol implementation bugs with well-defined oracles. Nyx [5] is a static analyzer for detection of exploitable front-running vulnerabilities in smart contracts, which features a Datalog-based preprocessing procedure that efficiently and soundly prunes a large part of the search space, followed by a symbolic validation engine that precisely locates vulnerabilities with an SMT solver. Phoenix [8] is a system for detecting and locating resilience issues in blockchain systems by context-sensitive chaos. The authors firstly identify two typical types of resilience issues in blockchain systems: node unrecoverable and data unrecoverable. Then, they design three context-sensitive chaos strategies tailored to the blockchain feature. They also create a coordinator to effectively trigger resilience issues by scheduling these strategies. ESCORT [10] is a deep learning-based vulnerability detection method that uses a common feature extractor to learn generic bytecode semantics of smart contracts and separate branches to learn the features of each vulnerability type. As a multi-label classifier, ESCORT can detect multiple vulnerabilities of the contract at once. ESCORT is also the first deep learning-based framework utilizing transfer learning on new vunerability types with minimal model modification and retraining overhead. Panda [16] is the first extensible static analysis (symbolic execution and constraint solving) framework that automatically nine types of generic vulnerabilities in Algorand smart contracts. The authors also construct the first benchmark dataset to evaluate Panda. BlockScope [12] is a patch-based code clone detection tool that can detect multiple types of cloned vulnerabilities given an input of existing Bitcoin/Ethereum security patches, leveraging similarity-based code match and proposing a new way of calculating code similarity to cover all the syntax-wide variant clones. To make BlockScope language-agnostic, there is no program analysis-alike preprocessing. Topic 2: Novel Attacks & Defenses In this section, we select four studies introducing novel attacks or defense mechanisms in Web3 security. Ape [15] is a generalized imitation attack methodology. Imitation attack is one type of front-running attacks, where the attackers only copy-paste and front-run a pending profitable transaction without understanding its logic. Leveraging dynaic program analysis techniques (dynamic taint analysis, program synthesis, and advanced instrumentations), Ape supports the automatic synthesis of adversarial smart contracts. Besides attack, blockchain imitation can also act as an intrusion prevention system by mimicking an attack, appropriating the vulnerable funds, and returning them to its victim. Ma et al. [2] presents the first comprehensive security analysis of smart contract verification services in the wild. By diving into the detailed workflow of existing verifiers, the authors summarized the key security properties that should be met, and observed eight types of vulnerabilities that can break the verification. Sting [14] is a novel runtime defense mechanism against smart contract exploits. The key idea is to instantly synthesize counterattack smart contracts from attacking transactions and leverage the power of Maximal Extractable Value (MEV) to front run attackers. TxPhishScope [7] is the largest TxPhish (transaction-based phishing scam) website detection system, which detects TxPhish websites and extracts phishing accounts automatically by dynamically visiting the suspicious websites, triggering transactions, and simulating results. Topic 3: Optimization POSE [9] is a practical off-chain protocol for smart contracts that addresses shortcomings of existing off-chain solutions, such as costly blockchain interactions, lack of data privacy, huge capital costs from locked collateral, and supporting only a restricted set of applications. POSE leverages a pool of Trusted Execution Environments (TEEs) to execute the computation efficiently and to swiftly recover from accidental or malicious failures. Topic 4: Privacy Issues Torres et al. [13] analyzes the privacy implications that Web3 technologies have on users. The authors build a framework that measures exposure of wallet information. The evaluation results show that 1,325 from the top 100K websites run scripts to probe whether users have wallets installed in their browser, and there are more than 2000 leaks across 211 applications and over 300 leaks across 13 wallets, which leak the user’s unique wallet address to third-parties. The approach is tracking, intercepting and analyzing the network traffic. References NDSS'24 [Crush] Ruaro, Nicola, et al. “Not your Type! Detecting Storage Collision Vulnerabilities in Ethereum Smart Contracts.” Ma, Pengxiang, et al. “Abusing the Ethereum Smart Contract Verification Services for Fun and Profit.” arXiv preprint arXiv:2307.00549 (2023). [vetEOS] Li, Levi Taiji, et al. “VETEOS: Statically Vetting EOSIO Contracts for the “Groundhog Day” Vulnerabilities.” SP'24 [SmartInv] Wang, Sally Junsong, Kexin Pei, and Junfeng Yang. “SMARTINV: Multimodal Learning for Smart Contract Invariant Inference.” 2024 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2024. [Nyx] Zhang, Wuqi, et al. “Nyx: Detecting Exploitable Front-Running Vulnerabilities in Smart Contracts.” 2024 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 2024. CCS'23 [FuzzDelSol] Smolka, Sven, et al. “Fuzz on the Beach: Fuzzing Solana Smart Contracts.” Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 2023. [TxPhishScope] He, Bowen, et al. “TxPhishScope: Towards Detecting and Understanding Transaction-based Phishing on Ethereum.” Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 2023. [Phoenix] Ma, Fuchen, et al. “Phoenix: Detect and locate resilience issues in blockchain via context-sensitive chaos.” Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 2023. NDSS'23 [POSE] Frassetto, Tommaso, et al. “POSE: Practical off-chain smart contract execution.” arXiv preprint arXiv:2210.07110 (2022). [ESCORT] Sendner, Christoph, et al. “Smarter Contracts: Detecting Vulnerabilities in Smart Contracts with Deep Transfer Learning.” NDSS. 2023. [LOKI] Ma, Fuchen, et al. “LOKI: State-Aware Fuzzing Framework for the Implementation of Blockchain Consensus Protocols.” NDSS. 2023. [BlockScope] Yi, Xiao, et al. “BlockScope: Detecting and Investigating Propagated Vulnerabilities in Forked Blockchain Projects.” arXiv preprint arXiv:2208.00205 (2022). Security'23 Torres, Christof Ferreira, Fiona Willi, and Shweta Shinde. “Is your wallet snitching on you? an analysis on the privacy implications of web3.” 32nd USENIX Security Symposium (USENIX Security 23). 2023. [Sting] Zhang, Zhuo, et al. “Your exploit is mine: Instantly synthesizing counterattack smart contract.” 32nd USENIX Security Symposium (USENIX Security 23). 2023. [Ape] Qin, Kaihua, et al. “The blockchain imitation game.” 32nd USENIX Security Symposium (USENIX Security 23). 2023. [Panda] Sun, Zhiyuan, Xiapu Luo, and Yinqian Zhang. “Panda: Security analysis of algorand smart contracts.” 32nd USENIX Security Symposium (USENIX Security 23). 2023.

这份报告总结了近年来研究热点的Web3安全领域的16篇论文,涵盖了漏洞检测、新型攻击与防御、优化和隐私问题等主题。这些论文讨论了智能合约漏洞检测的各种工具和技术,分析验证服务的安全性质,防御攻击,优化离链协议,以及分析隐私影响。

相关推荐 去reddit讨论

热榜 Top10

Dify.AI
Dify.AI
LigaAI
LigaAI
eolink
eolink
观测云
观测云

推荐或自荐