Attached is a cleartext, PGP signed version of this same email.
Cisco confirms the statements made.
These issues are being tracked by two Cisco Bug IDs:
CSCsc13698 -- directed DoS attack employing the EIGRP "Goodbye Message"
CSCsc13724 -- Authenticated EIGRP DoS attack/Information Leakage
We would like to thank Arhont Ltd. Information Security, especially
Konstantin V. Gavrilenko and Andrew A. Vladimirov for reporting these
issues to us.
We greatly appreciate the opportunity to work with researchers on
security
vulnerabilities, and welcome the opportunity to review and assist in
product reports.
Additional Information
======================
Posting: Unauthenticated EIGRP DoS
+---------------------------------
Original Posting:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040330.
html
Cisco confirms the reports made by Arhont Ltd.
Within this article two separate vulnerabilities are raised:
a) EIGRP ARP DoS attacks
Reference is drawn to "http://www.securityfocus.com/bid/6443", which
discusses EIGRP ARP DoS attacks. This topic has been previously
addressed by Cisco. Please refer to:
This is documented in Cisco Bug ID: "CSCsc15285 -- EIGRP ARP DoS"
No additional information is available at this time.
b) Directed DoS attack employing the EIGRP "Goodbye Message"
The EIGRP implementation in all versions of IOS is vulnerable to a
denial of service on selective neighbors, if it receives a spoofed
neighbor announcement with either mismatched "k" values, or "Goodbye
Message" TLV .
Forged packets can be injected into a network from a location outside
its boundary so that they are trusted as authentic by the receiving
host, thus resulting in a failure of integrity. Such packets could
result in routing neighbor relationships being torn down and
reformed.
Repeated exploitation could result in a sustained DoS attack. From a
position within the network where it is possible to receive the
return
traffic or create neighbor establishments (but not necessarily in a
position that is directly in the traffic path), a greater range of
violations is possible. For example, the contents of a message could
be diverted, modified, and then returned to the traffic flow again,
causing a failure of integrity and a possible failure of
confidentiality.
EIGRP can operate in two modes - Unicast Hellos; Multicast Hellos.
IOS versions 12.0(7)T and later, unicast hellos will be rejected
unless
explicitly configured in the neighbor statements. Once static
neighbors
are configured, IOS will only accept hello packets from defined
neighbors.
Cisco is tracking this report as part of:
CSCsc13698 -- directed DoS attack employing the EIGRP "Goodbye
Message"
Within the workarounds section the following will apply:
* Static configured EIGRP neighbors (IOS versions 12.0(7)T and
later)
* Blocking access to the core infrastructure
* Configure anti-spoofing measures on the network edge
* 802.1x based port security
* MD5 Neighbor Authentication
Original Posting:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040332.
html
Cisco confirms the reports made by Arhont Ltd.
- From a position within an EIGRP authenticated AS where it is possible
to
receive/listen to EIGRP Hello Updates, it is possible, with reply
attacks,
to forge illegitimate hello packets in an authenticated AS. This can
result
in additional information about the EIGRP domain being collected from
the
triggered UPDATE packets, by the malicious device. This could also
result in
carrying out similar DoS attacks as per "CSCsc15285 -- EIGRP ARP DoS",
however within an authenticated AS.
Cisco recommends proper securing of the IGP routers. Mechanisms such as
port
security or 802.1x may be used to ensure only valid routing devices are
connected to the common segments.
Cisco is tracking this report as part of:
CSCsc13724 -- Authenticated EIGRP DoS attack/Information Leakage
Within the workarounds Section the following will apply:
* Blocking access to the core infrastructure
* 802.1x based port security
Workarounds
===========
Ensuring that the infrastructure devices are protected, by both local
and
remote access means will help mitigate these vulnerabilities.
Blocking access to the core infrastructure
+-----------------------------------------
Although it is often difficult to block traffic transiting your network,
it
is possible to identify traffic which should never be allowed to target
your
infrastructure devices and block that traffic at the border of your
network.
Infrastructure access control lists (ACLs) are considered a network
security
best practice and should be considered as a long-term addition to good
network security as well as a workaround for this specific
vulnerability.
The white paper entitled:
"Protecting Your Core: Infrastructure Protection Access Control Lists",
available at http://www.cisco.com/warp/public/707/iacl.html, presents
guidelines and recommended deployment techniques for infrastructure
protection ACLs. Exceptions would include any devices which have a
legitimate
reason to access your infrastructure (for example, BGP peers, NTP
sources,
DNS serves, and so on). All other traffic must be able to traverse your
network without terminating on any of your devices.
Configure anti-spoofing measures on the network edge
+---------------------------------------------------
In order for an adversary to use the attack vector described in this
advisory,
it must send packets with the source IP address equal to one of the IP
addresses in the subnet of the EIGRP neighbors. You can block spoofed
packets
either using the Unicast Reverse Path Forwarding (uRPF) feature or by
using
access control lists (ACLs).
By enabling uRPF, all spoofed packets will be dropped at the first
device.
To enable uRPF, use the following commands:
The configuration guide, available at:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configur
ation_guide_chapter09186a00804b046b.html
presents guidelines on how uRPF works and how to configure it in various
scenarios. This is especially important if you are using asymmetric
routing.
ACLs should also be deployed as close to the edge as possible. Unlike
uRPF,
you must specify the exact IP range that is permitted. Specifying which
addresses should be blocked is not the optimal solution because it tends
to
be harder to maintain.
Caution: In order for anti-spoofing measures to be effective, they must
be
deployed at least one hop away from the devices which are being
protected. Ideally, they will be deployed at the network edge
facing
your customers.
802.1x based port security
+-------------------------
To prevent unauthorized local access to the routing subnets that the
EIGRP
neighbor relationships exist on, deploying 802.1x on the router and
switches
(in 802.1x mutual authentication) would help mitigate any local attacks.
For further information on how to configure 802.1x and products
supported
refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft
/123limit/123x/123xa/gt_802_1.htm#wp1166017
Static defined peers
+-------------------
If neighbors are explicitly configured post integration of CSCdm81710
(IOS versions 12.0(7)T or later), this acts as a workaround for these
vulnerabilities. Pre CSCdm81710, explicit neighbors are still subject to
For further information on Static defined EIGRP neighbors refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/1
23tip2r/ip2_n1gt.htm#wp1110498
MD5 Neighbor Authentication
+--------------------------
Enabling MD5, will mitigate remote malicious tear down of neighbors, by
the
methods described within this document.
For further information on MD5 EIGRP Neighbor Authentication refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/1
23tip2r/ip2_i1gt.htm#wp1106697
Cisco Security Procedures
=========================
Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and registering
to
receive security information from Cisco, is available on Cisco's
worldwide
website at:
"http://www.cisco.com/en/US/products/products_security_vulnerability_pol
icy.html"
This includes instructions for press inquiries regarding Cisco security
responses. All Cisco security advisories are available at
http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cisco Response
==============
This is Cisco PSIRTs' response to the statements made from Arhont Ltd.
Information Security in their messages:
* Unauthenticated EIGRP DoS.
* Authenticated EIGRP DoS / Information leak.
posted on the 2005 December 19th 17:00 UTC (GMT).
The original emails are available at:
* Unauthenticated EIGRP DoS:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040330.
html
* Authenticated EIGRP DoS / Information leak:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040332.
html
Attached is a cleartext, PGP signed version of this same email.
Cisco confirms the statements made.
These issues are being tracked by two Cisco Bug IDs:
CSCsc13698 -- directed DoS attack employing the EIGRP "Goodbye Message"
CSCsc13724 -- Authenticated EIGRP DoS attack/Information Leakage
We would like to thank Arhont Ltd. Information Security, especially
Konstantin V. Gavrilenko and Andrew A. Vladimirov for reporting these
issues to us.
We greatly appreciate the opportunity to work with researchers on
security
vulnerabilities, and welcome the opportunity to review and assist in
product reports.
Additional Information
======================
Posting: Unauthenticated EIGRP DoS
+---------------------------------
Original Posting:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040330.
html
Cisco confirms the reports made by Arhont Ltd.
Within this article two separate vulnerabilities are raised:
a) EIGRP ARP DoS attacks
Reference is drawn to "http://www.securityfocus.com/bid/6443", which
discusses EIGRP ARP DoS attacks. This topic has been previously
addressed by Cisco. Please refer to:
http://www.cisco.com/en/US/tech/tk365/technologies_security_notice09186a
008011c5e1.html
This is documented in Cisco Bug ID: "CSCsc15285 -- EIGRP ARP DoS"
No additional information is available at this time.
b) Directed DoS attack employing the EIGRP "Goodbye Message"
The EIGRP implementation in all versions of IOS is vulnerable to a
denial of service on selective neighbors, if it receives a spoofed
neighbor announcement with either mismatched "k" values, or "Goodbye
Message" TLV .
Forged packets can be injected into a network from a location outside
its boundary so that they are trusted as authentic by the receiving
host, thus resulting in a failure of integrity. Such packets could
result in routing neighbor relationships being torn down and
reformed.
Repeated exploitation could result in a sustained DoS attack. From a
position within the network where it is possible to receive the
return
traffic or create neighbor establishments (but not necessarily in a
position that is directly in the traffic path), a greater range of
violations is possible. For example, the contents of a message could
be diverted, modified, and then returned to the traffic flow again,
causing a failure of integrity and a possible failure of
confidentiality.
EIGRP can operate in two modes - Unicast Hellos; Multicast Hellos.
IOS versions 12.0(7)T and later, unicast hellos will be rejected
unless
explicitly configured in the neighbor statements. Once static
neighbors
are configured, IOS will only accept hello packets from defined
neighbors.
Cisco is tracking this report as part of:
CSCsc13698 -- directed DoS attack employing the EIGRP "Goodbye
Message"
Cisco recommends protecting from forged source neighbor packets
leveraging MD5 authentication and/or infrastructure protection
schemes.
Within the workarounds section the following will apply:
* Static configured EIGRP neighbors (IOS versions 12.0(7)T and
later)
* Blocking access to the core infrastructure
* Configure anti-spoofing measures on the network edge
* 802.1x based port security
* MD5 Neighbor Authentication
Posting: Authenticated EIGRP DoS/Information leak
+------------------------------------------------
Original Posting:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040332.
html
Cisco confirms the reports made by Arhont Ltd.
- From a position within an EIGRP authenticated AS where it is possible
to
receive/listen to EIGRP Hello Updates, it is possible, with reply
attacks,
to forge illegitimate hello packets in an authenticated AS. This can
result
in additional information about the EIGRP domain being collected from
the
triggered UPDATE packets, by the malicious device. This could also
result in
carrying out similar DoS attacks as per "CSCsc15285 -- EIGRP ARP DoS",
however within an authenticated AS.
Cisco recommends proper securing of the IGP routers. Mechanisms such as
port
security or 802.1x may be used to ensure only valid routing devices are
connected to the common segments.
Cisco is tracking this report as part of:
CSCsc13724 -- Authenticated EIGRP DoS attack/Information Leakage
Within the workarounds Section the following will apply:
* Blocking access to the core infrastructure
* 802.1x based port security
Workarounds
===========
Ensuring that the infrastructure devices are protected, by both local
and
remote access means will help mitigate these vulnerabilities.
Blocking access to the core infrastructure
+-----------------------------------------
Although it is often difficult to block traffic transiting your network,
it
is possible to identify traffic which should never be allowed to target
your
infrastructure devices and block that traffic at the border of your
network.
Infrastructure access control lists (ACLs) are considered a network
security
best practice and should be considered as a long-term addition to good
network security as well as a workaround for this specific
vulnerability.
The white paper entitled:
"Protecting Your Core: Infrastructure Protection Access Control Lists",
available at http://www.cisco.com/warp/public/707/iacl.html, presents
guidelines and recommended deployment techniques for infrastructure
protection ACLs. Exceptions would include any devices which have a
legitimate
reason to access your infrastructure (for example, BGP peers, NTP
sources,
DNS serves, and so on). All other traffic must be able to traverse your
network without terminating on any of your devices.
Configure anti-spoofing measures on the network edge
+---------------------------------------------------
In order for an adversary to use the attack vector described in this
advisory,
it must send packets with the source IP address equal to one of the IP
addresses in the subnet of the EIGRP neighbors. You can block spoofed
packets
either using the Unicast Reverse Path Forwarding (uRPF) feature or by
using
access control lists (ACLs).
By enabling uRPF, all spoofed packets will be dropped at the first
device.
To enable uRPF, use the following commands:
router(config)#ip cef
router(config)#ip verify unicast reverse-path </pre>
The configuration guide, available at:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configur
ation_guide_chapter09186a00804b046b.html
presents guidelines on how uRPF works and how to configure it in various
scenarios. This is especially important if you are using asymmetric
routing.
ACLs should also be deployed as close to the edge as possible. Unlike
uRPF,
you must specify the exact IP range that is permitted. Specifying which
addresses should be blocked is not the optimal solution because it tends
to
be harder to maintain.
Caution: In order for anti-spoofing measures to be effective, they must
be
deployed at least one hop away from the devices which are being
protected. Ideally, they will be deployed at the network edge
facing
your customers.
802.1x based port security
+-------------------------
To prevent unauthorized local access to the routing subnets that the
EIGRP
neighbor relationships exist on, deploying 802.1x on the router and
switches
(in 802.1x mutual authentication) would help mitigate any local attacks.
For further information on how to configure 802.1x and products
supported
refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft
/123limit/123x/123xa/gt_802_1.htm#wp1166017
Static defined peers
+-------------------
If neighbors are explicitly configured post integration of CSCdm81710
(IOS versions 12.0(7)T or later), this acts as a workaround for these
vulnerabilities. Pre CSCdm81710, explicit neighbors are still subject to
DoS attacks of this nature.
Example post CSCdm81710:
router eigrp 1
network 192.168.1.0
network 192.168.66.0
neighbor 192.168.66.2 FastEthernet0/0
neighbor 192.168.66.1 FastEthernet0/0
no auto-summary
For further information on Static defined EIGRP neighbors refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/1
23tip2r/ip2_n1gt.htm#wp1110498
MD5 Neighbor Authentication
+--------------------------
Enabling MD5, will mitigate remote malicious tear down of neighbors, by
the
methods described within this document.
For further information on MD5 EIGRP Neighbor Authentication refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/1
23tip2r/ip2_i1gt.htm#wp1106697
Cisco Security Procedures
=========================
Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and registering
to
receive security information from Cisco, is available on Cisco's
worldwide
website at:
"http://www.cisco.com/en/US/products/products_security_vulnerability_pol
icy.html"
This includes instructions for press inquiries regarding Cisco security
responses. All Cisco security advisories are available at
http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQ6dPA3sxqM8ytrWQEQLWYgCgyjX8d2wlcy7X0p+punRpEx8XuNIAoJHl
zdgDiSjTuzaPLdnXgayxeDvF
=rOWF
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cisco Response
==============
This is Cisco PSIRTs' response to the statements made from Arhont Ltd.
Information Security in their messages:
* Unauthenticated EIGRP DoS.
* Authenticated EIGRP DoS / Information leak.
posted on the 2005 December 19th 17:00 UTC (GMT).
The original emails are available at:
* Unauthenticated EIGRP DoS:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040330.
html
* Authenticated EIGRP DoS / Information leak:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040332.
html
Attached is a cleartext, PGP signed version of this same email.
Cisco confirms the statements made.
These issues are being tracked by two Cisco Bug IDs:
CSCsc13698 -- directed DoS attack employing the EIGRP "Goodbye Message"
CSCsc13724 -- Authenticated EIGRP DoS attack/Information Leakage
We would like to thank Arhont Ltd. Information Security, especially
Konstantin V. Gavrilenko and Andrew A. Vladimirov for reporting these
issues to us.
We greatly appreciate the opportunity to work with researchers on security
vulnerabilities, and welcome the opportunity to review and assist in
product reports.
Additional Information
======================
Posting: Unauthenticated EIGRP DoS
+---------------------------------
Original Posting:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040330.
html
Cisco confirms the reports made by Arhont Ltd.
Within this article two separate vulnerabilities are raised:
a) EIGRP ARP DoS attacks
Reference is drawn to "http://www.securityfocus.com/bid/6443", which
discusses EIGRP ARP DoS attacks. This topic has been previously
addressed by Cisco. Please refer to:
http://www.cisco.com/en/US/tech/tk365/technologies_security_notice09186a
008011c5e1.html
This is documented in Cisco Bug ID: "CSCsc15285 -- EIGRP ARP DoS"
No additional information is available at this time.
b) Directed DoS attack employing the EIGRP "Goodbye Message"
The EIGRP implementation in all versions of IOS is vulnerable to a
denial of service on selective neighbors, if it receives a spoofed
neighbor announcement with either mismatched "k" values, or "Goodbye
Message" TLV .
Forged packets can be injected into a network from a location outside
its boundary so that they are trusted as authentic by the receiving
host, thus resulting in a failure of integrity. Such packets could
result in routing neighbor relationships being torn down and reformed.
Repeated exploitation could result in a sustained DoS attack. From a
position within the network where it is possible to receive the return
traffic or create neighbor establishments (but not necessarily in a
position that is directly in the traffic path), a greater range of
violations is possible. For example, the contents of a message could
be diverted, modified, and then returned to the traffic flow again,
causing a failure of integrity and a possible failure of
confidentiality.
EIGRP can operate in two modes - Unicast Hellos; Multicast Hellos.
IOS versions 12.0(7)T and later, unicast hellos will be rejected unless
explicitly configured in the neighbor statements. Once static neighbors
are configured, IOS will only accept hello packets from defined neighbors.
Cisco is tracking this report as part of:
CSCsc13698 -- directed DoS attack employing the EIGRP "Goodbye Message"
Cisco recommends protecting from forged source neighbor packets
leveraging MD5 authentication and/or infrastructure protection schemes.
Within the workarounds section the following will apply:
* Static configured EIGRP neighbors (IOS versions 12.0(7)T and later)
* Blocking access to the core infrastructure
* Configure anti-spoofing measures on the network edge
* 802.1x based port security
* MD5 Neighbor Authentication
Posting: Authenticated EIGRP DoS/Information leak
+------------------------------------------------
Original Posting:
http://lists.grok.org.uk/pipermail/full-disclosure/2005-December/040332.
html
Cisco confirms the reports made by Arhont Ltd.
- From a position within an EIGRP authenticated AS where it is possible to
receive/listen to EIGRP Hello Updates, it is possible, with reply attacks,
to forge illegitimate hello packets in an authenticated AS. This can result
in additional information about the EIGRP domain being collected from the
triggered UPDATE packets, by the malicious device. This could also result in
carrying out similar DoS attacks as per "CSCsc15285 -- EIGRP ARP DoS",
however within an authenticated AS.
Cisco recommends proper securing of the IGP routers. Mechanisms such as port
security or 802.1x may be used to ensure only valid routing devices are
connected to the common segments.
Cisco is tracking this report as part of:
CSCsc13724 -- Authenticated EIGRP DoS attack/Information Leakage
Within the workarounds Section the following will apply:
* Blocking access to the core infrastructure
* 802.1x based port security
Workarounds
===========
Ensuring that the infrastructure devices are protected, by both local and
remote access means will help mitigate these vulnerabilities.
Blocking access to the core infrastructure
+-----------------------------------------
Although it is often difficult to block traffic transiting your network, it
is possible to identify traffic which should never be allowed to target your
infrastructure devices and block that traffic at the border of your network.
Infrastructure access control lists (ACLs) are considered a network security
best practice and should be considered as a long-term addition to good
network security as well as a workaround for this specific vulnerability.
The white paper entitled:
"Protecting Your Core: Infrastructure Protection Access Control Lists",
available at http://www.cisco.com/warp/public/707/iacl.html, presents
guidelines and recommended deployment techniques for infrastructure
protection ACLs. Exceptions would include any devices which have a legitimate
reason to access your infrastructure (for example, BGP peers, NTP sources,
DNS serves, and so on). All other traffic must be able to traverse your
network without terminating on any of your devices.
Configure anti-spoofing measures on the network edge
+---------------------------------------------------
In order for an adversary to use the attack vector described in this advisory,
it must send packets with the source IP address equal to one of the IP
addresses in the subnet of the EIGRP neighbors. You can block spoofed packets
either using the Unicast Reverse Path Forwarding (uRPF) feature or by using
access control lists (ACLs).
By enabling uRPF, all spoofed packets will be dropped at the first device.
To enable uRPF, use the following commands:
router(config)#ip cef
router(config)#ip verify unicast reverse-path </pre>
The configuration guide, available at:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configur
ation_guide_chapter09186a00804b046b.html
presents guidelines on how uRPF works and how to configure it in various
scenarios. This is especially important if you are using asymmetric routing.
ACLs should also be deployed as close to the edge as possible. Unlike uRPF,
you must specify the exact IP range that is permitted. Specifying which
addresses should be blocked is not the optimal solution because it tends to
be harder to maintain.
Caution: In order for anti-spoofing measures to be effective, they must be
deployed at least one hop away from the devices which are being
protected. Ideally, they will be deployed at the network edge facing
your customers.
802.1x based port security
+-------------------------
To prevent unauthorized local access to the routing subnets that the EIGRP
neighbor relationships exist on, deploying 802.1x on the router and switches
(in 802.1x mutual authentication) would help mitigate any local attacks.
For further information on how to configure 802.1x and products supported
refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft
/123limit/123x/123xa/gt_802_1.htm#wp1166017
Static defined peers
+-------------------
If neighbors are explicitly configured post integration of CSCdm81710
(IOS versions 12.0(7)T or later), this acts as a workaround for these
vulnerabilities. Pre CSCdm81710, explicit neighbors are still subject to
DoS attacks of this nature.
Example post CSCdm81710:
router eigrp 1
network 192.168.1.0
network 192.168.66.0
neighbor 192.168.66.2 FastEthernet0/0
neighbor 192.168.66.1 FastEthernet0/0
no auto-summary
For further information on Static defined EIGRP neighbors refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/1
23tip2r/ip2_n1gt.htm#wp1110498
MD5 Neighbor Authentication
+--------------------------
Enabling MD5, will mitigate remote malicious tear down of neighbors, by the
methods described within this document.
For further information on MD5 EIGRP Neighbor Authentication refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123tcr/1
23tip2r/ip2_i1gt.htm#wp1106697
Cisco Security Procedures
=========================
Complete information on reporting security vulnerabilities in Cisco
products, obtaining assistance with security incidents, and registering to
receive security information from Cisco, is available on Cisco's worldwide
website at:
"http://www.cisco.com/en/US/products/products_security_vulnerability_pol
icy.html"
This includes instructions for press inquiries regarding Cisco security
responses. All Cisco security advisories are available at
http://www.cisco.com/go/psirt
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQ6dNfnsxqM8ytrWQEQJpOQCg3H3slUUBB6jWWQmBJ8o2FqDaROcAn2JP
I5nsoJNXpav5UK/xNXSdYAqn
=ZSn0
-----END PGP SIGNATURE-----
[ reply ]