!FDRbtNYiWrrJOvqKdW:matrix.org

OSFW - Security-Discuss

520 Members
4 Servers

Load older messages


SenderMessageTime
18 Jan 2022
@_slack_osfw_UHHTC8528:matrix.orgDaniel aka CyReVolt
In reply to@_slack_osfw_UHHTC8528:matrix.org
There is a PDF version here: https://www.serdp-estcp.org/Tools-and-Training/Installation-Energy-and-Water/Cybersecurity/Resources-Tools-and-Publications/Resources-and-Tools-Files/CNSSI-4009-Committee-on-National-Security-Systems-CNSS-Glossary
(edited) > ognize your session variable. This may have been caused by: > > ... => I reached an error page stating: > ...
23:31:36
19 Jan 2022
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith
In reply to@_slack_osfw_UHHTC8528:matrix.org
I reached an error page stating: > Using a bookmark to access a specific part of this site. Not all pages in this site can be bookmarked. > Whoopsie 😬
ugh, my bad
21:22:50
@_slack_osfw_UBS57H2UE:matrix.orgjack synjack
In reply to@_slack_osfw_UCWQTGKHA:matrix.org
ugh, my bad
Yes that's great, thanks Daniel P. Smith, Right, if the NIST definition of trustworthy is what they were going for, IMHO the authors should cite it ( like they did for microkernel, etc. ).
21:37:44
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith
In reply to@_slack_osfw_UBS57H2UE:matrix.org
Yes that's great, thanks Daniel P. Smith, Right, if the NIST definition of trustworthy is what they were going for, IMHO the authors should cite it ( like they did for microkernel, etc. ).
so the link i posted through is the digital glossary which gives links to documents where that definition was used/defined https://csrc.nist.gov/glossary
21:39:22
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith
In reply to@_slack_osfw_UCWQTGKHA:matrix.org
so the link i posted through is the digital glossary which gives links to documents where that definition was used/defined https://csrc.nist.gov/glossary
(edited) ... posted through is the ... => ... posted was through the ...
21:39:37
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith
In reply to@_slack_osfw_UCWQTGKHA:matrix.org
so the link i posted was through the digital glossary which gives links to documents where that definition was used/defined https://csrc.nist.gov/glossary
so probably should have provided this one, https://csrc.nist.gov/glossary/term/trustworthiness
21:41:11
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith
In reply to@_slack_osfw_UCWQTGKHA:matrix.org
so probably should have provided this one, https://csrc.nist.gov/glossary/term/trustworthiness
there is this definition as well, https://csrc.nist.gov/glossary/term/trustworthiness_system
21:41:42
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith
In reply to@_slack_osfw_UCWQTGKHA:matrix.org
there is this definition as well, https://csrc.nist.gov/glossary/term/trustworthiness_system
the first is a little more general while the second is more focused on a computer system
21:42:11
20 Jan 2022
@_slack_osfw_U02LJME020K:matrix.orgGabriel Kerneis https://securelist.com/moonbounce-the-dark-side-of-uefi-firmware/105468/ 12:37:17
@_slack_osfw_UHHTC8528:matrix.orgDaniel aka CyReVolt
In reply to@_slack_osfw_U02LJME020K:matrix.org
https://securelist.com/moonbounce-the-dark-side-of-uefi-firmware/105468/
> We detected other non-UEFI implants in the targeted network that communicated with the same infrastructure which hosted the the stager’s payload > sounds like some degree of architectural sophistication, quite interesting
14:10:47
@_slack_osfw_U02LJME020K:matrix.orgGabriel Kerneis Do you understand it as the UEFI implants talking to malware services running on other hosts on the same network? I thought they just meant they detected UEFI and non-UEFI malware that both reported to the same host outside the attacked network. 14:19:28
@_slack_osfw_U02LJME020K:matrix.orgGabriel Kerneis Which would only mean UEFI was one tool in a kit of various attacks ran by the same attacker. 14:19:56
@_slack_osfw_UHHTC8528:matrix.orgDaniel aka CyReVolt I am reading it the same way, yea, not interpreting too much. It would be interesting to figure out whether the components can correlate and communicate with each other, using some sort of ID etc.. 14:31:14
@_slack_osfw_U014KF2U0R0:matrix.orgFoxboron joined the room.14:32:44
@_slack_osfw_U014KF2U0R0:matrix.orgFoxboron It's unclear to me if the infected device was running secure boot and enabled TPM. I reckon the TPM should have gotten a checksum of the OpROM and had it's signature validated? 14:33:49
@_slack_osfw_U02LJME020K:matrix.orgGabriel Kerneis (not commenting about this attack in particular) If the device has no BootGuard (or the AMD equivalent) enabled, the infected firmware can merely report fake values to the TPM. There is nothing outside of the firmware measuring it to the TPM, it's acting as a root of trust. 14:38:47
@_slack_osfw_U02LJME020K:matrix.orgGabriel Kerneis Then again, if correct security measures were in place, it shouldn't be possible to infect a firmware and only correctly signed firmwares can replace existing ones. But that's assuming no security flaw. 14:39:55
@_slack_osfw_U02LJME020K:matrix.orgGabriel Kerneis In other words, the firmware is measured to the TPM, but it's measuring itself (unlike the later stages which are measured before being launched). Dynamic Root of Trust is another way to avoid that leap of trust (with the CPU doing the work of measuring a page and executing it atomically). 14:44:30
@_slack_osfw_U02LJME020K:matrix.orgGabriel Kerneis What's unclear to me from the article is how they managed to write to the SPI. 14:47:26
@_slack_osfw_U01803E1HM4:matrix.orgAndrew Cooper the bottom of the article says "should use technologies like SecureBoot" which I suspect means that this particular instance wasnt 14:50:58
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith i'd be curious how they would surmise that SecureBoot would have stopped the attack 20:23:47
@_slack_osfw_US18CKM1C:matrix.orgdwizzzle
In reply to@_slack_osfw_UCWQTGKHA:matrix.org
i'd be curious how they would surmise that SecureBoot would have stopped the attack
I've got teams working on this - our current theory is secured boot off, unlocked SPI flash - this was how the hacking team UEFI implant worked as well.
22:46:11
21 Jan 2022
@_slack_osfw_UL2JL9T54:matrix.orgShawn C secureboot can't help much if the SPI flash were compromised. TPM+FDE with verifiedboot (hate the term secureboot) make more sense, even better with cbnt. 02:55:42
@_slack_osfw_UL2JL9T54:matrix.orgShawn C the infection stage is fun part of the whole attack, either chipset locks didn't enabled by default (some vendors still does) or archive the write by exploit (e.g: fancy CVE-2014-8273) 02:57:52
@_slack_osfw_UHHTC8528:matrix.orgDaniel aka CyReVolt Yea speaking of Secure Boot ™️, there was a nice preso at LCAU: https://youtu.be/VS2sk3P1_Cc 10:06:15
@_slack_osfw_UMN081QHH:matrix.orgfutaris I think that was the first time Irving gave a talk. Chatted with him a few times at LCA in Sydney, Gold Coast and online. 12:28:28
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith
In reply to@_slack_osfw_US18CKM1C:matrix.org
I've got teams working on this - our current theory is secured boot off, unlocked SPI flash - this was how the hacking team UEFI implant worked as well.
dwizzzle sounds like to me the root cause is unlocked SPI.
18:46:12
@_slack_osfw_US18CKM1C:matrix.orgdwizzzle
In reply to@_slack_osfw_UCWQTGKHA:matrix.org
dwizzzle sounds like to me the root cause is unlocked SPI.
yes same as vectorEDK https://github.com/hackedteam/vector-edk
18:47:53
@_slack_osfw_UCWQTGKHA:matrix.orgDaniel P. Smith
In reply to@_slack_osfw_US18CKM1C:matrix.org
yes same as vectorEDK https://github.com/hackedteam/vector-edk
So if SecureBoot had been on or turning on would not really block the attack. Someone would just need to find a fimware vuln that give SPI access. Having SecureBoot off just made it easier.
19:28:55
22 Jan 2022
@_slack_osfw_U016T7YTAJK:matrix.orgJohnny Lin (Wiwynn) joined the room.03:45:48

There are no newer messages yet.


Back to Room List