|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical snmp-forum
Forwarded for Ian Finlay by owner-nanog. Sorry for the slow turn around, I was flying back from Miami yesterday. -sue Sue Joiner Merit Network [email protected] XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Date: Wed, 13 Feb 2002 12:56:11 -0500 (EST) From: Ian Finlay <[email protected]> X-X-Sender: [email protected] To: [email protected] Cc: [email protected] Subject: snmp-forum Message-ID: <[email protected]> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [email protected] -----BEGIN PGP SIGNED MESSAGE----- As you may already know, the CERT/CC has set up a forum where administrators can share ideas and techniques that can be used to develop proper defenses. We have essentially created an unmoderated mailing list for system and network administrators to discuss helpful techniques and tools. You can subscribe to the mailing list by sending an email message to [email protected] In the body of the message, type subscribe snmp-forum After you receive the confirmation message, follow the instructions in the message to complete the subscription process. This information was included in the Advisory we sent out yesterday (http://www.cert.org/advisories/CA-2002-03.html). Since that time, ~525 people have subscribed and the list continues to grow. I have included a digest of what has transpired on the list so far for your convenience. Because of the expertise that exists within the NANOG community, we'd love to have you folks participate (some of you are already). Thanks, Ian Ian A. Finlay CERT (R) Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA USA 15213-3890 - ----------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 12:33 PM -0500 From: Joshua Wright <[email protected]> To: "'[email protected]'" <[email protected]> Subject: RE: Bypassing Cisco ACL's for SNMP <me backpedaling> Reading Cisco's advisory another few times, it seems the configuration in question that will bypass ACLs goes like this: access-list 1 permit host X.X.X.X access-list 1 deny any log snmp-server community blah rw 1 snmp-server host X.X.X.X blah When setting the trap host for SNMP with the same community string, access to the SNMP will be permitted with no access to the MIB (bypassing the ACL). This is because of the order the configuration commands are kept in the configuration file, the "snmp-server host" command happens _after_ the "snmp-server community" command. According to the Cisco advisory, even without access the MIB, the PROTOS tool has the ability to DoS the router. You can configure the router in this fashion: access-list 1 permit host X.X.X.X access-list 1 deny any log snmp-server host X.X.X.X blah snmp-server community blah rw 1 And your ACL will be applied, but a reboot will revert to the same order as described above. Best to use different community strings for GET/SET and traps. Better yet, use a different pair of community string for each router you control. Better still, filter UDP/161 and UDP/162 at your edge, then apply the steps described in the Cisco advisory. </me backpedaling> The question remains however - why does IOS accept SNMP GET/SET PDUs on a community string defined for traps, even without access to the MIB? Why not just reject these packets as if we didn't have "snmp-server community string" defined? I consider this a separate bug aside from the PROTOS exploit. - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University [email protected] pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Wednesday, February 13, 2002 9:01 AM To: [email protected] Subject: Bypassing Cisco ACL's for SNMP - - -----BEGIN PGP SIGNED MESSAGE----- Joshua Wright writes: > Trying to confirm or deny posting on securitydatabase.net that indicates "If > there is a snmp-communitystring defined with an ACL on it and a 'snmp-server > host' is configured with the same community-string, then a packet could be > send to the router/switch, that ignores all ACL's on the device". The > posting is possibly suspect to misinterpretation of the CERT advisory, but > otherwise scary if confirmed. Not really. This is basically a configuration error. Imagine the following configuration: access-list 1 permit host X.X.X.X access-list 1 deny any snmp-server community blah rw 1 snmp-server community blah rw So what the 3rd line says is: Allow SNMP PDUs but only from ip address X.X.X.X (depending on the definition of access-list 1) and only when the community is equal to "blah". Then the 4th line says: Allow all SNMP PDUs as long as the community string is equal to "blah". What we really have are two conflicting statements and the cisco device just obeys the last order given. These are only to options of the same statement, none of them is "superior" to the other. Really, this is IMHO just a plain dumb way to configure SNMP on ciscos. > Certainly, UDP ACL's can be bypassed easily through spoofing the > source address of the packet, but this requires knowledge of the > permit statements in the ACL as well as the community string for > access. The only safe way, as long as fixed IOS versions are not widely deployed, is to have a seperate management VPN (with IPSec on it) or to manage the routers only through SSH. Both may not be present on some devices. Of course, the canonical way would be to ditch SNMPv1 and switch to SNMPv3 with signing and encryption turned on. But that is diffucult, because a) SNMPv2 and SNMPv3 are not supported by most SNMP manager software. b) I'm not sure about the performance impact on the managers side when dealing with a lot of devices. c) I'm not sure about the performance impact on the agents side when dealing with a lot of requests in a short time. Regards, Klaus Moeller, DFN-CERT - - - -- Klaus Moeller | mailto:[email protected] DFN-CERT GmbH | http://www.cert.dfn.de/team/moeller/ Oberstrasse 14b | Phone: +49(40)808077-555 D-20144 Hamburg | FAX: +49(40)808077-556 Germany | PGP-Key: finger [email protected] - - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface iQEVAwUBPGpxbYrEggYLt8j5AQFYIAf5AcIIsrEUGSraka5ZmG9cwhJtxzAq3T8e CTa2YnqrGhBDWdn68NG4ivqJJqweQ5FraK/0WlWBKXwjmrd5oWFP5AHt0L0MhaBL 8tC45njL6sVlG7d8gb1+/Z/3VmsbBOX9c3++veuDCuHuaq2071sraWFQuxglPIng TAEc+jAHBo+UAj9Zs8GXA1HJs3DWrOg9tO9u9aHtesXh8Mcj78jH9ycafszIzGU7 0s/N0CBXWtiUeZ/qLx0YzcmGj4KHfuXMjmh4rQlsG5pD70PEkCwBtp5v361pCjky NyK2MeW2uUs2WZLKNSGUGau7VtZT0ZugS4R9rwcZe/oCA58bCielLw== =zFlB - - -----END PGP SIGNATURE----- - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 12:16 PM -0500 From: Joshua Wright <[email protected]> To: [email protected] Subject: RE: Cisco SNMP Recommendations? This is good practice, but does not protect you from the Cisco "surprise" community strings (cable-docsis, ILMI) that have been uncovered in IOS. Surely, others exist. Best to block SNMP at your firewall or border router before it enters your network. Also apply the controls you have documented below for a multi-tiered approach. Also, I am a fan of adding "access-list 10 deny any log" to ACL's to gather some logging information. This makes numbered access-lists difficult to maintain when adding additional hosts to be permitted because you have to perform a "no access-list 10" and recreate the entire ACL to add another permitted host/network. My 2 cents. - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University [email protected] pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - -----Original Message----- From: Ryan J Standish [mailto:[email protected]] Sent: Wednesday, February 13, 2002 11:50 AM To: Jim Duncan Cc: [email protected]; [email protected] Subject: Re: Cisco SNMP Recommendations? Any opinions/ideas? If protecting the router itself is the only concern, does the following acls offer any less protection than applying an explicit acl to an interface instead of just to the snmp-server config? Is the rtr still vulnerable to an snmp DOS attack? access-list 10 remark -- SNMP Read Access -- access-list 10 permit 192.168.100.0 0.0.0.255 access-list 11 remark -- SNMP Write and Telnet Access -- access-list 11 permit 192.168.100.0 0.0.0.255 snmp-server community foobar RO 10 snmp-server community foobar2 RW 11 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 12:16 PM -0500 From: Jim Duncan <[email protected]> To: [email protected] Subject: port 1993 is a shill Folks, I can't find the previous message, but earlier today someone in this forum asked about filtering port 1993 in regard to the current SNMP vulnerabilities. We don't use port 1993, tcp or udp, in any Cisco products. There is no reason to call special attention to it. Port 1993 is an artifact from a moribund project many years ago that provided network management over TCP using a system based on SNMP. I believe the effort predates any 11.0 releases of IOS. I could find no 11.x or 12.x releases that provided services for port 1993, tcp or udp. Filtering unnecessary ports and turning off unneeded services is always a good idea, but there is nothing especially important about 1993. We have mentioned this in our advisory and ask that unless you have specific reasons to include it, please remove it from your own notices. It generates a lot of unnecessary calls and messages. If you _do_ have a good reason to mention it, please let us know. :-) Thanks. Jim == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: [email protected] Phone(Direct/FAX): +1 919 392 6209 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 12:10 PM -0500 From: Joshua Wright <[email protected]> To: "'[email protected]'" <[email protected]> Subject: RE: Cisco SNMP Recommendations? I would modify your ACL slightly to add logging information for attempts to access SNMP resources: ip access-list extended example1 deny udp any any eq snmp log-input deny udp any any eq snmptrap log-input permit ip any any If you are not already, start logging to a syslog server as well: logging facility local0 logging trap debug logging 1.1.1.1 On your Unix box, something like $ echo "local0.debug /var/log/routerlogs.log" >>/etc/syslog.conf $ kill -HUP pid_of_syslogd They you will have some logging information regarding whether you have broken something legitimate, or if someone is trying to access SNMP illegitimately. You can also check out "sh logging" if you are "logging buffered nnn". SANS also recommended blocking UDP/1993, but only if your IOS was born in the stone ages (e.g. <11.0). If your IOS is <11.0 you have other issues to worry about. :) - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University [email protected] pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - -----Original Message----- From: Jim Duncan [mailto:[email protected]] Sent: Wednesday, February 13, 2002 11:29 AM To: [email protected] Cc: [email protected] Subject: Re: Cisco SNMP Recommendations? Robert Osantowski writes: > Could anyone offer their suggestions for blocking SNMP requests at a network > boundary on a Cisco Router? > > I could place an ACL on the inbound Internet interface and do something like > I've shown below, but I'm wondering if there is a better way? > > Interface Serial0/0 > ip access-group example1 in > > ip access-list extended example1 > deny udp any any eq snmp > deny udp any any eq snmptrap > permit ip any any > > Any feedback would be appreciated. Thanks. Rob, this is the same thing we recommend in our advisory, http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml Jim == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: [email protected] Phone(Direct/FAX): +1 919 392 6209 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 11:49 AM -0500 From: Ryan J Standish <[email protected]> To: Jim Duncan <[email protected]> Subject: Re: Cisco SNMP Recommendations? Any opinions/ideas? If protecting the router itself is the only concern, does the following acls offer any less protection than applying an explicit acl to an interface instead of just to the snmp-server config? Is the rtr still vulnerable to an snmp DOS attack? access-list 10 remark -- SNMP Read Access -- access-list 10 permit 192.168.100.0 0.0.0.255 access-list 11 remark -- SNMP Write and Telnet Access -- access-list 11 permit 192.168.100.0 0.0.0.255 snmp-server community foobar RO 10 snmp-server community foobar2 RW 11 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 11:28 AM -0500 From: Jim Duncan <[email protected]> To: [email protected] Subject: Re: Cisco SNMP Recommendations? Robert Osantowski writes: > Could anyone offer their suggestions for blocking SNMP requests at a network > boundary on a Cisco Router? > > I could place an ACL on the inbound Internet interface and do something like > I've shown below, but I'm wondering if there is a better way? > > Interface Serial0/0 > ip access-group example1 in > > ip access-list extended example1 > deny udp any any eq snmp > deny udp any any eq snmptrap > permit ip any any > > Any feedback would be appreciated. Thanks. Rob, this is the same thing we recommend in our advisory, http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml Jim == Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc. http://www.cisco.com/warp/public/707/sec_incident_response.shtml E-mail: [email protected] Phone(Direct/FAX): +1 919 392 6209 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 10:22 AM -0600 From: [email protected] To: [email protected] Subject: Cisco SNMP Recommendations? Could anyone offer their suggestions for blocking SNMP requests at a network boundary on a Cisco Router? I could place an ACL on the inbound Internet interface and do something like I've shown below, but I'm wondering if there is a better way? Interface Serial0/0 ip access-group example1 in ip access-list extended example1 deny udp any any eq snmp deny udp any any eq snmptrap permit ip any any Any feedback would be appreciated. Thanks. - - -Rob Osantowski - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 4:30 PM +0100 From: [email protected] To: [email protected] Subject: Bypassing ACL's to DoS Cisco routers through OOB SNMP GET's Joshua Wright writes: > And goes on to mention that the PROTOS tool may be able to DoS a router that > has no access to the MIB through the use of the community string used to > SEND trap information. As far as I understand this: As long as the SNMP Server is enabled (although no communities are defined), the cisco does evaluate SNMP PDUs. If the error is triggered *before* the community string is evaluated (for example, when evaluating the structure of the PDU or the version number), the "protection" from the community string is bypassed. > I do not understand what extra protection is gained from having a different > community string for access to the MIB and for sending SNMP traps. I > believe this is a good common practice, and using ACL's to control access to > the router is an otherwise good idea as well. Unless someone is sniffing > the segment that the SNMPv1 messages are sent out on, what is the ultimate > risk of having the community string the same for MIB access and for traps? > Has the PROTOS tool uncovered a spot in the MIB where the community string > is kept? This only works, if the traps take a different way from the router to the manager than the requests take from the manager to the router. If, in this case, the community in the trap PDU is the same as for request PDUs, the cisco would be compromised. Second: Traps may be triggered from the outside, even if the attacker has no way to access the device through the "management channel". So, the attacker could trigger and sniff a trap anytime he/she wants, while requests from the manager may be send only a few times a day. But I agree on the basic point, it's pretty useless if the attacker can sniff both traps and requests. Regards, Klaus Moeller, DFN-CERT - - -- Klaus Moeller | mailto:[email protected] DFN-CERT GmbH | http://www.cert.dfn.de/team/moeller/ Oberstrasse 14b | Phone: +49(40)808077-555 D-20144 Hamburg | FAX: +49(40)808077-556 Germany | PGP-Key: finger [email protected] - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 3:00 PM +0100 From: [email protected] To: [email protected] Subject: Bypassing Cisco ACL's for SNMP - - -----BEGIN PGP SIGNED MESSAGE----- Joshua Wright writes: > Trying to confirm or deny posting on securitydatabase.net that indicates "If > there is a snmp-communitystring defined with an ACL on it and a 'snmp-server > host' is configured with the same community-string, then a packet could be > send to the router/switch, that ignores all ACL's on the device". The > posting is possibly suspect to misinterpretation of the CERT advisory, but > otherwise scary if confirmed. Not really. This is basically a configuration error. Imagine the following configuration: access-list 1 permit host X.X.X.X access-list 1 deny any snmp-server community blah rw 1 snmp-server community blah rw So what the 3rd line says is: Allow SNMP PDUs but only from ip address X.X.X.X (depending on the definition of access-list 1) and only when the community is equal to "blah". Then the 4th line says: Allow all SNMP PDUs as long as the community string is equal to "blah". What we really have are two conflicting statements and the cisco device just obeys the last order given. These are only to options of the same statement, none of them is "superior" to the other. Really, this is IMHO just a plain dumb way to configure SNMP on ciscos. > Certainly, UDP ACL's can be bypassed easily through spoofing the > source address of the packet, but this requires knowledge of the > permit statements in the ACL as well as the community string for > access. The only safe way, as long as fixed IOS versions are not widely deployed, is to have a seperate management VPN (with IPSec on it) or to manage the routers only through SSH. Both may not be present on some devices. Of course, the canonical way would be to ditch SNMPv1 and switch to SNMPv3 with signing and encryption turned on. But that is diffucult, because a) SNMPv2 and SNMPv3 are not supported by most SNMP manager software. b) I'm not sure about the performance impact on the managers side when dealing with a lot of devices. c) I'm not sure about the performance impact on the agents side when dealing with a lot of requests in a short time. Regards, Klaus Moeller, DFN-CERT - - - -- Klaus Moeller | mailto:[email protected] DFN-CERT GmbH | http://www.cert.dfn.de/team/moeller/ Oberstrasse 14b | Phone: +49(40)808077-555 D-20144 Hamburg | FAX: +49(40)808077-556 Germany | PGP-Key: finger [email protected] - - -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface iQEVAwUBPGpxbYrEggYLt8j5AQFYIAf5AcIIsrEUGSraka5ZmG9cwhJtxzAq3T8e CTa2YnqrGhBDWdn68NG4ivqJJqweQ5FraK/0WlWBKXwjmrd5oWFP5AHt0L0MhaBL 8tC45njL6sVlG7d8gb1+/Z/3VmsbBOX9c3++veuDCuHuaq2071sraWFQuxglPIng TAEc+jAHBo+UAj9Zs8GXA1HJs3DWrOg9tO9u9aHtesXh8Mcj78jH9ycafszIzGU7 0s/N0CBXWtiUeZ/qLx0YzcmGj4KHfuXMjmh4rQlsG5pD70PEkCwBtp5v361pCjky NyK2MeW2uUs2WZLKNSGUGau7VtZT0ZugS4R9rwcZe/oCA58bCielLw== =zFlB - - -----END PGP SIGNATURE----- - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 8:16 AM -0500 From: Joshua Wright <[email protected]> To: "'[email protected]'" <[email protected]> Subject: Bypassing Cisco ACL's for SNMP Trying to confirm or deny posting on securitydatabase.net that indicates "If there is a snmp-communitystring defined with an ACL on it and a 'snmp-server host' is configured with the same community-string, then a packet could be send to the router/switch, that ignores all ACL's on the device". The posting is possibly suspect to misinterpretation of the CERT advisory, but otherwise scary if confirmed. Certainly, UDP ACL's can be bypassed easily through spoofing the source address of the packet, but this requires knowledge of the permit statements in the ACL as well as the community string for access. Can anyone provide any additional information regarding this claim? Cisco did not provide any indication in their security advisory that this is true. Thanks. - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University [email protected] pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 7:56 AM -0500 From: Joshua Wright <[email protected]> To: "'[email protected]'" <[email protected]> Subject: Bypassing ACL's to DoS Cisco routers through OOB SNMP GET's Cisco has posted a security advisory regarding malformed SNMP message-handling vulnerabilities at http://www.cisco.com/warp/public/707/cisco-malformed-snmp-msgs-pub.shtml. In their advisory, Cisco identifies a workaround that involves using an ACL to control access to the SNMP MIB on the router. The advisory continues with a caveat that mentions: "If community strings are also configured for notifications, they must be different than the community strings used for requests in order for this workaround to be effective." And goes on to mention that the PROTOS tool may be able to DoS a router that has no access to the MIB through the use of the community string used to SEND trap information. I do not understand what extra protection is gained from having a different community string for access to the MIB and for sending SNMP traps. I believe this is a good common practice, and using ACL's to control access to the router is an otherwise good idea as well. Unless someone is sniffing the segment that the SNMPv1 messages are sent out on, what is the ultimate risk of having the community string the same for MIB access and for traps? Has the PROTOS tool uncovered a spot in the MIB where the community string is kept? Any other comments on the functionality of the PROTOS tool are welcome as well. Thanks. - - -Joshua Wright Team Leader, Networks and Systems Johnson & Wales University [email protected] pgpkey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD44B4A73 fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73 - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 3:16 AM -0800 From: Noah Leaman <[email protected]> To: SNMP-Forum <[email protected]> Subject: HP OpenView and the SNMP problems How about people using HP OpenView products (e.g. Network Node Manager)... any tips to help secure oneself from this SNMP issue? - - -- Noah - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 10:50 AM +0000 From: "Clay, James" <[email protected]> To: "'[email protected]'" <[email protected]> Subject: HPUX and the SNMP problems Hello, Has anyone got any more details/experience with the SNMP problem for MC/ServiceGuard and EMS for HPUX? Thanks, Jim ********************************************************************** Information in this email is confidential and may be privileged. It is intended for the addressee only. If you have received it in error, please notify the sender immediately and delete it from your system. You should not otherwise copy it, retransmit it or use or disclose its contents to anyone. Thank you for your co-operation. ********************************************************************** - - ---------- End Forwarded Message ---------- - - ---------- Forwarded Message ---------- Date: Wednesday, February 13, 2002 11:11 AM +0100 From: Livens Wim <[email protected]> To: "'[email protected]'" <[email protected]> Subject: nmap scan Does anyone has a reliable way of scanning large address ranges for open udp snmp ports ? I tried nmap -v -sU -p161,162,199,391,1993 but this gives false positives if the packets are dropped by packet filters (ACLs on routers) The manpage seems to confirm this: The technique is to send 0 byte udp packets to each port on the target machine. If we receive an ICMP port unreachable message, then the port is closed. Otherwise we assume it is open. Since an ACL just drops the packet, nmap assumes the port is open. - - -- Wim Livens. - - ---------- End Forwarded Message ---------- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBPGqny6CVPMXQI2HJAQFWtAP+LxMWaj66sdbHADBm5tyYjsvAgxgqpu7c SNfL8k7swFE9EAh3AgI1Pwyq9qoaUsowSsmqn0EtV5HVC4XCNzvUZiXk1RL+dZls 3dg//YQS7hxHkciXCIOcJFV50VrO6KRC8s+0KsJiif44fiSbJhCnpfhwDVFEj+Co L8oMxGirxfw= =WYTP -----END PGP SIGNATURE-----
|