オカダリョウタロウ (@okdt) header
オカダリョウタロウ (@okdt) profile picture

OWASPer / セキュリティリサーチャ| アスタリスク・リサーチ📈 | 神戸デジタル・ラボCSA🍖| 神戸高専 | OWASP SAMM practitioner/ OWASP CycloneDX | Hardening Project organizer | 歌と打楽器

Japan
Joined April 2007
Photo by オカダリョウタロウ (@okdt)Photo by オカダリョウタロウ (@okdt)Photo by オカダリョウタロウ (@okdt)Photo by オカダリョウタロウ (@okdt)Photo by オカダリョウタロウ (@okdt)Photo by オカダリョウタロウ (@okdt)Photo by オカダリョウタロウ (@okdt)Photo by オカダリョウタロウ (@okdt)
オカダリョウタロウ retweeted
「デザイナーは美大生がなるべき」という話は「ミュージシャンは音大生がなるべき」という話に置き換えると無茶苦茶感が伝わると思う。
本来、デザイナーは美大生がなるべき職、もしくはそれと同レベルの人。 その美大生たちはデッサンをひたすら何百何千枚も入学前に描いて、さらにセンスや能力を選抜された人たちが美大生になっている。 なのに、ここ数年、素人が副業でパッとできますくらいに宣伝され、有象無象に発生してるから地獄
12
83
11
486
30,283
おおよそこの形を、わたしはグレイボックステストと呼んでいます。 AIにかかわらず、単なるブラックボックステストと比べて格段に有効な発見ができるアプローチなので、手動でもできるように、なにをどうみてどう関係させるかわかるように、訓練しておくのがいいです。 AIの診断の残念な特徴は報酬的である(ひとつ見つけるとおおげさに喜びすぎ、徹底したり反証したりしたがらない)ところです。 調査と分析のハーネスを、自分でできるひとが組むといいと思います。
いくつかご指摘をいただきましたので、AIによる動的診断と静的診断を組み合わせてWebサーバを守る形態をできるだけ簡潔にまとめてみました
1
2
17
2,809
これは....! いまサイバー攻撃に戦々恐々としている事業者が刮目すべき、粛々とやるべき渾身のアドバイスと、根拠資料たち....!
不正アクセスによる情報漏えい事案が相次ぐ状況を踏まえ、国家サイバー統括室では、ウェブサイトやモバイルアプリを使用した事業を運用し、個人情報を取り扱う事業者等に対して新たな注意喚起を発出しました。こちらを確認いただき、改めて基本的な対策の徹底をお願いします。cyber.go.jp/pdf/press/261105…
4
57
20,615
オカダリョウタロウ retweeted
みんなあまりGMOの熊谷社長のことをいじらない方がいいんじゃないかな。。。個性なんだから。
127
33
49
615
139,789
オカダリョウタロウ retweeted
今回の事案がどういうものかとその評価、AIとPHPの関係も含め、他のどのテレビ出演有識者よりも的確に解説しているのが、ホリエモン。やっぱりプログラム作っていた経験は理解の解像度を左右するよね。 youtube.com/watch?v=zHp-i_A-…
131
17
494
151,521
CVSSのスコアは変わります。 これテストにでます。
私が確認した時点から昨夜、Red Hatだけでなく、Amazon Linux 2023についても、CVSS 7.0から8.1への変更されていますね。 脆弱性を静的なスコアではなく、脅威の変化に応じて評価する継続的な脆弱性管理の考え方が必要です。 CVSSの評価は暫定的なものであり、新たな分析結果によって見直されることがあります。 重要なのは、こうした変更を継続的に把握し、自組織のシステム構成、攻撃成立条件、悪用状況、業務影響を踏まえて対応優先度を再評価することですね。
1
1
15
2,155
オカダリョウタロウ retweeted
Replying to @kashioka
後者だろうね その情報、持ってても仕方ない(が、本人にとってだけ意味がある)世界線しかない 早くからネットやってるおれらは、もうとっくにメアドも生年月日も名前も、かつて設定しがちだったパスワードもHave I pwnedサイトみたらわんさと漏れてて、 とっくに「おれの情報もって悪用しようとしてもたいした影響なし」を経験してる気がするよ
1
1
2
307
やってみてる いまでいえば/compact みたいな感じ
― 集中力の筋トレ ― 集中力の筋トレは、日常でできる。 小さな行動をダンベルにする。 集中のコツは、 虫眼鏡のように「意識のすべてを一点に集める」のではなく、「ひとつ残して、あとはすべて留守にする」ことだ。 コーヒーを飲む。 その150ccだけを感じる。 歯を磨く。 その28本だけを感じる。 タオルを畳む。 その4つの角だけを感じる。 散歩する。 その500歩だけを感じる。 気が散ったら、別のダンベルに持ち替えてもいい。 もっと小さく始めるなら、 紙に点をひとつ描いて、見つめる。 点ひとつを残して、自分も世界も少しの間、留守にする。 これに慣れると、調査や分析、問題解決、企画、資料作り、人の話を聞くときにも、不思議なことが起きる。 探していた集中のスイッチが、いつの間にか手元にある。
1
278
あれ、とっくにワンタイムですよ。 あ、強制じゃなかったのか 「従来は固定パスワードとワンタイムパスワードの2方式を提供していたが、今後はワンタイムパスワード方式に統一する」
3Dセキュアのことでしたか。まだ固定パスワードというのにびっくりしたよ / “楽天カード、本人認証をワンタイムパスワードに統一 27年2月から順次” htn.to/2mabdtoFtA
370
attending @offensive_con
Agenda for OffensiveCon Tokyo 2026 is live! Explore the talks and plan your schedule now: offensivecon.jp/agenda/2026.… #OffensiveCon #Tokyo
292
まあこう言っときゃだいたい当たる時代な
【速報】PHP級以上の重大な欠陥の公表を予告、米クラウドフレアCEO ・今後数週間〜数カ月に複数公表されるのは「ほぼ確実」と説明 ・別ソフトの欠陥について、すでに事前情報を把握
Readers added context they thought people might want to know
Cloudflare CEOの発言はReutersインタビューで他の重要ソフトの深刻脆弱性を認識しAIで今後多発予測した一般論で、PHP級以上の特定欠陥公表を予告したものではありません。 thehindubusinessline.com/info-tech/ai-d… secnews.gr/en/743113/clou…
2
4
994
それなんてHardening
#脆弱性大運動会 えー、皆様もふるってご参加ください。 第1種目「Web混合パッチ当てリレー」 第2種目「カーネル更新リレー」 第3種目「DNSパッチ当てリレー」 第4種目「全員参加 秘密鍵更新リレー」 第5種目「NW管理縮退OS更新リレー」 第6種目「AI Agent 合戦(守備)」 アナウンス「まもなく第7種目がはじまります。」
3
392
AIエージェントのコードは、ただいま現在では やすい・はやい・うまい には全然いってなくて、 あきらめやすい・てっとりばやい・うまくやりすごす ってつまりエラードリブン(エラーが起きてからその対処をまじめに考える)なので、 ユーザにとってエラーは日常的にぼろぼろでるしやり直しも多いけど、うまくいけばそのうち直るってことでいいんだったら AI丸投げシステムでもいいのかもしれんよ
1
437
そういや @takoratta さんがエージェントドリブンなコードは「例外処理が日常運用」ってAI学会で言ってた いまだにそんな感じ
1
183
金曜の午後は、整理したり宿題をこなしたり翌週のための作戦を組み直すためにあるのであって新たなことにチャレンジするためには使わないほうが生産性上がるよね 毎週そう心がけている 金曜午後のミーティングで決まったことはたいてい実現されない
Don’t Push to Production on Friday.
2
301
オカダリョウタロウ retweeted
これまで「蓋」がされてた(ように錯覚されていた)パンドラの箱が一気に開いてしまい、今は「(長年の)膿を出す辛抱の期間」と信じたい。。 これまでサイバーセキュリティの現場が悶々としていた課題に一気に向き合ってる日本中の企業と経営層が、ひと皮むけて脱皮した姿を数ヶ月後に見たい、という気持ちでいます。
1
9
1
25
1,825
オカダリョウタロウ retweeted
違うんです。みんなが気にしていなかっただけで、ウェブサーバやその上で動くウェブアプリケーションに携わる人達は、これまでずっと脆弱性と戦ってきたんです。 日々、脆弱性が報告され、そのたびに自分達のシステムへの影響の有無を判定し、影響があればパッチを当ててアップデートする。ログを監視し、アタックがあればブロックし、バグがあれば修正し、そしてまた次の報告が来る。何も起きない日は誰にも気付かれないし、褒められもしない。それでもインターネットが動き続けてきたのは、完璧なプログラムがあったからじゃなくて、壊れるそばから直し続けてきた人達がいたからなんです。 ただ AI の登場で、脆弱性を見つけて突くスピードが一気に上がって、直すスピードより壊すスピードの方が速くなってしまっただけなんです。 これからは、サーバアプリケーションを作る人達も AI を使って直すスピードを上げ、先を予見して穴を塞いでいかなければなりません。今はちょうどその過渡期なのです。
私は50年近くプログラミングをやってきたけれど、脆弱性のないプログラムを書くことは難しく、自分の技術力では到底たどり着けない領域だと感じていた。 それでも、世界には自分など及びもつかないほど頭のいい人たちが大勢いて、そういう人たちが書いた堅牢で美しいプログラムによって、インターネットという巨大な仕組みが支えられているのだろうと、どこか楽観的に信じていた。 自分にはできなくても、きっと誰かにはできるのだろうと、長いあいだ思っていたのである。 しかし、今日の騒動を見ていると、どうやらそうでもなかったらしい。 人類は月に人を送り、何十億もの人々が瞬時につながる世界を作り上げ、ついには人間のように言葉を操るAIまで生み出したというのに、それらを支えるプログラムから脆弱性をなくすという、一見ささやかな願いさえ、いまだに叶えられずにいる。 人類には、脆弱性のないプログラムを書くことは、まだ難しすぎた。 今日ぐらいは、そんなクソデカ主語で語っても許されるだろうか。
23
2,187
124
6,927
659,848
まあ今回の件でWordPressをアップデートしろとしか言わなかったひとたちは特殊な人たち扱いして良いと思う #php2shell
PHPの脆弱性の話なのに「OSとブラウザ、特にアプリのアップデートを急いで!」ってテレビで話をしてるセキュリティ専門家を見た。これを「何を勘違いなコメントしてるのか」と思う業界人も多いと思うけど、俺は「違う件についてコメントを求められたのに編集でPHPのコメントに使われたのやなと思った。
1
5
611
まあ、そうなりますよね しばらくは
🚨 UPDATE: PHP 8.5.12 may still be vulnerable to php2shell! Researchers are reporting a successful double-free trigger on the newly patched release. ⚠️ The official fixes may be incomplete. A crash alone doesn't confirm RCE, but this deserves urgent investigation. Don't assume you're safe just because you've patched. #php4shell #php #cybersecurity teapawt.org/_annieversary/status/2…
2
612
PHP2Shell 着弾発見ガイド(実務反映版)出すよー ■ error.log ``` zgrep -HnEi 'Allowed memory size.*exhausted|Unknown on line 0|Out of memory|SIGSEGV|Segmentation fault|zend_mm_heap corrupted|exited on signal 11' error.log* ``` ■ access.log ``` # 5xxを返したPOSTをIPごとに集計(パスで絞らない) zgrep -HnE 'POST ' access.log* | grep -E ' (500|502|503) ' | awk '{print $1}' | sort | uniq -c | sort -nr ``` ■ ポイント ・発火がアプリより前なので、パスで絞らない方が漏れにくい ・標準ログの大きい数字は「応答サイズ」。リクエストサイズは %I や $request_length を足さないと残らない ・暫定で memory_limit=-1 にした環境では "Out of memory" も検索対象 ・ここで見えるのは「試行」まで。着弾確認は以下も見る ■ 着弾確認 ``` # php-fpm / apache2 からシェルが起動していないか ps aux | grep -E 'php-fpm|apache2|httpd' | grep -v grep # Webルートに新しい .php が増えていないか find /var/www /www /srv -name '*.php' -mtime -1 2>/dev/null ``` #PHP2Shell
リョウタロウさんのPHP2Shellの着弾確認ガイド、error.logで「Unknown on line 0」まで拾っているのが、アプリより前の起動段階で落ちるこの脆弱性の性質に合っていて、ありがたい整理です。ありがとうございます。 手元で式を試したので、補足です。 ・access.logの式は /api/ などの候補が「/」始まりのため、POST //api/ にしか一致しませんでした。先頭の / を外すと拾えます ・6桁以上の数字は標準形式だと応答サイズです。リクエストサイズは %I や $request_length を足さないと残りません ・発火がアプリより前なので、パスで絞らず、5xxを返したPOSTをIPごとに数える方が漏れにくいと思います ・暫定策で memory_limit=-1 にした環境では、Out of memory も検索語になります ここで見えるのは試行までなので、apache2やphp-fpmからのシェル起動、Webルートに増えた .php も合わせて見たいところです。 ディストリ版は版数据え置きで修正が入るので、確認はchangelogで。設定とモニタリングの強化、同感です。 補足で使った式です(combined形式のaccess.logを想定)。 zcat -f access.log* | awk '$6=="\"POST" && $9 ~ /^5/ {print $1}' | sort | uniq -c | sort -rn | head -20 error.log側は元の式に Out of memory を足すだけで、memory_limit=-1 の環境もカバーできます。
2
121
9
405
38,482
@connect24h さんありがとー て、まあ、わかってたんだけどね、 モニタリングって大事!
1,440