|
Juniper have just released a product security alert regarding their NetScreen / ScreenOS devices. During an audit, it was discovered that their source code was compromised and an unknown attacker planted a backdoor within the firewall code.
The backdoor permitted: 1. Unauthenticated remote administrative access over SSH or telnet. 2. IPSec VPN traffic decryption (possibly by leaking private keys to the attacker). Detailed information can be found in JSA10713. Am I vulnerable? The ScreenOS firmware was compromised in August 2012. Only ScreenOS versions 6.2.0r15 to 6.2.0r18, and 6.3.0r12 to 6.3.0r20 are known to contain the backdoor. If you are running a version number below this release, earlier than August 2012, then your network should be secure. Juniper recommends that anyone using these firmware versions should upgrade immediately. Fixes are included in: 6.3.0r12b, 6.3.0r13b, 6.3.0r14b, 6.3.0r15b, 6.3.0r16b, 6.3.0r17b, 6.3.0r18b, 6.3.0r19b CVE-2015-7755 has been assigned for this issue. This is a timely reminder to employ "defence in depth" techniques, such as installing layered firewalls from different vendors, to protect your internal assets in the event one is defeated. Have a safe and relaxing holiday season, Introduction
Often you will find yourself in a situation where you can upload arbitrary content to a web server. If the webserver accepts dynamic content (e.g. ASP, PHP, EXE, PL, etc) then you may want to upload a "backdoor shell" to provide a web based GUI for the command line. Method Examples include;
Recommendation None - however keep in mind the following: 1) The backdoor shell may be trojaned. Read the code FIRST! 2) Don't leave it there for too long, as someone else may find it or worse - Google may index it! 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! |
Archives
September 2017
Categories
All
|
RSS Feed
|
NSW Government ICT Services (SCM0020) approved supplier
|
|
|
|
|
|
|
|
OSI Security is proud to support a number of recognised charities, development projects and industry groups...
|
|
|
|
|