1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
| $ git clone https://github.com/vulsio/gost.git
$ make install
$ gost fetch microsoft
INFO[03-17|01:52:04] Initialize Database
INFO[03-17|01:52:04] Fetched all CVEs from Microsoft
INFO[03-17|01:52:06] Insert Microsoft CVEs into DB db=sqlite3
INFO[03-17|01:52:06] Inserting cves cves=11813
11813 / 11813 [----------------------------------------------------------------------------] 100.00% 2904 p/s
INFO[03-17|01:52:10] Insert KB Relation relations=6339
6339 / 6339 [------------------------------------------------------------------------------] 100.00% 5418 p/s
$ gost server
INFO[03-17|01:52:48] Starting HTTP Server...
INFO[03-17|01:52:48] Listening URL=127.0.0.1:1325
____ __
/ __/___/ / ___
/ _// __/ _ \/ _ \
/___/\__/_//_/\___/ v3.3.10-dev
High performance, minimalist Go web framework
https://echo.labstack.com
____________________________________O/_______
O\
⇨ http server started on 127.0.0.1:1325
{"time":"2023-03-17T01:53:27.583056389+09:00","id":"","remote_ip":"127.0.0.1","host":"127.0.0.1:1325","method":"GET","uri":"/microsoft/cves/CVE-2020-27844","user_agent":"curl/7.81.0","status":200,"error":"","latency":606859,"latency_human":"606.859µs","bytes_in":0,"bytes_out":2588}
{"time":"2023-03-17T01:54:09.395139706+09:00","id":"","remote_ip":"127.0.0.1","host":"127.0.0.1:1325","method":"POST","uri":"/microsoft/kbs","user_agent":"curl/7.81.0","status":200,"error":"","latency":1257395,"latency_human":"1.257395ms","bytes_in":50,"bytes_out":178}
{"time":"2023-03-17T01:58:13.061191365+09:00","id":"","remote_ip":"127.0.0.1","host":"127.0.0.1:1325","method":"POST","uri":"/microsoft/filtered-cves","user_agent":"curl/7.81.0","status":200,"error":"","latency":153815619,"latency_human":"153.815619ms","bytes_in":57,"bytes_out":174274}
// CVRFやBulletinSearchで定義された脆弱性情報がレスポンスされる
$ curl http://127.0.0.1:1325/microsoft/cves/CVE-2020-27844 | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2588 0 2588 0 0 2537k 0 --:--:-- --:--:-- --:--:-- 2527k
{
"cve_id": "CVE-2020-27844",
"title": "Chromium CVE-2020-27844: Heap buffer overflow in OpenJPEG",
"description": "<p>This CVE was assigned by Chrome. Microsoft Edge (Chromium-based) ingests Chromium, which addresses this vulnerability. Please see <a href=\"https://chromereleases.googleblog.com/2021\">Google Chrome Releases</a> for more information.</p>",
"faq": "<p><strong>Why is this Chrome CVE included in the Security Update Guide?</strong></p>\n<p>The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable. Please see <a href=\"https://msrc-blog.microsoft.com/2021/01/13/security-update-guide-supports-cves-assigned-by-industry-partners/\">Security Update Guide Supports CVEs Assigned by Industry Partners</a> for more information.</p>\n<p><strong>How can I see the version of the browser?</strong></p>\n<ol>\n<li>In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window</li>\n<li>Click on <strong>Help and Feedback</strong></li>\n<li>Click on <strong>About Microsoft Edge</strong></li>\n</ol>\n<p><strong>What is the version information for this release?</strong></p>\n<table>\n<thead>\n<tr>\n<th>Microsoft Edge Version</th>\n<th>Date Released</th>\n<th>Based on Chromium Version</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>89.0.774.45</td>\n<td>3/4/2021</td>\n<td>89.0.4389.72</td>\n</tr>\n</tbody>\n</table>",
"tag": "Microsoft Edge (Chromium-based)",
"cna": "Chrome",
"exploit_status": "DOS:N/A",
"mitigation": "",
"workaround": "",
"products": [
{
"product_id": "11655",
"name": "Microsoft Edge (Chromium-based)",
"impact": "",
"severity": "",
"score_set": {
"base_score": "",
"temporal_score": "",
"vector": ""
},
"kbs": []
}
],
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2020-27844",
"acknowledgments": "",
"publish_date": "2021-03-04T20:03:54Z",
"last_update_date": "2021-03-04T20:03:54Z"
}
// リクエストした適用済みKBIDと未適用KBIDから更新プログラムの置き換えを展開する
$ curl -H "Content-type: application/json" -X POST -d '{"applied": ["3194343"], "unapplied": ["4503327"]}' http://127.0.0.1:1325/microsoft/kbs | jq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 228 100 178 100 50 63753 17908 --:--:-- --:--:-- --:--:-- 111k
{
"applied": [
"3194343"
],
"unapplied": [
"3202790",
"3209498",
"3214628",
"4512578",
"4503327",
"4014329",
"4020821",
"4022730",
"3201860",
"4025376",
"4511553",
"4010250",
"4018483",
"4507469"
]
}
// Productに関係する脆弱性のうち, KBで修正可能な脆弱性や更新プログラムが提供されていない脆弱性を求める
$ curl -H "Content-type: application/json" -X POST -d '{"products": ["Windows Server 2019"], "kbs": ["4503327"]}' http://127.0.0.1:1325/microsoft/filtered-cves | jq | pbcopy
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 170k 0 170k 100 57 1097k 367 --:--:-- --:--:-- --:--:-- 1098k
...
"CVE-2013-3900": {
"cve_id": "CVE-2013-3900",
"title": "WinVerifyTrust Signature Validation Vulnerability",
"description": "<p><strong>Why is Microsoft republishing a CVE from 2013?</strong></p>\n<p>We are republishing CVE-2013-3900 in the Security Update Guide to update the <strong>Security Updates</strong> table and to inform customers that the EnableCertPaddingCheck is available in all currently supported versions of Windows 10 and Windows 11. While the format is different from the original CVE published in 2013, the information herein remains unchanged from the original text published on December 10, 2013.</p>\n<p>Microsoft does not plan to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows. This behavior remains available as an opt-in feature via reg key setting, and is available on supported editions of Windows released since December 10, 2013. This includes all currently supported versions of Windows 10 and Windows 11. The reg key already exists in Window 10 and Window 11, so no security update is required but the reg key must be set. See the <strong>Security Updates</strong> table for the list of affected software.</p>\n<p><strong>Vulnerability Description</strong></p>\n<p>A remote code execution vulnerability exists in the way that the WinVerifyTrust function handles Windows Authenticode signature verification for portable executable (PE) files. An anonymous attacker could exploit the vulnerability by modifying an existing signed executable file to leverage unverified portions of the file in such a way as to add malicious code to the file without invalidating the signature. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.</p>\n<p>If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.</p>\n<p>Exploitation of this vulnerability requires that a user or application run or install a specially crafted, signed PE file. An attacker could modify an existing signed file to include malicious code without invalidating the signature. This code would execute in the context of the privilege in which the signed PE file was launched.</p>\n<p>In an email attack scenario, an attacker could exploit this vulnerability by sending a user an email message containing the specially crafted PE file and convincing the user to open the file.</p>\n<p>In a web-based attack scenario, an attacker would have to host a website that contains a specially crafted PE file. In addition, compromised websites and websites that accept or host user-provided content could contain specially crafted content that could be used to exploit this vulnerability. An attacker would have no way to force users to visit a website that is hosting the specially crafted PE file. Instead, an attacker would have to convince users to visit the website, typically by getting them to click a link in an email message or Instant Messenger message that directs them to the attacker's website.</p>\n<p><strong>Update History</strong></p>\n<p>On December 10, 2013, Microsoft released an update for all supported releases of Microsoft Windows that changes how signatures are verified for binaries signed with the Windows Authenticode signature format. This change can be enabled on an opt-in basis. When enabled, the new behavior for Windows Authenticode signature verification will no longer allow extraneous information in the WIN_CERTIFICATE structure, and Windows will no longer recognize non-compliant binaries as signed. On July 29, 2014 Microsoft announced that it no longer plans to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows. To this date, it remains available as an opt-in feature in all currently supported releases of Microsoft Windows.</p>\n<p><strong>Recommendation</strong>. Microsoft recommends that executables authors consider conforming all signed binaries to the new verification standard by ensuring that they contain no extraneous information in the WIN_CERTIFICATE structure. Microsoft also recommends that customers appropriately test this change to evaluate how it will behave in their environments. Please see the <strong>Suggested Actions</strong> section for more information.</p>",
"faq": "<p><strong>What is the result of opting into the stricter verification behavior?</strong></p>\n<p>Opting into the stricter verification behavior causes the WinVerifyTrust function to perform strict Windows Authenticode signature verification for PE files. After you opt in, PE files will be considered "unsigned" if Windows identifies content in them that does not conform to the Authenticode specification. This may impact some installers. If you are using an installer that is impacted, Microsoft recommends using an installer that only extracts content from validated portions of the signed file.</p>\n<p><strong>How can I enable the new signature verification behavior?</strong></p>\n<p>Customers who would like to enable the new Authenticode signature verification behavior can do so by setting a key in the system registry. When the key is set, Windows Authenticode signature verification will no longer recognize binaries with Authenticode signatures that contain extraneous information in the WIN_CERTIFICATE structure. Customers can choose to disable the functionality at any time by disabling this registry key. See <strong>Suggested Actions</strong> for instructions.</p>\n<p><strong>How can I disable the functionality?</strong></p>\n<p>Customers who have already enabled the stricter verification behavior, and have not experienced problems, can choose to leave the verification behavior enabled. Customers who are experiencing application compatibility problems with the new behavior, or customers who simply want to disable the new behavior, can disable the functionality by removing the EnableCertPaddingCheck registry key. See <strong>Suggested Actions</strong> for instructions.</p>\n<p><strong>If I do not want to enable this functionality, do I need to do anything?</strong></p>\n<p>No. The stricter verification behavior resides on the system but will be dormant functionality until enabled.</p>\n<p><strong>Does the new verification behavior affect already-installed software?</strong></p>\n<p>The new stricter verification behavior, when enabled, applies primarily to portable executable (PE) binaries that are signed with the Windows Authenticode signature format. Binaries that are not signed with this format or that do not use WinVerifyTrust to verify signatures are not affected by the new behavior. Binaries most likely to be affected are PE installer files distributed via the Internet that are customized at time of download. The most common scenario in which users could perceive an impact is during the downloading and installation of new applications. This is the case only if customers have chosen to enable the stricter verification behavior, after which users may observe warning messages when attempting to install new applications with signatures that fail validation.</p>\n<p><strong>Does the new verification behavior impact AppLocker policies?</strong></p>\n<p>For customers who have chosen to enable the stricter verification behavior, any AppLocker rule that depends on files being signed, or expects a specific publisher, may be impacted if the signature on a file does not meet the stricter Authenticode signature verification requirements.</p>\n<p><strong>Does the new verification behavior impact Windows Defender Application Control (WDAC)?</strong></p>\n<p>No. The new verification behavior does not impact WDAC.</p>\n<p><strong>Does the new verification behavior impact Software Restriction Policies?</strong></p>\n<p>For customers who have chosen to enable the stricter verification behavior, any Software Restriction Policy that depends on files being signed, or expects a specific publisher, may be impacted if the signature on a file does not meet the stricter Authenticode signature verification requirements.</p>\n<p><strong>The new stricter verification behavior deems my binary non-compliant. What are my options?</strong></p>\n<p>If a binary is deemed non-compliant with the stricter Authenticode signature verification behavior, this will not be a problem on systems that have not had the new verification behavior enabled because Microsoft is not enforcing the stricter behavior by default. However, to correct problems with a binary failing validation on systems where the new verification behavior has been enabled, that binary will need to be re-signed with strict adherence to the Windows Authenticode Signature format and specifically not include extraneous information in the WIN_CERTIFICATE structure.</p>\n<p><strong>Is there any possibility of a signature being recognized as non-compliant with the stricter verification process if I sign using non-Microsoft-provided signing tools?</strong></p>\n<p>Yes. For customers opting to enable the stricter verification behavior, signing binaries with non-Microsoft-provided signing tools runs the risk of signatures being recognized as non-compliant with the stricter verification behavior. Using Microsoft products, or signature tools Microsoft provides, such as signtool.exe, helps to ensure that signatures are recognized as compliant.</p>\n<p><strong>What is Windows Authenticode?</strong></p>\n<p>Windows Authenticode is a digital signature format that is used to determine the origin and integrity of software binaries. Authenticode uses Public-Key Cryptography Standards (PKCS) #7 signed data and X.509 certificates to bind an Authenticode-signed binary to the identity of a software publisher. The term "Authenticode signature" refers to a digital signature format that is generated and verified using the WinVerifyTrust function.</p>\n<p><strong>What is Windows Authenticode signature verification?</strong></p>\n<p>Windows Authenticode signature verification consists of two primary activities: signature checking on specified objects and trust verification. These activities are carried out by the WinVerifyTrust function, which executes a signature check then passes the inquiry to a trust provider that supports the action identifier, if one exists. For more technical information regarding the WinVerifyTrust function, see <a href=\"http://msdn.microsoft.com/en-us/library/aa388208(vs.85).aspx\">WinVerifyTrust function</a>. For an introduction to Authenticode, see <a href=\"http://msdn.microsoft.com/en-us/library/ms537361(v=vs.85).aspx\">Introduction to Code Signing</a>.</p>\n<h3>Suggested Actions</h3>\n<p><strong>Review Microsoft Root Certificate Program Technical Requirements</strong></p>\n<p>Customers who are interested in learning more about the topic covered in this advisory should review <a href=\"https://docs.microsoft.com/en-us/security/trusted-root/program-requirements\">Windows Root Certificate Program - Technical Requirements</a>.</p>\n<p><strong>Modify Binary Signing Processes</strong></p>\n<p>After reviewing the technical details underlying the change in Authenticode signature verification behavior, Microsoft recommends that customers ensure that their Authenticode signatures do not contain extraneous information in the WIN_CERTIFICATE structure. Microsoft also recommends that executables authors consider conforming their Authenticode-signed binaries to the new verification standard. Authors who have modified their binary signing processes and would like to enable the new behavior may do so on an opt-in basis. <a href=\"https://docs.microsoft.com/en-us/security/trusted-root/program-requirements\">Windows Root Certificate Program - Technical Requirements</a> for guidance.</p>\n<p><strong>Test the Improvement to Authenticode Signature Verification</strong></p>\n<p>Microsoft recommends that customers test how this change to Authenticode signature verification behaves in their environment before fully implementing it. To enable the Authenticode signature verification improvements, modify the registry to add the EnableCertPaddingCheck value as detailed below.</p>\n<p><strong>Warning</strong> Performing these steps to enable the functionality changes will cause non-conforming binaries to appear unsigned and, therefore, render them untrusted.</p>\n<p><strong>Note</strong> If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.</p>\n<p>To enable the functionality perform the following steps:</p>\n<p><strong>For 32-bit versions of Microsoft Windows</strong></p>\n<p>Paste the following text in a text editor such as Notepad. Then, save the file by using the .reg file name extension (for example, enableAuthenticodeVerification.reg).</p>\n<pre><code>Windows Registry Editor Version 5.00 \n[HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Cryptography\\Wintrust\\Config] \n"EnableCertPaddingCheck"="1" \n</code></pre>\n<p>You can apply this .reg file to individual systems by double-clicking it.</p>\n<p><strong>Note</strong> You must restart the system for your changes to take effect.</p>\n<p><strong>For 64-bit versions of Microsoft Windows</strong></p>\n<p>Paste the following text in a text editor such as Notepad. Then, save the file by using the .reg file name extension (for example, enableAuthenticodeVerification64.reg).</p>\n<pre><code>Windows Registry Editor Version 5.00 \n[HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Cryptography\\Wintrust\\Config] \n"EnableCertPaddingCheck"="1"\n\n[HKEY_LOCAL_MACHINE\\Software\\Wow6432Node\\Microsoft\\Cryptography\\Wintrust\\Config] \n"EnableCertPaddingCheck"="1"\n</code></pre>\n<p>You can apply this .reg file to individual systems by double-clicking it.</p>\n<p><strong>Note</strong> You must restart the system for your changes to take effect.</p>\n<p><strong>Impact of enabling the functionality change</strong>: Non-conforming binaries will appear unsigned and, therefore, be rendered untrusted.</p>\n<p><strong>How to disable the functionality</strong>. Perform the following to delete the registry value previously added.</p>\n<p>For 32-bit versions of Microsoft Windows, paste the following text in a text editor such as Notepad. Then, save the file by using the .reg file name extension (for example, disableAuthenticodeVerification.reg).</p>\n<pre><code>Windows Registry Editor Version 5.00 \n[HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Cryptography\\Wintrust\\Config] \n"EnableCertPaddingCheck"=-\n</code></pre>\n<p>You can apply this .reg file to individual systems by double-clicking it.</p>\n<p><strong>Note</strong> You must restart the system for your changes to take effect.</p>\n<p>For 64-bit versions of Microsoft Windows, paste the following text in a text editor such as Notepad. Then, save the file by using the .reg file name extension (for example, disableAuthenticodeVerification64.reg).</p>\n<pre><code>Windows Registry Editor Version 5.00 \n[HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Cryptography\\Wintrust\\Config] \n"EnableCertPaddingCheck"=-\n\n[HKEY_LOCAL_MACHINE\\Software\\Wow6432Node\\Microsoft\\Cryptography\\Wintrust\\Config] \n"EnableCertPaddingCheck"=-\n</code></pre>\n<p>You can apply this .reg file to individual systems by double-clicking it.</p>\n<p><strong>Note</strong> You must restart the system for your changes to take effect.</p>",
"tag": "WinVerifyTrust Signature Verification",
"cna": "Microsoft",
"exploit_status": "Publicly Disclosed:Yes;Exploited:Yes;Latest Software Release:Exploitation Detected;Older Software Release:Exploitation Detected;DOS:N/A",
"mitigation": "",
"workaround": "",
"products": [
{
"product_id": "11571",
"name": "Windows Server 2019",
"impact": "Security Feature Bypass",
"severity": "Important",
"score_set": {
"base_score": "7.4",
"temporal_score": "6.4",
"vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N/E:U/RL:O/RC:C"
},
"kbs": []
}
],
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2013-3900",
"acknowledgments": "",
"publish_date": "2022-01-21T08:00:00Z",
"last_update_date": "2022-01-21T08:00:00Z"
},
"CVE-2019-0620": {
"cve_id": "CVE-2019-0620",
"title": "Windows Hyper-V Remote Code Execution Vulnerability",
"description": "<p>A remote code execution vulnerability exists when Windows Hyper-V on a host server fails to properly validate input from an authenticated user on a guest operating system. To exploit the vulnerability, an attacker could run a specially crafted application on a guest operating system that could cause the Hyper-V host operating system to execute arbitrary code.</p>\n<p>An attacker who successfully exploited the vulnerability could execute arbitrary code on the host operating system.</p>\n<p>The security update addresses the vulnerability by correcting how Hyper-V validates guest operating system user input.</p>",
"faq": "",
"tag": "Windows Hyper-V",
"cna": "",
"exploit_status": "Publicly Disclosed:No;Exploited:No;Latest Software Release:Exploitation Less Likely;Older Software Release:Exploitation Less Likely",
"mitigation": "",
"workaround": "",
"products": [
{
"product_id": "11571",
"name": "Windows Server 2019",
"impact": "Remote Code Execution",
"severity": "Critical",
"score_set": {
"base_score": "7.6",
"temporal_score": "6.8",
"vector": "CVSS:3.0/AV:A/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C"
},
"kbs": [
{
"article": "4503327",
"restart_required": "Yes",
"sub_type": "Security Update",
"fixed_build": "",
"article_url": "https://support.microsoft.com/help/4503327",
"download_url": "https://catalog.update.microsoft.com/v7/site/Search.aspx?q=KB4503327"
}
]
}
],
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2019-0620",
"acknowledgments": "HongZhenhao of IceSword Lab, Qihoo 360",
"publish_date": "2019-06-11T07:00:00Z",
"last_update_date": "2019-06-11T07:00:00Z"
},
...
|
