Web2からWeb3へのマイグレーション / How to make a jump from Web2 hacking to Web3 hacking?

 

Web2ハッキングからWeb3ハッキングへのレベルアップをどうするか?  
{1} 何事もそうですが、高度なものに飛びつく前に、しっかりとした基礎が必要です。  

まずはイーサリアムの仕組みについて読んでおくことをおすすめします。 … これでイーサリアムの内部構造の概要がよくわかると思います。  
{2} すべてのEthereum DAppsはスマートコントラクト(SC)に依存しています。 その内容や書き方を知ることは、バグ発見への大きな一歩となる

SolidityはSCに最も人気のある言語であり、@ProgrammerSmartはこの言語を学ぶための素晴らしいリソースを作成しました。  
{3} 素晴らしいウェブサイトとは別に、彼は様々なSolidity/Security/DeFiのトピックに関するYouTubeビデオも作成しています。 チェックする価値はありますよ。 言語を学ぶだけでなく、アプリケーションの状況やDeFiとは何なのかを知ることも重要です。 
{4} DeFiアプリは、イーサリアムベースのアプリケーションの中で最も人気のあるものの1つです。 それらがどのようなもので、どのように機能するかを知ることは、バグを発見するのに役立ちます。 このトピックについて詳しく知るのに最適なリソースの1つが @finematics です。
こちらもご覧ください @officer_cia 
{5} アプリケーションの壊し方を見たり学んだりする最も楽しい方法の1つは、CTFをクリアすることです。 Web3は、この点についてもカバーしており、チェックする価値のあるCTFが複数用意されています。 1.
https://ethernaut.openzeppelin.com

2.
https://capturetheether.com

3.
Challenges to learn offensive security of DeFi smart contracts
その知識と練習ができたら、次のステップとして、様々なハック/バグに関する記事を読むことをお勧めします。 @adrianhetman 

{6}   また、評判の良い監査法人をチェックするのもよいでしょう。 @trailofbits / @ConsenSysAudits / @OpenZeppelin / @peckshield などなど
いつも面白いことを書いているし、監査報告書のほとんどを公開している。 このような監査報告書を読むことは、知識の宝庫である
{7} バグハンターはテスト用デバイスや環境を持つことが必須です。 基本を学ぶ価値があるのは @HardhatHQ と @BrownieEth です。  
これらがなければ、独自のPoCを書くことはできません。 Web3.js/Web3.pyパッケージを使いこなし、Ethereumのクエリやトランザクションを簡単に操作できるようにする。 
{8}
 あなたのワークフローを改善し、あなたを助けることができる興味深いセキュリティツールのいくつかを紹介します。 1. Solidity Visual Developer 2. Surya 3.
 http://ethtx.info

4.
GitHub - dapphub/dapptools: Dapp, Seth, Hevm, and more
5. seth
{9} スマートコントラクト監査人を目指すなら、
が、ちょうどそのことについて素晴らしいブログ記事を作成しました。 貴重な情報が得られるので、一読の価値ありです。
{11} このような知識と練習を積んだ上で、次のようなバグバウンティプラットフォームにバグを提出する準備が整いました。バグレポートの正しい書き方を知りたい方は、@immunefiがカバーしています。 .  
{12} ブロックハッキングの始め方を説明した素晴らしい記事がもう一つあります。ぜひ読んでみてください。 ブロックチェーンをハックする。究極のガイド
{13} このスレッドがお役に立ち、Web3セキュリティへの第一歩を踏み出すことができれば幸いです。

サイバーセキュリティの全体像 / Cybersecurity: The Big Picture


サイバーセキュリティ、あるいは情報セキュリティと呼ぶものは、広大な分野である。一人の人間がサイバーセキュリティ全体の専門家になることは不可能なほど広大です。サイバーセキュリティの専門家」になることは、「医学の専門家」になること以上に不可能なことなのです。

多くのプロフェッショナルは、特に特定の専門分野を持っている場合、サイバーセキュリティの様々な側面に目を奪われ、時には自分の専門分野の色眼鏡ですべてを見ることになりかねません。

その上、サイバーセキュリティの管理には、ユニークな側面もあります。サイバーセキュリティの管理は、いくつかの理由から他のタイプの管理とは異なります。

サイバーセキュリティの大きな側面と、なぜ違うのかを見てみましょう。

なぜサイバーセキュリティなのか?

サイバーセキュリティには、以下のような仕事があります。

  • サイバーセキュリティのインシデントを回避する

  • インシデントを回避するための、アイデンティティ管理や事業継続性管理

  • インシデントを回避するための、脆弱性管理、マルウェアからの保護、他の信頼できるシステムからしかシステムにアクセスできないようにするなどの技術的対策。

  • 個人情報保護法等の国内および海外の法令遵守対応。

  • PCI-DSSなどの業界コンプライアンス対応。

  • ISO27000、NISTなどの規格コンプライアンス対応と、それに代わる無数の要求事項

  • 社内コンプライアンス対応。

私たちはどこにいて、どこに向かっているのか。

ほとんどの組織は、サイバーセキュリティに関する状況を理解する必要があります。

コンプライアンスに関する状況は、対応できていないものをリストアップすればよいので簡単です。

インシデントを回避することがセキュリティにつながる、あるいはセキュリティを確保することがインシデントの回避につながる等、セキュリティの定義には様々なものがあります。

セキュリティを測る最も一般的な方法は、その反対であるリスクを測ることです。つまり、リスクが少ないほどセキュリティが高く、その逆もまた然りです。別の方法として、サイバーセキュリティのインシデントを数えるという方法もあります。

あまり知られていませんが、成熟度評価もあります。

また、広く使われている技術やソフトウェアベースのセキュリティ対策と比較することも、現状を把握するための一般的な方法として挙げられます。

我々はどこにいて、どこに向かっているのか?コンプライアンス、リスク/セキュリティ、技術的な状況(成熟度)、賢明さ、そして定期的に見直すことのできる改善目標を設定することで、答えを出すことができます。

どうすれば目標に到達できるのか?

ここで、サイバーセキュリティの専門家の色眼鏡が最も強く働くことになります。

リスク管理の専門家であれば、他のどのようなアプローチよりもリスクを低減する計画を立てるでしょう。

もしあなたがコンプライアンスの専門家であれば、他のどのようなアプローチよりもコンプライアンスを向上させる計画を立てるでしょう。

もしあなたがテクニカルスペシャリストであれば、他のどのようなアプローチよりも技術ソリューションを導入する計画を立てるでしょう。

もしあなたが成熟度のスペシャリストなら、他のどのようなアプローチよりも成熟度を向上させる計画を立てるでしょう。

どのアプローチを使っても、あなたの評価基準や成功基準は、他のアプローチとは大きく異なるでしょう。

サイバーセキュリティの価値を証明できるか?

サイバーセキュリティの究極は、インシデントが発生しないことです。

ネガティブな結果が無いと成果が見えないため、サイバーセキュリティの価値を証明することは非常に困難です。これはセキュリティマネジメントに特有のものです。

また、サイバーセキュリティの活動と結果の繋がりは非常に弱いです。例えば、あるシステムを2倍の頻度でペントテストしたとしても、それによってそのシステムが必ずしも2倍安全になるわけではありません。しかし、1時間に2倍のサンドイッチを作って売れば、原理的には2倍の利益を上げることができるのです。

ポジティブなセキュリティ目標を定義することは可能だと思いますが、現在このアプローチは一般的ではありません。

価値を証明するのが難しいもう一つの理由は、すべての情報システムが同じ程度にビジネス目標に貢献するわけではないことです。そのため、複雑なIT環境の保護に成功しても、それをビジネスの重要な目標の保護につなげることができないのです。

さらに、現代のIT環境は何層にも重なっており、それらをすべて保護することは現実的でない、あるいは費用がかかりすぎるという問題があります。

また、組織やIT環境は常に変化しているため、静止しているわけにはいきません。

サイバーセキュリティの価値を証明することが困難なため、組織内で必要な賛同と投資を得るのに多くの問題が生じています。

私たちは、必要なことをすべて知っているのでしょうか?

セキュリティを定義することの難しさ、セキュリティを管理するためのさまざまなアプローチ、環境の複雑さ、そして、「負の成果物」を生み出すという事実の結果、サイバーセキュリティ管理者は、不完全な情報の霧の中にいることに気づかされます。

組織やIT環境について知るべきことをすべて知っているわけではありませんし、状況を評価して改善を図るためのツールも、最良のものである場合もあれば、そうでない場合もあります。

サイバーセキュリティは、私たちが手に入れたい情報に比べて、扱える情報が限られていることも特徴的だと思います。

どうすればいいのか?

Evidence Based Cybersecurity Management は、現在コンプライアンスやリスク、テクノロジーといったアプローチを好んでいる実務家の助けになると思います。

最も重要な理由は、自己補正が可能なことです。成功基準を達成できなかった場合、インシデントが発生した場合、新しい要件が発生した場合、それを管理システムにフィードバックして軌道修正することができます。これは、従来のアプローチでは必ずしもそうではありませんでした。

もし、あなたのチームが、複雑な環境の中で、あらゆる機会を捉えて学び、教訓を適用することを望むなら、Evidence Base Cybersecurity Management が必要です。

出典:Cybersecurity: The Big Picture

テレグラムのランキングサイト / Rating of Telegram channels


MetaMaskをツイートしたり、暗号に関する公開Telegramチャットに書き込んだりすると、すぐにDMやツイートの返信に怪しいメッセージが来るのはなぜでしょうか?

答えは簡単で、以下のようなサービスがあるからです。


uk.tgstat.com/en/alerts

この様な方法は、もともとコカ・コーラのような企業がネガティブキャンペーンに対処するために使っていたものです(そしてそれはSEM/SIEM/OMの一部です)また、レピュテーション・マネジメントとも呼ばれます。


Inverse Financeがハッキングされ、120万ドル以上盗まれる / Hacker steals over $1.2 million from Inverse Finance, their second such exploit in under three months


イーサリアムベースの分散型金融(DeFi)ツールInverse Financeが2022年6月16日の朝、120万ドル以上悪用されたことが、明らかになった。

ハッカーはフラッシュローン攻撃を使ってプロトコルを騙し、110万ドル相当の53ビットコイン以上と、米ドルを1対1で裏付けするテザー(USDT)1万USTDを盗んだようだ。この悪用は、既報の通り、攻撃者が同様の攻撃でInverse Financeから1500万ドル相当の暗号通貨を盗んでから2カ月余りで行われたものです。

6/16に、Inverse Financeの開発者はユーザーに対する借入機能を一時停止し、事件を調査していると述べた。

フラッシュローンはDeFi特有の仕組みで、同じ取引内で返済する限り、ユーザーは少ない担保で高額な資金を借りることができる。一般的にはトレーダーが使用しますが、悪質な業者はフラッシュローンを使ってプロトコルのスマートコントラクトを騙し、流動性プールの価格を操作してそのプールの資産を乗っ取ることもあります。

ブロックチェーンのデータによると、攻撃者は攻撃を行うために、レンディングプロトコルAaveから約27,000ラップビットコインをフラッシュローンしていたようです。この資金は、スワップサービスCurveを通じて様々な安定コインに回された後、Inverse Financeのプールから安定コインであるDOLAを取り除くために使われたようです。

ブロックチェーン分析ツールEtherscanで「Inverse Finance Exploiter」とタグ付けされたアドレスが、悪用後にプライバシーミキサーのTornado Cashに900イーサー(100万ドル相当)を送ったらしいことが、データから判明した。

Tornado Cashは、ユーザーがアドレスをマスクすることができ、攻撃者が盗んだ資金を隠すために採用されることもある。

本社システムの障害発生に関してお詫びとお知らせ 2022年6月14日 株式会社化学工業日報社


2022年6月6日(月)、化学工業日報社本社システムの一部がランサムウェアの攻撃を受け、新聞制作システム等に障害が発生しております。本紙「化学工業日報」につきましては関係先のご協力の下、発行を継続しております。ご購読者の皆様をはじめ関係各位にはご迷惑をおかけし、深くお詫び申し上げます。

弊社内の全端末について直ちに安全確保および安全対策の強化を行い、現在のところなりすましメール等の被害は確認されておりませんが、万一弊社発を装った不審なメール等をお受け取りになられた際は、ご注意いただきますようお願いいたします。

すでに警察および公的機関に連絡し、システム会社のご協力を受けながら調査を進める方針です。今後、お知らせすべき新たな事実が判明した際は、改めて本紙、弊社ウェブサイト等にてお知らせいたします。

H&M、アプリで他人の購入履歴が丸見えに 「システムアップデートが原因」


衣料品大手のエイチ・アンド・エム ヘネス・アンド・マウリッツ・ジャパン(H&M)は2022年6月15日、会員制サービス「H&Mメンバー」のスマートフォンアプリについて、一部顧客の個人情報や注文履歴が他のユーザーに表示される状態になっていたと発表した。問題はすでに修正済みという。

Twitter上では、14日頃から「H&Mのアプリで他人の購入履歴が載っている」などの報告が上がっていた。購入履歴や氏名、住所などが見られる状態だったという。

「ハッキングなどによる外部からの被害ではなく、社内で行ったシステム・アップデートに伴うエラーによるもの」(H&M)としている。現在は原因などを調査中で、詳細が分かり次第発表する方針。


セキュリティ関連リストコレクション / Cybersecurity Repositories

 

ハッカー、ペンテスター、セキュリティ研究者のための素晴らしいリストのコレクションです。

Android Security

AppSec

Asset Discovery

Bug Bounty

Capsulecorp Pentest

CTF

Cyber Skills

DevSecOps

Embedded and IoT Security

Exploit Development

Fuzzing

Hacking

Hacking Resources

Honeypots

Incident Response

Industrial Control System Security
InfoSec

IoT Hacks

Mainframe Hacking

Malware Analysis

OSINT

OSX and iOS Security

Pcaptools

Pentest

PHP Security

Red Teaming

Reversing

Sec Talks

SecLists

Security

Serverless Security

Social Engineering

Static Analysis

The Art of Hacking Series

Threat Intelligence

Vehicle Security

Vulnerability Research

Web Hacking

Windows Exploitation - Advanced

WiFi Arsenal

YARA

Hacker Roadmap

Adversarial Machine Learning

AI Security

API Security Checklist

APT Notes

Bug Bounty Reference

Cryptography

CTF Tool

CVE PoC

Detection Lab

Forensics

Free Programming Books

Gray Hacker Resources

GTFOBins

Hacker101

Infosec Getting Started

Infosec Reference

IOC

Linux Kernel Exploitation

Lockpicking

Machine Learning for Cyber Security

Payloads

PayloadsAllTheThings

Pentest Cheatsheets

Pentest Wiki

Probable Wordlists

Resource List

Reverse Engineering

RFSec-ToolKit

Security Cheatsheets

Security List

Shell

ThreatHunter-Playbook

Web Security

Vulhub

採用合格通知1件を誤って17人に送信、別人に送るミスも - Osaka Metro


大阪市高速電気軌道は、採用管理システムより新卒採用の合格通知を送信したところ、誤った宛先に送信するミスがあったことを公表した。

同社によれば、2022年6月9日に合格者1人へ合格通知を送るところ、誤って採用管理システムから未受験者や他試験の受験者17人に送信するミスがあったという。誤って合格通知が届いた受信者より問い合わせがあり問題が発覚した。

採用管理システムにおいて通知内容を閲覧できないよう設定を変更したが、6人がすでに閲覧していたという。通知には合格者の氏名が記載されていた。

また同問題を受けて調査を行ったところ、合格者1人に対する通知を別の合格者1人に誤送信していたことも判明した。送信時のチェックが甘く、複数によるチェックも行われていなかったという。

同社では、情報が誤送信された合格者に経緯を説明して謝罪。誤送信先に対しても謝罪するとともに合格通知の削除を依頼した。


出典:採用合格通知1件を誤って17人に送信、別人に送るミスも - Osaka Metro