April 2014

Viewing posts from April , 2014

Norveç Açılış

Roma, Nisan 2014

Omnitech BT Güvenlik, bütüncül bir IT güvenlik yaklaşımı ile şirketin Norveç’te bir şirket açmaya karar verdik.

“Norveç bölge olarak BT güvenliği ve genel BT hizmetleri anlamında çok önemli olgun bir pazar, Roberto Mignemi, OMNITECH CEO’su diyor. 2013 boyunca birlikte ortaklarımızdan IBM ve Computer Associates ile büyük Norveçli şirketler ile çeşitli projeleri başardık. 2014 biz Norveç pazarında daha da yerel olmak için Norveçli şirket kurmak için karar verdik bu yüzden, şuanda durum daha umut verici görünüyor. ”

Norveçli şirket, aynı zamanda İsveçli Omnitech varlıklarını yöneten Krister Fransson tarafından idare edilecek. Krister Fransson son 20 yılda bilişim güvenliği sektöründe birçok uluslararası şirket açmıştır ve İskandinav bölgesinde yerel ekipler kuracaktır.

Apertura in Norvegia

Roma, aprile 2014

Omnitech IT, l’azienda con un approccio olistico di sicurezza IT ha deciso di aprire una società in Norvegia.

“La regione nordica è un mercato IT maturo, nel quale la sicurezza informatica è una parte molto importante nell’offerta IT, dice Roberto Mignemi, amministratore delegato di Omnitech. Nel corso del 2013 siamo stati in grado di avviare diversi progetti con grandi aziende norvegesi insieme ai nostri partner IBM e CA. Il 2014 sembra ancora più promettente, è per questo che abbiamo deciso di aprire una filiale norvegese a diventare ancora più locali considerando il mercato norvegese. ”

La filiale norvegese sarà coordinata da Krister Fransson, che gestisce anche la filiale Omnitech svedese. Krister Fransson ha collaborato con diverse aziende internazionali nel settore della sicurezza informatica nel corso degli ultimi 20 anni e si focalizzera’ a costruire e sviluppare team locali nei paesi nordici.

Apertura en Noruega

Roma, Abril de 2014

OmnitechIT Security, la compañía con una visión holística de la seguridad ha decidido abrir una filial en Noruega.

“La región nórdica tiene un mercado TI maduro, donde la seguridad TI es una pieza muy importante en todos los ámbitos. Durante 2013 nosotros hemos sido capaces de comenzar muchos proyectos con grandes compañías noruegas junto con socios tecnológicaso con IBM y Computer Associates. 2014 parece incluso más prometedor. Por esto hemos dicidido formar una compañía local en Noruegas para estar incluso más presentes en el mercado noruego” – Roberto Mignemi, CEO of OmnitechIT –

La filial noruega estará liderada por Kristen Fransson, quién también maneja la filial de OmnitechIT en Suecia. Krister Fransson ha liderado compañías internacionales en la industria de la seguridad TI durante los últimos 20 años y se centrará en establecer equipos locales en el área nórdica.

Opening in Norway

Rome, April 2014

Omnitech IT Security, the company with a holistic IT security approach have decided to open a company in Norway.

”The Nordic region is a mature IT market where IT security is a very important piece in the overall IT offering, says Roberto Mignemi, CEO of Omnitech. During 2013 we were able to start several projects with big Norwegian companies together with our partners IBM and Computer Associates. 2014 looks even more promising, that is why we have decided to form a Norwegian company to become even more local to the Norwegian market.”

The Norwegian company will be led by Krister Fransson, who also manages the swedish Omnitech entity. Krister Fransson has led several international companies within the IT security industry over the last 20 years and will focus to establish local teams in the Nordic area.


Heartbleed is a very serious security vulnerabilities discovered in the OpenSSL cryptographic library; this library is used in over 60 % of the encrypted communications over the Internet.

How the official discoverers explain:

“The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users”

The bug was introduced in the Code in 2012 release of OpenSSL 1.0.1, which adds support for RFC6520 and implements the heartbeat on TLS connections. This function is to keep the channel open and prevent that client and server should renegotiate connection in the event of temporary inactivity.
Hence the pun between heartbeat and Heartbleed .

The encryption expert Bruce Schneier has called Heartbleed “a catastrophic bug in OpenSSL ” because “It allows attackers to read up to 64KB of memory” and some security researchers said:

“Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business-critical documents and communication. ”

## Code indicted

The RFC6520 protocol requires that the client send a heartbeat packet, and the server responds the with same content that he originally received from the client (so that the client recognizes as a valid answer).

The portion of the code that handles the response of the server (which contains the bug ) is in ssl/d1_both.c , and was included in the OpenSSL 1.0.1 release with this commit / commit/4817504d069b4c5082161b02a22116ad75f822b1 .
/ * Allocate memory for the response , size is 1 byte
* Message type , plus 2 bytes payload length , plus
* Payload , plus padding
* /
OPENSSL_malloc buffer = (1 + 2 + padding + payload ) ;
bp = buffer ;

/ * Enter the response type , length and copy payload * /
* bp + + = TLS1_HB_RESPONSE ;
S2N (payload , bp) ;
memcpy ( bp , pl, payload ) ;

In the above code the variable “payload” is the size of the package declared by the client and not recalculated by the server. If the sender instead of declaring the true size of the package put 0xffff (the maximum number expressible with two unsigned bytes), the recipient would copy the 34 bytes of the packet true and others that are 65501 bytes in memory after the packet legitimate and would send them to the the sender.

It is not possible to establish in a deterministic way what contain those 65501 bytes, but some tests have revealed that in response OpenSSL can provide a lot of sensitive data, including the private key that the server uses to encrypt communications.

The worst thing is that exploit this vulnerability does not need special skills nor any form of authentication. “The currently- available proof- of-concept scripts allow any client, anywhere in the world, to perform a session hijacking attack of a logged in user”.
The most impacting consequences of Hearthbleed is that some hacker may have intercepted and stored encription key and can use it to decrypt all traffic even after the bug has been patched.
What can you do?

If you are a user

if the site is still vulnerable : do nothing, it makes no sense to change the password if the transmission channel is vulnerable.
if your site is NO more vulnerable : change your password.

If you are Site Administrator

Apply the latest OpenSS patch to remove vulnerability
Renew you server cetificate
Force all users to change their password.

Final considerations

This bug reveals a widespread problem in today security of communications; the open source software, while it allows anyone to test the code, and then, if necessary, to fix the bugs, on the other side accepts contributions audited by small groups. How many people actually control the source code?
So it is possible that security weaknesses are introduced in the code without anyone noticing or that someone notices it, does not make it public, and exploit them to their advantage. How many have identified the bug before the official discoverers and have taken advantage without making it public in the last two years? Could the same happen if the source code wasn’t public?
Probably it would have been more difficult to identify the bug experimentally rather than reading the source code.

The problem is compounded by the fact that many commercial software have open source libraries within their products amplifying the outcome of these bugs, exploiting the work of the volunteers of open source.
References: (rfc ufficiale)