![]() |
|
#1
|
||||
|
||||
|
Quote:
|
|
#2
|
||||
|
||||
|
Wrote about this earlier.
Adobe's response has been top notch when you remember what the typical CA's responses are ie: hiding it. This was a targeted attack - most users should not worry.
__________________
|
|
#3
|
||||
|
||||
|
See also:
http://blogs.adobe.com/asset/2012/09...rtificate.html http://www.adobe.com/support/securit...apsa12-01.html http://www.wired.com/threatlevel/201...l-cert-hacked/ http://www.securityweek.com/adobe-re...d-sign-malware
__________________
siljaline MS MVP Alum . MVPS HOSTS . Rename Hosts . ESET for Business . 10 Immutable Laws of Security . System Lookup . ESET Threat Blog . MBAM |
|
#4
|
|||
|
|||
|
So if I am understanding this correctly, Adobe has internal software build servers. Someone cracked into one of those servers, put their own malicious software on there, and then sent it on to be signed by Adobe. Are there not mechanisms in place to check *what* software is being signed? It seems to me that the Adobe signing server just blindly trusts anything that comes from its build server IP addresses. Such an amateur mistake by such a large company.
Here is how it should work: Each Adobe developer should have his/her own key-pair. Once they get ready to send some code to the build server, they sign it first. The build server has a list of those public keys and then checks to make sure it is signed by a valid developer. From there it builds and can be sent on to be signed by the official Adobe key. And the master Adobe signing key should be locked away and air-gapped from the network. The weak link in this system is the developers themselves having their personal keys stolen. One way to mitigate that is to enforce a policy that the developer's development machine must never touch the network. Or perhaps instead of that they could provide them crypto-sticks where the keys are stored and, thus, cannot be stolen. But in any case, merely having the signing server blindly sign anything that comes from the build server was a stupid idea. |
|
#5
|
||||
|
||||
|
Quote:
They're reworking the system to ensure it doesn't happen again.
__________________
|
|
#6
|
|||
|
|||
|
Rumours say this is how Flame was spread?
|
|
#7
|
||||
|
||||
|
Doubt it. Flame was a govt project - don't think they'd go hacking Adobe.
__________________
|
|
#8
|
||||
|
||||
|
Flame has little or nothing to do with this thread.
Quote:
__________________
siljaline MS MVP Alum . MVPS HOSTS . Rename Hosts . ESET for Business . 10 Immutable Laws of Security . System Lookup . ESET Threat Blog . MBAM |
|
#9
|
|||
|
|||
|
This is pretty bad, really bad if you ask me. If their source code got owned then yikes....
http://www.wired.com/threatlevel/201...l-cert-hacked/ |
|
#10
|
|||
|
|||
|
Quote:
I hope their source code did get owned and I hope the attackers release it so the FOSS community can fix their software for them. |
|
#11
|
|||
|
|||
|
Antivirus vendors not covering this threat so well yet...
Check the following files in VirusTotal: PwDump7.exe MD5 hash: 130F7543D2360C40F8703D3898AFAC22 MD5 hash of file with signature removed: D1337B9E8BAC0EE285492B89F895CADB libeay32.dll MD5 hash: 095AB1CCC827BE2F38620256A620F7A4 MD5 hash of file with signature removed: A7EFD09E5B963AF88CE2FC5B8EB7127C myGeeksmail.dll MD5 hash: 46DB73375F05F09AC78EC3D940F3E61A MD5 hash of file with signature removed: 8EA2420013090077EA875B97D7D1FF07 |
|
#12
|
||||
|
||||
|
__________________
siljaline MS MVP Alum . MVPS HOSTS . Rename Hosts . ESET for Business . 10 Immutable Laws of Security . System Lookup . ESET Threat Blog . MBAM |
|
#13
|
|||
|
|||
|
Quote:
Yeah but having your keys stolen is actually worse than having your source code taken. This is really really bad.... |
| « Previous Thread | Next Thread » |
| Thread Tools | Search this Thread |
|
|