Pre-hijacking Attacksについてのメモ書きです。 元の論文と記事は次のページを読んでください。
Pre-hijacking Attacks はメールアドレスの確認をしないでアカウントを作れるサービスという前提があります。
アカウント作成からそのまま機能を利用できるようにすることで、利用体験をよくするための施策として、メールアドレスの確認のステップを後回し またはしないサービスがあります。
Security Advisories / Bulletins / vendors Responses linked to Log4Shell (CVE-2021-44228)
| ## AWS | |
| # from http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories | |
| http://169.254.169.254/latest/user-data | |
| http://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE NAME] | |
| http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE NAME] | |
| http://169.254.169.254/latest/meta-data/ami-id | |
| http://169.254.169.254/latest/meta-data/reservation-id | |
| http://169.254.169.254/latest/meta-data/hostname | |
| http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key |
トラップはよい機能だけど完全に信頼できるというわけではないよ。SIGKILLとSIGSTOPはトラップできない。
大昔のいくつかのUnixにはSIGKILLをトラップする怪しげな方法があった。もしプログラムがptraceされていたら、どのようなシグナルでも（SIGKILLでも）、そのプロセスを停止させてptraceをしている側のプロセスに通知するという動作になっていた。
そこで僕は"sh"という名前のプログラムを書いた。そのプログラムはメモリサイズを/bin/shと同じになるように注意深く調整したあと、fork & execして、子プロセスをptraceした。子プロセスは"superman"というプログラムだった。僕の偽shは、supermanが何らかのシグナルを受け取ると、そのシグナル番号をsupermanのメモリに書き込んだ後、つねにSIGINTでsupermanを再開するという動作になっていた。supermanのSIGINTハンドラはシグナル番号をみて面白メッセージを表示するようになっていた。
僕はそのプログラムを起動して、システム管理者のところにいって、何かプロセスがkillできないんだけど、と言った。システム管理者は^Cや^\を一応試した後、別の端末からログインしてrootになって、psでsupermanを見つけて、それをkill -9した。
「クリプトン星人にはSIGKILLは効かないぞ」と表示されてプロセスが動き続けているのを見た時の彼の顔といったらなかなかのものだった。
namespaces - overview of Linux namespaces http://man7.org/linux/man-pages/man7/namespaces.7.html
mount_namespaces - overview of Linux mount namespaces
| . | |
| .. | |
| ........ | |
| @ | |
| * | |
| *.* | |
| *.*.* | |
| 🎠|
これは Aizu Advent Calendar 2016 の 9日目の記事(遅刻)です．
http://www.adventar.org/calendars/1530
8日目: オフィスにいる人間をSlackに通知するやつ作った - 人権真骨頂
10日目: @mic_psm
As I've discovered, managing LXC containers is fairly straightforward, but when building out a system for provisioning out user maintained instances of NodeBB, it was imperative that unprivileged LXC containers were used, so that in the event of shell breakout from NodeBB followed by privilege escalation of the saas user, the root user in the LXC container would only be an unprivileged user on the host machine.
During the course of development, I ran into numerous blockers when it came to managing LXC containers in unexpected circumstances. Namely:
su or executing lxc-* commands as another user via sudolxc-* commands via a program, application, or script. In my case, a Node.js application.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.