root権限を取り返したい - イントラサーバー奮闘記録

0日目

私は自宅用に外部公開していないUbuntu Serverを運用しています。
時折SSHでログインしてsudo apt update && sudo apt upgradeとかWinSCPでファイル操作しているのですが、ある日こう思いました。

root所有のファイルに触れないのがめんどくさい

そこでなんとなく自分がrootグループに所属してれば解決する気がしたので、少し検索してこのコマンドを入力しました。

$ sudo usermod -G root kurema

ここで私は3つ間違いを犯しています。

1. rootグループに所属したところでroot権限は得られない。得られるのも望ましくない。
2. rootグループに所属したところでパーミッションがrwxrwx---みたいなファイルしか触れない。大抵はrwx------とか。
3. usermodの-Gオプションは副グループが指定したものに書き換わる。追加したいなら-aG。

やらかしました。
この時は気付いていません。

(ただしsambashareグループは残っていたので何か別の操作をしたかもしれません。)

1日目

しばらくしてログインした時、sudoで以下のエラーが出ることに気づきました。

$ sudo apt update
kurema is not in the sudoers file. This incident will be reported.

ここでusermodコマンドを間違えたくさいと思い当たりました。
Ubuntu Serverではsudoグループに所属しているユーザーがsudoできます。
/etc/sudoersに書いてあります。adminでも良いようです。

しまった。現時点でsudo権限を持ったユーザーが居ない。どうしよう？
なんとかして誤魔化せないか。いや一般ユーザーがroot権限を普通に奪取出来たら脆弱性だ。
権限昇格系の脆弱性が公開されるのを待つか？いや待ってられないし実証コードとか絶対めんどくさいに決まってる。
考えろ。考えるんだ…。

まぁこの時点で解決策は分かっていました。
サーバーには物理アクセスできるわけですから、キーボードとモニターを刺してレスキューモードに入る、最悪ハードディスクを抜いて直接書き換えればどうにでもなる(ファイルシステムは暗号化していません)。
しかしそれは嫌でした。
なぜならめんどくさいからです。

そこで思い浮かびました。
確かcrontabでrootが毎日シェルスクリプトを回してる。
もうsudoできないので記憶頼みだけど確かそうです。
しかもkuremaが書き換え可能な権限持ってる！
やった。勝った！

というわけでシェルスクリプト末尾に以下の行を追加しました。

cd `dirname $0`
#...

usermod -aG sudo kurema

そして安心して寝ました。
cronは夜働くからです。

2日目

再びログインして、sudoを試しました。

$ sudo apt update
kurema is not in the sudoers file. This incident will be reported.

何も変わりません。groupsの結果も同じです。
スクリプト自体は動いた形跡があります。
とりあえずエラーか何かで途中で終了したのかもと考え、usermod行を末尾から先頭に移動しました。

ちなみにシェルスクリプトでは途中エラーが出ても普通に下まで実行するはずなのでこれは間違いです。
途中で終了させたい場合はset -eなどとしますが、今回してないので推測がおかしいです。
その辺はなんとなく分かってましたがダメもとです。

usermod -aG sudo kurema

cd `dirname $0`
#...

• シェルスクリプト内のエラーが発生した場所で異常終了したい
• bashスクリプトのエラー処理のベストプラクティス

3日目

再び試しました。案の定ダメです。
以前、cronでshutdownを実行するときrootでもsudo shutdown -r nowのように書かなければならなかったことを思い出し、sudo usermod -aG sudo kuremaのようにしました。
ないだろうなぁ。

sudo usermod -aG sudo kurema

cd `dirname $0`
#...

4日目

ダメです！
意味が分かりません。エラー文が見たいのでファイル出力を設定しました。
明日解決する可能性はないですが、原因は分かるはずです。
これは3日目にまとめてやったかも。

sudo usermod -aG sudo kurema > /home/.../usermod.log 2>&1

cd `dirname $0`
#...

5日目

ファイルを確認してみよう。
あれ、ファイルが存在しません。
シェルスクリプト自体が実行された形跡はあります。
これはおかしい…。

ここでいくつか推測。

1. ほぼ同一のシェルスクリプトが他の場所にあるのでそっちを実行してた…？←一行目がcd `dirname $0`(シェルスクリプトの場所にcd)なのでそれはないはず
2. セキュリティ上の理由で、シェルスクリプトはcrontab -e実行時のものがキャッシュされる仕組みがある？←そんな非直感的な仕様はないはず。調べてもなさそうだった。

違う。
そして思い出しました。
「そういやこれ、フォルダをdockerコンテナにvolumeでマウントして、docker内からシェルスクリプトを実行してる。」
忘れてた。

詰んだ。
これはもう素直にモニターを運んでつなげるしかないのでしょうか。
嫌だなぁ。

ただdockerはroot権限でファイルは作れるんだよな。
何かできないか？
ファイル作れても仕方ないしなぁ。

そうだ！
/etc/sudoers.d/をボリュームに追加でファイル作れるじゃん！
これで解決だよ。良かった。

というわけでdocker-compose.yml(これもkuremaが変更可能)を書き換え、シェルスクリプトも書き換え、寝ました。

version: '3'
services:
  nicochcgi:
#...
    volumes:
      - ./config:/etc/nicochcgi
      - /home/share/niconico:/media/niconico
      - /etc/sudoers.d:/media/sudoers.d #ここを追加

echo `kurema ALL=(ALL:ALL) ALL` > /media/sudoers.d/kurema
#...

• sudoを/etc/sudoers.d/fileで許可する

6日目

確認。変化なし。
考えてみるとdocker-compose.ymlを実行中書き換えても反映されないだろうし、コンテナ再起動が必要か。忘れてた。
サーバーごと再起動っと。

$ shutdown -r now
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to open initctl fifo: Permission denied
Failed to talk to init daemon.

そりゃそうだ。
再起動は確か日曜日にスケジュールしてたはずだ。
電源ボタンを押せば手動でできるけど、dockerが起動しなくなったりすると厄介なので待とう。

7日目

(再起動までの数日除く)

ダメ。慣れてきた。
そういえば、ボリューム追加にはあらかじめマウント先のフォルダを作ってないといけないかったような。
とりあえずフォルダを作るか。

mkdir /media/sudoers.d
echo `kurema ALL=(ALL:ALL) ALL` > /media/sudoers.d/kurema
#...

さすがにもう一週間は待てないので電源ボタンを押す。まぁ大丈夫だろう。

8日目

またもダメ。変化なし。
しかしなぜ動かないんだろう。
dockerはroot権限で動いて、作るファイルもroot所有…。
あ！

Ubuntu ServerのdockerはSnappyで動いてる！
Snappyだと/etcとかには直接触れないんだ！
思い出した…。そんなことあったわ。

うーん。何か手はないか。
…まぁないだろ。
サンドボックス下からsudo権限取れたら話にならんし。
dockerをclassicオプション付きで再インストールできれば良いが、当然sudoが必須だし。

• Snap(Snappy) コマンドの使い方

…諦めよう。

9日目

仕方ないのでキーボードとモニターを持って行ってサーバーに繋げました。
shutdown -r nowはなぜかsudoなしで動きました。直接繋ぐとOKなのかな？
まぁ目の前に電源ボタンがあるからsudo必須にする意味もないか。
(ちなみに下の作業前にインストールメディアから色々やろうとしたが、LVMのマウントが面倒だったので検索しなおした。)

1. 電源投入時Esc連打。
2. GRUBメニューが出たらnormalEnterすぐEsc。
3. Advanced options for Ubuntu選択。
4. Ubuntu, with Linux *.*.*(recovery mode)選択。2つあったがどっちでも良い。
5. ⁠root:Drop to root shell prompt選択。
6. ls /homeとかでサーバーと同じ環境で普通にマウントされてることを確認。念の為。
7. usermod -aG sudo kurema。groups kuremaで確認。

• 第639回　Ubuntuに「トラブル時に」ログインするいろいろな方法

終わり。
長かった。

毎日やったのは数行程度の作業だから「最初からこうすれば」ということはなかった。
数日sudo使えなくても実害はないし。
むしろモニターとキーボードをつないで作業するってのはホントめんどくさい。

というわけで奮闘むなしくシングルユーザーモードでログインして解決しました。
一番避けたかった(再インストールやHDD抜き差しという最悪の事態は回避できたとはいえ)結果に終わったのは残念ではあるけれど。

改めて攻撃者の立場で見てみると、結構やらかしてる点があるというのに気づきました。
最終的にroot奪取はできなかったけど、sudo権限を奪われてもrootでファイル操作は多少できていたし、docker-composeも書き換えられるし。
自分はsudo可能だから大して気にしてなかったけど本来はよろしくないね。
あと念のためレスキュー用ユーザーでも作っておくのも良いかなとも思いました。散らかるのでやらないけど。