おまたせしました この度、ついにこの記事を完成させることができました。これは私が数年前からずっと書きたいと思っていた、ウェブのアクセスログに対する、機械学習を使った異常検知の実例です。私は事あるごとに(※1)「情報セキュリティ分野でもデータサイエンスの技術は非常に重要だ」と繰り返していますが、この記事の内容はまさにその1つの証となると思います。この記事で示される内容を見れば、「うわ、機械学習、マジでヤバイい(語彙力)んだな...」となるでしょう。以下に心当たりのあるセキュリティエンジニアはぜひ読んで、そして実践してみてください。 機械学習に興味はあるものの、どこから手を付ければよいのかイメージがわかない 本当にAIやデータサイエンス、機械学習がセキュリティの分野で役に立つのか、確信がもてない データサイエンスや機械学習は難しそうだと思っている ログ解析において、grepや単純な統計処理より

はじめに 以前「シグネチャ依存型のWAFは避けよう」という記事に詳しく書いたように、WAFの仕事の本質は分類です。 WAFにはファイアウォールという言葉が含まれることから、その仕事には「守る」あるいは「防ぐ」ようなイメージがありますが、実際にはWAFが仕事を行う上で最も重要になるのは、その通信が攻撃なのかどうかを見分けること、つまり「分類」です。分類が終わってしまえば、その結果に応じて通信を許可したり、禁止するだけでよいので、そこには技術的な意味での難しさはありません。 つまりWAFというのは「ソフトウェアが分類を行う場面」であり、いかにしてコンピュータ、ソフトウェアに上手に物事を見極めてもらうのか、分類してもらうのかという点が、よいWAFを実現するために必要な技術のコアになります。 あるHTTPリクエストを見て、「ああ、これは攻撃だよね」と専門家が目で確認してわかる場合。果たしてソフトウ

はじめに 最近ではIaaSやPaaSを中核とする大手クラウドサービスが、それら以外にも数多くのメニュー、サービスを横並びに展開するようになりました。ここにはCDNやWAFが含まれることもあります。これらのクラウドサービスにおいて、CDNはさておき、WAFについてはあくまでも「オプション」的な立ち位置にあるものが多いようです。今回は個人的にこの「クラウドのオプション型」のWAFについて気になっている点を紹介します。 1. シグネチャ依存型が多い 大手クラウドサービスではメインとなる稼ぎ頭はIaaSやPaaS、あるいはデータベースのSaaS等であることが多いと思いますが、「一通りのサービスがこのクラウドだけで揃う」という点を重視しているのか、WAFという名目で、私から見るとあまり機能が充実していないものを提供しているケースがあります。そしてこれらはほぼ全てのケースでWAFの実装としてシグネチャ

はじめに 私は「シグネチャ依存型のWAFは避けよう」という記事(以下、前記事)において、以下の内容を示しました。 WAFの仕事の本質は「分類」である WAFというのは、ソフトウェアが分類を行う場面である ソフトウェアが分類する＝AI/データサイエンス分野の技術である シグネチャは10年以上前の古い分類技術で性能が低く、2020年の時点で使うべきでない 上記だけ眺めれば、WAFにおいてシグネチャを使っても良い事はなさそうに見えます。しかし実際には、シグネチャ(あるいはルール)だけを使っている「シグネチャ依存型」のWAFが今もたくさん存在しています。つまり、何かしら、シグネチャが生き残っている理由があるはずです。 今回は、WAFにおけるシグネチャの利点・欠点について、より掘り下げて行きたいと思います。なお、本文内で何度か登場する「誤検知」は、「本来止めるべきでない正常な通信を、誤って攻撃と分類

はじめに Scutumには他の多くのWAFと同じようにIPアドレスを使ったアクセス制御の仕組みが備わっています。例えば特定のネットワークからのアクセスを拒否したり、逆に特定のネットワークやアドレスからのみアクセスを許可する、という設定が可能です。 このとき、例えば「日本の国内のIPアドレスからのみアクセスを許可したい」のような要求がある場合など、数千〜数万くらいの大量のネットワークアドレスのエントリが列挙されて設定されることがあります。 実際にアクセスを制御する場面では、そのとき接続してきたある1つのIPアドレスが、上記の大量のネットワークアドレスの中の「いずれかにマッチするか、あるいはまったくマッチしないか」を高速に判定する必要があります。 Scutumではこの処理に二分探索を使うことで高速なマッチングを実現しました。今回はこのアルゴリズムを紹介します。 このアルゴリズムの要点 実際には

はじめに ScutumはフルマネージドなWAFサービスなので、利用しているユーザさんが気づかない間にどんどん変化し、防御能力を強化しています。これらの強化された点について、これまではあまり宣伝や周知を行っていなかったのですが、今後は少しずつ、このブログでお知らせしていこうと思っています。 防御を強化しているポイントはマニアックな細かなものから重要なものまで多岐に渡ります。今回紹介するのは、我々としてはかなりインパクトがあると考えているものです。 2019年の秋に、コマンドインジェクションに対する防御能力を強化しました。コマンドインジェクションといっても普通のものではなく、比較的最近になって知られるようになった、「WAFを回避する」種類のコマンドインジェクションです。 WAFを回避するコマンドインジェクション 攻撃者とWAFの間では互いに「見つからないように」「見逃さないように」というイタチ

はじめに 「ゾーン」あるいは「フロー状態」と呼ばれる精神状態があります。スポーツや楽器の演奏、ゲームのプレイ中、そしてプログラミングなどにおいて、高い生産性や成果をもたらすことがよく知られています。プログラマーであれば、誰でもコードを書いているうちに、いつのまにかゾーンに入っていたという経験があるのではないでしょうか。 高い生産性や、そのこと自体が気持ちの良い体験であることから、基本的にプログラマーがゾーンに入っていることに対しては肯定的なイメージがあるかと思います。しかし今回は、筆者の個人的な経験に基づいた「わざとゾーンに入らずにコードを書く」というメソッドについて紹介したいと思います。 ゾーンとプログラミングへの一般的な見方 ゾーンに入っている間、プログラマは非常に生産的になり、コードを書くということ自体が楽しくなってきます。自身が書いているコードの内容に対する迷いがなく、目的の機能を

はじめに H2OはH2O.ai社がOSSとして公開している機械学習の実装です。 筆者が使ってみた感じ、以下のような特徴があるようです Javaでフルスクラッチで開発されている しかし、PythonやRのユーザも取り込めるように、PythonとRのインターフェースもきちんと用意されている 使用できるアルゴリズムの数は非常に少ないが、どれもKaggle等でよく使われる厳選されたものになっている(上画像を参照) そのため、「サービスやプロダクトに機械学習を実用する」という視点だと、迷いがなく非常に使いやすい 研究や学習向けではなく、完全に実用向き 学習時に並列処理が行われるので、マルチコアCPUの良さを十分に活かすことができる。(H2Oでクラスタを作成することもできるようだが、筆者はそちらは調べていない) OSSであるが、非常にお金がかかっている印象。UIが洗練されており、ヘルプやドキュメントも

HRSとは 2018年の7月に、「XSS due to the header Transfer-Encoding: chunked」というタイトルでPHPの脆弱性報告がありました。 https://bugs.php.net/bug.php?id=76582 日本語の情報源としては徳丸さんによるこちらの記事が参考になります。 この脆弱性は下記のように、HTTPリクエストヘッダ内に一見矛盾していたり、明確でない内容が含まれている場合の挙動についてのものでした。 Transfer-Encoding: chunked Content-Length: 25 この問題はHTTPリクエストスマグリング(HTTP Request Smuggling、以下HRS)と呼ばれていて、今から13年前、2005年に知られたものです。筆者は今から11年前に「ウェブアプリケーションセキュリティ」という本(通称:金床本)

はじめに IPレピュテーションはIPアドレスそのものの信頼性をスコアリングし共有する手法で、主にスパムメール対策において使われてきました。しかし近年では(他社さんの)WAFがウェブアプリケーションへの攻撃を防ぐためにIPレピュテーションを利用する、というケースが増えてきたように感じます。 筆者は、あくまで個人的な感覚としてですが、「IPレピュテーションはウェブの攻撃検知・防御では役に立たないだろう」と思っていたのですが、今回これを客観的に評価してみることにしました。 何を調べるか？ IPレピュテーションというのは要するに「一度(あるいはそれ以上)悪さをしたIPアドレスは、次から許さないぞ」というアプローチです。つまりあるIPアドレスからの最初の攻撃に対しては無力ですが、一度攻撃を見つけたら、次からはそのIPアドレスからの攻撃を防ぐことができる、ということになります。 そのため調べるべきなの

はじめに 2017年にJoomlaに見つかったLDAPインジェクションの脆弱性、CVE-2017-14596について調査をしたので、簡単にブログにまとめたいと思います。 怪しい動画 脆弱性があったのは./plugins/authentication/ldap/ldap.phpの中です。ユーザ入力をそのままエスケープ処理することなくLDAPのSearchに渡してしまっているという、典型的なものでした。 これを発見したのはRIPSTechという企業のようで、こちらのブログ記事が一時情報源となっているようです。この記事からはこの脆弱性を突くデモ動画へのリンクが存在しているのですが、この動画は非常に興味深い（？）です。 一見するとLDAPインジェクションの脆弱性をうまく突いて、管理者のパスワードを抜いているようであり、「あちゃ〜、Joomlaダメだこりゃ...」と思います。しかしよく考えると、かな

はじめに 2017年、ついにOWASP Top 10が更新されました。筆者が一番印象的だったのは「Top 10にCSRFが入っていない」ということです。 なぜCSRFが圏外になってしまったのかは4ページのリリースノートで軽く説明されています。「retired, but not forgotten」つまり「引退したね...でも君の事は忘れてないよ」という感じでしょうか。全米がCSRFのために泣きそうです。 それはさておき、具体的には「as many frameworks include CSRF defenses, it was found in only 5% of applications.」という部分が引退理由だと思われます。「多くのフレームワークがCSRF対策を備えた結果、5%のアプリケーションにしかCSRFは見つからなかった」というのが引退の理由です。 この理由を読むと、「というこ

はじめに Apache Tomcatに立て続けに見つかったCVE-2017-12615～12617の3つの脆弱性は基本的には同じ原因によるものでした。3つのうち2つは任意のJSPファイルをPUTリクエストでアップロードできてしまい、アップロード後にアクセスすることでJavaのコードが実行できてしまう、というパターンのRCE。残りの1つはJSPがそのまま静的ファイルとしてアクセス可能なためにソースコードが漏洩してしまう、というものです。 今回JPCERT/CCも注意喚起するなど、広く知られることになりましたが、一方でなかなかパッチが提供されないという状況にもなっています。今回はこの脆弱性についての調査を報告します。 readonlyパラメータとは何か JSPがアップロードできてしまうのはreadonlyパラメータがfalseになっている場合です。このパラメータはデフォルトでtrueであり、f

はじめに 先日、Struts 2に新たな脆弱性S2-052(CVE-2017-9805)が発見され、修正されました。 これはリモートからの任意のコードの実行(RCE)が可能な脆弱性であり、「またか」と思われた方も多かったのではないかと思います...。 しかし実はこの脆弱性によるRCEは、過去繰り返しStruts2に報告されてきたOGNLインジェクションとは異なるメカニズムで発生するものでした。 ここでは、この脆弱性の原因と、RCEに至るメカニズムを解説してみようと思います。 多少プログラミングの知識のある方向けになってしまいますが、ご容赦ください。 シリアライズ／デシリアライズ プログラム内で扱うオブジェクトのインスタンスを特定のフォーマットに従ってバイト列に変換する、またその逆操作を行う仕組みをシリアライズ／デシリアライズと呼びます。 これは単なるデータの保存・復元ではなく、オブジェクト

はじめに 2017/9/10(日)に「Security meets Machine Learning」に参加し、Scutumにおけるデータサイエンスの使い方について発表を行ってきました。今回は簡単な参加レポートをしたいと思います。 自分の発表 私はトップバッターでした。40分ほど時間を頂き、Scutumの防御機能の中核であるベイジアンネットワークや、最近導入を開始しているクラスタリングによる異常検知について紹介をさせていただきました。講演に使った資料は我々の主な敵であるスクリプトキディに見られたくない部分を含むため、非公開となっています。 現在、24時間休みなく、Scutum上を正常と異常が混ざった大量のデータが通過していきます。まさに「ビッグデータ」が手に入る状況ですが、それらすべてに「攻撃である・攻撃ではない」のようなラベルを付けることは現実的ではありません。そのためKaggleをウォ

はじめに 私は以前の「Struts2が危険である理由」というブログ記事において 例えばS2-045については止めることが出来ていました(ゼロデイでも防ぐことが出来ていました）が、S2-046についてはギリギリ、わずか数時間の差で先にScutum側の防御機能のアップデートが間に合いました。これを受けて今後、より力を入れてStruts2のOGNLインジェクションに特化したゼロデイ攻撃を想定した防御機能を開発する予定です と書きましたが、これを実際に開発し、現在稼働中の全てのScutumのサーバに対してデプロイしました。 個々の脆弱性への対応ではなくOGNLインジェクションを防ぐ これまでScutumでは、Struts2に脆弱性が見つかった場合、それぞれの（例えばS2-045、S2-046といった）脆弱性に対してHTTPリクエスト内での発生箇所を絞り、シグネチャを作成していくアプローチを中心にし

はじめに 2017年3月、Struts2にまたしても新たな脆弱性(S2-045、S2-046)が見つかり、複数のウェブサイトにおいて情報漏洩等の被害が発生しました。筆者は2014年4月（およそ3年前）に「例えば、Strutsを避ける」という記事を書きましたが、今読み返してみると「やや調査不足の状態で書いてしまったな」と感じる点もあります。今回、良いタイミングなのでもう一度Struts2のセキュリティについてざっとまとめてみたいと思います。 なぜJavaなのにリモートからの任意のコード実行(いわゆるRCE)が可能なのか Struts2はJavaアプリケーションであり、Java製のアプリケーションサーバ上で動作します。Javaはいわゆるコンパイル型の言語であるため、通常はランタイムにおいて任意のコードを実行することはできず、RCEは難しいはずです。 JavaのウェブアプリケーションでRCEが成

はじめに 私は自ら「串職人」と名乗るほどウェブの(つまりHTTPの）Proxyサーバが好きで、もう10年以上もプロキシサーバを作り続けています。このブログの主題であるクラウド型WAF、Scutumもそのひとつです。そもそもプロトコルとしてのHTTPが好きです。ウェブの裏側に、とてもシンプルな、テキストベースのHTTPプロトコルが活躍しているということが私の串職人としての出発点です。 HTTP/2が出た 先日、ついにHTTP/2が出ました。 数年前から、「SPDY」などのキーワードに代表される次世代のHTTPが模索されていることは何となく知っていましたが、どうもGoogleのような非常に大きいトラフィックを処理している組織が主導しているもので、一般の開発者やウェブの利用者にとってそれほど魅力的なものではなさそうだな、という印象を抱いていました。 サーバ側を作っているのもGoogle、ブラウザ

はじめに 先日、私たちが開発しているクラウド型WAFサービス、Scutum(スキュータム)において、予想していなかった箇所の修正によってサーバの負荷が大幅に減るということがありました。原因はこのエントリのタイトルにもあるように、Stringクラスのインスタンスを生成する際の方法にありました。 Stringクラスのコンストラクタとcharset Stringクラスにはいくつかのコンストラクタが用意されています。我々が使っていたのはString(byte[] bytes, String charsetName)です。2つめの引数で、"MS932"や"UTF-8"のような文字集合(以下charset)を明示的に指定するものです。 ScutumのようなWAF(Web Application Firewall)は通常のウェブアプリケーションとは異なり、起動している間にさまざまなcharsetを扱うこ