December 2020 Archives

２０２０年ももう終わりということで、今年習得したアームバランスのバリエーションを紹介します。

普通のヨガじゃ物足りないという方や、筋トレはあまり好きじゃないという方にもお勧めです。

アームバランスは腕の力がないと難しいイメージがありますが、実は腕の力はそんなに使わなくとも、体重移動を色々してみて、バランスが取れるところをうまく探せればできます。

むしろ、コアを鍛えたい場合は、腕の力は使わない方が良いくらいです。

一言でアームバランスと言っても、実は結構いろんなバリエーションがあります。

難易度は個人差はあると思いますが、私が習得に時間がかかったものから、左上から右下に並べてみました。

やり方の詳細はこちらのサイトによくまとまっています。

初級編：

左：一番ベーシックなアームバランスで、天秤のポーズ（トーラーサナ）と呼ばれるもの。蓮華座が組んで、脚を引き上げれば比較的簡単に浮きます

中：サイドクロウと呼ばれるポーズで、私は右の鶴のポーズよりこちらの方がやり易かったです。太ももを思い切り両肘に乗せるのがポイント。初めは膝は曲がっていてもOK

下：こちらも有名なアームバランスで、鶴のポーズ（バカーサナ）と呼ばれます。怖がらずに思い切り体重を前に載せて、脚の付け根を引き込むと自然に脚が上がります

中級編：

左：ベビーバカーサナと呼ばれる、肘をついた鶴のポーズなのですが、これが意外とキツイ。普通の鶴のポーズよりやりづらい人も多いみたいです。

中：ホタルのポーズ（ティッティバーサナ）と呼ばれるものです。子供がよくやっていますね。両肩にしっかりもも裏を乗せて床をプッシュ。

下：サイドクロウからこめかみを床に降ろし、上の脚を高く上げていきます。江頭がよく取ってるポーズって実はこれ？（笑）

上級編：ここからのポーズは体が柔らかくないと痛めてしまう可能性もあるので、先ずはストレッチから。

左：パドママユラーサナ（蓮華座を組んだ孔雀のポーズ）と呼ばれるポーズ。蓮華座を組んで逆手にし、肘の内側にみぞおちを差し込んでアップ。内臓の活性化におすすめ。

中：名前が分からないのですが鶴のポーズの変形版で、立ち木のポーズから両手を床について行う鶴のポーズです。股関節の柔軟性がないと難しいかもしれません。

下：賢人カウンディニャに捧げるポーズ （エーカパーダカウンディニャーサナ）と呼ばれすポーズで、曲げた片足とみぞおちを二の腕に乗せてバランスを取ります。意外なことに、上の脚は高い方が楽なので、鍛えたい場合は、上の脚はなるべく低くキープ。

左：横向きの鶴のポーズ（パールシュヴァバカーサナ）と呼ばれ、その名の通り、前ではなく、横向きに体重をかけて鶴のポーズを行います。腕をしっかり曲げて、身体を低くするとやりやすいです。

右：八曲がりのポーズ（アシュタヴァクラーサナ）。上の脚を肩に担いだ状態からスタートします。こちらも腕をしっかり曲げて、身体を低くするのがポイント。

どのポーズでも、ポイントは同じかもしれません。

・無理に手で浮こうとせずに、体重移動で自然に浮くまで待つ

・腕全体で床をしっかり押す

・脚の付け根を引き込む

・顔は下げずにしっかり前方を見る

2020年もあと数日で終わり。
コロナで特異な年ではあったものの、全体を振り返ると、良い１年だったかなと。

・個人的には何と言っても、２本目のジャーナル論文が出せたことが嬉しかったです！

・ライフイベントとして大きかった点は、7月に自社に出向復帰したことですね。何しろ、５年間自社に戻っておらず、出向中に昇格したこともあって、
　復帰当時は、諸々お金や見積もり系の事務処理に物凄く手間取りました＾＾；
　そして、出向復帰してから、驚く程技術に専念できる時間が減ってしまい。。（中間管理職の宿命ですね泣）
　最近はすっかり平日日中帯はMS Officeとお友達です（笑）もう少し黒い画面とお友達になりたいですね。。
　２０％くらい、大学や今までやっていた講師、研究業務も兼務しているので、そちらの業務が良い気分転換になっています。
　出向先で得た、Active Directoryや制御システムセキュリティのノウハウをこれから自社でサービス化していく予定です。

・今年は社会人ドクターの１年目でもあります。１本目の論文（効率的な制御システムのリスクアセスメント手法）が無事、ACMの国際学会に採択されました。
　成果を出さなきゃなと焦ってもいたので、こちらも嬉しかったですね。

・上記論文を含め、リモートワークになったことによって時間ができたので、色々勉強や研究できたのは良かったです。
　同僚にアドバイスをもらいながら、ラズベリーパイをCODESYSでPLCにしてみたり、Windows系の脆弱性の検証をやってみたり。
　脆弱性検証なんて、ここ数年やっていなかったので、昔を思い出して楽しかったです（笑）　脆弱性検証のサマリーは過去のブログにもあげていますので、ご興味があればどうぞ。

・緊急事態の時は、突然受け持っている講義がリモートに変更になってどうしようかと思いましたが、可能な限りでリモート化できるものは対応しました。
　結果的に新たなコンテンツができて良かったですね。今年もどうなるか分からないですし。。

・リモートワークの日は1日座りっぱなしだとしんどいので、夜ヨガに行くようになりました。行く時は正直ちょっと面倒だなーと思ったりもしますが、
　行ってレッスンを受けてみると爽快で、そんな気持ちは吹き飛びますね。お腹も空いて、夜ご飯も美味しく食べられます。

・以前、当たり前のように行けていた食事や飲みの機会が減り、その貴重性を再認識するようになりました。
　今では、1回1回の食事や会話を大切にしようと思えるようになりました。

来年の目標は。。

・前代未聞のハンズオン形式のリモート海外演習を成功させること（英語な上にリモート、実機も使うと言う難関。。）

・ドクターのジャーナルを通すこと

・昇格できればいいな（社会人ドクターはお金がかかるのです。。）

・Active Directoryや制御システムセキュリティのサービスリリース（折角得たノウハウを多くの人に使ってもらいたい）

あたりですかね。

来年もよろしくお願いしますー！

こんなのあったのですね。。セキュリティの仕事していながら、初めて知りました。

The World's Largest Repository of historical DNS data

無料でサインアップすれば、過去のドメインとIPの紐付けが遡って見れます。

私のドメインの履歴もちゃんと出てきました（笑）

私が取る半年くらい前に誰か他の人がreverse-edge使ってたみたいです＾＾；

結構短スパンで明け渡されるもんなんですね。。

話は逸れましたが、DNSのクエリログって量が多いので、取るの大変なこともあると思いますけど、こういうツールがあると便利ですね！

記念すべき２本目のジャーナル論文"Detection of Malicious Tools by Monitoring DLL Using Deep Learning"が公開されました。

この論文は私はsecond authorなのですが、共同研究者と一緒に苦労して頑張った論文でもあったので、自分がファーストオーサーのジャーナルが再録された時よりも嬉しいくらいです。

東大の研究員としての活動の総仕上げとも言える論文で、研究員としての最初の一歩は、2007年のHitconでした。

プロセスがロードするDLLのリストを用いてmimikatzの実行を検知するというアイディアから始まり、それをmimikatzだけではなく複数の攻撃ツールに拡張した研究をIEEE AINS 2019で発表。

ここまではあまり苦労しなかったのですが、そこからが大変でした。。

改めて、ジャーナル論文のハードルの高さを思い知りました＾＾；

不再録になった際にいただいたレビュアーのコメントを反映して再投稿したところ、やっと条件付き再録で光が見えるも、レビューコメントの反映がむちゃくちゃ大変。。

コロナでリモートワークになり、修正の時間が持ちやすかったのが幸いでした（笑）

コメントに真摯に対応して再提出したところ、無事再録となりました。

諦めずに、方向性を踏み外さずに進んでいけば、良い結果が待っていると確信できました。

そして、何よりファーストオーサである共同研究者の挫けず技術的信念を貫いた姿勢が素晴らしいと思いました。

さて、また興味深そうなものが出ました。

Bronzeという言葉から、Golden/Silver Ticketを連想させますが、この脆弱性を悪用する攻撃が成立するには条件があるので、

Golden/Silver Ticket程の脅威はないと思います。

Kerberosの制約付き委任(Constrained Delegation)を設定している際に、攻撃者がService Ticketに細工をすることで、

ユーザが本来直接利用できないサービスを利用できるようになるという内容です。

委任(Delegation)の概念が少し分かりづらいのですが、本ブログの最後に張っているリンクを読んでもらうと分かると思います。

Webサーバのようなフロントエンドのサーバと、APサーバ/DBサーバのようなバックエンドサーバで構成されるサービスを想像すると分かりやすいです。

ユーザがWebサービスにログインする場合、Webサーバはユーザの認証情報を持っていないので、APサーバ/DBサーバにユーザを認証してもらうように問い合わせますよね。

この場合、WebサーバがAPサーバ/DBサーバに対して認証の委任を行うことになります。

つまり、サーバがユーザに代行して認証を行うようなケースを指します。

しかし、ユーザがWebサービスにログインできるのはWebサーバ経由でHTTPを通して利用できるのであって、直接APサーバ/DBサーバにSSHログインする様なことは普通できないですよね。

あくまで例えになりますが、本脆弱性を悪用すると、あるユーザアカウントとWebサーバを侵害した攻撃者が、直接APサーバ/DBサーバのOSにログインする様な事が可能になります。

技術的に正確な情報が知りたい方は、文末のブログをお読みください。

そもそも、攻撃が成立するのが制約付き委任(Constrained Delegation)を使用している場合なので、攻撃手法が公開されているとはいえ、影響は限定的かと思います。

AD環境と連携する他サービス（IISでWebサーバを立てているなど）がある場合は、調査が必要かもしれません。

12月にセキュリティ更新プログラムもリリースされており、ドメインコントローラに適用することで、攻撃者が細工したサービスチケットを作成することを防ぐ事ができます。

ただし、既に作成されてしまっている不正なサービスチケットについては、パッチ適用後も使えました。

（パッチではKDCのチケット検証の部分が修正されているそうなのですが、サービスチケットを使うときはDCにリクエストをしないからなのでしょう）

次回は、攻撃時に記録される痕跡についても別途発信しようと思います。

以下が攻撃手法の説明

CVE-2020-17049: Kerberos Bronze Bit Attack - Practical Exploitation

以下が脆弱性や攻撃の仕組みの説明

CVE-2020-17049: Kerberos Bronze Bit Attack - Theory