by jan.monsch on December 21, 2006
in SBN
This week Websense reported the first Trojan using the Skype API as part of its evil workings. The currently available information does not tell us what the Trojan uses the Skype API for. As already discussed in the blog article “Proof-of-Concept Trojan using Skype API”, such a Trojan can hide its communication in the Skype network and no currently available content inspection technique will be able to cope with such a covert channel. Although the current Trojan will provoke a warning dialog from the Skype client, telling the user that a third party program wants to access the Skype API, it is most likely that adversaries will soon learn to bypass this warning using some Windows low-level API.
As we can see from the above screenshot the user can permanently enable access for a particular third party application. This prevents the warning dialog to be shown in future. If a user has accidentally permitted access or wants to know which applications have access to the Skype API, he or she can find a link called “Manage other programs’ access to Skype” in the section Privacy of the Skype Options dialog.
There he or she can view or modify the permissions for each individual third party application.
According to Bill Campbell’s article “Simple corporate security tip: disable Skype API and File Transfer“ there is a way to disable the Skype API using registry settings. The following registry key is officially documented in the Skype knowledgebase article 632. The policy prevents that any third party application can attach to the Skype API.
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Skype\Phone]
“DisableApi”=dword:00000001
In- and outbound file transfers can also be disabled by a registry setting. This is documented in the Skype knowledgebase article 631:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Skype\Phone]
“DisableFileTransfer”=dword:00000001
After applying the file transfer policy, an error dialog is shown to the user when he or she wants to send a file from a protected client:
When sending a file to a policy protected Skype client the file transfer immediately aborts and the following error is shown:
I have verified both registry settings and they both work. In a corporate environment this allows administrators to lockdown Skype. But it requires that the user does not have administrative privileges. Otherwise the Trojan can remove these entries again. Administrators must further ensure that the registry ACL does not permit users to modify these registry keys.
As a preemptive measure I suggest that companies, who do not have Skype deployed, should also deploy the above registry settings to their workstations using Windows Group Policies. This prevents the two most dangerous use cases where employees place the Skype executable onto their system without permission. It should be noted that Skype does not require any special privileges to run. Being an ordinary user is just enough.
by SOX Jockey on December 19, 2006
in SBN
Responding to my tag from
Mike, here are my top 10 security predictions for 2007. I've broken mine into 5 vulnerability oriented predictions, and 5 industry ones.
1. SCADA sploits will break out.
I am no SCADA expert, but if one tenth of what
Jim C says could happen does happen, things could get pretty ugly!
2. Virtualization will get own3ed.
The big push to virtualization will make it a juicy enough target that embarrassing vulnerabilities will be revealed in 2007.
3. Social Networking Sites will be patient 0 (over and over).
SNS are digital Bird Flu. Web worms will take this threat vector from the back page to the front page as repeated exploits are discovered and gain broad coverage.
4. Phishing will increase, despite strong efforts to curtail it.
Phishing is exploding, and even with phish bait warning widgets, regulation, and user education, you ain't seen nothing yet.
5. Vista will be the most secure Windows yet.
A bright spot in a sea of vulnerability predictions, Vista will have fewer defects than previous versions of Windows. But that doesn't mean zero defects or security vulnerabilities!
6. The glory days of security spend are behind us.
Business will hold steady or cut security spending in an effort to control compliance oriented costs.
7. Process, process, process.
Security spending will slant towards process control versus product acquisition. Metrics, oversight and control are in. Flashy objects are out.
8. Outsourcing is your friend.
There will be more security outsourcing in 2007 as specialization will enable cost controls that cannot be attained through DIY.
9. Auditors rule.
The driving force behind security and compliance initiatives will continue to be the auditors.
10. SOX pressures will not abate.
Despite the change in Congress, and my post that change might be coming, there won't be enough pressure to overcome the Democratic urge to regulate.
by SOX Jockey on December 15, 2006
in SBN
The mantra a few years ago was, "Everything is going to the web!" Companies, counties, agencies all rushed to put records and information online. Some states passed laws requiring documents like public legal proceedings to be put on the web.
This
article shows how the pendulum has swung. Now massive redaction efforts are needed to reel in personal, sensitive information from the public web.
What goes around comes around...
by jan.monsch on December 15, 2006
in SBN
In my review practice I often have to look at Java source code which is used to generate passwords, authentication tokens or session ids. Ever so often this code uses the Java API class java.util.Random to generate random numbers. It is well-established in security industry that this particular random generator is not secure. Since I did not know what the reason is for this perception I started to have a closer look.
During the review of the Java API source code I discovered two vulnerabilities which cause the internal state of java.util.Random to be partially exposed or easy guessable. The paper Ruining Security with java.util.Random demonstrates two techniques how security mechanisms based on java.util.Random can be attacked and under certain conditions can be broken within seconds. Using these weaknesses an attacker can synchronize into the stream of random numbers and therefore calculate all future random numbers. For security relevant code java.util.Random should never be used. At least the Java class java.security.SecureRandom with the default constructor should be utilized. This provides much better security.
If you know about other vulnerabilities in the design of java.util.Random or you know about vulnerabilities in java.security.SecureRandom I would be happy to hear about it.
by SOX Jockey on December 14, 2006
in SBN
This
article by Robert Reich talks about the imperative for globalization and innovation. Reich says that IT managers frequently think too much about security, and not enough about innovation. That is undoubtably true.
I think this is a possible way out of the regulatory black hole. Strive to make security the enabler for innovation, and you can assist in making the business safer *and* more dynamic.
by always peace on December 14, 2006
in SBN
Making business means taking risks. Risk management deals with exposures to specific threats that can take advantage of existing vulnerabilities and affect organisations. Enterprise risk management (ERM) consists of the processes used to manage risks in the enterprise.
Strategic (not defining and meeting objectives), market (negative interactions with the market), credit (exposure to non-payments) and operational risk (exposure to loss from internal processes, people, systems and external events) constitute ERM.
An ERM umbrella that is aligned with the business strategy helps the organisation achieve its objective.
Information is an essential asset for most organisations: it connects all risk management disciplines and, more broadly, most business processes use it. Information risk management, also called information security, is an element of operational risk.
There is a current tendency towards linking the information security activity (infosec) with the operational risk management (ORM) practice and, more generally, with the enterprise risk management activity.
The link between infosec and ORM disciplines can eventually play a positive role in constructing sustainable and superior benefits for organisations.
An overarching model is proposed to understand and manage the complexity of infosec and ORM in organisations: the ‘risk house’ model.
This model explains how to link the infosec practice with the ORM strategy and practice. It locates ORM within ERM and signals the pervasiveness of information and the need to develop information security and to link it with ORM.
The infosec-ORM link should always happen in accordance to the risk appetite of the organisation. ORM objectives can be significantly facilitated if both risk disciplines are aligned with the strategy of the organisation to achieve its objective.
A
survey of 82 experts provides two main conclusions: First,
management commitment, the degree of development of information security and the alignment of risk management with the business strategy (i.e. its strategic alignment) are strongly related to superior benefits achieved in organisations.
Second,
the three most probable superior benefits achieved are stakeholder value, new business opportunities and better compliance. These three benefits ultimately contribute to the responsible image of the organisation.
by Bill P on December 11, 2006
in SBN
Fine. I’ve not had anything of any consequence to chat about for a bit (other than trials and tribulations with a pair of teenage boys and maybe that of my grease car habits) – but this thread about Agents and Appliances is threatening to send me over the proverbial network edge. So – a level setting comment. I’m not knocking or promoting anyone’s particular technology or implementation. My
by jan.monsch on December 11, 2006
in SBN
Black Hat USA and DEFCON in Las Vegas are amongst the biggest IT security conferences in the world. This year Walter Sprenger and I had the opportunity to attend. Both events have been very interesting on their own merits. Whereas Black Hat is more directed towards the corporate IT users, DEFCON addresses the security geeks. For me Black Hat had the most interesting presentations and DEFCON proofed to be the better place to network with people.
The biggest topics this year at Black Hat were VoIP security, Windows Vista security and all flavors of phishing attacks (Phishing, Vishing, SMiShing). As users grow aware of e-mail based phishing they are likely to fall victim to phishing originating from other communication channels. Although web application security has been top agenda for IT security professionals for years, the situation does not seem to improve but rather worsens: Cross-Site Scripting based worms and Intranet attacks are the new kids on the block. With the large adoption of the AJAX concept new opportunities for attacks will arise. Interesting are the new advances in attacking WLANs and Bluetooth devices. At the DEFCON talks reverse engineering and privacy issues were the main topics. Of course the fun factor with all the contests (CTF, warwalking, lock picking, beverage cooling) has its own charm.
Walter and I have put together a document with the latest IT security trends (5.2 MB) we have picked up at the conferences. Some pictures have been added to give you an impression of both events. See the Black Hat USA 2006 and the DEFCON 14 proceedings for further details.
by jan.monsch on December 7, 2006
in SBN
Lately I came across several Citrix and Terminal Server projects which provide a restricted set of applications to their users. This is achieved using Windows Software Restriction Policies or AppSense Application Manager to white or black list executables.
One of these permitted binaries is often java.exe. Now the problem arises that once Java is enabled any Java application can be executed on the system. This allows a malicious user to execute arbitrary Java code, like replacement shells (JSH), RDP clients (Propero Java RDP) and network port scanners. I could block java.exe but business requires that the company’s Java application must still work. This lead me into this research on how to white list Java applications in a restricted Windows environment.
First of all Java has a mechanism called Java 2 Security which allows implementing policies based on code location or digital signatures. These policies are configured through the files java.policy and java.security. When java.exe gets executed these policies are not enforced by default. To enforce the restrictions the Java system property java.security.manager must included at the startup command line:
java.exe -Djava.security.manager MyCode
This property causes Java’s Security Manager to be installed and the policy to be enforced. So far so good. But how can I pass this parameter without having it to be specified on the command line? Well Java offers the environment variable _JAVA_OPTIONS. So I thought I place the parameter into a Windows system environment variable:
_JAVA_OPTIONS=-Djava.security.manager=
Testing revealed that java.exe can be executed with the Security Manager enabled without passing the parameter on the command line directly. Further testing revealed that when I start a cmd.exe as a low-privileged user I can overwrite this system environment variable and I can bypass the Java Security Manager using following command:
set _JAVA_OPTIONS=
I tried the same from within a Microsoft Word macro. The effect is the same. According to my research and feedback from Microsoft the system environment variables can always be overwritten within the process for the local process. In the paper Software Restriction Policies in Windows XP on page 13 in Chapter Analysis of Path Rule John Lambert writes:
Environment variables are not secure, and any user who can load a command prompt can temporarily redefine them.
So this melts down to my question: Is there a way to tell java.exe to always use the Java Security Manager without the possibility of manipulation by the user?
I would be very interested to learn your ideas. For those of you who want to play yourself I provide a ZIP archive with the files I used for testing. Please send your comments by mail to: jan.monsch ät iplosion.com. I will then write-up a post with the discussion results
by barry on December 5, 2006
in SBN
There is a great deal of gray area around Common Criteria Certifications . not because they is anything wrong with them, But the opposite - RFP's come out for answers without asking For any legitimate source of information about the capabilities Of the product they request.
What happens is as follows :
When a firm\company needs a technological product , lets just Say - a firewall. They put out the specifications they require And ask for a certain throughput , vpn abilities , content Inspection abilities and so on . The integration\product provider usually answers this RFP by Implementing best knowledge and whitepaper cut-outs .
In that way - the firm\company that requested the product May get a product that is cheap but answers for all required Technical specifications , but the product itself is poorly Implemented and written , the documentation of the product Says that it supports just about everything and that the Product is "very secure and hardened"
Common Criteria comes as a legitimate standard of checking The entire process of product development , deployment And benchmarking , therefore giving a certification to a Product in such a way - that a customer can rely assured that He is getting a product of at least a certain level of standard Checks.
The 7 different steps of the Common Criteria are known as EAL "Evaluation Assurance Level" and is marked as such :
A product that gained EAL level of 4 may get the certificate Of "EAL4 Certified".
Therefore When requesting an RFI\RFP - one should request An EAL level that is the minimum for this product . by that The company assures itself it gets a product that satisfies Its needs.
There is some great information at the common criteria portal
( "
http://www.commoncriteriaportal.org" ) . for instance You can read the user guide and get familiar with the different
Levels of EAL and the ways each level is checked at :
http://www.commoncriteriaportal.org/public/files/ccusersguide.pdfhttp://www.commoncriteriaportal.org/public/files/ccintroduction.pdfas a security engineer , when a customer asks me for consultancy about a product or a solution for securing an element of his IT\IS my first question for this product will always be : "What is its CC-EAL level certification" .
Always remember , when a standard is being requested , and the Product\solution you get is certified to that standard , you Usually get what you pay for , nothing less , maybe more.
