Name | Modified | Size | Downloads / Week |
---|---|---|---|
Parent folder | |||
README | 2011-03-03 | 3.2 kB | |
NomNomAgent-v0.1.py | 2011-03-03 | 6.8 kB | |
Totals: 2 Items | 10.0 kB | 0 |
NomNom Proxy Contact: pasvninja [at] gmail[dot]com AIM: liquidlatency Website: http://nomnomproxy.sf.net/ Basic Description: Purpose: This will accomplish what Firesheep has to "educate" the IT community about the dangers of plaintext browsing and weak session handling methods. The final product will be so easy to use that anyone can install it and monitor/impersonate cookies from any network that the agents are installed in (windows version? :P). These flaws have been around for so long and the only way to make real change in the security community anymore is to raise the threat level of a given vuln. I know this is a negative view, but it is absolutely true (just look at Microsoft or any other big vendors' patch cycles). I want change, so excuse me, but we're all pulling our teeth out today. Why not just use Firesheep? Because firesheep was built for the purpose of one insecure network, and one browser and this project's scope is a little more wide to incorporate: ANY insecure network and ANY browser (that is any browser that supports proxies). Releases thus far: keep in mind this project is in its infancy, I've just been working on it a little bit in my spare time here and there. So far what has been released is purely Proof Of Concept. The original program I wrote to dissect HTTP traffic was actually built to monitor my own network but then I saw another use later. The design is as follows: an agent listens in on the local network capturing cookies, site info, and other relevant information. It then simulatenously connects to a dedicated port on the proxy server. This connection supports SQL inqueries to and fro the agent(s) and the proxy server. The user that has the NomNom proxy server on their system then sets their proxy settings accordingly to use said proxy and configures which session/identity will be used in subsequent HTTP headers. The proxy server basically adds or replaces cookies intercepted by the agent. By using this it essentially accomplishes what projects like Firesheep and others attempt but without a browser plugin. The technical details are still up to debate but my initial idea is as follows: NomNom Agent: -uses scapy to intercept/parse packets -sniffs on local LAN (optional arp poison? ettercap or scapy -keeps a local SQLite DB that stores (either in memory or on disk (for recovery)) a list of useful packet info: COOKIE, POST/GET query info, User Agent, <title>, host info, etc. The SQL logging is done on a separate thread that uses a priority queue to push up entries. -opens a socket on a TCP port to NomNom Proxy server that accepts commands. These commands are more dominantly SQL inqueries from the proxy server to sync up with their local db. This is also either forked or a separate thread. NomNom Proxy Server: -keeps its own local SQLite db of all the queries it caches from agent(s) -acts like a normal proxy but replace (or adds) cookie values to the HTTP header -provides a user interface via a webpage (ie: redirects control.com or whatever to a page that allows the user to select which cookies to use or which host to completely impersonate (session ID/user agent/etc) -