Re: Update: [TZO-06-2009] IBM Proventia - Generic bypass (Limited disclosure - see details)

["Vladimir '3APA3A' Dubrovin" <3APA3A@xxxxxxxxxxxxxxxx>]

Thierry,

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

--Thursday, July 16, 2009, 12:02:35 AM, you wrote to bugtraq@xxxxxxxxxxxxxxxxx:



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.






-- 
Skype: Vladimir.Dubrovin
~/ZARAZA http://securityvulns.com/
Ìàøèíà îêàçàëàñü ñïîñîáíîé ê åäèíñòâåííîìó äåéñòâèþ,
à èìåííî óìíîæåíèþ 2x2, äà è òî ïðè ýòîì îøèáàÿñü. (Ëåì)