Message-ID: <427657762.20090716145849@Zoller.lu>
Date: Thu, 16 Jul 2009 14:58:49 +0200
From: Thierry Zoller <Thierry@...ler.lu>
To: "Vladimir '3APA3A' Dubrovin" <3APA3A@...URITY.NNOV.RU>
Cc: bugtraq <bugtraq@...urityfocus.com>,
	full-disclosure <full-disclosure@...ts.grok.org.uk>,
	<info@...cl.etat.lu>, <vuln@...unia.com>, <cert@...t.org>,
	<nvd@...t.gov>, <cve@...re.org>
Subject: Re[2]: Update: [TZO-06-2009] IBM Proventia - Generic bypass (Limited disclosure - see details)

Hi Vladimir,

Please  understand  that  I will not enter that discussion any longer.
Please note that :
V3D> is not malware/intrusion or malware in the form unused in-the-wild
V3D>  is   not  vulnerability.

Is  false.  It  is  recognised malware,  else  the  test  woulnd't  make  sense -
obviously.


Regards,
Thierry

V3D> Thierry,

V3D>  I think inability of antivirus / intrusion detection to catch something
V3D>  that is not malware/intrusion or malware in the form unused in-the-wild
V3D>  is   not  vulnerability.  Antivirus  (generally)  gives  no  preventive
V3D>  protection.  They  can add signatures for your PoCs to their database -
V3D>  and that's how it works.

V3D> --Thursday, July 16, 2009, 12:02:35 AM, you wrote to bugtraq@...urityfocus.com:



TZ>> As I received a lot of feedback on this bug, I thought I'd update you. After not replying
TZ>> to my notifications and subsequent forced partial disclosure, IBM stated
TZ>> officially on their website that they where not affected and to my surprise
TZ>> IBM got in contact immediately after disclosure to "coordinate"

TZ>> If your read the Timeline till the end, the story has a nice swing.., Drama, insults,
TZ>> everything. You could make a soap opera out of it. And you don't even have all the mails.

TZ>> What happened during this "coordination" even surprised myself. I am used to discussions,
TZ>> I am used to stupid answers. However what happened here bears no description.


TZ>> Short Guerilla Version of the Timeline  (complete timeline below):
TZ>> -------------------------------------------------------------------
TZ>> - Hey Thierry sorry, we did not get your report, we'll keep you updated!
TZ>> We have IBM written on the proventia boxes but don't send reports to IBM!!

TZ>> - Post official statement to IBM website that IBM is NOT affected and
TZ>> forgetting to inform Thierry

TZ>> - Thierry, You cannot evade proventia, because we use special propretary
TZ>> ingredients!

>>> What are these ingredients?

TZ>> - We won't tell !! and by the way you suck! your test methods suck! You aren't even
TZ>> EAL2 ! A test team costs too much to tests your POCs! Your mails suck! Learn from
TZ>> the big mighty IBM. 

>>> Sorry, the same poc evaded proventia last year! So you mus miss something!!

TZ>> - Thierry, stop sending us POC files, YOU CANNOT EVADE PROVENTIA, IT is
TZ>> IMPOSSIBLE, IRREVQUABLE, PERIOD !!!!

>>>Silence

TZ>> - Thierry here is our report, you DID evade all our proventia products, we will
TZ>> credit you.



TZ>> In the timeline below you find my summary
TZ>> -----------------------------------------
TZ>> 02.04.2009 - Forced partial disclose
TZ>> 02.04.2009 - An known contact at IBM asks for the POC
TZ>> 02.04.2009 - POC is resend
TZ>> 02.04.2009 - An third person is added to the coordination "list"
TZ>> 04.04.2009 - Sending another POC file (RAR)
TZ>> 06.04.2009 - POC is acknowledged and promise is made to get back
TZ>>              once the material has been analysed.
TZ>> 10.04.2009 - Sending another POC file (ZIP)
TZ>> 10.04.2009 - The third person ergo the "Cyber
TZ>> Incident & Vulnerability Handling PM" is taking over coorindation

TZ>> 14.04.2009 - A comment was made to my blog that indicated IBM did
TZ>> answer the Bugtraq posting and negate my findings, having 
TZ>> received no response from them personaly I ask
TZ>> "Dear Peter, I was refered to this url in a comment posted to my blog:
TZ>> http://iss.custhelp.com/cgi-bin/iss.cfg/php/enduser/std_adp.php?p_faqid=5417
TZ>> can you confirm this ?"

TZ>> 15.04.2009 -  IBM responds:
TZ>> "[..] we
TZ>> apologize that the path of communicating the disclosure was somewhat
TZ>> confusing.  [..]  The IBM contact address in the
TZ>> OSVDB is typically used for software products that are in another division
TZ>> of IBM, and thus, your report was not routed to us in a timely manner.  In
TZ>> the future, we'd prefer that you contact myself directly"

TZ>> "We have now investigated the TZO-04-2009-IBM incident you reported and have
TZ>> found that we are not susceptible to this evasion."
TZ>> "[..]in  this  case,  there  are  other  components in our Proventia
TZ>> products that prevent this evasion from occurring"
TZ>> "Testing our production products, rather than testing this one
TZ>> piece of our technology, then you would have been able to see the same
TZ>> results"

TZ>> 16.04.2009 - As my tests indicate otherwise I ask "Could you please
TZ>> specify which >components< would prevent the evasion, as it is
TZ>> hard  to see how to prevent it when the unarchiver code cannot extract
TZ>> the code itself" and
TZ>> "I  would  be  glad  to do so [Red:test production products] : 
TZ>> Please send the respective appliances to <my adress>"


TZ>> 16.04.2009 - IBM answers
TZ>> [..] "We are not an open source company, so the internal workings of
TZ>> our proprietary software is not something we publicly disclose.  
TZ>> We do not provide our products for free to all of the independent 
TZ>> testers that might be interested in our product lines--the number 
TZ>> of requests simply would not be scalable or manageable if
TZ>> we did"

TZ>> 17.04.2009 - As I have no way to reproduce and IBM gives no details
TZ>> about their OH-SO Secret propretary software I state that 
TZ>> "I  cannot  verify  nor  reproduce your statements as such I will leave
TZ>> this CVE entry as disputed." "Please provide tangible proof that 
TZ>> you detect the samples. Screenshots, logs, outputs."
TZ>> AND
TZ>> "My  worktime  is not open source either[..] Yet I
TZ>> am currently working for your interests and customers, for free. I can
TZ>> stop reporting responsibly  if this is what you are trying to achieve."

TZ>> 21.04.2009 - As their was no reply, I resend the previous mail

TZ>> 22.04.2009 - IBM acks receipt and promises to reply soon.

TZ>> ==
TZ>> In the mean time, as I thanked AV-TEST gmbh in my advisory, 
TZ>> somebody complains directly at AV-TEST Gmbh as force them to 
TZ>> no longer give me access to their test clusters. AV-TEST Gmbh 
TZ>> subsequently asks me to stop testing using their systems.
TZ>> As a note: Anybody spots a paralel to the mob?
TZ>> ==

TZ>> 23.04.2009 - I inform IBM that 
TZ>> "Interestingly instead of spending the time cooperating with me
TZ>> some think it might be more usefull to complain at AVTest." [..]
TZ>> "I perceive the complaints as a direct attack against myself"

TZ>> 23.04.2009 -  IBM informs me that it wasn't them that complained and
TZ>> that 
TZ>> "[..] We processed your claim.   You do NOT evade our products.   
TZ>> You are talking about a component that never deploys singularly.  
TZ>> Hence you cannot evade."

TZ>> "As for testing our products, we have organizations that do that from
TZ>> time-to-time.   Those are contractual agreements.   Since you published
TZ>> incomplete data previously, I see no reason to engage for such a test."

TZ>> "You ask for cooperation, but yet
TZ>> you only have leveled insinuations and have attempted to turn what has
TZ>> taken place into something else.   Hardly following responsible disclosure
TZ>> as you have listed it."

TZ>> "I welcome your thoughts and your input as there is always something to
TZ>> reflect upon and to learn about.   But this is a two way street,  and I ask
TZ>> you to learn from us that how we deploy our products is not what you
TZ>> tested/researched."

TZ>> "Further, we are not going to loan a Proventia device for you to learn upon."


TZ>> 23.04.2009 - I answer that 
TZ>> "[..] I asked for
TZ>> screenshots  or  logs,  something,  if  test have been done, should be
TZ>> readily available anyways" "You seem not be be acustomed to handling
TZ>> vulnerability reports, if negative finding  is  reported  a  vendor 
TZ>> usualy responds that the finding was negative he usualy attaches a 
TZ>> log, screenshot or similar."

>>>You do NOT evade our products.You are talking about a component 
>>>that never deploys singularly.  
>>>Hence you cannot evade."
TZ>> "Hmm, that might be the case, or might not -
TZ>> I  have  an  email from last year that states that a sample I provided
TZ>> evaded  proventia,  using the very same methods of tests as this time."

>>>Further, we are not going to loan a Proventia device for you to learn upon.
TZ>> "I   have   not   asked  to  be  *loaned*  a proventia device. You will
TZ>> have  to  find  the balance yourself. It's interesting to see that you
TZ>> think I could somehow "learn" something from an appliance.

TZ>> Anyways, if you don't provide me with guidance I can only sent in more
TZ>> and  more  samples  (that may be more and more false positives). Again
TZ>> trying to help, but if you don't need help that's fine with me too."

TZ>> 24.04.2009 - I inform IBM that 
TZ>> "Please note that I just made changes to my terms and policy to be able
TZ>> to  republish  mails  that  happen  during  notification  in  full  or
TZ>> partially"

TZ>> 24.04.2009 - IBM states that
TZ>>  "Thierry,
TZ>> Changes you make should be effective for new issues going forward.  Period."

TZ>> "We have reported to you that your issues DO NOT EVADE PRODUCTS.   That is
TZ>> unequivocable.   You have not proven an evasion of a product. "

TZ>> "We
TZ>> have conducted that research and the report is negative, your issues do not
TZ>> evade the product.   [..] Further, we do
TZ>> not for obvious reasons ever provide architectural details except in cases
TZ>> of NIAP review under Common Criteria for EAL 2 or Higher, then in only
TZ>> certain aspects.    Your research does not attain that benchmark."

TZ>> 08.05.2009 - Sending a new POC evading proventia (CAB)
TZ>> no reply

TZ>> 11.05.2009 - Re-sending asking for an acknowledgement

TZ>> 15.05.2009 -
TZ>> "We are in the final stages of completing the write up on our review of all
TZ>> your reports.   It may take until early AM US EDT to complete or possibly
TZ>> early AM Central European Time."

TZ>> 22.05.2009 - IBM sends in the results, and *surprise* it DID evade proventia.
TZ>> Quote:"
TZ>> IBM Proventia Desktop Endpoint Security - susceptible
TZ>> IBM Proventia Network Multi-Function Security (MFS) - susceptible

TZ>> Multiple engines are susceptible to this evasion. We are working internally
TZ>> and with third-party OEM vendors to create a fix for this evasion. For our
TZ>> own engine, we have placed a fix on our long-term development roadmap, but
TZ>> this is a low priority for us because this engine runs in a desktop
TZ>> environment where malicious code in these archives will be detected upon
TZ>> extraction or execution. If and when an update addressing this issue is
TZ>> delivered for our engine, we will credit you."

TZ>> Ignoring that the end-point argument doesn't hold true for the network
TZ>> device, isn't this incredible?

TZ>> 22.05.2009 - I respond that 
TZ>> "[..] The files
TZ>> bypass your protection - to argue with client-side protection (if any)
TZ>> is reserved for the clients that use your products. You should rate it
TZ>> as what it is. A bypass of your AV detection"


TZ>> Heard, nothing back since the 23th may. I trust IBM to disclose and fix,
TZ>> and maybe credit, but I thought I let IBM customers know where your 
TZ>> millions license fees are spent on.









-- 
http://blog.zoller.lu
Thierry Zoller

Powered by blists - more mailing lists