10669015 2003-09-09 22:52 -0400 /302 rader/ Chris Brenton <cbrenton@chrisbrenton.org>
Importerad: 2003-09-10 19:47 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <28920>
Ärende: Permitting recursion can allow spammers to steal name server resources
------------------------------------------------------------
From: Chris Brenton <cbrenton@chrisbrenton.org>
To: bugtraq@securityfocus.com
Message-ID: <3F5E9202.5030004@chrisbrenton.org>
Hi Dave,
Sorry this post is so long but I wanted to make sure testing and how
to fix the problem was spelled out exactly so people are more likely
to fix their servers.
Credits
Many thanks to William Stearns and Tanya Baccam for helping to pull
together this information.
_Executive Summary_ The default configuration of many domain name
servers (DNS) can leave you vulnerable to cache spoofing attacks as
well as allow spammers to steal resources from your servers. To
protect against these attacks, it is strongly recommended that any
name server exposed to the Internet be configured to act
non-recursively for all but trusted networks.
_Vulnerable Software_
Bind (at default settings)
Microsoft DNS (at default settings, but less so than Bind)
Probably many others
_Background_
There are three primary factors that attribute to the spammers ability
to steal your DNS resources:
1) Exposed name server configured to act recursively
2) DNS susceptibility to cache poisoning attacks
3) Poor validation by domain name registrars
First, a recursive name server is described to be a name server that
is willing to do the work in answering a DNS query. If the name
server does not have the answer to the query in cache, a recursive
name server will go out to the Internet and find an answer. A
non-recursive name server will only answer queries based on the
information in its cache. If the server does not know the answer to
the question being asked, the source is redirected to another
server, or an error code is returned.
For example, most people configure their internal name servers to act
recursively so they will lookup DNS information for the local user
base. The root name servers however are configured to act
non-recursively. They don't answer questions about specific hosts,
but rather re-direct you to the server that can answer the query
Second, DNS cache poisoning attacks are not a new problem. Excellent
papers have been written on these attacks over the years. Some good
examples are:
"Addressing Weaknesses in the Domain Name Protocol" by Christoph
Schuba
http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf
"Using the Domain Name System for system Break-ins" by Stephen
M. Bellovin ftp://ftp.research.att.com/dist/smb/dnshack.ps
"DNS Cache Poisoning - The Next Generation" by by Joe Stewart, GCIH
http://www.securityfocus.com/guest/17905
Additionally, there are a large number of tools out on the Internet
that permit an attacker to perform a variety of DNS attacks. One of
the more popular is ADMIDpack available at
http://www.securiteinfo.com/
Rather than re-invent the wheel by describing cache poisoning and how
it is done, we'll refer readers that require that information to the
above references. Instead, we will focus on what appears to be a new
trend with spammers, how it can impact your network, and what you
can do to protect yourself.
Finally, the fact that domain name registries perform extremely poor
validation of the information associated with a given domain name is
also well know. A good article on the subject can be found here:
http://news.com.com/2100-1025_3-5071523.html
_The Problem_ Just about everyone hates receiving spam and it is not
uncommon for people to lash out at the source of these
messages. Spammers know this, which is why they go to such great
lengths to hide their tracks. Spammers that set up legitimate
domains frequently find themselves to be the recipient of Denial of
Service (DoS) attacks, or discover that their Internet connectivity
is quickly terminated by their upstream ISP. One of the stealthy
tricks spammers have developed is to find mis-configured mail
servers that will permit them to relay their spam messages (this is
a well known technique). If the mail server gets attacked or blocked
by the Internet community, the spammer simply moves on to another
open mail relay. Of course the legitimate owner of the mail server
is not so lucky.
In an escalation of arms, it appears that some people also take
action against the spammer's name servers as well. The thought
process is that if the Internet community can take out the spammer's
DNS (note we are not advocating this practice, just describing it),
click though links in their spam messages as well as Web bugs and
the like may no longer function. This can severely hinder the
spammers ability to figure out which messages were actually
received, as well as the amount of interest generated by the
message. Unfortunately, spammers have found a way around this
problem in a similar fashion to the open SMTP relay method described
above. Instead of targeting mis-configured mail relays however, they
target mis-configured name servers.
Here's how it works. The spammer registers a domain name using name
servers that are under their control. Note that we found no
consistency in the amount of time that spammers use when registering
a domain name. It could be anywhere from a year to 10 years. Also,
we found no consistency with the registrar authority being used. The
spammers we tracked used a range of authorities.
Next the spammer seeks out name servers on the Internet that have
been mis-configured to act recursively for anyone. Unfortunately,
this appears to be a fairly easy task as testing we performed showed
that an overwhelming majority of the exposed name servers on the
Internet act recursively.
After that, the spammer populates the recursive name server with host
information regarding their spam domain. We prefer not to go into a
whole lot of detail as to how this is done, as we prefer not to train
script kiddie spammers on how to leverage this attack. Suffice to say
that once the spammer is finished, the target server contains cached
information about the spam domain. The amount of time this
information will be cached varies depending on the time to live
(TTL) values used by the spammer.
Next the spammer goes back to their registry authority and changes
their authoritative name servers to be the recursive name servers
they populated in the last step. Since it appears that registry
authorities no longer validate if a customer has permission to use
the name server they specify (note that this used to be done way
back when domain names were free), the record is quickly updated and
users on the Internet are directed to this populated name server
when querying information about the spammer's domain. The spammer is
now free to push out their spam and if the Internet community
decides to attack, the name server being attacked actually belongs
to someone else.
There is a limiting factor in all of this. Most name server software
allows you to specify a maximum amount of time that the server will
cache information. In other words, if the spammer attempts to set a
TTL cache value of 90 days, the name server doing the caching may
quietly truncate the TTL value to a lower setting.
For example, the maximum TTL cache time with Microsoft DNS is set
through the MaxCacheTtl registry key value. The default value is one
day. This gives a very small window of time that the spammer could
use to populate the name server, change their registry information,
send out their spam, and expect replies to come back. This makes
Microsoft DNS far less susceptible to this attack (by default) than
other name servers.
Bind limits this cache time though the max-cache-ttl parameter. The
default setting is seven days. Given that most registry authorities
make changes in 24 hours or less, this is still ample time to push
out spam messages and see who replies.
Please note that the root cause of the problem is not how long the
information is being cached. The real problem is that the server is
acting recursively by default. The above information has been included
in order to help identify the magnitude of the problem with different
name server software packages. Longer caching is actually preferred as
it helps to improve performance.
_How to fix the problem_
Fixing the problem varies depending on whether you are running Bind,
Microsoft DNS, or some other software. Regardless of what you are
running, testing to see if you are vulnerable is a consistent process.
Run the following command from a remote UNIX or Windows system. You
want to run this from a system that *should not* have recursive
access to your exposed name servers. DO NOT try this from an
internal host first, as it will skew your results. Good choices are
an external shell account, your home system, or possibly have a
trusted friend do the testing for you.
Here is the command to run:
nslookup bogus.spam-free-zone.com <IP address of the server to test>
If the command returns similar to the following:
Non-authoritative answer:
*** Can't find bogus.spam-free-zone.com: No answer
You name server is configured properly. Pass directly to "GO" and
collect $200. :-)
If however you get back an answer similar to:
Name: bogus.spam-free-zone.com
Address: 172.29.217.137
your name server is improperly configured to act recursively for
everyone on the Internet, and needs to be changed.
_Fixing the problem with Bind_
Changing Bind so that it will not act recursively for all hosts on the
Internet is a relatively simple process. Edit the /etc/named.conf file
to add in the "allow-recursion" parameter similar to the following:
options {
directory "/var/named";
allow-recursion {localnets; };
};
Note that you may already have additional options defined, which is
just fine. The important thing is to add in the allow-recursion line
as shown. The above command tells Bind to only act recursively for
systems that are part of the same logical subnet as the Bind
server. This way if there is a local SMTP or HTTP server than needs
to do name resolution, this functionality will continue to work. All
other subnets however will be blocked from doing recursive
queries. Users on the Internet will only be permitted to look up
information you are authoritative for (like your Web server's IP
address, your MX record, etc.). This will protect you from the
current round of spammers stealing name server resources.
If you need to have the Bind server act recursively for multiple
subnets, simply specify them in CIDR format, separated by commas. For
example:
allow-recursion {172.16.1.1, 10.0.0.0/8, 192.168.1.0/24;};
_Fixing the problem with Microsoft DNS_
Unfortunately, Microsoft DNS is not quite as configurable as Bind when
it comes to tweaking recursion. Your options are to either enable or
disable recursion; you cannot make exceptions for certain subnets like
we could with Bind using the allow-recursion parameter.
This can cause problems if there is a local SMTP, HTTP, etc. server
that relies on the Microsoft DNS server to perform recursive
queries. Disabling recursion will break this required
functionality. If you are in this situation, you may need to do one
or more of the following additional steps along with disabling
recursion on your exposed Microsoft DNS server:
1) Re-configure these systems to direct recursive queries though some
other name server, such as your upstream ISP 2) Run a local DNS
process on each of these systems but do not make TCP/53 and UDP/53
directly accessible from the Internet to these systems. 3) Replace
the server with a Bind server and use the allow-recursion parameter.
To disable recursion on a Microsoft DNS server from the command line,
run the following command while having Administrator level access to
the system:
dnscmd <server name> /config /NoRecursion 1
If you prefer to use the GUI interface, open Administrative Tools and
then DNS, and click on the following:
Properties--> Advanced --> Server Options --> Disable recursion --> OK
_Verifying that recursion is now disabled_
If you believe you have recursion properly disabled, you can test it
from an outside host in a similar fashion to the testing we performed
earlier:
nslookup bogus1.spam-free-zone.com <IP address of the server to test>
The IP address of this host is 172.29.217.138. Again, if you get a
failed lookup, the test is successful and your DNS server is safe
from recursive attacks. You can verify that recursion is working
properly by running the same command from an internal host. If the
command returns the above IP address, the name server is functioning
properly.
_Additional testing_
If you would like to verify that a domain's name server is acting as a
proper authoritative name server, rather than serving up cached
information only, the host command works quite nicely:
$host -C spam-free-zone.com
Nameserver host2.spam-free-zone.net:
spam-free-zone.com SOA host2.spam-free-zone.net.
postmaster.spam-free-zone.net. 200309091 28800 900 1209600 86400
Nameserver dns1.chrisbrenton.org:
spam-free-zone.com SOA host2.spam-free-zone.net.
postmaster.spam-free-zone.net. 200309091 28800 900 1209600 86400
A server that is suppose to be authoritative for a domain, but is only
serving up the information via cache would return no information.
You can configure Sendmail to reject SMTP messages when the name
servers for the domain are supposed to be authoritative, but are
actually serving up information from cache. Simply edit your
sendmail.mc file and comment out (add dnl to the beginning of the
line) the "accept_unresolvable_domains" option, similar to the
following:
dnl FEATURE(`accept_unresolvable_domains')dnl
Then just rebuild a new sendmail.cf file, restart Sendmail, and you
are cooking with gas. Rejected e-mails will get logged with the
following error code:
reject=451 4.1.8 Domain of sender address mail@iamastinkyspammer.com
does not resolve)
In our testing this tweak resulted in zero legitimate e-mails getting
dropped, but your mileage may vary. We are unable to come up with a
legitimate reason as to why someone would configure their domain this
way on purpose, and in fact it's in violation of the RFCs. It's
possible however that someone you communicate with has incorrectly
configured their domain this way, so watch your logs to see if you
start rejecting legitimate e-mails.
(10669015) /Chris Brenton <cbrenton@chrisbrenton.org>/(Ombruten)
Kommentar i text 10669829 av Mark Johnston <mjohnston@skyweb.ca>
Kommentar i text 10669862 av Greg A. Woods <woods@weird.com>
Kommentar i text 10670297 av Dan Harkless <bugtraq@harkless.org>
Kommentar i text 10691052 av Devin Nate <devin.nate@bridgecomm.net>
10669829 2003-09-10 13:21 -0500 /48 rader/ Mark Johnston <mjohnston@skyweb.ca>
Importerad: 2003-09-10 22:45 av Brevbäraren
Extern mottagare: Chris Brenton <cbrenton@chrisbrenton.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <28938>
Kommentar till text 10669015 av Chris Brenton <cbrenton@chrisbrenton.org>
Ärende: Re: Permitting recursion can allow spammers to steal name server resources
------------------------------------------------------------
From: Mark Johnston <mjohnston@skyweb.ca>
To: Chris Brenton <cbrenton@chrisbrenton.org>
Cc: bugtraq@securityfocus.com
Message-ID: <20030910182154.GA1788@omoikane.mb.skyweb.ca>
Chris Brenton <cbrenton@chrisbrenton.org> wrote:
> Changing Bind so that it will not act recursively for all hosts on the
> Internet is a relatively simple process. Edit the /etc/named.conf file
> to add in the "allow-recursion" parameter similar to the following:
>
> options {
> directory "/var/named";
> allow-recursion {localnets; };
> };
>
> All other subnets however will
> be blocked from doing recursive queries. Users on the Internet will only
> be permitted to look up information you are authoritative for (like your
> Web server's IP address, your MX record, etc.).
That's not entirely true. BIND (9, at least) is still vulnerable to
cache poisoning by local users, after which it will serve up the
cached answers to anyone that can query (not just
recursion-authorized clients.) Try looking up a domain you aren't
authoritative for from a recursion-authorized client, then from an
unauthorized one. You'll get the cached answer with the unauthorized
client. Of course, given an ISP or corporation, it's trivial to make
one of their users look up your hostname.
The rationale, as I understand it, is that returning a cached answer
doesn't require recursion, so allow-recursion doesn't apply.
The proper way to avoid this problem is to configure BIND to deny all
queries except ones you specifically want to answer:
options {
allow-query { localnets; };
allow-recursion { localnets; };
};
zone "example.com" { # An authoritative zone
allow-query { any; };
# other example.com statements
};
Mark
(10669829) /Mark Johnston <mjohnston@skyweb.ca>/(Ombruten)
10669862 2003-09-10 15:14 -0400 /83 rader/ Greg A. Woods <woods@weird.com>
Importerad: 2003-09-10 22:54 av Brevbäraren
Extern mottagare: Chris Brenton <cbrenton@chrisbrenton.org>
Extern kopiemottagare: bugtraq@securityfocus.com
Externa svar till: woods@planix.com
Mottagare: Bugtraq (import) <28939>
Kommentar till text 10669015 av Chris Brenton <cbrenton@chrisbrenton.org>
Ärende: Re: Permitting recursion can allow spammers to steal name server resources
------------------------------------------------------------
From: "Greg A. Woods" <woods@weird.com>
To: Chris Brenton <cbrenton@chrisbrenton.org>
Cc: bugtraq@securityfocus.com
Message-ID: <m19xAPq-000B1TC@proven.weird.com>
[ On Tuesday, September 9, 2003 at 22:52:50 (-0400), Chris Brenton wrote: ]
> Subject: Permitting recursion can allow spammers to steal name server resources
>
> _Executive Summary_
> The default configuration of many domain name servers (DNS) can leave
> you vulnerable to cache spoofing attacks
Note such attacks can still come from within your "trusted" networks
so I'm not sure there's too much point to discussing this problem in
relation to allowing global recursion.
Often those same servers which are the target of spammers will also be
specifically designed to supply recursive caching DNS for vast numbers
of customer machines, some of which may already be "owned" by spammers
who have employed cracker tools for this very purpose.
The real problem here of course lies with the registrars, just as
you've described. All registrars really must make 100% certain that
they're not being fooled by what may only be in a server's cache when
they check that a server is authoritative for the zone being
delegated to it. Perhaps this can be done by instituting a policy to
revoke registrar licenses when they fail to implement such checks
properly. After all this is a much more important security issue
than it is an anti-spam issue.
> as well as allow spammers to
> steal resources from your servers.
No kidding! ;-)
> Next the spammer seeks out name servers on the Internet that have been
> mis-configured to act recursively for anyone. Unfortunately, this
> appears to be a fairly easy task as testing we performed showed that an
> overwhelming majority of the exposed name servers on the Internet act
> recursively.
This is because there is tremendous utility in allowing arbitrary
persons to query a cache -- the lack of this ability makes debugging
certain kinds of DNS related problems very difficult since it turns a
two-second job into something that can stretch into days while people
play telephone tag and such. As I'll show below I don't think there's
any need to employ such drastic measures as completely disabling
recursive lookups from public networks -- only limiting their impact.
Note that spammers will also simply (ab)use third party open DNS
servers to resolve MX records for the domains they are spamming to.
This is happening on an increasing frequency and while it's usually
very easy for the operators of the abused server(s) to block the
offending spammer, such things to take time to discover and diagnose
and may trigger customer complaints and dissatisfaction in the mean
time.
I've been hoping to find time soon to implement response rate
limiting for BIND such that only a very limited number of queries per
minute will be answered for all non-trusted networks.
In the mean time it may be sufficient to use traffic shaping
mechanisms to limit the amount of abuse to open cache servers while
still allowing normal debugging efforts to procede un-hindered.
Of course all this depends on the registrars implementing better
checks to guarantee that their domains are only ever delegated to
truly authoritative nameservers. As I point out at the beginning
this really has to happen somehow regardless.
Thank you very much for raising this issue in such a well written
report!
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com> Secrets of the Weird <woods@weird.com>
(10669862) /Greg A. Woods <woods@weird.com>/(Ombruten)
10670297 2003-09-10 12:29 -0700 /45 rader/ Dan Harkless <bugtraq@harkless.org>
Importerad: 2003-09-11 00:50 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <28950>
Kommentar till text 10669015 av Chris Brenton <cbrenton@chrisbrenton.org>
Ärende: Re: Permitting recursion can allow spammers to steal name server resources
------------------------------------------------------------
From: "Dan Harkless" <bugtraq@harkless.org>
To: bugtraq@securityfocus.com
Message-ID: <200309101929.h8AJTvLq017076@www.harkless.org>
On September 9, 2003, Chris Brenton <cbrenton@chrisbrenton.org> wrote:
[...]
> "DNS Cache Poisoning - The Next Generation" by by Joe Stewart, GCIH
> http://www.securityfocus.com/guest/17905
[...]
> _Fixing the problem with Bind_
You aren't making any distinction between different versions of BIND,
but you probably should be. The traditional easy cache poisoning
attack using extra records in the "ADDITIONAL" section is resisted by
BIND 9, but BIND 4 and 8 are still vulnerable, IIRC. Against BIND 9
you'd have to use address, port, and transaction ID spoofing, as Joe
Stewart discusses in his article, which raises the bar for entry
quite a bit.
> Changing Bind so that it will not act recursively for all hosts on the
> Internet is a relatively simple process. Edit the /etc/named.conf file
> to add in the "allow-recursion" parameter similar to the following:
>
> options {
> directory "/var/named";
> allow-recursion {localnets; };
> };
[...]
> allow-recursion {172.16.1.1, 10.0.0.0/8, 192.168.1.0/24;};
As has been pointed out before, this still leaves you potentially
open to cache poisoning if the attacker can spoof those addresses
(and again, the attacker will need to be spoofing anyway, if
attacking BIND 9).
The safest setup is to run authoritative nameservers on separate
machines (or at least IPs) from caching recursive servers, as
discussed, e.g. here:
http://cr.yp.to/djbdns/separation.html
--
Dan Harkless
bugtraq@harkless.org
http://harkless.org/dan/
(10670297) /Dan Harkless <bugtraq@harkless.org>/(Ombruten)
Kommentar i text 10670287 av Mike Hoskins <mike@adept.org>
10670287 2003-09-10 15:00 -0700 /51 rader/ Mike Hoskins <mike@adept.org>
Importerad: 2003-09-11 00:45 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <28949>
Kommentar till text 10670297 av Dan Harkless <bugtraq@harkless.org>
Sänt: 2003-09-11 00:50
Ärende: Re: Permitting recursion can allow spammers to steal name server resources
------------------------------------------------------------
From: Mike Hoskins <mike@adept.org>
To: bugtraq@securityfocus.com
Message-ID: <20030910144350.S48700@fubar.adept.org>
On Wed, 10 Sep 2003, Dan Harkless wrote:
> On September 9, 2003, Chris Brenton <cbrenton@chrisbrenton.org> wrote:
> [...]
> > "DNS Cache Poisoning - The Next Generation" by by Joe Stewart, GCIH
> > http://www.securityfocus.com/guest/17905
> [...]
> > _Fixing the problem with Bind_
<snip>
> > allow-recursion {172.16.1.1, 10.0.0.0/8, 192.168.1.0/24;};
> As has been pointed out before, this still leaves you potentially open to
> cache poisoning if the attacker can spoof those addresses (and again, the
> attacker will need to be spoofing anyway, if attacking BIND 9).
luckily more providers have began properly filtering at ingress.
granted, spoofing is still quite possible from a large percentage of
IPv4 space.
> The safest setup is to run authoritative nameservers on separate machines
> (or at least IPs) from caching recursive servers, as discussed, e.g. here:
FWIW, i think this can be derived from Joe's article as well. also,
anyone configuring BIND should see Rob Thomas' _Secure BIND Template_,
http://www.cymru.com/Documents/secure-bind-template.html
everything discussed here relating to BIND configuration (and more) is
covered there.
i'd also like to point out that the title of this thread is a bit
misleading, or at least not 100% accurate wrt the suggestions being
given. yes, we can arrive at a relatively secure DNS implementation
using BIND or other alternatives... however, even with a secure
implementation, h4x0rz can 'steal name server resources'; if you have
a resolver (recursive or not) attached to the public Internet, it can
be bombarded with queries. that, like many forms of 'legitimate
use', is 'steal[ing] ... resources' and can't be easily avoided (only
mitigated). ;) it's also one of the more frequent things i see
reported on mailing lists these days... particularly thanks to M$.
-mrh
--
From: "Spam Catcher" <spam-catcher@adept.org>
To: spam-catcher@adept.org
Do NOT send email to the address listed above or
you will be added to a blacklist!
(10670287) /Mike Hoskins <mike@adept.org>/(Ombruten)
10691052 2003-09-13 21:15 -0600 /31 rader/ Devin Nate <devin.nate@bridgecomm.net>
Importerad: 2003-09-15 18:42 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <29004>
Kommentar till text 10669015 av Chris Brenton <cbrenton@chrisbrenton.org>
Ärende: Re: Permitting recursion can allow spammers to steal name server resources
------------------------------------------------------------
From: Devin Nate <devin.nate@bridgecomm.net>
To: bugtraq@securityfocus.com
Message-ID: <3F63DD4F.2080001@bridgecomm.net>
Nice work Chris & Team;
For folks that want to check if an email sender domain is being
served by an authoritative nameserver, don't have sendmail, and have
SpamAssassin, I've submitted patches to the SpamAssassin project to
add this check.
For those interested in adding this, the SA bug link is:
http://bugzilla.spamassassin.org/show_bug.cgi?id=2432
Thanks,
Devin Nate
--
____________________________________________________________
Devin Nate
Chief Consultant & General Manager
BridgeComm Corporation
http://www.bridgecomm.net/
mailto:devin.nate@bridgecomm.net
____________________________________________________________
(10691052) /Devin Nate <devin.nate@bridgecomm.net>/(Ombruten)
Bilaga (application/x-pkcs7-signature) i text 10691053
10691053 2003-09-13 21:15 -0600 /20 rader/ Devin Nate <devin.nate@bridgecomm.net>
Bilagans filnamn: "smime.p7s"
Importerad: 2003-09-15 18:42 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <29005>
Bilaga (application/x-pkcs7-signature) till text 10691052
Ärende: Bilaga (smime.p7s) till: Re: Permitting recursion can allow spammers to steal name server resources
------------------------------------------------------------
0 *H÷
01 0 + 0 *H÷
²000 ENµ ÿùÙÃÉÙ:#0
*H÷
0_1 0 UUS10U
VeriSign, Inc.1705U .Class 1 Public Primary Certification Authority0
020122000000Z
070121235959Z0«10U
Soltrus1 0 U VeriSign Trust Network1:08U 1Terms of use at https://www.soltrus.com/rpa (c)021:08U1Soltrus Class 1 Consumer Individual Subscriber CA00
*H÷
0 ¼öæHvCwX+SåÞWBQÚ e͵Bûooÿú?øFÈÕ\-¹¶ÀÃÅüÚx·ùx®SSN±2ÝSë 3møFpÊ&P7ÿÁô.2æÔ¶¦]QÙN¨þ«Ê íêDw"µf
uüÞÿñÿâÅ&Øó £00U 0ÿ 0CU <0:08 `HøE0)0'+https://www.soltrus.com/rpa0 U 0 `HøB0$U 0¤010U Class1-2-1-50
*H÷
cÒ¶éÔ© ¾Þ"j°VζÅó §cmÄ{CS}d
ÓEô'Må`gß=Á[zÍkÌ ÷»ßüým»µ p¡á|DÇdHerôȤ¬«æÓ´¦¾ø²¹¿Öø²|ü3wQ$-
ø÷Ð7H»=â]0;0¤ *XãWÑ,ÂdIÔ®0
*H÷
0«10U
Soltrus1 0 U VeriSign Trust Network1:08U 1Terms of use at https://www.soltrus.com/rpa (c)021:08U1Soltrus Class 1 Consumer Individual Subscriber CA0
030907000000Z
040906235959Z0>10U
Soltrus1(0&U Consumer Service Center Class
11200U )Terms of use at www.soltrus.com/rpa
(c)021'0%U Authenticated by Soltrus,
Inc.1'0%U Member, VeriSign Trust
Network1 0 U Persona Not
Validated10U Digital ID Class 110U Devin
Nate1(0&
*H÷
devin.nate@bridgecomm.net0"0
*H÷
0
®äÕBã³#ÒçÒ²7
$4µÉiÏã9;Å5êQéþÖ¿¾^kfæ+ÀÎdÌÅyà^Ŧ¾Á: _³f`e6ä%[wZÂ=¹´ï¿Ë«õÕ¬N
ï;óå _°:õÒP¤C«åiÉ4"fÂ=T° `RÂY«û7êsÎdö¨S-Ŷ3çv^É«ßcÑ6Ç~<ÀBÔsMÛ:ܸ"Ðo  ÊÇoË,D$+Ip1»1ü¨ËÍ~ôÌhA'ªéô,JËhP = ¥Á,UduP Û×t7ÉíâAN5ìÚÕ¥- ÒS + £D0@0 U 0 0^U W0U0S Q OMhttp://onsitecrl.soltrus.com/SoltrusConsumerServiceCenterClass1/LatestCRL.crl0¬U ¤0¡0 `HøE00(+ https://www.verisign.com/CPS0b+0V0VeriSign, Inc.0=VeriSign's CPS incorp. by reference liab. ltd. (c)97 VeriSign0 `HøB0
`HøE ÿ0
*H÷
î¥Õà@î¿W¦
Ø<ú¬g® #/]âX¦ÃyÖíX$WáY<óA ãzGÃù "-@N}åb3/9pÛ?
°ä7¤ÓGy~©-Ç3Ú$Lm:)68<3» ½½Õúî V õR$¿å¯Dîù £ð0;0¤ *XãWÑ,ÂdIÔ®0
*H÷
0«10U
Soltrus1 0 U VeriSign Trust Network1:08U 1Terms of use at https://www.soltrus.com/rpa (c)021:08U1Soltrus Class 1 Consumer Individual Subscriber CA0
030907000000Z
040906235959Z0>10U
Soltrus1(0&U Consumer Service Center Class
11200U )Terms of use at www.soltrus.com/rpa
(c)021'0%U Authenticated by Soltrus,
Inc.1'0%U Member, VeriSign Trust
Network1 0 U Persona Not
Validated10U Digital ID Class 110U Devin
Nate1(0&
*H÷
devin.nate@bridgecomm.net0"0
*H÷
0
®äÕBã³#ÒçÒ²7
$4µÉiÏã9;Å5êQéþÖ¿¾^kfæ+ÀÎdÌÅyà^Ŧ¾Á: _³f`e6ä%[wZÂ=¹´ï¿Ë«õÕ¬N
ï;óå _°:õÒP¤C«åiÉ4"fÂ=T° `RÂY«û7êsÎdö¨S-Ŷ3çv^É«ßcÑ6Ç~<ÀBÔsMÛ:ܸ"Ðo  ÊÇoË,D$+Ip1»1ü¨ËÍ~ôÌhA'ªéô,JËhP = ¥Á,UduP Û×t7ÉíâAN5ìÚÕ¥- ÒS + £D0@0
U 0 0^U W0U0S Q OMhttp://onsitecrl.soltrus.com/SoltrusConsumerServiceCenterClass1/LatestCRL.crl0¬U
¤0¡0 `HøE00(+ https://www.verisign.com/CPS0b+0V0VeriSign,
Inc.0=VeriSign's CPS incorp. by reference liab. ltd. (c)97
VeriSign0 `HøB0
`HøE
ÿ0
*H÷
î¥Õà@î¿W¦
Ø<ú¬g® #/]âX¦ÃyÖíX$WáY<óA
ãzGÃù "-@N}åb3/9pÛ?
°ä7¤ÓGy~©-Ç3Ú$Lm:)68<3» ½½Õúî V õR$¿å¯Dîù £ð1G0C0À0«10U
Soltrus1 0 U VeriSign Trust Network1:08U 1Terms of use at https://www.soltrus.com/rpa (c)021:08U1Soltrus Class 1 Consumer Individual Subscriber CA*XãWÑ,ÂdIÔ®0 + [0 *H÷
1 *H÷
0 *H÷
1
030914031527Z0# *H÷
1y ÅXp
ü~¿öÓvHM/0R *H÷
1E0C0
*H÷
0*H÷
0
*H÷
@0+0
*H÷
(0Ñ +71Ã0À0«10U
Soltrus1 0 U VeriSign Trust Network1:08U 1Terms of use at https://www.soltrus.com/rpa (c)021:08U1Soltrus Class 1 Consumer Individual Subscriber CA*XãWÑ,ÂdIÔ®0Ó *H÷
1Ã À0«10U
Soltrus1 0 U VeriSign Trust
Network1:08U 1Terms of use at https://www.soltrus.com/rpa
(c)021:08U1Soltrus Class 1 Consumer Individual Subscriber
CA*XãWÑ,ÂdIÔ®0
*H÷
¦ síÜh¥÷èÜ
uW+A¿Ï.òöËÚkå Ť«¥!ܤ³]W`±ÆøݲO_b#KÐ
Ïò¤Ð5ã'l ]L PÄyà1Ðï¢nÕ*ãZ9¸õ ûûÉ?N½fn9zé s t¾æ<Þa³ø°Æ¥÷ÐGUëär
Þç0~²]bº¢
s1;}`L¹ÝV£úuÕû¥r(7@Ì÷ËÅ*fM
Ä3uQºÈì_+¡¡$®ap])`ýè©yWK]ë©Ý:ëöp.±t2L=êÓ=\Þê£B WB1$¸6Ò"OÌ kz
(10691053) /Devin Nate <devin.nate@bridgecomm.net>/(Ombruten)