WordPressに仕込まれたマルウェアのコードが恐ろしすぎた
『Googleから「マルウェアに感染している」という警告が届いたので、調査して欲しい』という依頼を受けて、とあるサイトの調査をしたところ、どうやらWordPressにマルウェアが仕込まれている模様。 かなり時間を掛けて広範囲にヤラれていたので、マルウェアをすべて取り除くのに苦労したのですが、その際に見付けたマルウェアが中々恐しいものだったので、ここに書き残しておきたいと思います。 なお、真似してマルウェアを作られても困るので、ソースの一部を画像で載せることにします。 ## マルウェアのソースを人間に読めるようにしてみる では、早速マルウェアの中身を見てみましょう。 まず、いきなり始まるコメント行。そして、長くて一見ランダムに見える文字列。 そして2行目でランダムに見える文字列を base64_decode() し、eval() しています。base64_encode()しているのは、ソース
NHK NEWS WEB 広告ソフトが脅かすセキュリティー
購入したばかりのパソコンを使うと、クレジットカードなどの情報がインターネットから盗み見られてしまう。 去年販売されたパソコンの一部に、重大なセキュリティー欠陥があるソフトが最初から入っていたことがわかり、大きな批判を招いています。 問題から見えてきたのは、ネットユーザーを分析して利益を上げようという技術に潜む危険性です。 報道局の三輪誠司解説委員が解説します。 パソコンに入っていたソフトの正体は 問題のパソコンは、中国のパソコンメーカー「レノボ・グループ」が去年の９月から１２月にかけて世界中で販売した４０余りの機種です。 レノボが２月２０日明らかにしたところによりますと、これらのパソコンには「Ｓｕｐｅｒｆｉｓｈ（スーパーフィッシュ）」と呼ばれるソフトが出荷状態から入れられていました。 Ｓｕｐｅｒｆｉｓｈは利用者がショッピングサイトなどで商品を検索したり表示したりすると、その情報を別の企業の
本日の情報セキュリティコラム[国民を守る情報セキュリティサイト] - デジタル初心者・高齢の立場から考える『情報セキュリティ対策』 老テク研究会 事務局長 近藤 則子
２月１日～３月１８日は「サイバーセキュリティ月間」です。 普及啓発活動へご協力ください。 不審なメールによる情報漏えい被害や個人情報の流出など、生活に影響を及ぼすサイバーセキュリティに関する問題が多数報じられています。 誰もが安心してITの恩恵を享受するためには、国民一人ひとりがセキュリティについての関心を高め、これらの問題に対応していく必要があります。 このため、政府では、サイバーセキュリティに関する普及啓発強化のため、２月１日から３月１８日までを「サイバーセキュリティ月間」とし、国民の皆様にサイバーセキュリティについての関心を高め、理解を深めていただくため、サイバーセキュリティに関する様々な取組を集中的に行っていきます。
![本日の情報セキュリティコラム[国民を守る情報セキュリティサイト] - デジタル初心者・高齢の立場から考える『情報セキュリティ対策』 老テク研究会 事務局長 近藤 則子](https://cdn-ak-scissors.b.st-hatena.com/image/square/807d51f8f5c93f9a7c74859fd3cd49086fe5b68f/height=288;version=1;width=512/https%3A%2F%2Fsecurity-portal.nisc.go.jp%2Fassets%2Fimages%2Fcybersecuritymonth%2Fscreenshot-index.png)
PHPのmb_ereg関数群は不正な文字エンコーディングをチェックしない
PHPのbasename関数には、マルチバイトに対応していないという誤解（実際にはロケールの設定をすればマルチバイトでも使える）があったり、不正な文字エンコーディングをチェックしないという課題があったりで、イマイチだなーと思っている方も多いと思います。 そういう方々が、preg_replace（u修飾子つき）やmb_ereg_replaceを用いて代替関数を作成している解説も見かけますが、それではこれら正規表現関数は不正な文字エンコーディングをチェックしているのだろうかという疑問が生じます。 ざっと調べたところ、以下の様な状況のようです。 preg_replace : 不正な文字エンコーディングをチェックしている mb_ereg_replcae : 不正な文字エンコーディングをチェックしていない ここでは、mb_ereg_replaceが不正な文字エンコーディングをチェックしない状況と、そ
Superfish/eDellRootが危険な理由 - めもおきば
Lenovo製のPCの一部にSuperfishというマルウェアが標準でインストールされていることが確認され、大きな問題となっています。 [2015-11-24追記] DELL製のPCにも、「eDellRoot」とされるSuperfishと同様の問題を持つルート証明書が導入されているようです。 DellのPCに不審なルート証明書、LenovoのSuperfishと同じ問題か - ITmedia エンタープライズ Dude, You Got Dell’d: Publishing Your Privates - Blog - Duo Security Joe Nord personal blog: New Dell computer comes with a eDellRoot trusted root certificate https://t.co/chURwV7eNE eDellRootで
Lenovo製品にプリインストールされているアドウェアSuperfishに関連する情報をまとめてみた。 - piyolog
2015年2月19日、Lenovo製品のPCの一部にプリインストールされているアドウェアSuperfishに深刻な問題が確認されたとして報道されました。ここでは関連情報をまとめます。 公式発表 2015年2月19日 LENOVO STATEMENT ON SUPERFISH (魚拓：当初発表・変更後) 2015年2月20日 Superfishに関するレノボの見解 (魚拓：当初発表・変更後) 2015年2月20日 SUPERFISHの脆弱性 (魚拓) 2015年2月21日 Updated Lenovo Statement on Superfish (魚拓) 2015年2月21日 Superfish に関するレノボからのお知らせ（更新）(魚拓) 見解内容 2015年1月以降Superfishのサーバー側作用により完全に無効となっており、この無効化は市場に出回っている全てのSuperfishが対
PHPのbasename関数は不正な文字エンコーディングをチェックしない
昨日のエントリにて、PHPのbasename関数はマルチバイト文字を扱えることを説明しましたが、このブログの読者であれば、きっとbasename関数は不正な文字エンコーディングについてどの程度チェックするのかという疑問が生じたことでしょう（きっぱり）。実はbasename自体は、不正な文字エンコーディングをチェックせず、垂れ流してしまいます。その理由をbasenameのソースコードで確認してみましょう。以下は、basename関数の実装の一部です。 // ext/standard/string.c // php_basenmae() while (cnt > 0) { inc_len = (*c == '\0' ? 1: php_mblen(c, cnt)); switch (inc_len) { case -2: case -1: inc_len = 1; php_ignore_valu
PHPのbasename関数でマルチバイトのファイル名を用いる場合の注意
まずは以下のサンプルをご覧ください。サーバーはWindowsで、内部・外部の文字エンコーディングはUTF-8です。UTF-8のファイル名を外部から受け取り、Windowsなのでファイル名をShift_JISに変換してファイルを読み込んでいます。basename関数を通すことにより、ディレクトリトラバーサル対策を施しています。 <?php header('Content-Type: text/plain; charset=UTF-8'); $file_utf8 = basename($_GET['file']); $file_sjis = mb_convert_encoding($file_utf8, 'cp932', 'UTF-8'); $path = './data/' . $file_sjis; var_dump($path); readfile($path); しかし、ディレクトリト
GHOST脆弱性を用いてPHPをクラッシュできることを確認した
GHOST脆弱性について、コード実行の影響を受けるソフトウェアとしてEximが知られていますが、PHPにもgethostbynameという関数があり、libcのgethostbyname関数をパラメータ未チェックのまま呼んでいます。そこで、PHPのgethostbynameを用いることでPHPをクラッシュできる場合があるのではないかと考えました。 試行錯誤的に調べた結果、以下のスクリプトでPHPをクラッシュできることを確認しています。CentOS6(32bit/64bitとも)、Ubuntu12.04LTS(32bit/64bitとも)のパッケージとして導入したPHPにて確認しましたが、phpallで確認した限りPHP 4.0.2以降のすべてのバージョンのPHPで再現するようです。なぜかPHP 4.0.0と4.0.1では再現しませんでした。 <?php gethostbyname(str_
ホスト名バリデーションのやり方
(Last Updated On: 2018年8月13日)徳丸さんのブログで私のブログ「GHOSTを使って攻撃できるケース」にコメントがあったようなので、好ましいホスト名バリデーションの方法を書いておきます。 特定の低レベルAPIのバグが10年ほど前に書いた本のコードで対応できていない、と議論するのもどうかと思いますがしっかりチェックする場合の例を書いておきます。 そもそもホスト名の仕様はどうなっているのか？ 入力バリデーションを行うには仕様を理解する必要があります。ホスト名の仕様は幾つかのRFCで言及されています。例えば、RFC 2181の11. Name syntaxには That one restriction relates to the length of the label and the full name. The length of any one label is li
EximのGHOST脆弱性の影響とバリデーションの関係
追記(2015/2/6) 大垣さんから訂正依頼のコメントを頂いておりますので合わせてお読みください。徳丸としては特に訂正の必要は感じませんでしたので、本文はそのままにしています。そう思う理由はコメントとして追記いたしました。 (追記終わり) 大垣さんのブログエントリ「GHOSTを使って攻撃できるケース」を読んだところ、以下のようなことが書いてありました。 1. ユーザー入力のIPアドレス（ネットワーク層のIPアドレスではない）に攻撃用データを送る。 2. バリデーション無しで攻撃用の不正なIPアドレスをgethostbyname()に渡される。 3. ヒープオーバーフローでヒープ領域のメモリ管理用の空きサイズを改竄する。 【中略】 どんなソフトウェアが危ないのか？ ユーザー入力のIPアドレスをバリデーションしないでgethostbyname()を使用している。 インタラクティブな動作を行っ
)
Sandbox (Windows)
Internet Explorer 10 and Windows apps using JavaScript introduce support for the sandbox attribute. The sandbox attribute enables security restrictions for iframe elements that contain untrusted content. These restrictions enhance security by preventing untrusted content from performing actions that can lead to potentially malicious behavior. The sandbox attribute is specified in Section 4.8.2 of
Qiita Markdownのコードハイライト部分にXSS脆弱性 - Qiita
はじめてQiitaに日記を投稿します。よろしくお願いします。 先日友人から「レポートを生成するためにQiita Markdownを使っているが、どこかにXSSがある気がする」という話を聞き、これは面白そうだとQiitaを覗きに来てみると、投稿画面にはプレビュー機能が付いているようです。Qiita Markdownをインストールする手間が省けたぞと喜んだあと、Qiita Markdownには一体どんな追加機能があるのだろうかとGoogleというサイトで検索して調べました。 技術系の記事を投稿するためのサービスなだけあって、真っ先にコードハイライトするための記法が見つかったので、それをQiitaの投稿ページに入力してみました。
ブラウザ上でMarkdownを安全に展開する - 葉っぱ日記
不特定のユーザーが入力したMarkdownをブラウザ上でJavaScriptを使ってHTMLに変換するという場面においては、JavaScriptで変換してHTMLを生成するという処理の都合上どうしてもDOM-based XSSの発生を考えないわけにはいかない。かといって、MarkdownをパースしHTMLを生成するという処理すべてをXSSが存在しないように注意しながら自分で書くのも大変だし、markedやmarkdown-jsなどの既存の変換用のJSを持ってきてもそれらがXSSしないかを確認するのは結構大変だったりする。 そういった場合には、Markdownから生成されたHTMLをRickDOMを通すことで、万が一HTML内にJavaScriptが含まれていたとしてもそれらを除外し、許可された要素、許可された属性だけで構築された安全なHTMLに再構築することができる。さらに、そうやって生成
SQLインジェクション対策漏れが重過失認定された判決文を読んだメモ | F's Garage
徳丸さんの記事をたどって、判決文読んだ。 SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記 技術面に限った僕的解釈メモ（あくまで個人的な読書メモですので、正確な内容はこちらをご参考ください） ・カード番号の保存は、売り掛け金についてのカード業者を特定するための仕様追加。 ・決済業者へのリンク型の決済を、自社サーバ経由の決済に切り替えた時に全てのカード情報を保存していた。 ・管理画面には、カード情報の一部しか表示されない仕様になっていればよかったのに（カード番号先頭６桁で把握可能）、なぜか律儀にセキュリティコードまで保存されていた。 ・さらにログファイルにも個人情報やカード情報が保存されていて、さらに外部から参照可能になっていた（これが直接の流出原因とはされていない） ・特定の機能について適切にSQLをエスケープしておらず、そこにSQLインジェクションをつくアタック
SQLインジェクション対策もれの責任を開発会社に問う判決
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
Web セキュリティに関するインターンで伝えようとしたこと - co3k.org
これは VOYAGE GROUP エンジニアブログ：Advent Calendar 2014 の 17 日目のエントリです。 VOYAGE GROUP では もの創り実践プログラム Treasure というエンジニア向けインターンシップを開催しています [1] [2] 。 Treasure 全体の様子は既に VOYAGE GROUP エンジニアブログにて 前編 と 後編 に分けて紹介されていますが、このエントリでは、前半パートにおいて僕が担当した Web セキュリティに関する講義についてお話ししていきます [3] 。 講義は休憩や実際に手を動かしてもらいつつで 3 時間半という長丁場でしたが、なぜか随所で笑いが巻き起こる状態で非常に評判がよく、同じ内容を 独立した 1 day インターンシップとして京都でも開催 させていただけました [4] 。これもひとえに必死に内容に食らいついてくれたイ
SQLインジェクションは本当に避けられないのか - ドクジリアン柔術少女 すから☆ぱいそん - ワルブリックス株式会社
ありもしない完全な代替品を求めるよりも、より現実的な選択肢を改善することについて。 SQLからなるべく乖離しないでDRYを実現するっていうScalikeJDBCの落としどころが素晴らしい。「結局のところSQLは書かなきゃいけんねん」「SQLよりつぶしの効くRDB操作用言語は存在しえないねん」っていうORMの教訓を経てきた人類はここに到達したって感じで。 — 嶋田大貴 (@shimariso) 2014, 11月 21 というツイートをしたところ、 何をいうか。必ずORMを使うべきだ SQLは根本的にSQLインジェクションを回避できない問題がある みたいな趣旨の反応があったのだけれど、前者についてはWikipediaのここ を一読いただくとして、後者についてはプログラミング言語のほうが発達してて状況が違ってきてるよという話をしたい。 誤解しないでいただきたいのは、別にSQLが良いものであると
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
汎用JPドメイン名3200円、属性型JPドメイン名5800円で独自 ドメイン取得！ アリクイネット！
/blog/2015/02/poodle-2015-4-internet-explorer-11-ssl-3-0/