2020年6月3日水曜日

私はこうやってEGSSに潜り込んだ 新卒編

こんにちは。エンジニアの竹添です。
本日は、新卒でセキュリティエンジニアになった私が、どのような経緯で業界に足を踏み入れ、どのようなお仕事をしているのか、というテーマで記事を書いてみたいと思います。

セキュリティエンジニアの業界に興味を持っている方に、今後の参考として読んでいただければ幸いです。

自己紹介

はじめに、私のプロフィールを公開します。
・年齢:25歳(1994年生まれ)
・出身:長崎県
・趣味:アニメ、バイク、お料理
・技術領域:ウェブセキュリティ全般、PHP、WordPress

我ながら、これといった特徴も無い普通のプロフィールだと思います。
技術領域に書いてある内容も、ここ2,3年で身に付けたものです。
大した事無いじゃないか、と思っていただくために書きました。


わたしの学生時代

大学は理系の情報工学部に所属していました。
絵に描いたようなインドア学生生活をしていたので、惰性で毎日を送っていました。
大学で出された課題をこなして後は好きなことをするだけの生活です。

そんなある日、知人の紹介でセキュリティ系の勉強会に足を運ぶ機会があり、
これをきっかけにセキュリティの分野に興味を持つようになりました。

あまり耳にしたことのない話が多くて、注目されている。
目新しい感じがして、難しそうなことをしていて、かっこいい。
雑ですが、最初に感じたイメージはこの通りでした。

その後、無知な状態からのスタートでしたが、
情報をキャッチアップする手段を覚え、
業界で起こっている出来事や考え方に触れる機会が増えたことで、
徐々に面白さが分かるようになっていきました。


卒業後の話

大学を卒業してからは、セキュリティエンジニアになりたいと思うようになりました。
理由はたくさんありますが、少し背伸びをするレベルのお仕事をやりたかったこと、とても多くの事を学ぶことが出来そうなこと、これまで会ってきたセキュリティエンジニアの方々が楽しそうにお仕事の話をしていたことが主な動機でした。

「新卒からセキュリティエンジニアを職にするのは難しいから、まずは開発や運用を学んでからにした方がいい」
というアドバイスを受けることもしばしばありましたが、諦めの悪い性分だったので就活の方向性をそのままセキュリティエンジニアに絞りました。

アルバイトを開始

まず、自分の実力が不足していることを知っていた私は、
セキュリティエンジニアになるために必要なスキルを身に付けたいと考えました。
そこで、知人のWeb系の会社に頼み込み、アルバイトとして雇って貰いました。
全くの未経験からのスタートでしたが、最終的にPHPとWordPressの話を多少出来るレベルになりました。

後から振り返ってみると、
この時勇気を出して開発経験を身に付けて良かったと思います。
作り手としての考え方はセキュリティを考える上で強い武器になるからです。

脆弱性診断を例に挙げると、
自分が送信した攻撃文字列が、システムに受け取られた後、
どのように処理されるか仮説を立てながら攻撃を行うことが出来るため、
精度面や効率面で大きなメリットを感じました。

採用に至るまで

Web業界への名残はありましたが、
1年のアルバイト期間を経て、私はEGセキュアソリューションズの門戸を叩きました。

EGセキュアソリューションズは、かの徳丸本の著者である徳丸さんの会社で、少数精鋭のため新卒を募集しておらず、狭き門だという事を理解していました。
ですが、他社と比べた時に、セキュリティベンダーとしての「建前」が無く、本気でお客様のセキュリティ向上に取り組んでいるように見えたので応募に踏み切りました。
※これから弊社に応募される方は、志望動機欄に同じ事を書かないようにお願いします。

実際の採用面接についてはあまり記憶が残っていませんが、志望動機等のヒアリングに加え、「ウェブの世界を安全にしたい」という社の方針に対する自分の考えを問われました。
また、二次試験では実技試験として、徳丸さんと一緒に脆弱性診断を行いながら見つけた事象に関する質問を受けますが、私はことごとく間違えました。

結果としては内定をいただくことが出来ましたが、
今になって思うと、Webの開発経験と、業界の情報を多少なりともキャッチアップしていたことが評価されたおかげではないかと思います。


入社後の話

セキュリティエンジニアといっても様々なお仕事がありますが、
EGセキュアソリューションズでは、社員の基本スキルとしてWebアプリケーションの脆弱性診断を学びます。
新入社員はまず、社長の著書『徳丸本』を片手に脆弱性の原理と影響を学び、研修用のやられサイトの脆弱性診断を行います。
結果は報告書にまとめ、社長から直接レビューを受けることになります。

やられサイトは名前の通り、「やられること」を目的としたサイトのため、たくさんのバグや不具合が見つかります。それらの中から脆弱性として問題のある事象を報告するのはとても大変で、確認漏れがあったり、分析が甘かったり、間違った解釈をしてしまったりと苦労することが多かったです。

また、脆弱性診断で技術力を磨く一方で、
お客様とのやり取りにも積極的に参加し、たくさんの事を学びます。

メールや打ち合わせでのやり取りで、お客様が求めている事をヒアリングし、
弊社が出来る事を理解していただくのは口にするほど簡単ではありません。
「メールでどのような書き方をすればこちらの意図が伝わるだろうか…」
「お客様が本当に求めている事はどのように聞けば良いだろうか…」
日々こんなことばかり考えていますし、それが楽しいです。

担当した業務

業務は脆弱性診断とお客様連絡を中心にしつつ、
希望業務にはどんどん関わる社風のため、色々なお仕事に参加させて貰いました。
私は元々計画を立てることが好きだったこともあり、イベントの運営担当も務めました。
  • Web、プラットフォーム脆弱性診断
  • 開発ガイドラインの策定
  • お客様連絡
  • イベント運営 etc...

入社後に思った事

セキュリティには技術的な要素だけでなく、コミュニケーションによる状況把握能力や解決策を考える思考能力も必要で、総合力が要求されることが分かりました。

また、入社前に抱いていたイメージよりも地味で根気のいる作業が多く、地道に経験を積みながら業務に慣れることが出来ました。私は元々地道な作業を好んでいたこともあり、このお仕事に対する適正が高かったのかもしれません。

加えて、ビジネスにも共通する話だと思いますが、普段から心掛けていることが業務に役立つことも多々ありました。情報のキャッチアップ然りすぐ手を動かすこと然り。自分が必要と思う事は積極的に挑戦するべきだと思いました。


まとめ

本日のまとめです。
  • まずは行動を起こすことが大切
  • セキュリティエンジニアは技術力だけでなく、総合力が求められるお仕事

皆さんの中には、セキュリティエンジニアは華やかなお仕事というイメージを持っている方がいるかもしれません。
それは高難度の案件をずば抜けた技術力のエンジニアが解決するイメージが強いからだと思います。
ですが、私のような人間がセキュリティエンジニアとして生計を立てることが出来ているのも事実です。


セキュリティはこれからもっと一般的な業界になります。
この記事を通して皆さんも業界に興味を持っていただけると幸いです。


PR
EGセキュアソリューションズ株式会社では、私たちと一緒に働く仲間(脆弱性診断員、コンサルタント)を募集しています。新卒・既卒問いませんので、興味のある方は採用ページを参照下さい。

2020年1月30日木曜日

Apacheが最新版(2.4.41)かどうかを確認する方法

こんにちは。EGセキュアソリューションズの社長の徳丸です。
今日は、Apacheが本稿執筆時点での最新版 2.4.41 であるかを確認する方法を公開しちゃいます。

はじめに

脆弱性診断の一環で、サーバーソフトウェアのバージョンを確認したいというニーズがあります。今どき、Apache等のServerヘッダにバージョンが出ていることはまずない(…とも言えず実はよくある)ので、Serverヘッダ以外からソフトウェアのバージョンを確認する方法が知られています。以下はその例です。
2番目の、とある診断員さんの記事は、Apache 2.2のすべてのバージョンをビルドして確認する方法が具体的に説明されています。そして、上の2つの記事はApache 2.2を題材にしていますが、2.2はとっくにサポートが終了しており、2.4系のバージョン確認の方法が求められますよね。
実は、Apacheの最新版 2.4.41 になって、エラーメッセージの表示内容が微妙に変わりましたので、バージョン確認に使えます。まずは、404 Not Foundの表示を用いて説明します。

試してみよう

以下は、Apache 2.4.39(2.4.40は欠番)における存在しないパス /xx に対するレスポンスの例です。
HTTP/1.1 404 Not Found
Date: Thu, 30 Jan 2020 01:48:04 GMT
Server: Apache/2.4.39 (Unix) PHP/5.3.3
Content-Length: 200
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /xx was not found on this server.</p>
</body></html>
以下は、Apache 2.4.41(最新版)における /xx に対するレスポンスの例です。
HTTP/1.1 404 Not Found
Date: Thu, 30 Jan 2020 01:50:08 GMT
Server: Apache/2.4.41 (Unix) PHP/5.3.3
Content-Length: 196
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
</body></html>
2.4.39までと比べると、パス名(/xx)が省略されていることがわかります。これを使ってApache 2.4.41か、それより前のバージョンであるか判別できます。

404ページをカスタマイズしている場合

ただ、404 Not foundのページは通常カスタマイズされているのでApacheが生成するレスポンスボディを見ることはできないケースが多いと思います。その場合は、他のステータスを用いることができます。たとえば、TRACEメソッドは禁止されているケースが多いと思いますが、この禁止されている場合のレスポンスが使える場合があります。

まずは 2.4.39の場合(リクエストとレスポンス)
TRACE /xx HTTP/1.1
Host: apacheall:2439

HTTP/1.1 405 Method Not Allowed
Date: Thu, 30 Jan 2020 01:59:48 GMT
Server: Apache/2.4.39 (Unix) PHP/5.3.3
Allow: 
Content-Length: 225
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for the URL /xx.</p>
</body></html>
次に、2.4.41の場合(リクエストとレスポンス)
TRACE /xx HTTP/1.1
Host: apacheall:2441

HTTP/1.1 405 Method Not Allowed
Date: Thu, 30 Jan 2020 02:03:11 GMT
Server: Apache/2.4.41 (Unix) PHP/5.3.3
Allow: 
Content-Length: 222
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>405 Method Not Allowed</title>
</head><body>
<h1>Method Not Allowed</h1>
<p>The requested method TRACE is not allowed for this URL.</p>
</body></html>
やはり、2.4.39まであったパス名が2.4.41では省略されています。脆弱性診断実務では、TRACEメソッドの許可を調べているケースが多い(参照)と思うので、一石二鳥ですよね!
ステータスの405までカスタムエラーページを用意してあればこの方法でもダメですけどね。Apacheのソースコード(./modules/http/http_protocol.c)の差分で見る限り、以下のメソッドがチェックに使えそうです。

CodeReason-Phrase
305Use Proxy
403Forbidden
404Not Found
405Method Not Allowed
406Not Acceptable
410Gone
412Precondition Failed
413Request Entity Too Large
451Unavailable For Legal Reasons
501Not Implemented
506Variant Also Negotiates

これらのステータスには、引き起こすのが難しいケースもありますが、403, 404, 405,  501あたりが使いやすそうです。

ただし、404を観察するくらいならともかく、エラーを故意に起こす通信は不正アクセスの予備行為と見なされ得るものですので、許可を得ていないサーバーで勝手に試すことは慎みましょう。

どうやって調べたか

Apache の2.2、2.4のすべてのバージョンをビルドして、それぞれポート番号を変えて実行する環境を作りました。先のリクエストで、apacheall:2441 というHost名が見えていましたか、ポート番号 2441 = Apache 2.4.41 という意味です。最終的にソースコードを確認する場合でも、動的解析であたりをつけておくと作業が楽ですよね。

まとめ

Apache 2.4.41以降か、それ未満かをチェックする方法について説明しました。まだApache のバージョンを2.4.41にしているサイトはそこまで多くないと思いますので、脆弱性診断等で「Apacheが最新版ですないです!! ドヤー」とすることができます…
というのは冗談で、この程度でドヤ顔はよくないですw ApacheはLinuxディストリビューションのパッケージで導入していて見かけのバージョンは古いがパッチが適用されているケースが多いですからね。現実的なリスクを踏まえて適切なアドバイスを心がけましょう。

PR

EGセキュアソリューションズ株式会社では、徳丸とともに働く仲間(脆弱性診断員、コンサルタント)を募集しています。興味のある方は採用ページを参照下さい。

フォロワー