|
The NSA ShadowBrokers exploit leak included a tool known as “BenignCertain” which triggers an information leak which may result in credential and private key disclosure to unauthenticated parties. Cisco IOS routers, PIX and ASA firewalls with VPN IKE IPSec enabled may be affected.
The NSA toolkit's bc-genpkt, bc-id and bc-parser binaries can be used to generate vulnerability triggering packets, send the packet and store the response, and parse the information leak to reveal VPN credentials such as username and password. Alternatively, the Metasploit Framework contains a module to scan for and trigger this vulnerability known as cisco_ike_benigncertain. Example: The device appears to leak RAM contents when the fault is triggered: 0000 00 00 00 00 00 00 00 02 00 00 00 00 00 00 2e e0 0010 00 00 2e e0 12 a1 fb 48 00 00 00 00 00 00 00 00 0020 00 00 09 ec 00 00 09 d0 00 00 00 01 01 00 00 0e 0030 00 00 09 c4 00 00 00 01 00 00 00 01 0b 83 d4 d4 ... [ snip ] ... 0470 0f ff ff ff 0f ff ff ff 00 00 00 00 00 00 00 00 0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0490 00 00 00 00 00 00 00 06 A1 44 93 40 00 00 00 00 When conducting subsequent tests, the memory bytes disclosed appear to change which indicates that this is likely vulnerable. Non-Cisco IPSec devices to not dump excessive bytes when responding to the vulnerability trigger (e.g. 10 bytes vs 2500+ bytes for vulnerable devices device). However, it is important to note that the usable exploit only affects Cisco PIX devices. This device may be vulnerable but due to slightly different implementation may be leaking less valuable information to an attacker or requires tweaking using the NSA bc-genpkt tool. Recommendation: Ensure the latest patched IOS firmware is installed. If the firmware is confirmed as vulnerable, the preshared VPN keys should also be changed and private keys on the device should be regenerated. Risk: High. Please be aware there is a Samba remote code execution vulnerability that has been published today in Metasploit and mass exploitation is likely to follow or be used to self-propagate in the form of a worm.
The vulnerability affects all versions of Samba over the past 7 years, the open source Unix/Linux implementation of the Microsoft File and Print Sharing service, and a patch was released yesterday. The vulnerability is triggered by connecting to a writeable file share (it can be abused as an anonymous user or with credentials) then uploading a Unix .so shared object file which is then executed on the server. Many Linux and Unix based operating systems are vulnerable, as are products like NAS (Network Attached Storage) file servers such as Synology, mediacentres and modems etc. CVE-2017-7494 has been assigned to this issue and reports indicate over 100,000 internet accessible systems are currently vulnerable. If you are unable to patch immediately, the vulnerable feature can be disabled by setting the 'nt pipe support = no' directive within the /etc/samba/smb.conf file and restarting the service. Many of you would have seen our anti-malware solution test website known as WICAR (think EICAR AV Test File, but for web based attacks).  This is just a quick email to let you know we now have SSL enabled for our test malware attacks, so not only can you test your firewall, IDS/IPS, proxies, content filtering and desktop antivirus, but you can also check if you are protected against payloads delivered over HTTP/S or verify your SSL-inspection products are working. Simply open the Test Malware page and click the [SSL] hyperlink to conduct the test over SSL to ensure your organisation is adequately protected (most attacks today are delivered over SSL to get around proxy inspection).  Introduction:
At some point you may be required to audit the configuration of a SonicWALL device. If you have physical/admin access to the management interface, then this is probably the easiest method - drill down every option and check for misconfiguration. If not, obtain a configuration export file (file name is generally 'sonicwall-name-date.exp') such as sonicwall-SydneyDC-20100607.exp. You will notice the file is a single line of Base64 encoding. Method: Either use software such as nipper (a tool to automatically decode multi-vendor firewall, router, switch etc.. configurations then analyse the settings and make recommendations in a pretty report) or Base64 decode it yourself and read the variables. Linux: 'base64 -d file' Windows (if you have ActiveState Perl): 'c:\bin\decode-base64.bat file' Recommendation: Often issues such as SSH v1 and SNMP will be present. Also check the firmware as SonicWALL is notorious for format string bugs. Over the past 6 months, a new rootkit known as Max++, ZeroAccess, Sirefef (and others) has been impacting a significant number of businesses and home users.
Recently, OSI Security responded to a client affected by this malware:
To fix this issue, the TCP/IP stack needs to be working (check Device Management, Hidden Devices and TCP/IP may have the yellow exclamation mark if the device is not working). In our situtation, TCP/IP would not start because a group dependency failed. The IPSEC Service wouldn't start, and a check of the system32\drivers directory showed ipsec.sys driver was missing. To fix, get the ipsec.sy_ (cab) file from the Windows CD-ROM in the i386 directory and extract it to C:\Windows\system32\drivers\ipsec.sys. For example, go to Start -> Run -> cmd.exe, then in the command prompt type (assuming D:\ is your Windows install CD). extract d:\i386\ipsec.sy_ c:\Windows\system32\drivers\ipsec.sys If the above command worked as expected, you should now be able to go to Services (services.msc) and start the IPSEC Service. If it started as hoped, you should now reboot and find that the issue with ipconfig / the network adapter not being able to obtain an IP address is now resolved. If not, consider doing the same extract for tcpip.sy_ and doing a 'netsh ip reset all' and 'netsh winsock reset catalog' then rebooting. Once we resolved this matter, we encountered another issue:
This occurs because the Microsoft Windows TCP/IP stack or Winsock API is corrupted. Specifically, the nslookup tool works because it is sending DNS lookup information directly across the wire, whereas everything else uses the Windows host operating system's Winsock gethostbyname() API which is broken. To fix, firstly reboot into the Microsoft Windows Recovery Console, then (where D:\ is the Windows install CD-ROM); expand D:\i386\dnsapi.dl_ C:\Windows\system32\dnsapi.dll expand D:\i386\dnsrslvr.dl_ C:\Windows\system32\dnsrslvr.dll Reboot and you should find that nslookup, ping, Internet Explorer etc is now functioning as expected. Note 1: Under normal Windows, the command is 'extract' to extract a CAB file (the .sy_ or .dl_ files). Under the Recovery Console, the command is 'expand'. Using either is fine for ipsec, tcpip, dnsapi, dnsrslvr files however you will likely find using 'extract' is denied as the destination file is in use by Windows and cannot be replaced - thus, you may wish to use the Recovery Console and 'expand' for all 4 files to avoid the file in use / access denied message. Note 2: We observed other users with similar issues i.e. nslookup works but ping does not. The above dnsapi.dll and dnsrslvr.dll replacement should in theory resolve the issue, irrespective of presence of any malware. Worth trying.. Good luck! Introduction
Visit www.openspf.org for more information on this technology. Method It is held within a TXT record for the domain. You can query this with the host command under Linux/POSIX. $ host -t txt [victim].com [victim].com descriptive text "v=spf1 a mx include:[victim].com" Recommendation Consider adding SPF records to allow MX records to send email. SPF helps prevent forging of the FROM address on the receiver end. Customer MTAs which support SPF will reject fraudulent emails because the SPF record will not match the spammers IP source addresses when forging @[victim].com FROM addresses. Maltego is an open source intelligence and forensics application. It will offer you timous mining and gathering of information as well as the representation of this information in a easy to understand format. Coupled with its graphing libraries, Maltego allows you to identify key relationships between information and identify previously unknown relationships between them.
It can be utilised in searching for the following (entities): * Autonomous System Number * DNS Name * Domain * Email Address * IP Address * Location * MX Record * NS Record * Netblock * Person * Phone Number * Phrase * URL * Website It is offered in 2 editions which are Commercial edition and Community edition. Community edition can be downloaded from the following link: http://www.paterva.com/web4/index.php/client/community-edition It is also available as a built in tool with the current backtrack editions. The following link describes in detail the process of finding information about people and organisations using Maltego in 2 parts. http://www.ethicalhacker.net/content/view/202/24/ Introduction
By default BIND DNS reveals the version number when queried for a certain TXT record. Command # dig chaos txt version.bind @ns.[target].com Result An example is below: ; <<>> DiG 9.7.1-P2 <<>> chaos txt version.bind @ns.[target].com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18628 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "9.3.6-P1-RedHat-9.3.6-4.P1.el5" ;; AUTHORITY SECTION: version.bind. 0 CH NS version.bind. ;; Query time: 329 msec ;; SERVER: [ip]#53([ip]) ;; WHEN: Sat Aug 21 03:55:28 2010 ;; MSG SIZE rcvd: 87 Recommendation Using the 'version' directive in the 'options' section will block the 'version.bind' query - usually in /etc/named.conf. Introduction
If a PPTP service has been detected, as part of the protocol the software (and/or hardware) vendor is meant to disclose this information. Generally the server hostname is also revealed, which may aid in an attack. Method There are many ways to determine this, but a simple scenario would be to create a new "dial-up" connection within Windows with a connection type of VPN -> PPTP and connect whilst running a Wireshark packet capture. By following the captured stream within Wireshark and looking at the protocol dissector, the vendor and hostname will be disclosed. |
Archives
September 2017
Categories
All
|
RSS Feed
|
|
|
|
|
|
|
|
OSI Security is proud to support a number of recognised charities, development projects and industry groups...
|
|
|
|
|