PDF Reader Risk Mitigation and Herd Mentality in IT Security Best Practice

The prevailing trend for security conscious system administrators and IT personnel nowadays regarding the risks that Adobe Acrobat PDF reader presents in the network is to dump the entire PDF reader application in favor of another.

This trend is an attempt to accomplish Risk Avoidance. Risk Avoidance is a Risk Management Method wherein you terminate the activity that is introducing the risk. In short, no need to implement and keep track of your Risk Mitigation process since there is nothing to keep track of in the first place. No Adobe PDF Reader, no risk. And why worry about Adobe PDF Reader Zero-Day exploits when you can use another PDF reader that is not affected by such vulnerabilities? Ok, that sounds logical and you may have a point Mr. IT Admin Sir, but please listen.

Enter Foxit PDF reader, the leading candidate and alternative for Adobe's dominant PDF Reader. However, converting your entire company to Foxit PDF reader does not guarantee 100% Risk Avoidance. The Top 2 misconceptions about Foxit PDF Reader are the following:

1. Foxit PDF Reader does not have Javascript (Who needs Javascript on a document reader anyways?!)

>False. Foxit PDF Reader (the most recent version in time of this writing is 3.1.1.0901) also has Javascript and as a matter of fact, is also enabled by default during first installation. So go ahead and disable that damn Javascript by going to Tools>Preferences>Javascript and remove the check mark to disable it.

2. Foxit PDF Reader doesn't have exploits and vulnerabilities like Adobe PDF Reader.

>False. Although Adobe PDF Reader leads in scoring when it comes to exploits and vulnerabilities (Like 10 Exploits Adobe PDF Reader, and 2 Exploits Foxit PDF Reader) Foxit has its own share of bad apples. From Buffer Overflow Exploit to Remote Denial of Service Exploit, yes, Foxit is also prone to PDF-related exploits and vulnerabilities.



It won't take long for malware authors and security researchers to create new and more exploits targeting alternative PDF readers such as Foxit PDF Reader. The same rule applies when dumping Adobe PDF Reader in favor of another; patch your applications and systems on a regular basis, keep tab of Zero-Day exploits. Enforce your company or organization Policies, Standards, Baselines, Guidelines and Procedures to the full extent but not to the point that you lose your sanity in the process, and your co-workers start tagging you as control freak.

Although I find random on-the-spot, casual conversation, Security Awareness Training the best tactic one can employ inside the workplace. So every morning, while lining up for coffee at the pantry room, go ahead and break some "cool" and "leet" IT security news to your fellow workers, they will enjoy it as long as you tell the story like how movies tell them. Avoid jargon and acronyms please and make it exciting. Think Quentin Tarantino directing a hacker-movie.

Bruce Schneier made an excellent point on his speech about "The Future of the Security Industry: IT is Rapidly Becoming a Commodity" on a recent OWASP Meet. Bruce mentioned that the trend nowadays with IT security is slowly turning into a somewhat herd mentality. They are doing it, so let's do it, that kind of thing. Even current Best Practices recommended by the community is suffering from such herd-mentality syndrome. I somehow agree on this notion since everywhere I go and every material I read describes a Best Practice guide which usually doesn't always apply to all.

We need to treat each system, no matter how closely it resembles other systems, as a unique system with a different set of variables and behavior. So please, stop treating those Best Practice Guides as your bible and study your network how it behaves.

Cheers!
Ron

Sources:
1. "Handling Risk" Page 107, Chapter 3: Information Security and Risk Management, All-in-One CISSP Exam Guide 4th Edition by Shon Harris, CISSP, MCSE
2. Bruce Schneier: The Future of the Security Industry: IT is Rapidly Becoming a Commodity, http://vimeo.com/groups/owaspmsp/videos/6495257
3. Open Web Application Security Project (OWASP), http://www.owasp.org/index.php/Main_Page
4. http://www.schneier.com/

Steganography meets VoIP in hacker world

An excellent way to hide messages or malicious payloads, making use of the unused UDP-RTP bits on a voice stream. I bet I can see the malformed or modified part of the RTP stream on Wireshark! Back to the lab for some tests!

Complete details on the link below.

Steganography meets VoIP in hacker world
Posted using ShareThis

Have fun inserting stuff on those unused bits!
Ron

"Daemon" by Daniel Suarez.

A must-read for everyone interested in the future of AI, automation and technology in general.

This novel is awesome. All the enumeration, sniffing and penetration methods and tools used in the story are all real and up-to-date. A computer game software genius dies and leaves behind the best AI ever created and a kick-ass "daemon" process to automate things. How do you fight evil packets? Go figure it out how the rest of the story unfolds.

So for a change, get out of your chair, away from your computer monitor and pick up the book from the nearest bookstore t. Currently enjoying the Audio Book version for my second reading of the book, and drooling of having my hardcover copy signed by the author.


http://thedaemon.com/

Below is a brief E-mail exchange with the genius behind the book, Daniel Suarez:

Excellent novel Daniel, looking forward to Freedom (TM).

One question though, regarding this line from the novel:

"So far, Gragg had a cache of nearly two thousand high-­
net-­wort identities to sell on the global market, and the Brazilians and Filipinos
were snapping up everything he offered."

Does this mean that based on your research (and statistics), most of these bad guys lurking around IRC channels are either from Brazil or the Philippines?

I am a Filipino residing here in the Bay Area and I am into VoIP Security, and overall IP-based Systems Security as well.

All the best,
Ron

+++

Hi Ronald,

Thanks for the kind note. I'm glad you enjoyed Daemon.

When I wrote Daemon back in 2004, Brazil and the Philippines were big
centers for identity theft; however, much of that has since moved to other countries. With the rise of botnets, though, it's increasingly difficult to tell where exploits and penetrations originate (with zombies serving as proxies...).


Best,
D.S.

+++

Daniel,

Agreed, 2004, those where the days. Now the Philippines is into hosting Call Centers
(and exploiting them) and Brazil is into US-Satellite tapping, lol.

Do you mind if I post your reply to my blog? (http://packetboyperseus.blogspot.com) I am planning to put up a simple personal review so my network of friends can see it and eventually pick it up from the nearest bookstore. I am sure they will love it as well.

All the best,
Ron

Hi Ronald,

My main point is that the future of cyber warfare is going to be driven by botnets and
distributed attacks originating from small groups of individuals (not
nations).

I don't want to sound like I'm 'blaming' that on Russians,
Brazilians, or Filipinos. The root cause of our IT security problem is
the inherently open architecture of global networks and the monoculture
that is modern software.

There are now cyber criminals and cyber warfare
units all around the world, and solving the infrastructural issues is
more important than playing international whack-a-mole with would-be
perpetrators--no matter what country they hail from.

Best,
D.S.

+++

Tracing packet drops in Florida and sniffing traffic from 35K feet

I recently traveled to Hollywood, Florida for a customer on-site network troubleshooting. We usually do things over the phone and remote access if needed, but this customer insists that its our VoIP application acting up, and not their network. So the next day I went to their facilities, met with one of their IT Staff and immediately started mapping out their wired network (for fun and profit).



After a couple of minutes of tracing un-labeled RJ45 cables and network devices in general, I was able to trace the root cause. The bottleneck is originating from a commercial firewall installed on their network. I am not going to identify the brand and model, but its one of those firewall not meant to handle tremendous amount of traffic. In short, its a small-office-home office firewall/router. Their facility generates around 12 to 20mbps of outbound traffic on a daily basis.

This firewall goes gaga when hit by too much traffic; it simply drops all concurrent connections and resets as evident on the firewall and router logs. Good thing their Network Admin made the right choice and decided to get hold of a Cisco ASA 5505 Security Appliance and replace their current firewall. The problem is this guy does not know how to configure the ASA and needs to outsource the configuration and installation, so the ASA needs to wait while the problem still persists on their converged network.

To add salt to the wound, they are using old-school workstations; running Celeron 2.0ghz processors with a measly 256mb of SDRAM. Understand that these workstations handle a softphone-based VoIP client, a web-based CRM, Instant Messaging client, and Agent productivity apps. I say good luck with that. As suspected, Agents usually encounter the white screen of death where everything halts and freezes, hitting the Reset button is their usual routine.

Add the workstation hardware issues and misconfiguration on the network and you get a very painful and regretful VoIP experience.

Knowing how painful this experience is to their Agents, what I did was strip down Windows XP Pro to the bare minimum to free additional memory and overall system resources. What I meant with a stripped-down version is by disabling all Local Services that are not needed, adjust the workstation to Best Performance, disable tons of start up and running applications via msconfig, and finally, lock down the Agent login to Limited Rights so they can't install those nasty shopping IE add-on toolbars, lol. Things you must do when no Domain Controller is not present on a large network.

On my way back home to the Bay Area, I had some fun on-flight thanks to Gogo In-flight Internet without actually signing up for their service.

Thanks to Wireshark, ZenMAP GUI, and my laptop's Intel(R) Wireless WiFi Link 5100 card I was able to take a glimpse of the WiFi activity on-board the plane.

Intense Scan plus UDP output on NMAP:

nmap -sS -sU -T4 -A -v -PE -PA21,23,80,3389 172.19.131.2

Starting Nmap 5.00 ( http://nmap.org ) at 2009-09-03 16:40 Pacific Daylight Time
NSE: Loaded 30 scripts for scanning.
Initiating ARP Ping Scan at 16:40
Scanning 172.19.131.2 [1 port]
Completed ARP Ping Scan at 16:40, 0.22s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 16:40
Completed Parallel DNS resolution of 1 host. at 16:40, 11.39s elapsed
Initiating SYN Stealth Scan at 16:40
Scanning 172.19.131.2 [1000 ports]
Discovered open port 80/tcp on 172.19.131.2
Completed SYN Stealth Scan at 16:40, 5.05s elapsed (1000 total ports)
Initiating UDP Scan at 16:40
Scanning 172.19.131.2 [1000 ports]
Completed UDP Scan at 16:40, 4.26s elapsed (1000 total ports)
Initiating Service scan at 16:40
Scanning 1001 services on 172.19.131.2
Service scan Timing: About 0.40% done
Service scan Timing: About 1.50% done; ETC: 18:43 (2:00:31 remaining)
Service scan Timing: About 3.00% done; ETC: 18:13 (1:29:33 remaining)
Service scan Timing: About 4.50% done; ETC: 18:02 (1:18:15 remaining)
Service scan Timing: About 5.99% done; ETC: 17:57 (1:12:09 remaining)
Service scan Timing: About 7.49% done; ETC: 17:54 (1:08:07 remaining)
Service scan Timing: About 10.39% done; ETC: 17:43 (0:56:12 remaining)
Service scan Timing: About 10.49% done; ETC: 17:50 (1:02:43 remaining)
Service scan Timing: About 13.39% done; ETC: 17:43 (0:54:02 remaining)
Service scan Timing: About 13.49% done; ETC: 17:48 (0:58:55 remaining)
Service scan Timing: About 16.38% done; ETC: 17:43 (0:52:03 remaining)
Service scan Timing: About 16.48% done; ETC: 17:47 (0:55:49 remaining)
Service scan Timing: About 19.38% done; ETC: 17:42 (0:50:03 remaining)
Service scan Timing: About 19.48% done; ETC: 17:46 (0:53:11 remaining)
Service scan Timing: About 22.38% done; ETC: 17:42 (0:48:06 remaining)
Service scan Timing: About 28.37% done; ETC: 17:42 (0:44:16 remaining)
Service scan Timing: About 34.37% done; ETC: 17:42 (0:40:29 remaining)
Service scan Timing: About 40.36% done; ETC: 17:42 (0:36:45 remaining)
Service scan Timing: About 46.35% done; ETC: 17:42 (0:33:01 remaining)
Service scan Timing: About 52.35% done; ETC: 17:42 (0:29:19 remaining)
Service scan Timing: About 58.34% done; ETC: 17:42 (0:25:37 remaining)
Service scan Timing: About 64.34% done; ETC: 17:42 (0:21:55 remaining)
Service scan Timing: About 70.33% done; ETC: 17:42 (0:18:13 remaining)
Service scan Timing: About 76.32% done; ETC: 17:42 (0:14:32 remaining)
Service scan Timing: About 82.32% done; ETC: 17:42 (0:10:51 remaining)
Service scan Timing: About 88.31% done; ETC: 17:42 (0:07:10 remaining)
Service scan Timing: About 94.31% done; ETC: 17:42 (0:03:30 remaining)
Service scan Timing: About 98.90% done; ETC: 17:43 (0:00:41 remaining)
Completed Service scan at 17:42, 3688.53s elapsed (1001 services on 1 host)
Initiating OS detection (try #1) against 172.19.131.2
NSE: Script scanning 172.19.131.2.
NSE: Starting runlevel 1 scan
Initiating NSE at 17:42
Completed NSE at 17:43, 36.19s elapsed
NSE: Starting runlevel 2 scan
Initiating NSE at 17:43
Completed NSE at 17:43, 5.02s elapsed
NSE: Script Scanning completed.
Host 172.19.131.2 is up (0.0014s latency).
Interesting ports on 172.19.131.2:
Not shown: 1000 open|filtered ports, 999 filtered ports
PORT STATE SERVICE VERSION
80/tcp open http?
| html-title: Site doesn't have a title.
|_ Did not follow redirect to http://airborne.gogoinflight.com/abp/page/abpDefault.do?REP=127.0.0.1&AUTH=127.0.0.1&CLI=172.19.131.153&PORT=54273&RPORT=54272&acpu_redirect=true
MAC Address: 00:E0:4B:22:96:D9 (Jump Industrielle Computertechnik Gmbh)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.18 - 2.6.27, Linux 2.6.26
Uptime guess: 0.405 days (since Thu Sep 03 07:59:45 2009)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=197 (Good luck!)
IP ID Sequence Generation: All zeros

Host script results:
|_ nbstat: ERROR: Name query failed: TIMEOUT

Read data files from: C:\Program Files\Nmap
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 3757.66 seconds
Raw packets sent: 4045 (148.498KB) | Rcvd: 31 (1502B)

Wireshark Capture Screenshot:



Noteworthy discovered Protocols and Services gathered from the Wireshark .pcap capture:

- Cisco IP-SLA
- TACACS and XTACACS
- BOOTP
- TFTP
- CLDAP (Connectionless Lightweight Directory Access Protocol)
- Cisco Wireless LAN Context Control Protocol
- Mobile IP Protocol (RFC 3344)
- RIP (Routing Information Protocol)
- OpenVPN
- OCSP (Online Certificate Status Protocol)
- Slimp3 Communication Protocol (Device ID: 101) (Firmware Revision: 6:12 (0x6c)
- Base Station Subsystem GPRS Protocol (BSSGP)
- CFLOW (Cisco NetFlow/IPFIX)
- CUPS (Common Unix Printing System)
- GPRS Tunneling Protocol (GTP)
- H.225.0 RAS

Discovered Network Device Signatures/MAC OUI's:

- JUMP INDUSTRIELLE COMPUTERTECHNIK GmbH (00:e0:4b)
- Hon Hai Precision Ind. Co., Ltd. (00:22:69)

You can easily Google those two identified manufacturers and you will have and idea what type of devices they produce.

As always, hit me up on E-mail if you want a copy of the complete .pcap capture and I will be glad to send you a copy, for research and analysis of course. Let me know if you guys need additional information as well about my recent 35K feet packet-sniffing adventure.

On my next flight, I am bringing an external USB antenna with packet-injection capability :-) attached to my future 1000HE netbook.

Happy packet-sniffing everyone and try not to break any law in the process!
Ron

Source Codes for a Skype Eavesdropper Trojan Released for Public Viewing

Skype trojan sourcecode available for download.

Aug 25th, 2009 by carrumba

As announced some weeks ago the Skype trojan sourcecode will be available for download. You find the source packages in the Tools & sources section if you are the impatient type.

The code is simple and straightforward. You have know malware development is no rocket science and if you expect big magic you are at the wrong place. The backdoor receives instructions from the dropzone and transferres audio files. The Skype-Tap intercepts the Skype function calls, extracts and dumps audio data to files, converts it to the mp3 format and encrypts it.

The code is not 100% complete. I removed the plugin system in the backdor and also the firewall bypassing system is not there anymore. I will publish both of them in separate tools later. If you don’t like this … well, I can’t help you. Thats how it is. Take it or leave it.

As always I am open for your opinions and criticism.



Complete article and technical details from Megapanzer's website:

From http://www.megapanzer.com/

The day my box almost got 0wn3d by Chinese boxes

Last month, I moved to a new apartment and decided to hook-up a high-speed Cable Internet from Comcast (as openly documented on this very same blog) as my primary connection to the world wide weird. This was July 15 and I was working at home that day.

With no router or a switch at hand yet, my Sony Vaio VGN-BZ560 laptop is connected directly to Comcast's modem, getting a dynamic Public IP address from time to time. Something exciting happened right in front of my eyes as my Symantec Endpoint Protection software started displaying notification windows, stating a couple of Intrusion Prevention logs. I immediately accessed the Client Management Logs - Security Log feature of Symantec's Endpoint Protection and here's what I found:

[SID: 20081] MS SQL Stack BO detected.
Traffic has been blocked from this application: C:\Program Files\Microsoft SQL Server\90\Shared\sqlbrowser.exe

Traffic from IP address 58.51.89.122 is blocked from 7/15/2009 1:33:12 PM to 7/15/2009 1:43:12 PM.

Active Response that started at 07/15/2009 13:33:12 is disengaged. The traffic from IP address 58.51.89.122 was blocked for 600 second(s).

I immediately launched my Wireshark to capture the network interface, then went inside Symantec Endpoint Protection's Client Management - Security Logs and turns out the attack has started since 5AM this morning PST!

Here are the logs of the first attempt:

[SID: 20081] MS SQL Stack BO detected.
Traffic has been blocked from this application: C:\Program Files\Microsoft SQL Server\90\Shared\sqlbrowser.exe

Traffic from IP address 218.23.37.51 is blocked from 7/15/2009 5:48:38 AM to 7/15/2009 5:58:38 AM.

The logical thing for me to do is to trace where these IP addresses are coming from. So I made a few back traces using my VisualRoute Tool and surprise! Surprise! Yes, the IP addresses are all from China.

The source IP's are all from China, if the back trace is reporting it correctly and these attackers are not using some mechanism to hide their real location, or probably just a bunch of compromised boxes or BotNets serving their master somewhere here in the States. But my guts keep on telling me that these are really coming from China.

My Sony Vaio Laptop is running Windows XP SP3. Installed is Microsoft Office 2007, with Microsoft SQL Server 2005 pre-installed which is the backdoor of this attack based on the Symantec Endpoint Protection Security Logs.

I am sure that my MS SQL Server 2005 service is not running on the background as a Service on my laptop turns-out that our new customer network connectivity troubleshooting tool called PathView by Apparent Networks is using a Local SQL Server Service on my laptop as well. By virtue of logic, I believe this application gave another backdoor for this MS SQL based vulnerability.

Below are actual screen shots while the attack is occurring:

(Click on the images to enlarge them)

Symantec Endpoint Protection Client Management Logs - Security Logs

PathView SQL Server running as a Local Service

Wireshark capture while the attack is happening

Let me know if you guys need a copy of the actual Wireshark capture (.pcap file) for analysis, I have no problem sending it out.

So what have I learned from this? Always double-check your new machine what applications are pre-installed on it, as well as ensure that unnecessary Services are not running on the background. This happened to me because I got lazy when the new Sony Vaio was handed over to me from work and I did not bother hacking into it like what I usually do with my personal machines.

Peace out and spread the word.

The madness stopped on the 4th day: My Comcast Hell

It took them 4 days in total, to resolve a simple physical connection problem. Turns out that my actual cable was disconnected. The apartment located on the 2nd floor got disconnected from their Comcast Service so someone from Comcast Provisioning disconnected them. They did not even check that the connection was originating from a splitter, one goes to the apartment on top of me, one goes to my apartment. They disconnected the entire cable feed. Another epic provisioning to on-site tech coordination FAIL.

My savior on my 4th day in fire and brimstone of zero Internet was a good-natured on-site tech guy named Tom. Tom was a classic good-ol'-American gentleman. He reminded me of those 1950's to 60's Handymen portrayed on television. He has a cool utility belt with all the tools he need, he has a cool mustache and beard, and sports an old-school baseball cap. He was a little bit odd with his seemingly non-sense gibbering while tracing the coax cables from my living room all the way outside the veranda but one thing is for sure, he knows his craft. He knows how to pacify someone who has been deprived of their connection for days by virtue of hard-work and results. Comcast Tech Support people should take a page out of Tom's book of work ethics.

All work, less talk. No promises.