EXHIBIT 1 

REDACTED

PUBLIC VERSION

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 1 of 165
UNITED STATES DISTRICT COURT 

NORTHERN DISTRICT OF CALIFORNIA 

SAN FRANCISCO DIVISION 

FEDERAL TRADE COMMISSION, 

Plaintiff, CIVIL ACTION NO. 

3:l 7-CV-00039-JD 

V. 

D-LINK SYSTEMS, INC.,

Defendant. 

EXPERT REPORT OF MARK G. GRAFF, CISSP 

Dated: July 6, 2018 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 2 of 165
2 

TABLE OF CONTENTS 

I. Introduction ....................................................................................................................... 5

A. Summary of Experience and Qualifications ....................................................... 5

B. Scope of Opinion ................................................................................................... 8

C. Materials Considered in Forming My Opinion.................................................. 9

D. Compensation ........................................................................................................ 9

II. Summary of Expert Opinion............................................................................................ 9

III. Expert Opinion ................................................................................................................ 11

A. Background on Software .................................................................................... 11

1. Software is a Critical Component of Routers and IP Cameras .............. 11

2. Software Vulnerabilities ............................................................................. 17

3. Formalization of the Expert Field of Software Security .......................... 22

4. Industry Checklists and Protocols for Secure Software Development

Cycles. ........................................................................................................... 24

5. Maturity Models and Secure Development Lifecycles ............................. 28

B. D-Link Systems, Inc. and D-Link Corporation: The Organizations and

Their Respective Responsibilities ...................................................................... 29

1. D-Link Corporation .................................................................................... 30

2. D-Link Systems ............................................................................................ 33

C. D-Link Systems Lacked the Practices and Controls to Develop Software

in a Secure Way and to Systematically Address Vulnerabilities .................... 38

1. Absence of Indications of Seriousness ....................................................... 38

2.

 .................................................................. 42

3. No Independent Ability to Determine Safety of Products ....................... 47

4. No Internal Procedures to Track Vulnerabilities ..................................... 48

5. Ignored Repeated Warnings that Security Practices Were

Inadequate .................................................................................................... 54

6. “Trust” Is Not Enough ................................................................................ 56

D. The Fundamental Code Development Failures that Repeatedly Appeared

in D-Link Routers and IP Cameras Demonstrate that D-Link Systems’

Trust in D-Link Corporation and its Vendors was Misplaced ....................... 58

1.

............................................................................................................. 59

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 3 of 165
3 

2. .......................................................................... 64

3. Unnecessary System() Library Calls ......................................................... 70

4. Unnecessary Protocols and Services .......................................................... 72

5. Backdoors: Hard-Coded and Undocumented Credentials ...................... 74

6. Clear Text Passwords .................................................................................. 78

7. Code Maintenance Failures ........................................................................ 80

8. Private Key Exposure ................................................................................. 83

E. Critical Vulnerabilities that Appear in D-Link Routers and IP Cameras .... 87

1. Router Vulnerabilities ................................................................................. 89

2. Camera Vulnerabilities ............................................................................. 108

3. Failing to Encrypt Mobile App Credentials ............................................ 117

4. Code Signing Key Exposure ..................................................................... 119

F. D-Link Systems’ Limited Affirmative Processes and Procedures Were

Inadequate ......................................................................................................... 122

1. D-Lab and Vendor Testing....................................................................... 124

2. III/Onward Security .................................................................................. 127

3. Short-Lived Bug Bounty Program ........................................................... 132

4. Other Security Practices ........................................................................... 134

5. Recent Efforts to Address Security .......................................................... 135

G. Many D-Link Routers and IP Cameras Were Not Secure From

Unauthorized Access or Control ...................................................................... 146

1. From December 2013 to September 2015, D-Link Systems Failed to

Take Reasonable Steps to Secure D-Link Routers and IP Cameras

From Unauthorized Access ....................................................................... 146

2. The DIR-615 Was Not Secured From Unauthorized Access or

Control ........................................................................................................ 146

3. The DIR-412 Was Not Secured From Unauthorized Access or

Control ........................................................................................................ 147

4. The DIR-815 Was Not Secured From Unauthorized Access or

Control ........................................................................................................ 148

5. The DIR-645 Was Not Secured From Unauthorized Access or

Control ........................................................................................................ 148

6. Many D-Link IP Cameras Were Not Secure From Unauthorized

Access or Control ....................................................................................... 148

Appendix A List of Router and IP Cameras ........................................................................ A-1 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 4 of 165
4 

Appendix B Experience, Qualifications, Testimony, and Publications ..............................B-1 

Appendix C Materials Considered ........................................................................................ C-1 

Appendix D Bibliography of Selected Secure Coding Books ............................................. D-1

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 5 of 165
5 

I. Introduction

A. Summary of Experience and Qualifications

1. I have worked as an Information Technology professional since 1975, and completed a

Bachelor of Science degree in computer science in 1978. I first worked professionally in cyber 

security in 1986, and have specialized in security since 1994. My areas of focus include the 

cyber defense of enterprise networks; secure coding, including the prevention and detection of 

software vulnerabilities; and the protection of election systems against cyber attack. I have 

written several books in the field, including the seminal Secure Coding (2003), with Kenneth van 

Wyk.1

2. I am a Certified Information Systems Security Professional (CISSP). The CISSP is the

primary international credential establishing information security expertise. The international 

body that certifies information security professionals, awarding the CISSP credential, is called 

(ISC)2. The (ISC)2 publishes a “common body of knowledge” on information security called the 

“The Official (ISC)2 Guide CISSP CBK Reference.” I recently authored the chapter on 

Identification and Access Control in the fifth edition of this book (forthcoming 2018).2

 

3. Currently, I am working as the head of Tellagraff LLC, a consulting firm. Prior to this

role, I served for three years as the Chief Information Security Officer for NASDAQ, leaving in 

2015. I was responsible for both cyber defense and application security at NASDAQ. From 

1

 MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING: PRINCIPLES & PRACTICES (2003), 

http://securecoding.org. My book with Mr. van Wyk is cited broadly. Indeed, I was pleased to see that III/Onward 

Security, whom I discuss in greater detail below at Section III.F.2, cited our book in a 2016 presentation to D-Link 

Corporation about secure software development. See III/Onward Secure Coding Presentation (Sept. 8, 2016) 

(DKC0005191–287, at DKC0005283) (citing our book, SECURE CODING, as the first resource in the section of the 

presentation titled “Reference”). The presentation is partially in Chinese, but the English content makes clear that it 

is a software security training presentation. 

2

 THE OFFICIAL (ISC)2 GUIDE CISSP CBK REFERENCE (5th ed. forthcoming 2018) (ISBN 9781119423348). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 6 of 165
6 

2003 to 2012, I was head of cyber security at Lawrence Livermore National Laboratory, 

responsible for unclassified as well as classified national security matters. 

4. My formal experience as a cyber security professional began during my employment with

Sun Microsystems (1992–2000). At Sun Microsystems (“Sun”), I became deeply involved in the 

question of how software developers could consistently design and code software resistant to 

exploitation by attackers. In 1994, I became the Security Coordinator for Sun. 

5. As Security Coordinator, I collected reports of all vulnerabilities in Sun products, as well

as in related technologies such as the UNIX operating system. In this capacity, I worked with 

internal engineers as well as with reports from customers, external security groups (e.g., 

Carnegie Mellon’s CERT), and law enforcement agencies such as the FBI. I was then 

responsible for ensuring that all Sun vulnerabilities were fixed—sometimes doing the 

maintenance myself, sometimes monitoring the work of other Sun teams—and then releasing 

and announcing the updated software in the form of “patches” to the worldwide Sun customer 

base. In the course of this work focusing on software vulnerabilities, I became acquainted with 

(and often coordinated code fixes and bug reports with) many of the teams and agencies leading 

the development of improved processes to prevent, detect, and respond to security 

vulnerabilities. One of my personal contributions to the developing state of the art was the use of 

cryptographic checksums as part of the release of new Sun software and patches.3

 I believe I 

was the first to institute the practice, in 1997. Such checksums are now ubiquitous. 

3

 Checksums allow users to verify that the patch has not been altered in transit. In terms of confidentiality, integrity, 

and availability, checksums guard against attacks on integrity. See ISO 27002, Section 10.1 Cryptographic controls

(“There should be a policy on the use of encryption, plus cryptographic authentication and integrity controls such as 

digital signatures and message authentication codes, and cryptographic key management.”), 

http://www.iso27001security.com/html/27002.html. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 7 of 165
7 

6. From 1992 to 1998, I served as a member of the Steering Committee of the Forum of

Incident Response and Security Teams (“FIRST”), the first international association of security 

specialists.4 I served as chair of FIRST for two years in the mid-1990s. In this capacity, I was in 

frequent contact with many of the top security practitioners in the world. 

7. These connections into the emerging world of software security remained useful when,

after leaving Sun, I worked for two years as Chief Scientist of the security startup Para-Protect. 

In 2001, I researched and wrote for a Para-Protect client my first summary of the history, best 

practices, and challenges inherent to security-conscious programming, “Secure Coding: the State 

of the Practice.”5 This white paper served as the foundation for the 2003 book Secure Coding, 

which I co-wrote with Kenneth R. van Wyk.6 Secure Coding was well received and, since its 

release in 2003, has been used in several universities around the world as a reference for sound 

programming practice. It has also been recommended at various times for study by companies 

such as Microsoft, Google, and Veracode, as well as by many security researchers and 

associations. 

8. As the Chief Information Security Officer for NASDAQ, I was responsible both for the

information security of the company and the secure development of the software produced and 

sold by NASDAQ. NASDAQ is, in part, a software company; it supplies, in my understanding, 

approximately eighty percent of global stock exchange software. Members of my security 

groups functioned as internal consultants to the development teams. There were several software 

4

 See FIRST, The global Forum of Incident Response and Security Teams (“The purpose of FIRST was to foster 

cooperation and coordination in incident prevention, to stimulate rapid reaction to incidents, and to promote 

information sharing among members and the community at large”), https://www.first.org/. 

5

 MARK G. GRAFF, SECURE CODING: THE STATE OF THE PRACTICE (Para-Protect Services, Inc., White Paper, 2001). 

6

 MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING: PRINCIPLES & PRACTICES (2003), 

http://securecoding.org.

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 8 of 165
8 

development groups there, some quite large. As I recall, a single group I supported had 450 

developers. 

9. I have twice testified as an expert before Congress, once in 2000 (representing Sun

Microsystems, on the subject of Internet security and software vulnerabilities) and again in 2012 

(appearing for NASDAQ, discussing the vulnerability of stock markets and other critical 

financial systems to attack). I also served as an expert witness for the state of California in a 

civil matter, relating to election security, during 2008 and 2009.7

B. Scope of Opinion

10. I was asked to evaluate the materials provided to me in this case and render an opinion as

to: 

(a) whether, from December 2013 to September 2015, D-Link Systems, Inc. (“D-Link

Systems”) took reasonable steps to secure their routers and IP cameras8

 from 

unauthorized access; 

(b) whether the following routers, DIR-645, DIR-615, DIR-412, and DIR-815, were

secure from unauthorized access or control; and 

(c) whether two sets of IP cameras—the (1) DCS-2132L, DCS-2210, DCS-2230, DCS2310L, DCS-2332L, DCS-3112, DCS-3710, DCS-3716, DCS-6010L, DCS-6210, DCS6510, DCS-6511, DCS-6513, DCS-6616, DCS-6818, DCS-7010L, DCS-7413, and DCS7513, and the (2) DCS-1100/1100L, DCS-1130/1130L, DCS-3410, DCS-3411, DCS3430, DCS-5605, and DCS-5635—were secure from unauthorized access or control, 

particularly whether they were secure from access using credentials other than the 

7

 Attached hereto as Appendix B is my Curriculum Vitae with relevant publications and professional experience. 

8

 The FTC’s attorneys have advised me that discovery in this case was structured around a list of selected routers 

and IP cameras, attached hereto as Appendix A. My opinions are based on the materials I considered. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 9 of 165
9 

credentials set by the user on the administrator account. I will refer to these two sets of 

cameras, collectively, as the “Specified IP Cameras” later on. 

11. I was also asked to determine, even in cases where D-Link routers and IP cameras were

not secure from unauthorized access or control, whether D-Link had taken reasonable steps, from 

2011 to the end-date of the discovery materials available to me, 

(a) to secure those devices from unauthorized access or control, or

(b) to corroborate that those devices were secure from unauthorized access or control.

C. Materials Considered in Forming My Opinion

12. In forming my opinion, I considered materials that are cited in this report and listed in

Appendix C. In addition, in forming my opinion, I had access to the database of all documents 

produced in this case by D-Link Systems, D-Link Corporation, and third parties. In order to 

review this large number of documents, I ran targeted searches using keywords to call up a 

variety of documents relevant to proving or disproving my opinion. 

D. Compensation

13. I am compensated at a rate of $450 per hour for my consulting work. I am compensated

at a rate of $600 per hour for testimony time. 

II. Summary of Expert Opinion

14. From December 2013 to September 2015, D-Link Systems did not take reasonable steps

to secure its routers and IP cameras from unauthorized access, such as through back doors or 

other means of unauthorized access. See Sections III.C, III.D, III.E, and III.F below. 

15. From December 2013 to September 2015, D-Link Systems did not take reasonable steps

to corroborate, through entities such as D-Link Corporation or third-party vendors, that its 

routers and IP cameras were secure from unauthorized access, such as through back doors or 

other means of unauthorized access. See Sections III.C and III.F below. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 10 of 165
10 

16. The DIR-645, DIR-615, DIR-412, and DIR-815 contained software vulnerabilities that

rendered them not secure from unauthorized access or control. See Sections III.D and III.E.1 

below. 

17. D-Link Systems did not take reasonable steps during the development and maintenance

to secure the DIR-645, DIR-615, DIR-412, and DIR-815 from unauthorized access or control. 

See Sections III.C, III.D, III.E.1, and III.F below. 

18. D-Link Systems did not take reasonable steps to corroborate, through entities such as

D-Link Corporation or third-party vendors, that the DIR-645, DIR-615, DIR-412, and DIR-815

were secure from unauthorized access or control. See Sections III.C and III.F below. 

19. The Specified IP Cameras were not secure from unauthorized access or control. See

Section III.E.2 below. 

20. In particular, the Specified IP Cameras credentials contained at least two undocumented

credentials that would permit any user with knowledge of those credentials to get unauthorized 

access to the video feed of the cameras without knowing the “admin” password set by a user 

during the set-up process. See Sections III.E.2.a and III.E.2.b below. 

21. D-Link Systems did not take reasonable steps to secure the Specified IP Cameras from

unauthorized access or control. See Sections III.C, III.D, III.E, and III.F below. 

22. D-Link Systems did not take reasonable steps to corroborate, through entities such as

D-Link Corporation or third-party vendors, that the Specified IP Cameras were secure from

unauthorized access or control. See Sections III.C and III.F below. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 11 of 165
11 

III. Expert Opinion

23. My opinion below is in six sections. First, I explain the importance of software, in

particular in the context of routers and IP cameras, and the maturation of thinking about secure 

software coding over the last three decades or so. See Section III.A. Second, I explain the 

respective roles of the companies involved in the development of the D-Link routers and IP 

cameras. See Section III.B. Third, I explain how D-Link Systems lacked many of the ordinary 

means of developing and maintaining secure code. See Section III.C. Fourth, I give some 

examples of the basic failures that were routinely found in D-Link Systems’ routers and IP 

cameras, which should have raised alarm bells and eroded the basis of any “trust” D-Link 

Systems had in D-Link Corporation and the vendors. See Section III.D. Fifth, I walk through 

some illustrative vulnerabilities, in which security researchers identified ways to exploit the code 

development failures to take over D-Link devices. See Section III.E. Sixth, I examine the 

affirmative steps that D-Link Systems (and its parent) have taken, including some that they have 

implemented recently, only after years of shipping devices with preventable vulnerabilities, to 

secure D-Link Systems’ routers and IP cameras. See Section III.F. Finally, I provide a summary 

of my opinions specific to certain devices that I am told are at issue in this matter. See Section 

III.G.

A. Background on Software

1. Software is a Critical Component of Routers and IP Cameras

24. Software is a critical component of all routers and IP cameras. The software on D-Link

Systems routers and IP cameras is essential for them to operate as intended. Without software, 

routers and IP cameras are just boxes with computer chips, cable connections, and radio 

antennas. Software is what allows a router to route network packets and connect a consumer’s 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 12 of 165
12 

home network to the Internet. Software is what allows a consumer to view a video feed, either 

from within their home or remotely. 

a. Routers

25. Consumer routers are electronic devices that connect computers and mobile phones

inside a home to each other, and to the Internet. Normally, routers are connected on one side to a 

modem supplied by a cable company or Internet Service Provider (ISP). On the other side, the 

router is connected physically or wirelessly to all other networked devices, such as computers, 

tablets, and mobile phones within a consumer’s home. These devices, connected together by the 

router, form what is called the local area network (LAN). Routers are particularly important to 

the smart home. Consumers with Internet-connected thermostats, ovens, door locks, and 

cameras connect those devices as well to the Internet through their routers. In addition, 

consumers sometimes connect data storage devices to routers to permit access to files from 

multiple computers within the same LAN.9

 Accordingly, routers have total access to sensitive 

information being either transmitted or stored within a consumer’s home. In an ordinary home 

LAN, the router may be able to “see” banking transactions, email contents, movie selections, and 

web browsing sessions for all such interactions pass through the router (sometimes, in encrypted 

form) on their way to the Internet and back. 

26. Although the purpose of a router is to route IP packets, it is a security device of critical

importance as well. Security is necessarily a core feature of routers. Just as routers must pass 

along data between the LAN and the Internet to make email, Web browsing, and camera viewing 

possible, consumer routers must also stop some data to protect the theft of personal information 

9

 At least some D-Link Systems routers provide this function. E.g., DIR-645 User Manual, v. 1.0 (May 26, 2011) 

(DLS0008663–8801, at DLS0008751) (describing how to share media from a storage device connected to the 

router’s USB port to other computers on the network). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 13 of 165
13 

or a successful cyber attack. In other words, part of routing data to the right place is not routing

data that does not belong there. Since the router must necessarily be able to communicate with 

the devices within a LAN, it should itself, concomitantly, be secure from attack and compromise, 

and afford security protection so as to prevent a malicious actor from using that same access to 

steal data and misuse devices on the LAN. Router manufacturers (including D-Link) 

acknowledge the centrality of security because they include on their devices certain security 

features: firewalls to stop certain incoming data and encryption for wireless connections on the 

LAN (e.g., WPA2). 

27. These safety precautions become virtually useless if router software is not secure.

Vulnerabilities in router software can permit attackers to get unauthorized access to sensitive 

information in a variety of ways. For example, some vulnerabilities, discussed below, might 

permit an attacker to access a device remotely from the Internet. Others would only allow an 

attacker to exploit the device from within the same LAN. Sometimes it might take multiple 

steps—an attacker cannot access the device remotely directly, but if the attacker is able to get a 

user on the local network to click on a malicious link containing malware, then the attacker 

might be able to remotely take over the device. 

28. An attacker may be able to take over a router by performing what is known as a

command injection. If an attacker takes over a consumer’s router, the attacker has the potential 

to do immeasurable harm.10 In the case of a router, an attacker could have access to all the 

10 GREG HOGLUND & GARY MCGRAW, EXPLOITING SOFTWARE: HOW TO BREAK CODE 7 (2004); 

MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 196 (2006) (“a vulnerability . . . could be used to cause a denial of 

service—to crash the application or the underlying operating system—whereas a more sophisticated exploit could 

run hostile code and allow an attacker to “own” the system.”), 

https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/; 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 14 of 165
14 

network traffic flowing through that router. The attacker could eavesdrop on that traffic if it 

were unencrypted and gain information about the internal network. The attacker could redirect 

traffic from the desired site that you were attempting visit—say, Google.com—to a different 

malicious website. If you store any confidential information on devices connected to your 

router, like financial information, or passwords to e-commerce sites or banks, the attacker could 

steal your confidential information to commit identity theft.11

29. The attacker could flood your router with so many requests that it would prevent any

traffic from going through the router at all. This is called a denial-of-service (DoS) attack. The 

attacker could also use your router, and thousands of other routers with the same vulnerabilities, 

to attack another target. The attacker could force your computer to send huge amounts of data to 

a website or send spam to particular email addresses. This kind of attack is called a distributed 

denial-of-service (DDoS).12 The attack is “distributed” because the attacker is using multiple 

computers, including yours, to launch the denial-of-service attack. 

30. The attacker could use your router as a stepping stone to get inside your internal network

and access all of the machines that are connected to your router, such as your IP camera, your 

smart thermostat, your smart door key, or other connected devices. The attacker could watch 

your baby through your IP camera, turn your thermostat up to 100 degrees, or unlock your door. 

CERT, SEI, Carnegie Mellon, Vulnerability Note VU# 950576, VULNERABILITY NOTES DATABASE (2015) (“A 

remote attacker may utilize these credentials to gain administrator access to the device.”), 

https://www.kb.cert.org/vuls/id/950576. 

11 ED SKOUDIS & TOM LISTON, COUNTER HACK RELOADED 8 (2002). 

12 ED SKOUDIS & TOM LISTON, COUNTER HACK RELOADED 534–35 (2002) (describing a DDoS attack); JOEL LAND,

SYSTEMIC VULNERABILITIES IN CUSTOMER-PREMISES EQUIPMENT (CPE) ROUTERS, CERT, SEI, CARNEGIE MELLON 

1 (July 2017) (“In August 2016, Mirai malware spread using default credentials on Internet-connected devices, 

including CPE routers. The Mirai botnet was involved in significant distributed denial-of-service attacks . . . [In 

August 25, 2015,] [a]t least five geographically disparate router vendors shown likely to be using a common source 

for firmware due to use of the same hardcoded password.”), 

https://resources.sei.cmu.edu/asset_files/SpecialReport/2017_003_001_502618.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 15 of 165
15 

b. IP Cameras

31. Internet protocol (IP) cameras are intended to be viewed over the Internet.13 Like routers,

IP cameras are a combination of software and hardware. Although IP cameras have a narrow 

purpose—to display a camera feed across a network connection—if a bad actor takes over a 

consumer’s IP camera, they are able to monitor a consumer’s whereabouts or to observe and 

record personal activities and conversations. IP cameras indeed are computers that reside on a 

consumer’s home network. As such, if they are inadequately secured, not only can they be 

misused by a malicious actor to view the IP camera feed, they also can be misused as launch 

points for attacks on other parts of a consumer’s home network—either the router, other 

computers, data storage units, or networked home control devices such as thermostats and doors. 

IP cameras can be used as nodes in botnets to attack servers outside a consumer’s home network, 

as in the 2016 Mirai botnet case I previously referenced. 

32. Some IP cameras are configured for viewing only over the LAN, the local network. But

IP cameras are commonly set up to be viewed remotely, over the Internet (a Wide Area Network, 

or WAN). IP cameras that are exposed to the Internet can be attacked over the Internet. IP 

cameras trained on subjects inside a home are perhaps the most sensitive information a consumer 

might have—a child’s bedroom, for example.14 Accordingly, software security is a critical 

component of IP cameras. 

33. For both routers and IP cameras, devices with known software vulnerabilities can be

recruited through malware into botnets. Botnets are armies of devices (sometimes, hundreds of 

13 D-Link Systems provides remote access to cameras through its mydlink service, and also provides instructions on 

how camera owners can connect their IP cameras directly to the Internet. E.g., DCS-2310L User Manual v.1.0 (Jul. 

10, 2012) (DLS0005107–95, at DLS0005136 (remotely access camera through mydlink service), DLS0005149 

(setup IP camera to have its own IP address for access over the Internet)). 

14 Doug Gross, Foul-mouthed hacker hijacks baby’s monitor, CNN (Aug. 14, 2013), 

https://www.cnn.com/2013/08/14/tech/web/hacked-baby-monitor/index.html. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 16 of 165
16 

thousands of devices) that can be commanded from afar to suddenly start sending requests to a 

single server, thereby overwhelming the server with tasks and preventing it from doing its job. 

(Such as an attack is often referred to as a distributed denial-of-service attack, or DDoS.) This 

could stop a small business retailer from taking orders during a critical few days;15 could attempt 

to silence a publication reporting on issues disfavored by the operator of the botnet;16 or, in 

extreme cases, could take down parts of the Internet by targeting an Internet infrastructure 

company.17

c. Software Vulnerabilities and Patches

34. In my experience, consumers rarely patch their routers and IP cameras (as well as other

“Internet of Things” devices).18 I believe consumers are less likely to update firmware of these 

“things” because, unlike computers or phones, consumers do not ordinarily interact with the 

screens of these devices, if they even have screens, and they expect them to “just work.” 

Accordingly, to the extent that businesses are serious about ensuring that their consumers have 

secure devices, they are advised, especially in the context of devices that are not frequently 

patched, to identify and address vulnerabilities prior to the release of the device.19

15 AdWeek Staff, Massive Cyberattacks Dramatically Hurt Revenues for All Kinds of Internet Players, ADWEEK

(Oct. 22, 2016), https://www.adweek.com/digital/massive-cyberattacks-dramatically-hurt-revenues-all-kindsplayers-174220/. 

16 Dan Goodin, How Google fought back against a crippling IoT-powered botnet and won, ARSTECHNICA (Feb. 2, 

2017), https://arstechnica.com/information-technology/2017/02/how-google-fought-back-against-a-crippling-iotpowered-botnet-and-won/. 

17 Brian Krebs, Hacked Cameras, DVRs Powered Today’s Massive Internet Outage, KREBSONSECURITY (Oct. 21, 

2016), https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-Internet-outage/. 

18 See, e.g., Sally Feller & Jeffrey Tang, 86 Percent of Consumers Never Update Their Router’s Firmware, 

THREATVECTOR, CYLANCE (Apr. 24, 2018), https://threatvector.cylance.com/en_us/home/86-percent-of-consumersnever-update-router-firmware.html. 

19 JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID SECURITY PROBLEMS THE RIGHT 

WAY 15–16 (1st ed. 2002) (“In simple economic terms, finding and removing bugs in a software system before its 

release is orders of magnitude cheaper and more effective than trying to fix systems after the release.” . . . “Then 

they rush out a patch instead of coming to the realization that designing security in from the start may be a better 

idea.”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 17 of 165
17 

d. Multiple Ways to Exploit

35. The dangers of vulnerable software on routers and IP cameras are enhanced by the

myriad techniques that hackers have developed to exploit these vulnerabilities. For example, 

routers and IP cameras with software vulnerabilities, in most cases, can be exploited on the local 

area network. Beyond that, in some cases, vulnerabilities can be exploited remotely, over the 

Internet, from anywhere in the world. Lastly, even in circumstances where a vulnerability 

cannot be directly exploited over the Internet, hackers have developed techniques to be able to 

mimic being on the local area network by tricking a user on the local area network to click a 

malicious link, using techniques such as a cross-site scripting attack20 or a cross-site request 

forgery attack.21 Using either of these techniques, both of which are well known, a hacker can 

exploit over the Internet a vulnerability that might otherwise only be able to be exploited on the 

local area network. 

2. Software Vulnerabilities

36. Long before D-Link, long before the proliferation of consumer home networks, and long

before the Internet of things, professionals have thought about how software can be misused. 

For more than forty years, academics and practitioners alike have been exploring, documenting, 

20 Top 10 2010-A2-Cross-Site Scripting (XSS), OWASP (2010) (“Attacker sends text-based attack scripts that 

exploit the interpreter in the browser. Almost any source of data can be an attack vector, including internal sources 

such as data from the database. XSS is the most prevalent web application security flaw. XSS flaws occur when an 

application includes user supplied data in a page sent to the browser without properly validating or escaping that 

content. There are three known types of XSS flaws: 1) Stored, 2) Reflected, and 3) DOM based XSS. Detection of 

most XSS flaws is fairly easy via testing or code analysis.”), https://www.owasp.org/index.php/Top_10_2010-A2-

Cross-Site_Scripting_(XSS). 

21 Top 10 2010-A5-Cross-Site Request Forgery (CSRF), OWASP (2010) (“Attacker creates forged HTTP requests 

and tricks a victim into submitting them via image tags, XSS, or numerous other techniques. If the user is 

authenticated, the attack succeeds. CSRF takes advantage of web applications that allow attackers to predict all the 

details of a particular action. Since browsers send credentials like session cookies automatically, attackers can 

create malicious web pages which generate forged requests that are indistinguishable from legitimate ones. 

Detection of CSRF flaws is fairly easy via penetration testing or code analysis.”), 

https://www.owasp.org/index.php/Top_10_2010-A5-Cross-Site_Request_Forgery_(CSRF).

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 18 of 165
18 

and lamenting the many ways that attackers might compromise the security of computer systems. 

Substantial progress in detecting, or even preventing, the development of insecure code has been 

made over the ensuing decades. I will begin a brief survey of this history by describing some of 

the earliest published efforts. 

37. Beginning in the 1950s and 1960s, associations of computing practitioners such as the

Association of Computing Machinery (ACM, founded in 1947) and the American Federation of 

Information Processing Societies (AFIPS, 1961) sponsored conferences and colloquia to advance 

the state of the art of data processing and computer science. One particular focus of academic 

research that emerged in that era was the question of software reliability—that is, whether 

programs could be proven to be “correct,” or beyond the ability of attackers to subvert them. 

One early inquiry along this line was the research paper, An Axiomatic Basis for Computer 

Programming, by the Irish professor C.A.R. Hoare, published in 1969.22 

38. By 1973, AFIPS had amalgamated various annual conferences into a single prestigious

annual event, the National Computer Conference (NCC). In 1975, Richard Linde presented at 

the NCC a thorough analysis of attack scenarios and strategies, appending to his paper, 

Operating System Penetration, analyses of dozens of “generic system functional flaws” and 

“generic operating system attacks.” He warned, for example, of the danger of weak passwords.23

39. Here is the way Linde described one issue: “Legality Checking—User parameters may

not be checked adequately; addresses may overlap each other or refer to system areas; condition 

code checks may be omitted; and unusual or extraordinary parameters may not be anticipated by 

22 C.A.R. Hoare, An Axiomatic Basis for Computer Programming, Communications of the ACM 12 (10), 576–83 

(Oct. 1968), https://www.cs.cmu.edu/~crary/819-f09/Hoare69.pdf. 

23 RICHARD R. LINDE, OPERATING SYSTEM PENETRATION 367 (AFIPS National Computer Conference, May 19–22, 

1975), https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830361.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 19 of 165
19 

the designer or implementer.”24 As we will see later, the checking of user-supplied parameters, 

which Linde articulated in 1975 and later became known as “input validation,” is implicated in 

several of the vulnerabilities found in D-Link devices by security researchers. See Section 

III.D.1 (input filtering).

40. Another issue Linde described in this paper related to the potential abuse of “utilities.”25

Utilities are programs that carry functions commonly needed on a computer system, for example, 

a file printing routine or a mathematical calculator. Many utilities are provided as an adjunct to 

the operating system itself, and perform some of the functions needed to operate the computer or 

make it useful. “The operational management and control of system utilities is often neglected 

by the system manager. This area is fraught with Trojan Horse attack potential. Frequently, 

utility designers are not aware of security design issues. For example, inadequate boundary 

checking at compile time may allow a user to execute machine code disguised as data in a data 

area.” 26 An inattention of utility designers—as, for example, the utility scripts used to process 

login actions as an administrator—to potential buffer overflow attacks is a cause of another set of 

vulnerabilities in the relevant D-Link products. See Section III.D. 

41. A watershed event in the quest for more secure computer systems occurred in 1983 with

the issuance by the National Computer Security Center of the Department of Defense Trusted 

24 RICHARD R. LINDE, OPERATING SYSTEM PENETRATION 366 (AFIPS National Computer Conference, May 19–22, 

1975), https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830361.pdf. 

25 RICHARD R. LINDE, OPERATING SYSTEM PENETRATION 364 (AFIPS National Computer Conference, May 19–22, 

1975) (“In a temporal sense, operating system controls are only effective during the period of system execution and 

must be augmented by static procedural controls, such as . . . building of software utilities. . . . Because control of 

this function is apart from the operating system in a temporal and physical sense, it is particularly vulnerable to 

interdiction and corruption of system code by planting trap doors and Trojan Horse routines. Personnel inefficiency 

and inadequate procedural controls account for this susceptibility.”), 

https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830361.pdf. 

26 RICHARD R. LINDE, OPERATING SYSTEM PENETRATION 367 (AFIPS National Computer Conference, May 19–22, 

1975), https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830361.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 20 of 165
20 

Computer System Evaluation Criteria (TCSEC), known as the Orange Book,27 which suggested 

guidelines for system developers, including programmers, on security issues.28 Topics for the 

standards included authentication means and assurance mechanisms, such as change control. 

TCSEC was superseded in 2005 by the federally sponsored Common Criteria, a more advanced 

and more prescriptive set of requirements, designed to standardize an evaluation approach across 

nations and technologies.29 The Common Criteria is an International Standard Organization 

(ISO) standard (15408, version 2.1).30

42. In 1988, a more disruptive security event occurred, which spurred both the formation of

formal incident response teams and increased research in software security quality. Known as 

the “Morris worm,” attack software written and launched by Cornell student Robert Tappan 

Morris ripped its way across the Internet on November 2, infecting and disrupting perhaps ten 

27 DEPARTMENT OF DEFENSE, TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA (2nd ed. l985) 

https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc1998/documents/early-cs-papers/dod85.pdf; FEDERATION OF AMERICAN SCIENTISTS, NSA/NCSC RAINBOW SERIES, 

https://fas.org/irp/nsa/rainbow.htm; Steve Lipner, The Birth and Death of the Orange Book, IEEE Annals of the 

History of Computing 37(2):19–31 (June 2015), https://www.researchgate.net/publication/277723752_The_Birth_ 

and_Death_of_the_Orange_Book; JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID 

SECURITY PROBLEMS THE RIGHT WAY 43 (1st ed. 2002). 

28 DEPARTMENT OF DEFENSE, TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA (l985) 

https://csrc.nist.gov/csrc/media/publications/conference-paper/1998/10/08/proceedings-of-the-21st-nissc1998/documents/early-cs-papers/dod85.pdf; NATIONAL COMPUTER SECURITY CENTER, A GUIDE TO 

UNDERSTANDING DISCRETIONARY ACCESS CONTROL IN TRUSTED SYSTEMS (1987) (“The guidelines defined in this 

document are intended to be used by computer hardware and software designers who are building systems with the 

intent of meeting the requirements of the Department of Defense Trusted Computer System Evaluation Criteria, 

DoD 5200.28-STD.”), https://csrc.nist.gov/csrc/media/publications/white-paper/1985/12/26/dod-rainbowseries/final/documents/tg003.txt. 

29 COMMON CRITERIA FOR INFORMATION TECHNOLOGY SECURITY EVALUATION (“COMMON CRITERIA”), 

https://www.commoncriteriaportal.org/; COMMON CRITERIA FOR INFORMATION TECHNOLOGY SECURITY 

EVALUATION, VERSION 2.3, CCMB-2005-08-001 (Aug. 2005), https://www.commoncriteriaportal.org/files/ccfiles/ 

ccpart1v2.3.pdf; MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR

DEVELOPING DEMONSTRABLY MORE SECURE SOFTWARE 28 (2006), 

https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/. 

30 JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID SECURITY PROBLEMS THE RIGHT 

WAY 44 (1st ed. 2002). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 21 of 165
21 

percent of the 60,000 or so total systems making up the Internet at that time.31 It was the first 

demonstration of the widespread vulnerability of Internet systems, and its impact—far beyond 

the $10 million the General Accounting Office estimated as a potential direct loss, and Morris’ 

conviction under the new Computer Fraud and Abuse Act32 was immediate. The Morris worm 

exploited, among other vulnerabilities, all three of the issues—poor input validation, buffer 

overflows, and weak passwords—I mentioned earlier in talking about in the 1975 Linde paper. 

43. During the next decade, the Internet exploded in size. Web browsing was invented, and

became commonplace. Cyber attacks grew explosively and also became commonplace. I was a 

cyber security leader at Sun Microsystems during most of the 1990s, and had a front-row seat to 

these changes. As Security Coordinator in the early 1990s, responsible for finding and fixing 

vulnerabilities in Sun products, I watched as attackers’ methods for finding weaknesses and 

flaws grew more sophisticated and became automated.33 

44. As the head of Sun’s network defense team in the last years of the decade, I saw attacks

against our worldwide network (we had an online corporate presence in, as I recall, about 130 

countries) escalate in both number and severity. Computer viruses, self-propagating “worms,” 

and “denial-of-service” attacks designed to take down or render incommunicado our systems: all 

these methods were invented or substantially refined in the 1990s.34

31 John Markoff, Author of Computer “Virus” is Son of N.S.A. Expert on Data Security, N.Y. TIMES (Nov. 5, 1988), 

https://www.nytimes.com/1988/11/05/us/author-of-computer-virus-is-son-of-nsa-expert-on-data-security.html; Ted 

Eisenberg, et al., The Cornell Commission: On Morris and the Worm, Communications of the ACM 32 (6) (June 

1989), http://www.cs.cornell.edu/courses/cs1110/2009sp/assignments/a1/p706-eisenberg.pdf. 

32 United States v. Robert Tappan Morris, 928 F.2d 504 (2d Cir. 1991). 

33 Aleph One, Smashing the Stack For Fun and Profit, PHRACK 7 (49) (1996), http://phrack.org/issues/49/14.html. 

34 GREG HOGLUND & GARY MCGRAW, EXPLOITING SOFTWARE: HOW TO BREAK CODE, 19–20 (Addison-Wesley 

Software Security Series 2004) (“Viruses became very popular in the 1990s and were mostly spread through 

infected executable files shuffled around on disks. A worm is a special kind of virus that spreads over networks and 

does not rely on file infection. Worms are a very dangerous twist on the classic virus and are especially important 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 22 of 165
22 

45. By the turn of the century, the online world had seen viruses such as “Melissa” (1999)

become almost routine, tying up thousands or tens of thousands of computers around the world at 

the whim of a single miscreant or criminal.35 Defensive methods improved, too: firewall 

techniques were strengthened, software to allow defenders to scan systematically for 

vulnerabilities and superfluous services began to emerge, and many insecure coding practices 

were identified and highlighted for change by security practitioners.36

3. Formalization of the Expert Field of Software Security

46. Beginning in 2002, these ideas began being compiled into standards and literature that

defined the idea of secure coding. Although experts and scholars had understood the need for 

software security for decades, their ideas had not been formalized into a field. 

47. This changed with the development by Microsoft, the world’s largest software company,

of the Secure Development Lifecycle (“SDL”) in 2002. The SDL was the seminal event in 

bringing technical issues well understood by security experts into the mainstream of software 

development.37 The importance of Microsoft’s commitment to the SDL cannot be overstated. 

By committing to this framework, Microsoft changed the way software developers thought about 

security, and provided a language for developers to incorporate secure coding techniques into the 

development process. 

given our modern reliance on networks. Worm activity became widespread in the late 1990s, although many 

dangerous worms were neither well publicized nor well understood.”). 

35 JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID SECURITY PROBLEMS THE RIGHT 

WAY 21 (1st ed. 2002). See also MICHAEL NEWTON, THE ENCYCLOPEDIA OF HIGH-TECH CRIME AND CRIMEFIGHTING: FROM AIRPORT SECURITY TO XYZ COMPUTER VIRUS 197 (2004). 

36 JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID SECURITY PROBLEMS THE RIGHT 

WAY (1st ed. 2002). 

37 More history regarding the development of the SDL is found on Microsoft’s website. MICROSOFT SECURE

DEVELOPMENT LIFECYCLE, https://www.microsoft.com/en-us/sdl. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 23 of 165
23 

48. In addition to the SDL, other literature came out that discussed secure coding. In 2002,

John Viega and Gary McGraw published their seminal book on coding.38 McGraw later went on 

to found the Building Security in Maturity Model (“BSIMM”) in 2009.39 In their 2002 book, 

Viega and McGraw focus on things you should know about software security before you even 

think about producing code. The authors emphasize methodologies and principles that reduce 

security risk by designing security into a system from the beginning. The book then moves to 

implementation-level issues, and shows developers how to recognize and avoid common 

implementation-level problems, such as buffer overflows and race conditions.40

49. In my 2003 book, written with Ken van Wyk, Secure Coding, van Wyk and I articulated

an approach to software development that, when applied, helps minimizes the risk that the 

software will be compromised by attackers.41 We also laid out several design principles and 

architectural elements that strengthen the security of any software in which they are applied. 

Other key elements of the book provide insights into the psychological, economic, and technical 

factors that contribute to the production of insecure software, and methods of developing, 

operating, and maintaining software systems, so as to promote security. This book has been 

included on the syllabi of several dozen courses on software development, software engineering, 

and information security, in many countries. This book is cited frequently in peer-reviewed 

technical papers in the Association of Computing Machinery (“ACM”), technical documents on 

these subjects, and by Microsoft, NIST, and others. 

38 JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID SECURITY PROBLEMS THE RIGHT 

WAY (1st ed. 2002). 

39 Building Security In Maturity Model (“BSIMM”), https://www.bsimm.com/. 

40 JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID SECURITY PROBLEMS THE RIGHT 

WAY xxiv–xxv (1st ed. 2002). 

41 MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING: PRINCIPLES & PRACTICES (2003), 

http://securecoding.org. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 24 of 165
24 

50. Appendix D is a selected bibliography of secure coding books.

4. Industry Checklists and Protocols for Secure Software Development

Cycles.

51. In addition to the literature on secure coding, standards began to be popularized to help

software developers create safe, responsible code. In the United States there are four sets of 

recommendations widely recognized by experts in the field and reflecting sound practices: The 

Open Web Application Security (OWASP) Secure Coding practices;42 the SAFECode body of 

recommendations;43 the SANS Institute and its Top 25;44 and the “standards” (truly, guidelines) 

developed and promulgated by the Software Engineering Institute out of Carnegie Mellon 

University.45 Resources from each of these sources, discussed below, are freely-available online. 

52. For companies seeking guidance on organizational steps to manage secure development,

the International Organization for Standardization (“ISO”) has published a series of information 

security management standards in its 27000 series.46 

a. SANS Top 25

53. The SANS Institute was established in 1989 with a mission of engaging in research and

education for security professionals around the world. It is a well-known and well-regarded 

organization in the information security field.47 Every year, SANS publishes the Top 25 

Software Errors, in three categories: (1) Software Error Category: Insecure Interaction Between 

Components; (2) Software Error Category: Risky Resource Management; (3) Software Error 

42 OPEN WEB APPLICATION SECURITY PROJECT (“OWASP”), https://www.owasp.org.

43 SOFTWARE ASSURANCE FORUM FOR EXCELLENCE IN CODE (“SAFECode”), https://safecode.org. 

44 THE SANS INSTITUTE, https://www.sans.org/about/. 

45 SOFTWARE ENGINEERING INSTITUTE, CARNEGIE MELLON UNIVERSITY (“SEI-CMU”), https://www.sei.cmu.edu/. 

46 INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (“ISO”), https://www.iso.org/isoiec-27001-informationsecurity.html. 

47 THE SANS INSTITUTE, https://www.sans.org/about/. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 25 of 165
25 

Category: Porous Defenses. (“Click on the CWE ID in any of the listings and you will be 

directed to the relevant spot in the MITRE CWE. . . . Each entry at the Top 25 Software Errors 

site also includes fairly extensive prevention and remediation steps that developers can take to 

mitigate or eliminate the weakness.”).48

b. OWASP Secure Development Publications

54. The Open Web Application Security Project (“OWASP”) began in December 2001.49

The OWASP non-profit foundation was started in 2004.50 OWASP has published several guides 

contributing to secure software development. Key among these is the OWASP Top Ten.51 The 

OWASP Top Ten Most Critical Web Application Security Risks was first published in 2003 and 

is regularly updated by a global community of software security professionals. The goal of the 

OWASP Top Ten is to raise awareness about application security by identifying some of the 

most critical risks facing organizations.52 Although the list is specific to web applications, many 

of the enumerated vulnerabilities, and the mitigation techniques, are found in software deployed 

in non-web environments.53 It is also widely respected as source of the most serious application 

48 SANS, CWE/SANS TOP 25 Most Dangerous Software Errors, https://www.sans.org/top25-software-errors/. The 

Top 25 makes use of Common Weakness Enumerations (CWEs)—a well-known list of categories of software flaws 

maintained by the Mitre Corporation. MITRE, Common Weakness Enumeration: A Community-Developed List of 

Software Weakness Types, https://cwe.mitre.org/index.html. CWE is sponsored by US-CERT in the office of 

Cybersecurity and Communications at the U.S. Department of Homeland Security. Ibid. 

49 OPEN WEB APPLICATION SECURITY PROJECT (“OWASP”), https://www.owasp.org. 

50 Ibid. 

51 OWASP Top 10 Project, OWASP (“The OWASP Top 10 is a powerful awareness document for web application 

security. It represents a broad consensus about the most critical security risks to web applications. Project members 

include a variety of security experts from around the world who have shared their expertise to produce this list.”), 

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project. 

52 OWASP has recently published a separate list of “Top Ten” for IoT. OWASP Top 10 IoT Vulnerabilities, 

OWASP (2014), https://www.owasp.org/index.php/Top_10_IoT_Vulnerabilities_(2014). This list is largely 

derivative of other Top Ten lists. 

53 Where OWASP has chosen to remove issues that would be pertinent to non-web application developers, it 

provides references to applicable OWASP resources on the issue. For example, when the category of “” was 

removed from the 2007 Top Ten list, OWASP noted that “Buffer overflows, integer overflows and format string 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 26 of 165
26 

security trends, and directs readers to a number of related sources to address them.54 In addition 

to the Top Ten, there are a number of other invaluable, free resources available to developers.55 

c. SAFECode

55. The Software Assurance Forum for Excellence in Code (“SAFECode”) is a non-profit

organization “dedicated to increasing trust in information and communications technology 

products and services through the advancement of effective software assurance methods.”56 

SAFECode is a consortium of software developers from various industries that currently is run 

by Steven Lipner, who is one of the progenitors of the secure software development movement. 

SAFECode offers a number of products, including Fundamental Practices for Secure Software 

Development.

57 In addition, there are many other valuable documents.58

issues “are extremely serious vulnerabilities for programs written in languages such as C or C++. ... If your code is 

written in a language that is likely to suffer buffer overflows, we encourage you to read the buffer overflow content 

on OWASP,” and providing links to that content. The Ten Most Critical Web Application Security Vulnerabilities 

2007 Update 5, OWASP, https://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf. As discussed in 

Sections III.D and E below, D-Link Systems’ software was written primarily in C, and its routers and IP cameras 

continued to be vulnerable to critical overflow vulnerabilities as recently as 2016. E.g., Sections III.E.1.g and 

III.E.2.c, below.

54 OWASP also publishes translated versions of its Top 10 in many other languages. See Category: OWASP Top 

Ten Project-OWASP Top 10 for 2010, OWASP, https://www.owasp.org/index.php/Category:OWASP_Top_Ten_ 

Project#OWASP_Top_10_for_2010 (including section with “2010 Translations”). 

55 See, e.g., OWASP Development Guide: The Development Guide provides practical guidance and includes J2EE, 

ASP.NET, and PHP code samples. The Development Guide covers an extensive array of application-level security 

issues, from SQL injection through modern concerns such as phishing, credit card handling, session fixation, crosssite request forgeries, compliance, and privacy issues. OWASP Testing Guide: The OWASP Testing Guide includes 

a “best practice” penetration testing framework that users can implement in their own organizations and a “low 

level” penetration testing guide that describes techniques for testing most common web application and web service 

security issues. Version 4 was published in September 2014, with input from 60 individuals. OWASP Code Review 

Guide: The Code Review Guide is currently at release version 1.1 and the second best-selling OWASP book in 

2008. OWASP Application Security Verification Standard (ASVS): The ASVS is a standard for performing 

application-level security verifications. WebGoat: WebGoat is a deliberately insecure web application created by 

OWASP as a guide for secure programming practices. Once downloaded, the application comes with a tutorial and 

a set of different lessons that instruct students how to exploit vulnerabilities with the intention of teaching them how 

to write code securely. 

56 SOFTWARE ASSURANCE FORUM FOR EXCELLENCE IN CODE (“SAFECode”), https://safecode.org. 

57 SAFECODE FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT, 

https://safecode.org/publications/#safecodepublications-186; 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 27 of 165
27 

d. Software Engineering Institute

56. The Software Engineering Institute, affiliated with Carnegie Mellon University, provides

training and publications over a wide range of cybersecurity topics, in coordination with the 

CMU-based organization CERT, the original Computer Emergency Response Team.59 In 

addition to training courses on such topics as “Network & Software Security,” “Risk Assessment 

& Insider Threat,” and “Software Architecture,”60 SEI has contributed more than a hundred 

publications to the corpus of de facto security standards.61

SAFECODE FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT 2ND EDITION, 

https://safecode.org/publications/#safecodepublications-190; 

SAFECODE FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT 3RD

EDITION,https://safecode.org/publications/#safecodepublications-2362. 

58 See, e.g., SAFECODE TACTICAL THREAT MODELING, https://safecode.org/publications/#safecodepublications1441; 

SAFECODE MANAGING SECURITY RISKS INHERENT IN THE USE OF THIRD-PARTY COMPONENTS,

https://safecode.org/publications/#safecodepublications-1437; 

SAFECODE PRINCIPLES OF SOFTWARE ASSURANCE ASSESSMENT,

https://safecode.org/publications/#safecodepublications-503; 

SAFECODE PRACTICES FOR SECURE DEVELOPMENT OF CLOUD APPLICATIONS,

https://safecode.org/publications/#safecodepublications-193; 

SAFECODE GUIDANCE FOR AGILE PRACTITIONERS, https://safecode.org/publications/#safecodepublications-192; 

SAFECODE INTERPRETING THE BSIMM, https://safecode.org/publications/#safecodepublications-191; 

SAFECODE OVERVIEW OF SOFTWARE INTEGRITY CONTROLS,

https://safecode.org/publications/#safecodepublications-189; 

SAFECODE FRAMEWORK FOR SOFTWARE SUPPLY CHAIN INTEGRITY, 

https://safecode.org/publications/#safecodepublications-188; 

SAFECODE SECURITY ENGINEERING TRAINING, https://safecode.org/publications/#safecodepublications-187; 

SAFECODE SOFTWARE ASSURANCE: AN OVERVIEW OF CURRENT INDUSTRY BEST PRACTICES, 

https://safecode.org/publications/#safecodepublications-185. 

59 SOFTWARE ENGINEERING INSTITUTE, CARNEGIE MELLON UNIVERSITY (“SEI-CMU”), https://www.sei.cmu.edu/. 

60 SEI-CMU COURSES INDEX, https://www.sei.cmu.edu/education-outreach/courses/index.cfm. 

61 SEI-CMU PUBLICATIONS INDEX, https://www.sei.cmu.edu/publications/index.cfm; 

SEI CERT C CODING STANDARD: RULES FOR DEVELOPING SAFE, RELIABLE, AND SECURE SYSTEMS (SEI-CMU, 

2016 ed., June 2016), https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=454220;

ROBERT C. SEACORD, SECURE CODING IN C AND C++, (SEI-CMU, 2nd ed., Apr. 2013), 

https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=54183; 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 28 of 165
28 

5. Maturity Models and Secure Development Lifecycles

57. While ad hoc principles and processes can occasionally be effective for casual projects of

limited risk, modern software developers predominantly use a formally defined software 

development lifecycle (“SDLC”). Typically, the SDLC to be used will be selected by company 

managers and imposed upon the development staff. It can be tailored to the corporation’s 

resources, history, and the priority the company gives to security. Whatever the process settled 

upon, it’s very important to have a concrete and repeatable set of rules that all developers will 

follow. An agreed-upon SDLC promotes consistency and quality, and facilitates proper testing, 

scheduling, and code maintenance. 

58. Hundreds of organizations have developed guidelines relating to software development,

with the purpose of facilitating the development of hard-to-exploit software. A few key 

exemplars (with descriptive quotes from their sponsoring organizations) include: 

a. BSIMM (“Building Security In Maturity Model”).62 BSIMM studies existing software

security initiatives, quantifying the practices of many different software development

organizations to develop a descriptive statistical model of modern real-world practice.

C CODING STANDARD: RULES FOR DEVELOPING SAFE, RELIABLE, AND SECURE SYSTEMS (SEI CERT 2016 ed., June 

2016), https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=454220; 

C++ CODING STANDARD: RULES FOR DEVELOPING SAFE, RELIABLE, AND SECURE SYSTEMS (SEI CERT, 2016 ed., 

Mar. 2017), https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=494932; 

Fred Long, Dhruv Mohindra, Robert C. Seacord, Dean F. Sutherland & David Svoboda, The CERT Oracle Secure 

Coding Standard for Java (SEI-CMU, Sept. 2011), https://resources.sei.cmu.edu/library/assetview.cfm?assetid=30320; 

SEI-CMU, ANDROID SECURE CODING STANDARD (currently a work in progress), 

https://wiki.sei.cmu.edu/confluence/display/android/Android+Secure+Coding+Standard.

62 BUILDING SECURITY IN MATURITY MODEL, https://www.bsimm.com/about.html. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 29 of 165
29 

b. OWASP Software Assurance Maturity Model (“SAMM”).63 SAMM is an open

framework to “help organizations formulate and implement a strategy for software

security that is tailored to the specific risks facing the organization.”

c. Microsoft Secure Development Lifecycle (“SDL”). Developed internally at Microsoft

and later offered for industry-wide use, the SDL “is a software development process that

helps developers build more secure software and address security compliance

requirements while reducing development cost.” 64

59. The use of a maturity model such as these reflects the current wisdom for competent

secure software development. Between the various books, checklists, guidelines, and models 

discussed above, there is an abundance of information that is useful for the development and 

maintenance of secure software. These approaches are not all identical, but many of the 

underlying design and architectural principles behind all these methods are commonly held. 

Companies that use these methods produce measurably fewer of the types of errors discussed 

below. 

B. D-Link Systems, Inc. and D-Link Corporation: The Organizations and Their

Respective Responsibilities

60. In this section, I will briefly describe what I understand to be the roles and

responsibilities of the different entities and their employees that are involved with D-Link IP 

cameras and routers.65

63 OWASP SOFTWARE ASSURANCE MATURITY MODEL (SAMM), 

https://www.owasp.org/index.php/OWASP_SAMM_Project. 

64 Microsoft Secure Development Lifecycle, MICROSOFT (“SDL”), https://www.microsoft.com/en-us/sdl.

65 Throughout this report, I refer to “D-Link” routers and “D-Link” IP cameras. When I do so, I am intending to 

refer to routers and IP cameras of the D-Link brand that are developed, manufactured, marked, and sold with the 

involvement of both D-Link Corporation and D-Link Systems, consistent with the process described in this section 

of the report. The nomenclature “D-Link routers” and “D-Link IP cameras” is not intended to presume any legal 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 30 of 165
30 

61. There are three main “players”: First, D-Link Corporation is the parent corporation, and

is based in Taiwan.66 Second, D-Link Systems is the U.S.-based subsidiary of D-Link 

Corporation.67 Third, there are the third-party vendors, such as Alpha Networks, Cameo 

Networks, APPRO Tech, and Fitivision, based in Asia, which manufacture and develop the 

hardware and software for D-Link routers and IP cameras.68

1. D-Link Corporation

62. D-Link Corporation, based in Taiwan, is the parent corporation of D-Link Systems.69 DLink Corporation works with third-party vendors in Asia to develop a number of technology 

products, including D-Link routers and IP cameras.70 D-Link Corporation does not sell D-Link 

routers and IP cameras in the United States.71 Instead, it sells these products through its U.S. 

subsidiary, D-Link Systems.72 The relevant employees at D-Link Corporation are as follows: 

significance about the particular corporate entities, but rather simply refers to routers and IP cameras of the D-link

brand.

66 Decl. of Chung-Chieh Lin in Supp. of Def. D-Link Corp.’s Mot. to Dismiss ¶3 (Apr. 3, 2017) (ECF 50-3) (“DLink Corp. is a company organized under the laws of Taiwan. D-Link Corp. has its principal place of business in 

Taipei City, Taiwan.”). 

67 Decl. of William Brown in Supp. of Def. D-Link Corp.’s Mot. to Dismiss ¶¶ 3–4 (Apr. 3, 2017) (ECF 50-2) (DLink Systems is a subsidiary of D-Link Corp. with its principal place of business in Fountain Valley, California). 

68 D-Link Corp. 30(b)(6) Dep. 37:13–14, 38:7–14 (Jan. 30, 2018); Wang Dep. 73:1–25 (Dec. 6, 2017); Brown Dep.

92:15–23 (Mar. 14, 2018); Decl. of William Brown in Supp. of Def. D-Link Corp.’s Mot. to Dismiss ¶ 17 (Apr. 3,

2017) (ECF 50-2) (“Instead, D-Link Systems receives the products it sells (including IP cameras and routers) 

directly from the independent third party vendors that manufacture and create and provide firmware updates for 

those products.”); ¶ 26 (“D-Link Systems products (including IP cameras and routers) are from third-party vendors 

(not D-Link Corp.) that manufacture those products and then ship those products to D-Link Systems.”); ¶ 27 (“All of

the third-party vendors that manufacture, ship, and create firmware updates for the routers and IP cameras that DLink Systems sells in the United States are located in China, Hong Kong, or Taiwan.”). 

69 Decl. of William Brown in Supp. of Def. D-Link Corp.’s Mot. to Dismiss ¶ 4 (Apr. 3, 2017) (ECF 50-2) (“D-Link

Systems is a subsidiary of D-Link Corp.”). 

70 Brown Dep. 97:13–22 (Mar. 14, 2018) (stating that D-Link Systems did not have contracts with the vendors). 

71 Decl. of Chung-Chieh Lin in Supp. of Def. D-Link Corp.’s Mot. to Dismiss ¶ 4 (Apr. 3, 2017) (ECF 50-3) (“DLink Corp. sells products domestically in Taiwan and does not sell any products to the United States.”); ¶ 13 (“DLink Corp. does not currently sell in and has not sold any goods into the United States since May 2006.”). 

72 Decl. of William Brown in Supp. of Def. D-Link Corp.’s Mot. to Dismiss ¶ 5 (Apr. 3, 2017) (ECF 50-2).

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 31 of 165
31 

a. Peter Tsai is an employee in the Corporate Technology Office of D-Link Corporation.73 In

2013, Peter Tsai negotiated the contract with D-Link Corporation’s third-party security

company, a company originally called the Institute for Information Industry (“III”), and

later called Onward Security Corporation (“III/Onward”).74 As the principal contact with

III/Onward, Peter Tsai received its security reports.75

b. Robert Lin is the head of the IP camera product department for D-Link Corporation.76

From approximately 2013 to the present, Robert Lin has been the go-between for IP

camera issues, including IP camera security issues, with D-Link Systems.77

c. Daniel Hsu is the Project Manager for the wireless router division of D-Link

Corporation.78 From 2013 to the present, Mr. Hsu has served as the go-between for router

issues, including router security issues, with D-Link Systems.79

63. Based on the information I have reviewed, D-Link Corporation has responsibility to

coordinate everything related to the security of D-Link routers and IP cameras.80 D-Link 

Corporation has its own in-house Quality Assurance department, called D-Lab, which includes 

73 Email from Peter Tsai to Chris Chen et al. (Jan. 8, 2015) (DKC0494466–74, at DKC0494466) (signature line). 

74 For simplicity, I will refer to this company as III/Onward. D-Link Corp. 30(b)(6) Dep. 28:1–9, 116:13–17 (Jan. 

30, 2018). Although not perfectly clear, Mr. Tsai described Onward as a “spin off” of III, rather than a mere name 

change. 

75 D-Link Corp. 30(b)(6) Dep. 174:2–25, 175:1–19 (Jan. 30, 2018). 

76 D-Link Corp. 30(b)(6) Dep. 230:15–22 (Jan. 30, 2018); Wang Dep. 202:5–8 (Dec. 6, 2017). 

77 Wang Dep. 209:2–6 (Dec. 6, 2017); Brown Dep. 58:4–20, 61:1–16 (Mar. 14, 2018). 

78 Hsu Dep. 11:18–16:25 (Jan. 31, 2018); Brown Dep. 61:14–16 (Mar. 14, 2018). 

79 Hsu Dep. 17:1–23:4 (Jan. 31, 2018); D-Link Corp. 30(b)(6) Dep. 174:12–21, 231:1–5 (Jan. 30, 2018); Brown 

Dep. 58:4–20, 60:23–25, 61:1–16 (Mar. 14, 2018). 

80 D-Link Corp. 30(b)(6) Dep. 41:5–17; 42:21–25; 43:1–24, 218:1–25; 219:1–25, 220:1–9 (Jan. 30, 2018); Cline 

Dep. 30:1–3 (Apr. 24, 2018) (“D-Link Corporation performed the [product] testing—or they produced the test 

reports to me.”); Brown Dep. 90:25, 91:1–21 (Mar. 14, 2018) (explaining that he elevated all his communications 

through D-Link Corp., and D-Link Corp. communicated in Chinese with the vendors). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 32 of 165
32 

basic security checking81 as part of its other tests (which also include things like heat resistance, 

etc.).82

64. D-Link Corporation, and not D-Link Systems, interfaces with III/Onward, which ran

security tests on selected D-Link routers and IP cameras.83 III/Onward is a Taiwanese software 

security company.84 They have provided device security testing reports to D-Link Corporation, 

and not D-Link Systems, since August 2012.85 III/Onward provided these security tests, which 

are originally written in Chinese, to D-Link Corporation.86

81 Hsu Dep. 20:12–25, 21:1–25, 22:1–2 (Jan. 31, 2018); D-Link Corp. 30(b)(6) Dep. 68:1–72:23, 104:7–12 (Jan. 30, 

2018) (D-Lab reports were not provided to D-Link Systems, unless D-Link Systems requested them). D-Lab is 

discussed further below, at Section III.F.1. 

82 D-Link Corp. 30(b)(6) Dep. 48:25, 49:1–15, 62:19–25, 63:1–24, 68:6–25, 69:1–25, 70:1–25, 71:1–25, 72:4–24, 

94:9–25, 95:1–22 (Jan. 30, 2018). 

83 Decl. of Chung-Chieh Lin in Supp. of D-Link Corp.’s Mot. to Dismiss ¶ 28 (Apr. 3, 2017) (ECF 50-3) (“At times, 

D-Link Corp. . . . has retained an independent third party security company to test various D-Link brand products,

which independent subsidiaries that sell variants of D-Link brand products in other parts of the world, such as DLink Systems, may also choose to use. This independent third party security company—formerly known as the

Institute for Information Industry, or ‘III,’ and renamed ‘Onward Security Corporation’ in late 2014—is located in

Taipei, Taiwan, and conducts all of its security testing of D-Link brand products in Taiwan. Because the third party

security company reports the test results in the Chinese language, D-Link Corp. personnel will sometimes translate

the results of such testing into the English language when D-Link Systems decides to use its testing services and

relay the results.”); D-Link Corp. 30(b)(6) Dep. 27:5–24 (Jan. 30, 2018).

84 Decl. of Chung-Chieh Lin in Supp. of D-Link Corp.’s Mot. to Dismiss ¶ 28 (Apr. 3, 2017) (ECF 50-3). 

85 D-Link Corp. 30(b)(6) Dep. 68:12–17, 73:20–74:14 (testing began in 2012), 85:6–16, 86:5–16, 91:21–25, 109:12–

18, 110:22–112:3 (D-Link Corp. will share III/Onward reports if D-Link Systems requests), 175:1–19 (Tsai has not 

discussed content of III/Onward quarterly security reports with D-Link Systems) (Jan. 30, 2018); Decl. of William 

Brown in Supp. of D-Link Corp.’s Mot. to Dismiss ¶ 34 (Apr. 3, 2017) (ECF 50-2) (III/Onward “conducts tests on 

D-Link Systems products overseas in Taiwan; [III/Onward] does not perform tests on D-Link Systems products in

the United States. Because [III/Onward] is located in Taiwan, it can promptly communicate with the manufacturers

in Taiwan, China and Hong Kong to identify the vulnerabilities, propose recommendation to address the issues and

conduct further testing on the update fix firmware to ensure the proper function of firmware. When the testing

reports are issued by [III/Onward], they are mostly reported in the Chinese language for the manufacture’s engineers

to review and evaluate. At D-Link Systems’ request, D-Link Corp. personnel will sometimes translate the results of

such testing into the English language and relay the results.”).

86

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 33 of 165
33 

2. D-Link Systems

65. D-Link Systems, based in California, is the U.S. subsidiary of D-Link Corporation.87 It is

responsible for marketing and selling D-Link devices, including D-Link routers and IP cameras, 

in the United States.88 The relevant employees at D-Link Systems are as follows: 

a. AJ Wang served in several leadership positions at D-Link Systems. He held the title of

Chief Technology Officer for 13 or 14 years, starting in the late 1990s.89 In December

2011, AJ Wang took over the role of CEO of D-Link Systems, while continuing to serve

as the Chief Technology Officer.90 In 2016, AJ Wang left the company.91

b. William Brown joined D-Link Systems in 1992.92 In 2010, William Brown became DLink Systems’ Associate Vice President of Technology.93 He was a member of the U.S.

Product Management team, where he served as an advisor to the sales team about new

products.94 In 2013, Chief Technology Officer, AJ Wang, formed a new group called the

Office of the Chief Technology Officer, or OCTO, whose purpose was to find ways to

improve the quality and usability of D-Link’s products.95 AJ Wang invited William

87 Decl. of William Brown in Supp. of D-Link Corp.’s Mot. to Dismiss ¶ 4 (Apr. 3, 2017) (ECF 50-2) (“D-Link 

Systems is a subsidiary of D-Link Corp.”). 

88 Decl. of William Brown in Supp. of D-Link Corp.’s Mot. to Dismiss ¶¶ 5, 20, 22, 26–27 (Apr. 3, 2017) (ECF 50-

2). 

89 Wang Dep. 13:11–12, 18:21–22 (Dec. 6, 2017) (stating that he was the CTO of D-Link Systems for about 13 or 

14 years). 

90 Wang Dep. 13:11–18, 18:5–22 (Dec. 6, 2017). 

91 Wang Dep. 150:18–23 (Dec. 6, 2017); Brown Dep. 53:8–11 (Mar. 14, 2018). 

92 Brown Dep. 41:1–3 (Mar. 14, 2018). 

93 Brown Dep. 42:10–14 (Mar. 14, 2018); Brown Investigational Hr’g. Tr. 24:1–8 (July 29, 2014); D-Link Sys. 

30(b)(6) Dep. 12:25–13:12 (Apr. 25, 2018). 

94 D-Link Sys. 30(b)(6) Dep. 11:6–17 (Apr. 25, 2018). 

95 D-Link Sys. 30(b)(6) Dep. 11:21–12:16 (Apr. 25, 2018); Brown Dep. 53:4–7 (Mar. 14, 2018); Wang Dep. 20:3–

25:3 (Dec. 6, 2017); Brown Investigational Hr’g. Tr. 25:9–10 (July 29, 2014). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 34 of 165
34 

Brown to join OCTO, at which point Brown became responsible for product security.96 

In 2015, when AJ Wang went to D-Link Corporation, William Brown assumed the 

responsibilities of CTO and President of D-Link Systems on an acting basis.97 On 

January 3, 2017, William Brown assumed his current position of Senior Vice President 

and Chief Information Security Officer for D-Link Systems.98

c. John Jimenez and Patrick Cline. John Jimenez joined OCTO along with William Brown

in 2013, and worked there until transferred to another group in late 2014.99 When John

Jimenez left OCTO, he was replaced by an engineer named Patrick Cline.100 Patrick

Cline worked as a senior network engineer in OCTO from January 2015 to April 2016.101

After he left, his position was eliminated.102

d. Ted Kuo is responsible for the twice-a-year audits of the Mydlink service, carried out by

III/Onward.103

66. D-Link Systems appears to be responsible for very little with respect to the security of

D-Link routers and IP cameras. Indeed, Mr. Wang testified that it would not make sense for D96 D-Link Sys. 30(b)(6) Dep. 15:9–25 (Apr. 25, 2018). 

97 Brown Dep. 41:15–23 (Mar. 14, 2018); D-Link Sys. 30(b)(6) Dep. 17:5–25, 18:3–12 (Apr. 25, 2018); Wang Dep. 

20:3–25:14 (Dec. 6, 2017). 

98 Brown Dep. 41:7–14 (Mar. 14, 2018); Decl. of William Brown in Supp. of D-Link Corp.’s Mot. to Dismiss ¶ 1 

(Apr. 3, 2017) (ECF 50-2); D-Link Sys. 30(b)(6) Dep. 19:10–14 (Apr. 25, 2018). 

99 Brown Dep. 49:1–6 (Mar. 14, 2018); Wang Dep. 20:20–21:2 (Dec. 6, 2017); D-Link Sys. 30(b)(6) Dep. 12:13–16, 

148:13–19 (Apr. 25, 2018). 

100 Cline Dep. 144:7–22 (Apr. 24, 2018); Wang Dep. 20:20–21:9 (Dec. 6, 2017); D-Link Sys. 30(b)(6) Dep. 148:13–

22 (Apr. 25, 2018). 

101 Cline Dep. 10:7–16 (Apr. 24, 2018); D-Link Sys. 30(b)(6) Dep. 149:4–25, 227:1–4 (Apr. 25, 2018). 

102 D-Link Sys. 30(b)(6) Dep. 149:4–21, 227:1–4 (Apr. 25, 2018). 

103 Brown Investigational Hr’g. Tr. 209:5–14 (July 29, 2014). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 35 of 165
35 

Link Systems to have a primary role, because security was an issue that affected all D-Link 

products, globally, and therefore should be handled at the D-Link Corporation level.104

67. D-Link Systems’ employees admitted that they did not receive III/Onward security

testing reports from D-Link Corporation as a matter of course.105 If they received the security 

reports at all, it was only upon request.106 My understanding from the FTC’s attorneys is that DLink Systems was asked to produce, as part of this litigation, any testing reports it had, and it 

produced none. D-Link Systems’ employees also admitted that they do not have the ability to do

security testing on their own.107 As discussed in detail below (see Section III.C.1 below), DLink Systems’ employees also admitted that they understand little, if anything, about the 

development process. 

68. D-Link Systems’ role appears to have been to interface with third-party security

researchers who reported bugs in D-Link products, beginning in late 2012 and early 2013.108

Their primary role, however, was to pass this information along to D-Link Corporation, and then 

pass any fixes back along to the security researcher to see if their concerns were addressed.109

Accordingly, in my opinion, the primary skill that D-Link Systems’ employees brought to the 

equation was to be a corporate pass-through that could speak English. 

104 Wang Dep. 93:10–94:3, 204:20–205:3 (Dec. 6, 2017).

105 Wang Dep. 94:14–95:8 (Dec. 6, 2017); Brown Dep. 229:2–234:10 (Mar. 14, 2018); Cline Dep. 34:5–13 (Apr. 24, 

2018) (testifying that he did not recall receiving testing reports for the products for which he was responsible). 

106 Wang Dep. 87:5–10, 94:14–95:8 (Dec. 6, 2017); Brown Dep. 229:2–235:25 (Mar. 14, 2018); D-Link Sys. 

30(b)(6) Dep. 52:22–54:15; 67–68; 82:1–87:24, 100:15–23 (Apr. 25, 2018). 

107 Wang Dep. 102:19–25 (Dec. 6, 2017). 

108 D-Link Sys. 30(b)(6) Dep. 46:11–19, 61:18–25, 65:21–25, 66:1–25, 68:12–24, 70:1–25 (Apr. 25, 2018). 

109 D-Link Sys. 30(b)(6) Dep. 75:14–24, 76:1–77:1, 78:17–20, 81:12–21 (Apr. 25, 2018); Brown Dep. 55:17–24, 

90:15–91:24 (Mar. 14, 2018) (describing how Brown would work with D-Link Corporation’s large staff, who 

facilitated fixes from the vendors); Brown Investigational Hr’g. Tr. 79, 81:16–25, 82–87 (July 29, 2014); Cline Dep. 

13:4–10, 26:24–25, 81:5–23 (Apr. 24, 2018) (“The broad strokes is they fix it, but I wouldn’t be able to tell you 

what they did exactly.”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 36 of 165
36 

69. I understand that D-Link Systems has formally taken the position in this litigation that DLink Systems, not D-Link Corporation, is responsible for addressing security vulnerabilities: 

D-Link Systems is responsible for addressing any potential security

vulnerabilities for any products that are sold by D-Link Systems in the United

States. D-Link Corp. will sometimes inform D-Link Systems of potential

vulnerabilities to be aware of; for example, if a product sold in other parts of the

world might potentially have an issue, analogous products we sell in the United

States may also potentially need to be evaluated to determine whether similar

issues may be present. But D-Link Systems is responsible for addressing any

potential security vulnerabilities for any products that are sold by D-Link

Systems.110

70. As a security professional, I struggle to understand this position. Mr. Brown states that,

for D-Link Systems, he is the “expert in the software security field.”111 It would be 

inconceivable for all security vulnerabilities on the long list of devices D-Link Systems has been 

selling (e.g., Appendix A) to be handled by William Brown—who lacks any formal security 

training (see Section III.C.1 below),112 cannot recall seeing a III/Onward security testing 

report,113 and neither had nor has much input into or understanding the development process (see 

Section III.F.4.c below). 

71. Moreover, this position in this litigation appears at odds with how D-Link Systems’

employees seem to understand their role. As discussed above, Mr. Wang, the former D-Link 

Systems president, stated in his deposition: 

110 D-Link Systems Answers. and Objs. to FTC 1st Reqs. for Admis. Nos. 2, 3, 5 (May 18, 2018); Decl. of William 

Brown in Support of Def. D-Link Corp. Mot. to Dismiss ¶ 25 (Apr. 3, 2017) (ECF 50-2). 

111 Brown Dep. 109:22–24 (Mar. 14, 2018). 

112 Brown Investigational Hr’g. Tr. 107:14–109:16 (July 29, 2014). 

113 D-Link Sys. 30(b)(6) Dep. 68:8–69:1 (Apr. 25, 2018). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 37 of 165
37 

[MR. WANG]: Security is a global phenomenon. D-Link Corporation 

should help me find that or do that work for me for D-Link Systems.114

In an internal email115 when he was serving as D-Link Systems’ president, Mr. Brown made a 

similar, clear statement of his understanding of D-Link Systems’ role, relative to that of D-Link 

Corporation: 

72. Although the FTC’s attorneys have asked me to accept D-Link Systems’ representation

that it was solely responsible for addressing security vulnerabilities in D-Link routers and IP 

cameras sold in the United States, it is impossible to evaluate the security posture without 

looking at times to the practices of D-Link Corporation. Accordingly, this report—in particular 

Section III.E—inevitably looks to the practices of D-Link Corporation to understand why DLink devices repeatedly contained obvious, remediable flaws. But the report also endeavors to 

accept the argument that D-Link Systems is responsible for addressing security vulnerabilities. 

114 Wang Dep. 93:10–12, 204:20–25 (Dec. 6, 2017). 

115 Email from William Brown to Hans Liu (Apr. 13, 2015) (DLS0049148–149, at DLS0049148). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 38 of 165
38 

C. D-Link Systems Lacked the Practices and Controls to Develop Software in a

Secure Way and to Systematically Address Vulnerabilities

73. Based on my decades of experience in security, including as a Chief Information

Security Officer, Mr. Brown and D-Link Systems lacked the procedures to be able to effectively 

prevent or address security vulnerabilities in D-Link devices sold by D-Link Systems.

1. Absence of Indications of Seriousness

 

 

75. Lack of discussions with leadership. Another way to evaluate the prioritization of

security is to examine the interactions between the board of directors and the individuals 

responsible for security. For example, when I was the CISO of NASDAQ, I reported to the CEO 

on a regular basis, presented to the board at times, and spoke with members of the board and 

other top leaders individually. We routinely discussed issues and agreed on priorities. By 

contrast, I learned from the deposition testimony and written discovery in this case that there 

116

117 Brown Investigational Hr’g. Tr. 26:21–22 (July 29, 2014). 

118 Brown Investigational Hr’g. Tr. 750:9–10 (July 31, 2014). 

119 D-Link Corp. 30(b)(6) Dep. 207:12–25 (Jan. 30, 2018). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 39 of 165
39 

 

 

, I 

conclude that this is another indicator of a lack of seriousness. 

76. Lack of evidence of serious internal discussions, other than email correspondence. In

addition to formal reporting to leadership, effective security teams should have formal, 

memorialized internal meetings to discuss software security. 

. Without these sorts of 

process-oriented efforts, companies will inevitably be reactive in their efforts to address security 

issues. 

77. Lack of evaluations of security professionals. Another indicator of seriousness is if the

security professionals are evaluated on their work. This does not seem to have occurred at D120 Brown Dep. 54:14–15 (Mar. 14, 2018). 

121 Wang Dep. 19:16–18 (Dec. 6, 2017). 

122 FTC First Set of Reqs. for Produc. to Def. D-Link Sys. and D-Link Corp., Req. No. 22 (Apr. 12, 2017). 

123 Wang Dep. 24:9–23:6 (Dec. 6, 2017). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 40 of 165
40 

Link Systems at any point. William Brown was not evaluated by his supervisor, Mr. Wang.124

Mr. Wang testified that he, himself, was rarely reviewed.125 Evaluations are necessary to 

identify where employees are failing, where they need to improve, and to inform management 

about additional needs. In my opinion, without performance reviews, a company cannot hope to 

maintain an effective staff addressing security.

78. Insufficient quantity of people. Based on the premise that, as D-Link Systems asserts,

that D-Link Systems was “responsible for addressing any potential security vulnerabilities,”126

D-Link Systems had inadequate personnel for the job, both in terms of quantity and training.

From 2013 to the present, Mr. Brown has been responsible for software security, and has only 

had one assistant during this time: John Jimenez127 at first and then Patrick Cline.128 Even this 

minimal “team” was eliminated with the departure of Mr. Cline in April 2016, leaving only Mr. 

Brown.129 Mr. Brown, in a candid email to his contacts at the parent corporation, appears 

resentful of his lack of staff: “Prior to SIM [the Security Incident Management process, 

described below in Section III.F.4.b], my team which was eliminated and now just me, used this 

124 Wang Dep. 69:25–70:5 (Dec. 6, 2017) (Q. Okay. So you’re saying that if anyone were to review William 

Brown, it would have been you? A. Correct. Q. And you’re also saying you never reviewed his performance? 

A. Correct.”). 

125 Wang Dep. 65:22–23 (Dec. 6, 2017) (“I never got review for many years.”).

126 Decl. of William Brown in Support of Def. D-Link Corp. Mot. to Dismiss ¶ 25 (Apr. 3, 2017) (ECF 50-2); DLink Sys. Answers to FTC 1st Set of Reqs. for Admis. Nos. 2, 3, 5 (May 18, 2018). 

127 It’s not clear how much of Mr. Jimenez’s job responsibilities related to security, as Mr. Brown testified: “I don’t 

recall John working much security.” D-Link Sys. 30(b)(6) Dep. 150:12–13 (Apr. 25, 2018). 

128 Brown Dep. 48:19–51:15 (Mar. 14, 2018). 

129 “Prior to SIM, my team which was eliminated and now just me, used this tracking sheet.” Email from William

Brown to Peter Tsai attaching file Security Incident Report—SitRep-022216.xlsx (Sept. 1, 2016) (DLS0036806);

Cline Dep. 10:7–9 (Apr. 24, 2018). See also D-Link Sys. 30(b)(6) Dep. 149:4–7 (Apr. 25, 2018) (Q. When Patrick

left, was he replaced? [Objection omitted] THE WITNESS: Unfortunately, no.”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 41 of 165
41 

tracking sheet.”130 In my opinion, having a fully-staffed office is necessary to effectively address 

security issues. 

79. Insufficient experience and training. In evaluating the qualifications of a security staff, as

I have often been called upon to do, one might ask whether individuals have a university degree 

or formal classroom training in security issues, and/or software development, formal technical 

training, or years of professional experience in the field. One would also look into any formal 

certifications, such as CISSP, or alternatively, CISM, a certification in information security 

management, offered by the International Accounting Management (“ISACA”). 

80.

 

130 Email from William Brown to Peter Tsai attaching file Security Incident Report—SitRep-022216.xlsx (Sept. 1,

2016) (DLS0036806–807); see also D-Link Sys. 30(b)(6) Dep. 149:4–7 (Apr. 25, 2108) (Q. When Patrick left, was 

he replaced? [Objection omitted] THE WITNESS: Unfortunately, no.”)

131 See, e.g., Brown Investigational Hr’g. Tr. 107:14–24 (July 29, 2014) Cline 

Dep. 143:1–25 (Apr. 24, 2018). 

132 Wang Dep. 215:20–216:12 (arguing that a clear text password might not be a flaw because it could not be seen 

by consumer or casual user), 100:10–101:16 (discounting vulnerabilities that can be exploited “if I was in your 

house,” demonstrating remarkable naiveté as to the methods attackers use to remotely leverage a local-area network 

vulnerability), 165:9–166:4 (confirming he means attacks from on the local-area network) (Dec. 6, 2017). 

133 Brown Investigational Hr’g. Tr. 297:13–22 (July 20, 2014). 

134 Brown Dep. 180:5–25 (Mar. 14, 2018) (“just like in most hacking things, you need to be trained by people using 

those tools, and so that’s why I just looked online and attempted to figure it out.”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 42 of 165
42 

Mr. Brown and Mr. Wang stated that D-Link Systems cannot keep up with threats because cyber 

threats are changing.135 But he seems genuinely ignorant that D-Link Systems is failing because 

of pervasive software flaws for which fixes were understood as many as 40 years ago (see 

Section III.C below). Patrick Cline demonstrated some ability to the team during his short 

tenure, given his lack of training and experience. But he was only able to perform basic steps to 

look for potential security issues, and was never replaced when he left.136

2.

81. D-Link Systems, and Mr. Brown in particular, repeatedly discussed “trusting” the

vendors and D-Link Corporation.137 But, in the security field, we talk about assurance, rather 

than trust in another organization. Assurance is grounds for confidence (to use the terminology 

of the Common Criteria standards I discussed earlier) that a Target of Evaluation meets the 

Security Functional Requirements.138 The drumbeat for assurance reveals the importance of 

135 Brown Investigational Hr’g. Tr. 334:16–336:3 (July 30, 2014); Wang Dep. 100:10–24 (Dec. 6, 2017) (“As I say, 

security is a[n] evolving issue, and you cannot fix everything because there are so many theoretical concept[s] to 

it.”). Mr. Brown also misunderstands something he has been told about chipsets providing built-in protection 

against buffer overflows—what he is thinking of are “traps” that can automatically reboot a device to stop a stack 

overflow; there are no hardware mitigations that can prevent all buffer overflows. D-Link Sys. 30(b)(6) Dep. 

220:16–19 (Apr. 25, 2018). 

136 D-Link Sys. 30(b)(6) Dep. 149:4–150:2 (Apr. 25, 2018). 

137 See, e.g., Brown Dep. 108:12–111:21, 139:3–9, 161:12–16 (Mar. 14, 2018); D-Link Sys. 30(b)(6) Dep. 73:9–21, 

75:15–76:1, 87:19–88:4 (“I think it’s—I don’t know of any documents in—a document could never replace the 

relationship that I’ve had, and the trust relationship I have with [D-Link Corporation] and the vendors.”), 108:18–

109:7, 197:12–198:14 (Apr. 25, 2018). 

138 See COMMON CRITERIA, PART 1: INTRODUCTION AND GENERAL MODEL 15 (Aug. 2005) (defining “assurance” as 

“grounds for confidence that a Target of Evaluation (“TOE”) meets the Security Functional Requirements 

(“SFRs”)), https://www.commoncriteriaportal.org/files/ccfiles/CCPART1V3.1R5.pdf. 

COMMON CRITERIA, PART 3: SECURITY ASSURANCE COMPONENTS 16 (Apr. 2017) (“The CC philosophy is to provide 

assurance based upon an evaluation (active investigation) of the IT product that is to be trusted. Evaluation has been 

the traditional means of providing assurance and is the basis for prior evaluation criteria documents. In aligning the 

existing approaches, the CC adopts the same philosophy. The CC proposes measuring the validity of the 

documentation and of the resulting IT product by expert evaluators with increasing emphasis on scope, depth, and 

rigour.”), https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 43 of 165
43 

demonstrating not just what you think you know about the security level of software, but how 

you know it.139 The Evaluation Assurance Levels (EALs) in the Common Criteria, for example, 

provide an increasing scale that balances the level of assurance obtained with the cost and 

feasibility of acquiring that degree of assurance.140 For assurance to work properly, a company 

interacting with another company must establish written expectations; must verify compliance 

with those expectations; and must take steps to enforce those expectations if anything goes 

wrong. 

82. D-Link Systems failed to specify what it expected from D-Link Corporation or its

vendors. Typically, a recipient of software sets expectations for its vendors or business partners 

in written form, usually through a contract that provides verifiable, testable, requirements.

83.

 This fatalist attitude is nonsense, because many of the most 

139 COMMON CRITERIA, PART 3, SECURITY ASSURANCE COMPONENTS 17–18 (Apr. 2017) (“Evaluation has been the 

traditional means of gaining assurance, and is the basis of the CC approach. Evaluation techniques can include, but 

are not limited to: (a) analysis and checking of process(es) and procedure(s); (b) checking that process(es) and 

procedure(s) are being applied; (c) analysis of the correspondence between TOE design representations; (d) analysis 

of the TOE design representation against the requirements; (e) verification of proofs; (f) analysis of guidance 

documents; (g) analysis of functional tests developed and the results provided; (h) independent functional testing; (i) 

analysis for vulnerabilities (including flaw hypothesis); (j) penetration testing.”), 

https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf. 

140 COMMON CRITERIA, PART 3, SECURITY ASSURANCE COMPONENTS 31–46 (Apr. 2017) (“The Evaluation 

Assurance Levels (EALs) provide an increasing scale that balances the level of assurance obtained with the cost and 

feasibility of acquiring that degree of assurance. The CC approach identifies the separate concepts of assurance in a 

TOE at the end of the evaluation, and of maintenance of that assurance during the operational use of the TOE.”), 

https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf. 

141 Brown Dep. 106:22–107:15 (Mar. 14, 2018). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 44 of 165
44 

consequential software flaws plaguing its devices were explained at least 40 years ago.142 DLink Systems could have measurably improved the security of its software by adopting a set of 

software security guidelines for its vendors that has been around since 2002.143

84. Even had D-Link Systems imposed security standards, by contract or otherwise, it would

need mechanisms to verify that its standards were being met. This could take multiple forms for 

an organization seeking confidence that its products are secure. Companies require evidence of 

the security practices being undertaken, or copies of evaluations of the security of devices or 

software. Companies might also require verification that fixes for past problems had occurred.

85. Many companies also require proof that products meet a prescribed level of security

quality.144 For example, a common example of security assurance is a requirement that software 

not contain any flaws or vulnerabilities at or above a certain severity level (such as medium, 

high, or critical) and that, for vulnerabilities of other levels, an explanation be provided of why 

the vulnerabilities are mitigated or will be corrected in a subsequent software release.145

86.

142 RICHARD R. LINDE, OPERATING SYSTEM PENETRATION (AFIPS National Computer Conference, May 19–22, 

1975), https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830361.pdf. 

143 See Section III.A.3 and 5, for the background on the development of Microsoft’s SDL.

144 This also requires an agreement as to how the software will be evaluated to determine the quality level. Here, DLink Systems allowed its parent D-Link Corporation to make all decisions about the appropriate testing. 

145 Notably, as discussed in Section III.F.4 below, D-Link Corporation finally seems to be imposing such a standard 

on vendors since this case began, in Spring 2017. Code review brief report (DKC1756978) at Tab 2.0 (“Scanning 

Result Summary”) (“Besides of third-party package, the result from code scanning should not be found any highrisk and above issue (such as high, critical, high-risk etc.), medium-risk should notify the reason why the patch is 

not applicable or following countermeasures for that.”). But this technique of gaining some assurance of the 

security of software has been prevalent for well over a decade before D-Link Corporation appears to have adopted 

it. And D-Link Systems continues to be unaware of these requirements or able to enforce them. D-Link Sys. 30(b)

(6) Dep. 89:22–91:24 (Apr. 25, 2018). 

146 D-Link Sys. 30(b)(6) Dep. 75:15–25 (Apr. 25, 2018) (explaining that there are no requirements to disclose 

vulnerabilities or fixes that arise from the black box testing because “this is a 30 year trust relationship”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 45 of 165
45 

 Although D-Link Systems 

points to the security testing performed by III/Onward, it did not receive the reports of the 

security testing conducted by this firm, and William Brown and AJ Wang could not remember 

asking for them.148 Had they, they might have understood that, even using the limited tools that 

it did, III/Onward uncovered pervasive, recurring, and well-known vulnerabilities that illuminate 

the poor development practices of D-Link Systems’ vendors (see Sections III.D and E below). If 

D-Link Systems had required its vendors to address systematic problems in a serious manner,

and to consider all potential instances where the same problem existed (even where III/Onward 

had not detected it), it might have avoided the serious exposure of D-Link Systems’ customers to 

potential attack and compromise. 

87. D-Link Systems did not have other processes to evaluate vendors on security

performance, such as auditing the vendors’ security practices or requiring vendors to submit 

documentation of those practices to D-Link Systems. Mr. Brown testified that D-Link Systems 

did not have a process to evaluate the security performance of its vendors over time,149 even as it 

learned of serious vulnerabilities in its devices and could have monitored whether certain vendors 

were the source of more or more serious vulnerabilities over time. 

147 Wang Dep. 94:14–25, 95:1–8 (Dec. 6, 2017); Brown Dep. 229:2–234:22 (Mar. 14, 2018); Cline Dep. 34:5–13 

(Apr. 24, 2018) (testifying that he did not recall receiving testing reports for the products for which he was 

responsible). 

148 D-Link Sys. 30(b)(6) Dep. 52:22–54:15 (William Brown can request the reports, but says in most cases it is 

quicker to pick up the phone), 68:8–69:1 (Mr. Brown does not recall ever requesting a black-box testing report, and 

was typically satisfied by phone discussions) (Apr. 25, 2018); Brown Dep. 229:2–230:1 (Mar. 14, 2018) (Mr. Brown 

has never reviewed an III/Onward Security report, and relies on D-Link Corp. contacts to tell him what he needs to 

know); D-Link Sys. 30(b)(6) Dep. 68:8–69:1 (Apr. 25, 2018) 

D-Link Sys. 30(b)(6) Dep. 68:3–25 (Apr. 25, 2018) (testifying that he did not recall asking for either a black-box

testing report or a white-box testing report); Brown Dep. 229:2–18 (Mar. 14, 2018) (testifying that he had never

reviewed an III/Onward report); Wang Dep. 101:18–102:17, 104:8–105:16 (Dec. 6, 2017) (testifying that D-Link

Corporation and the vendors received the III/Onward reports; and if anyone received them at D-Link Systems, it

would have been Mr. Brown)

149 Brown Dep. 161:12-16 (Mar. 14, 2018). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 46 of 165
46 

88. Finally, assurance requires consequences if the desired condition is not met. In the

context of security for products a company is having developed by a vendor, this could take 

many forms: refusal to accept flawed software; reduction of the payment for the software; 

contractual remedies such as billing costs to the vendor for having the software created by 

properly by another company; ceasing business with the vendor; or even a lawsuit by the 

company enforcing its contract with the vendor.

 

 

150 D-Link Sys. Answers to FTC 1st Set of Reqs. for Admis., No. 362 (May 18, 2018): 

REQUEST FOR ADMISSION NO. 362

Admit that there have been no contracts in effect during the Applicable Time Period 

between D-Link Systems and any Vendors governing the manufacture of any Relevant Devices.

RESPONSE TO REQUEST FOR ADMISSION NO. 362 

Denied to the extent that [D-Link Systems] has long-term trust relationships with the vendors that 

continuously manufacture provide firmware for the routers and IP cameras listed in Appendix A 

and assured its technical assistance and cooperation for the products. 

151 D-Link Sys. 30(b)(6) Dep. 50:13–21 (Apr. 25, 2018).

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 47 of 165
47 

90. It is impossible to enforce security standards when they are not written into contractual

language designed to require better practices.152 

3. No Independent Ability to Determine Safety of Products

.

155 

 

152 I reviewed contracts that appear be between three of D-Link Systems’ main vendors— APPRO Tech, Cameo 

Communications, and Alpha Networks—and D-Link Corporation. Alpha Technology, Inc. Purchase Contract 

(DKC0006140-T–54-T); Appro Purchase Contract (DKC0006155-T–73-T); Cameo Communications Inc. Purchase 

Contract (DKC0006183-T–98-T). These documents seem to give D-Link Corporation some rights to audit, stop 

shipment, impose requirements, etc., although they do not describe any of these steps as to security. The contracts 

for devices between the vendors and D-Link Corporation seems to contradict my understanding that D-Link 

Systems purchases the devices directly from the vendors. 

153 This error is discussed further below, at Section III.D.8.

154 Wang Dep. 200:1–25 (Dec. 6, 2017). 

155 As discussed in Section III.F.4.a below, D-Link Systems came closest to this level of evaluation with its work 

with SEARCH-LAB Ltd., but D-Link Systems did not begin using SEARCH-LAB to assess its device software 

until June 2016, and so far has only assessed the software for two IP cameras. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 48 of 165
48 

92. In addition, where D-Link Systems has been informed of vulnerabilities,

. Without this information, D-Link Systems cannot hold its vendors

accountable for addressing a particular flaw across all of its devices. 

93. Furthermore, D-Link Systems did not require, or even request, reports concerning

security testing of its devices performed by D-Link Corporation.156 D-Link Systems relied 

entirely on assurances from D-Link Corporation and vendors that problems were addressed, and 

was blind to the types of repeated flaws III/Onward identified in D-Link Systems’ devices. DLink Systems did not have its own contract with III/Onward, and thus relied on D-Link 

Corporation to ensure that an adequate number of devices were tested and that III/Onward used 

sufficient testing methods. 

4. No Internal Procedures to Track Vulnerabilities

94. Organizations that take security seriously also take reports of vulnerabilities in their

software seriously. An important part of that is managing the remediation of those 

vulnerabilities to ensure they are understood, all affected software is identified, and that software 

is appropriately patched. 157 Any enterprise managing a product line as large as D-Link Systems 

156 Brown Dep. 112:8–113:25 (Mar. 14, 2018) (admitting that he could not recall ever asking for a report from 

III/Onward verifying that vendors had fixed the software vulnerability); 229:2–18 (Mr. Brown said he had never 

reviewed one of the III/Onward reports and had never asked to review one). 

157 MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE 72–73 (2006) (“It is critically 

important that security and privacy bugs be tracked correctly in your bug-tracking database. Even more important, 

such bugs must be tracked in a consistent manner.”); MICHAEL HOWARD & DAVID LEBLANC, WRITING SECURE

CODE 46 (2d ed. 2003) (“When a security flaw is found in the design or in the code, you should log an entry in your 

bug-tracking database, as you would normally do.”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 49 of 165
49 

would have systems in place to manage this process and ensure nothing falls through the 

cracks.158

95. When security flaws are identified, by an outside party or internally, organizations need

to have a clear system to manage getting them fixed. Flaws need to be given a unique identifier 

so they can be distinguished while being discussed. III/Onward is a good model of this practice, 

which they applied to problems they identified. 159 But D-Link Systems (and D-Link 

Corporation) did not follow III/Onward’s model. 

96. Vulnerability and bug identification is especially important in an organization such as DLink Systems, which is managing many different products and need to track corresponding 

security flaws simultaneously. D-Link Systems instead relied on email threads stemming from 

reports provided by outside security researchers.160 In many cases, outside researchers disclosed 

a number of flaws, and D-Link Systems’ failure to have assigned an identifier to each issue 

created a morass for D-Link Systems to determine if every issue had been researched and 

addressed. Without proper tracking systems that help maintain a schedule for resolving 

vulnerabilities, it is easier to lose track of issues. 

97. Without a unique identifier by which to discuss a flaw, D-Link Systems created a

significant challenge for itself in pressing for details on the root cause of the problem, whether 

the flaw exists elsewhere in its code, or whether it has been addressed in other products that 

158 COMMON CRITERIA, PART 3, SECURITY ASSURANCE COMPONENTS 155 (Apr. 2017) (“Flaw remediation requires 

that discovered security flaws be tracked and corrected by the developer. Although future compliance with flaw 

remediation procedures cannot be determined at the time of the TOE evaluation, it is possible to evaluate the 

policies and procedures that a developer has in place to track and correct flaws, and to distribute the flaw 

information and corrections.”), https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf. 

159 E.g., III/Onward Security, DIR-868A1 Security Testing Report (Apr. 25, 2017) (DKC0004054–4100, at 

DKC0004070) (identifying high risk, hard-coded credential, with identifier “OnSec-VUZ-106-05001”). 

160 D-Link Sys. 30(b)(6) Dep. 146:23–147:5 (Apr. 25, 2018); Brown Dep. 229:2–230:11, 250:5–10 (Mar. 14, 2018). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 50 of 165
50 

share similar code. This confusion is evident in multiple examples of D-Link Systems’ 

correspondence on flaws and fixes.161 In this, D-Link Systems again relied on D-Link 

Corporation to manage the process of getting issues addressed,162 and took D-Link Corporation’s 

word that certain firmware fixed an issue, even in the face of examples of the same problem

arising again. 

98. The negative consequences of D-Link Systems’ inability to manage this process for itself

are not theoretical. In one example, D-Link Corporation learned of vulnerabilities, addressed 

them, but failed to provide the patched firmware to D-Link Systems for three years.163 D-Link 

Systems did not get the patch to provide to its customers until after another security researcher 

found the same problem and disclosed it to D-Link Systems.164 In order to be responsible for 

security, D-Link Systems needs access to issues reported to its affiliates, in order to determine 

for itself if there is an impact on its customers. 

99. Even assuming it is possible to keep track of security flaws by email, D-Link Systems’

approach would not succeed.165 

161 E.g., Email from Patrick Cline to Daniel Hsu (May 13, 2015) (DKC1587274–85). 

162 Brown Dep. 106:15–21 (Mar. 14, 2018) (“So I elevate all requests through [D-Link Corporation] who then 

facilitate to the vendors.”). 

163 See Email from William Brown to Osanda Malith Jayathissa (Dec. 21, 2016) (DLS0023367-68) (noting a fix had 

been posted on worldwide support site in 2014, but not to the United States support site) 

164 Email from Osanda Malith Jayathissa to William Brown attaching proposed public disclosure (Jan. 10, 2017) 

(DLS0023351-54); Osande Malith, D-Link DIR-615 Open Redirection and XSS, BLOG OF OSANDA, 

https://osandamalith.com/2017/01/04/d-link-dir-615-open-redirection-and-xss/; DIR-615 Firmware Release Notes 

(Apr. 14, 2014) (DLS0023364) (“Fixed the exploit... that can be used for CSRF attack from LAN side. ... Corrects 

XSS and Open Redirect on ping_response.cgi.”). 

165 In most cases, for instance, D-Link Systems simply adopts whatever email subject line was used by the security 

researcher who disclosed the report. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 51 of 165
51 

. Email is not a replacement for a 

centralized system that relates the vulnerabilities/flaws to affected devices, history, fixes, status, 

and a categorization of severity. The use of email exchanges to track vulnerabilities is also too 

prone to lead to parallel competing versions of information. 

100. D-Link Corporation started rolling out an improved process called Security Incident

Management (SIM), in 2015 and 2016. As discussed in Section III.E.4.b below, although this 

system is much improved over D-Link Systems’ tracking efforts, D-Link Systems can only read 

the entries, and relies on D-Link Corporation staff to create and update entries. For this reason, it 

does not give D-Link Systems the tools it needs to be assured that security flaws are adequately 

addressed. 

101. Mr. Brown interfaced with security researchers to collect information about

vulnerabilities. Mr. Brown reported that he first created an “official process” for taking in 

vulnerabilities in December 2012 or January 2013.167 However, Mr. Brown and D-Link Systems 

failed to track its collection of those vulnerabilities and track their status.168 I have reviewed the 

evidence of how D-Link Systems managed the security flaws and vulnerabilities to which its 

routers and cameras were vulnerable. This includes the testimony of Mr. Brown, AJ Wang, and 

166 See, e.g., Email from Daniel Hsu to William Brown (Apr. 24, 2015) (DLS0042150–167). 

167 Brown Investigational Hr’g. Tr. 35:7–20 (July 29, 2014). 

168 Brown Dep. 73:2–16 (Mar. 14, 2018) (admitting that he does not memorialize or log his tracking of security 

issues). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 52 of 165
52 

Patrick Cline; a spreadsheet maintained solely by Mr. Cline;169 a presentation that describes and 

shows images of content from D-Link Corporation’s SIM system;170 and voluminous emails in 

which D-Link Systems attempted to manage the response to security issues and fixes. 

102. The manner in which they did so was ad hoc and poorly maintained. D-Link Systems has

relied on email chains to keep track of open issues.171 The only centralized record D-Link 

Systems possessed of past vulnerabilities was a single spreadsheet maintained by Patrick Cline 

for keeping track of the reported security issues for which he was personally responsible.172 The 

mere fact that there was no clear-cut policy on how to track vulnerabilities demonstrates that DLink Systems failed to put in place the basic processes necessary to be responsible for identifying 

and correcting vulnerabilities. As with everything else, their process appears to have been 

entirely based on blind trust in their parent organization. 

169 Email from William Brown to Peter Tsai attaching file Security Incident Report—SitRep-022216.xlsx (Sept. 1,

2016) (DLS0036806–807). 

170 D-Link Product Security Issue Analysis (Oct. 10, 2017) (DKC0648113–54, at DKC0648115–16). 

171 E.g., Brown Dep. 254:23–255:11 (Mar. 14, 2018) (William Brown would have to search back through his email 

to locate information on particular vulnerabilities); D-Link Sys. 30(b)(6) Dep. 145:16–17 (Apr. 25, 2018) (“[W]e 

were just using e-mail to communicate and follow up by phone calls.”). 

172 Based on the text of his email, in 2016, Patrick Cline’s spreadsheet, with a list of past issues, was the only 

resource Mr. Brown could provide to D-Link Corporation for it to update its SIM database. Email from Brown to 

Tsai attaching Security Incident Report—SitRep-022216.xlsx (Sept. 1, 2016) (DLS0036806–07) (“Prior to SIM, my 

team which was eliminated and now just me, used this tracking sheet. It was provided to Yin/RC/AJ at one point but 

it maybe [sic] good to go back and validate closed or open and place them into SIM for proper tracking.”); Cline 

Dep. 45:16–47:23 (Apr. 24, 2018). At his deposition, Mr. Brown gave equivocal testimony that he and John 

Jimenez created this spreadsheet, and that it was then passed to Mr. Cline. Brown Dep. 243:9–20 (Mar. 14, 2018). 

But Mr. Brown subsequently testified, as did Mr. Cline, that this was not the case. D-Link Sys. 30(b)(6) Dep. 

148:24–149:2 (Apr. 25, 2018) (“Q: Did [D-Link Systems] use any other system, other than the e-mails you were 

describing, to track vulnerabilities and fixes prior to the implementation of the SIM? A: . . . So Patrick kept a 

spreadsheet of what he was working on; otherwise, I myself would use e-mail, and we’d communicate verbally all 

the time. . . .”); Cline Dep. 45:16–47:23 (Apr. 24, 2018). With the exception of one issue from August 2014, the 

spreadsheet’s entries are dated between January 2015 and February 2016, during Mr. Cline’s short tenure on Mr. 

Brown’s team. Email from Brown to Tsai attaching file Security Incident Report—SitRep-022216.xlsx (Sept. 1, 

2016) (DLS0036806–07); Cline Dep. 10:4–21 (Apr. 24, 2018) (Cline dates of employment in the Office of the 

CTO). Even were this spreadsheet a tracking system D-Link Systems maintained, it would be inadequate for 

managing something as complex as the many reported vulnerabilities D-Link Systems received regarding its 

devices, for many of the same reasons as D-Link Systems’ email management, as described below. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 53 of 165
53 

103. A mere exchange of emails, without a formal, centralized mechanism of tracking, is

inadequate to stay abreast of vulnerabilities.173 Worse, even Mr. Brown’s “system” of using 

emails is suspect in light of the fact that his main contact at D-Link Corporation appears at one 

point to have attempted to transfer his communications with Mr. Brown off of official company 

email and onto his personal email: “From now on I will use my private email to update the 

status of reported exploits.”174 Mr. Brown’s explanation for this email, in his testimony on 

behalf of D-Link Systems, makes no sense to me.175 Regardless of the motivation, it is highly 

ill-advised for a security professional to transfer these types of communications to non-corporate 

email. This behavior shows a lack of disciplined security awareness, a lack of concern for 

accurately tracking vulnerabilities, and bypasses the ability for the corporation to have data backups to preserve these critical communications. Moreover, by using his personal email address, 

Mr. Brown opens up additional potential concerns about the security of the information he is 

transferring, since his personal email would presumably not be subject to the same security 

procedures as his official corporate email. 

104. Based on this evidence, I have concluded that D-Link Systems’ processes for tracking

and remedying security flaws in its devices was at the most basic level, more expected for a startup organization or one with very limited products. In addition, D-Link Systems’ current 

173 COMMON CRITERIA, PART 3, SECURITY ASSURANCE COMPONENTS 155 (Apr. 2017) (“Flaw remediation requires 

that discovered security flaws be tracked and corrected by the developer. Although future compliance with flaw 

remediation procedures cannot be determined at the time of the TOE evaluation, it is possible to evaluate the 

policies and procedures that a developer has in place to track and correct flaws, and to distribute the flaw 

information and corrections.”), https://www.commoncriteriaportal.org/files/ccfiles/CCPART3V3.1R5.pdf; 

Michael Howard & Steve Lipner, The Security Development Lifecycle: A Process For Developing Demonstrably 

More Secure Software 30, 51, 72, 183 (2006) (“It is critically important that security and privacy bugs be tracked

correctly in your bug-tracking database.”), https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/freeebook-the-security-development-lifecycle/. 

174 Email from dlink dlink <wrpd.exploit@gmail.com> [Daniel Hsu] to dubyabee2@mac.com [William Brown] 

(Aug. 4, 2014) (DLS0042456–61, at DLS0042456). 

175 D-Link Sys. 30(b)(6) Dep. 212:2–6 (Apr. 25, 2018) (suggesting the corporate email system was “down”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 54 of 165
54 

processes in this area continue to be inadequate, or at least are entirely dependent on the 

reliability of its parent, because D-Link Systems does not have write-access to the vulnerability 

management system maintained by D-Link Corporation.176

5. Ignored Repeated Warnings that Security Practices Were Inadequate

105. While D-Link Systems failed to institute steady or systematic policies or process to

promote security quality, they did make sporadic efforts to identify issues with their products in 

the years 2012-2013. Notably, however, when issues were identified by the consultants and 

experts D-Link Systems engaged, the advice of those paid experts to address software 

development flaws systematically was ignored.177 For example, in the one security evaluation 

report Rapid7 produced about D-Link Systems devices in 2011, Rapid7 recommended that 

“[d]ue to the degree of these vulnerabilities Rapid7 additionally recommends D-Link develop 

and implement a comprehensive Security Development Life cycle program that will integrate 

secure design principals [sic] into the development process.” 178

106. Likewise, when D-Link Systems engaged Jason Doyle to perform security evaluations of

two of its routers in 2013, Mr. Doyle advised in his report that “[o]verall, the results of this 

176 Brown Dep. 249:1–11 (Mar. 14, 2018) (Mr. Brown cannot write information to the SIM); D-Link Sys. 30(b)(6) 

Dep. 137:19–138:1 (Apr. 25, 2018) (D-Link Systems cannot add information to the SIM; D-Link Systems sends 

information to contacts at D-Link Corporation and relies on D-Link Corporation to enter it). In some cases, 

correspondence shows that other D-Link subsidiaries around the world had to argue with D-Link Corporation staff 

to get a SIM entry created for an issue so that information on its resolution and status could be shared. Email from 

Mary Harrison, Head of European Marketing, to Quenton Miao, D-Link Corporation (Mar. 18, 2016) 

(DLS0038010–92). 

177 This is in addition to the warnings D-Link Systems should have heeded from the many serious vulnerabilities it 

was being informed of by outside security researchers, discussed further in Section III.E below. 

178 Rapid7, mydlink DCS-1130L Assessment (Jan. 25, 2011) (DLS0056608–59, at DLS0056611). Although it is 

unclear whether Rapid7 was performing services for D-Link Corporation or D-Link Systems, at least Ted Kuo of 

D-Link Systems received this report. Email from Mac Mac to Laurence Tsai, attaching Rapid7_-_D-Link_-

_MyDlink.com_-_DCS-1130_Final.pdf (Feb. 8, 2012) (DLS0056607–59, at DLS0056607) (copying Ted Kuo of DLink Systems, writing “[a]ttached is the Rapid7 test report.”). I have been told by the FTC attorneys that the DLS

prefix for the Bates numbers means the report was provided from D-Link System’s files. The FTC’s attorneys

informed that the Bates numbers on documents beginning “DKC” designates documents from D-Link Corporation,

and those with DKS Bates numbers were provided during the investigation period.

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 55 of 165
55 

assessment are indicative of [a] system that has not undergone a thorough security evaluation.”179 

He further recommended that “developers become familiar with the OWASP Top 10 list of web 

application security vulnerabilities and trained on secure coding practices which will help address 

common application vulnerabilities.”180 This advice was provided in April 2013. Had D-Link 

Systems acted on this advice and initiated a meaningful review of its product line, it likely could 

have addressed or prevented some of the serious vulnerabilities later discovered in its routers and 

IP cameras (see Section III.E below). 

107. Surprisingly, various D-Link Systems and D-Link Corporation employees’ emails

suggest they were well aware of broader security problems. At nearly the same time as Mr. 

Doyle’s reports, William Brown opined that “Alpha products are more vulnerable than Cameos. 

Cameos vulnerabilities are catastrophic when found.”181 Despite that perception, he notes that DLink Systems has just three processes in place to “discover and/or verify issues”:

(1) monitoring forums; (2) a (short-lived) bug bounty program (see Section III.F.3 below); and (3)

D-Link Corporations’ work with III/Onward and Mr. Brown’s contracting out to some trusted

experts.182 

108.

179 Jason Doyle, DIR-826L Security Evaluation (Apr. 16, 2013) (DLS00038165–76, at DLS00038168). Mr. Doyle’s 

work for D-Link Systems is also discussed in Section III.F below. 

180 Ibid. 

181 Email William Brown to Rick Chiang (Apr. 9, 2013) (DLS0030587–89, at DLS0030587). 

182 Ibid. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 56 of 165
56 

6. “Trust” Is Not Enough

109. Mr. Brown’s mantra in response to questions about the processes in place at D-Link

Systems is to repeat that he simply “trusts” D-Link corporation. 184 As discussed above, the 

touchstone in the security field is “assurance,” not “trust.” Assurances are based on reliable, 

auditable processes. All that said, even if “trust” were a legitimate approach to security, that 

trust could only be premised on results that would inspire trust. As I will discuss in the next 

section, the flaws that were repeatedly found in the code of D-Link routers and IP cameras 

should have undermined the basis of any trust. D-Link Systems should have never simply 

“trusted” someone else to make sure its devices were secure. But, even if “trusting” were a 

legitimate approach, D-Link Systems should have quickly understood, based on the nature of the 

flaws that have been identified by third parties from late 2012 to the present, that its trust in its 

parent corporation and the vendors was badly misplaced. The vulnerabilities that third parties 

identified revealed fundamental failures in the way these devices were being developed.185 

183 Email from Jay Radcliffe to Ping Chen (Apr. 11, 2015) (DLS0049144–45, at DLS0049145). In the same 

exchange, Hans Liu of D-Link Corporation pointed out that the devices should not have the telnet daemon, see 

Section III.D.4 above (Unnecessary Protocols and Services), or be using http basic authentication. 

184 Brown describes the relationship with D-Link Corporation as one of “trust.” See, for example, Brown Dep. 

108:12–111:21, 139:3–9, 161:12–16 (Mar. 14, 2018); D-Link Sys. 30(b)(6) Dep. 73:9–21, 75:15–76:1, 87:19–88:4

(“I think it’s—I don’t know of any documents in—a document could never replace the relationship that I’ve had, 

and the trust relationship I have with [D-Link Corporation] and the vendors.”); 108:18–109:7, 197:12–198:14 (Apr.

25, 2018).

185 See, for example, Jason Doyle and Rapid7 quotes in Section III.C.5 above, and Section III.F below. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 57 of 165
57 

110. D-Link Systems’ trusting approach is in stark contrasts to that of one of its European

counterparts.186 I have reviewed 2013 correspondence showing a D-Link business unit in 

Germany advocating for D-Link Corporation have devices tested by III/Onward.187 While they 

were in the process of choosing which devices to test, Michael Messner disclosed numerous, 

serious vulnerabilities in D-routers (affecting some D-Link Systems models too, see Section 

III.E.1.c below).188 In response, the business unit “reorganized our resources in DCE

[abbreviation for the business unit], so that we could perform our own testing.”189 Alexander 

Koller of the business unit evaluated several routers (the DIR-300, DIR-600, DIR-615, DIR-645, 

DIR-815, and DIR-845L).190 Mr. Koller found a number of additional problems. For example, 

regarding the DIR-615, he wrote “[m]ultiple options for code injections.... The problem is all 

variables are written directly into a Javascript code block at the top of the page, so a simple 

javascript injection is possible.... As [I] say [sic] before you have to check all input fields for 

malicious code injection.”191 Although the type of testing that “DCE” conducted would not 

solve D-Link Systems’ problem, it is a step in the right direction. In addition, in my experience, 

the serious response evidenced in the business unit’s reactions to Mr. Messner’s report is more in 

line with how companies who take security seriously would react. 

186 See Email from Tarik Erdemir to Daniel Hsu et al. and attached D-Link Router Security Test report (Mar. 28, 

2013) (DKC0010751–815, at 10780–81). 

187 Ibid. at DKC00010780–82. 

188 Ibid. at DKC00010778–80. 

189 Ibid. at DKC00010776–77. D-Link Systems, by comparison, paid an outside security researcher, Jason Doyle, 

$2000 to perform tests on two routers, one time. Jason Doyle Evaluation Request (July 25, 2013) (DKS00011858–

59). 

190 Ibid. at DKC00010783–815. Mr. Koller tested for new problems, and also tested whether vulnerabilities 

disclosed by Mr. Messner were fixed. 

191 Ibid. at DKC00010789. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 58 of 165
58 

111. In my opinion, at least after receiving the evaluations it hired Jason Doyle to perform in

April 2013, D-Link Systems should have realized that D-Link Corporation and the third-party 

vendors were shipping devices with multiple fundamental vulnerabilities resulting from a lack of 

a “comprehensive Security Development Life cycle program.”192 These multiple vulnerabilities 

and the lack of a comprehensive SDLC should have ruled out “trusting” D-Link Corporation and 

their vendors to assure adequate security in these devices. 

D. The Fundamental Code Development Failures that Repeatedly Appeared in

D-Link Routers and IP Cameras Demonstrate that D-Link Systems’ Trust in

D-Link Corporation and its Vendors was Misplaced

112. In the following sections, I will discuss some of the most basic design, implementation,

and code maintenance failures (collectively, “code development failures”) that appeared in DLink devices. I will describe how these types of failures were well-known to security 

professionals before 2012—sometimes for decades before. I will describe how security 

professionals and software developers were aware of many different ways to identify and prevent 

these vulnerabilities from appearing in devices. Lastly, I will describe how these failures 

appeared in multiple D-Link devices, with reference to the next section, in which I will discuss 

some of the particular vulnerabilities involving these failures. 

113. I discuss in this report a representative subset of the failures caused by D-Link’s

development policies and processes. This is not an exhaustive list. I have selected these flaws 

and failures because they are illustrative of the immature state of D-Link Systems’ security 

processes. They are illuminating because they have been well-known for a long time, and are so 

192 Rapid7 warned D-Link about this issue in 2011. See Rapid7, mydlink DCS-1130 Assessment (Jan. 25, 2011) 

(DLS0056608–DLS0056659 at DLS0056611). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 59 of 165
59 

easily preventable. The aggregate impact of these flaws and failures is to render D-Link 

Systems’ routers and IP cameras not secure against unauthorized access or control. 

114. The first pervasive software flaw affecting D-Link Systems’ routers and IP cameras is a 

failure to properly filter or validate input. Simply put, input filtering or validation is the process 

of inspecting user input (such as a string of characters typed in from a keyboard) to make sure 

that it will not cause a malfunction.193 This malfunction could be anything from improper data 

being written to a database field, to a device executing a hacker’s command and thereby handing 

over control of the device. Although it may be necessary in other contexts, input filtering as a 

security practice is critical where the input being handled comes from a user, either whole or in 

part. For example, where there is a field where a user needs to enter some information (like the 

user’s name, for the software to add to a database), a malicious actor could enter certain symbols 

that the software would execute as code, rather than just writing the information to the database 

as expected.194 Depending on the purpose of the input, there are numerous techniques to make 

sure correct inputs are permitted and incorrect inputs are rejected. Failing to properly filter 

193 Although I refer to this as user input for simplicity, this really applies to any time device software handles input 

that is provided in any respect by an external source (as opposed to the result of an earlier step in the software 

process or internal data). This could be text an individual types into a field in an interface. But it could also be any 

information a device receives from an outside source, like an “I’m here” message transmitted by another device on 

the network. If the input to a particular process is coming into the software from an external source, the software 

engineer needs to assume it could be incorrect in a damaging way or intentionally manipulated by someone with 

control over that external source, who may be trying to gain unauthorized access to the device. 

194 A1 2004 Unvalidated Input, OWASP (Apr. 18, 2010) (“Attackers can tamper with any part of [a]... request, 

including the url, querystring, headers, cookies, form fields, and hidden fields, to try to bypass... security 

mechanisms.”), https://www.owasp.org/index.php/A1_2004_Unvalidated_Input#Description. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 60 of 165
inputs, fo

that secu

115. F

arbitrary 

Dependin

command

to crash; 

remote co

command

explained

The expl

“ ‘); ” aft

word as a

a comma

fictional 

195 RICHAR

19–22, 197

196 See Exp

or example, i

rity research

ailing to pro

input to the 

ng on what l

ds to the dev

make unaut

ontrol of the

ds to the dev

d the danger

anation is th

ter it, the dat

a command, 

and to erase (

child’s nam

RD R. LINDE, O

75), https://ww

ploits of a Mom

is a predicat

hers repeated

operly filter u

software to 

library the in

vice allowing

horized chan

e device by c

vice on their 

rs of failing t

his: The data

tabase in que

rather than 

(“drop”) a d

e has the res

OPERATING SYS

ww.computer.or

m, XKCD, http

te to comman

dly reported 

user input cr

cause it mal

nput is provi

g him or her

nges; or, in t

creating a sh

computer, o

to filter inpu

abase wants 

estion (a com

a further par

atabase (“tab

sult of erasin

STEM PENETRAT

rg/csdl/proceed

s://xkcd.com/3

60 

nd injection 

to D-Link S

reates an opp

lfunction in 

ded to, the a

r to retrieve n

the worst cas

ell or comm

over the Inte

uts: 

to know the

mmon SQL d

rt of the user

ble”) called 

ng the table w

TION 361–368 

dings/afips/197

327/. 

vulnerabilit

Systems.195 

portunity for

a useful way

attacker coul

non-public in

se, provide t

mand line by 

rnet. A fam

e child’s nam

database) is 

r’s input. In

“students.” 

with all the s

(AFIPS Nation

75/5083/00/508

ties, a class o

r attackers to

y (to the atta

ld successful

nformation; 

the attacker w

which the at

mous comic f

me. But if th

cued to inter

n this case, th

Thus, the in

students’ nam

nal Computer 

830361.pdf. 

of vulnerabil

o try to feed

acker). 

lly inject 

cause the de

with ongoing

ttacker can e

from 2007196

he name inpu

rpret the nex

he next word

nput of the 

mes. 

Conference, M

lity 

evice 

g, 

enter 

6

ut has 

xt 

d was 

May 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 61 of 165
61 

116. The need for input filtering has been recognized since at least 1975,197 and it has been

represented in OWASP’s list of top ten web application flaws since its inception, circa 2004.198 

Every general software security reference with which I am familiar calls attention to the 

importance of input filtering or validation.199

197 RICHARD R. LINDE, OPERATING SYSTEM PENETRATION 361–368 (AFIPS National Computer Conference, May 

19–22, 1975), https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830361.pdf. 

198 In OWASP’s 2004 updates to its Top Ten Web Application Flaws, “Unvalidated Input” was the number one 

flaw. A1 2004 Unvalidated Input, OWASP (2004), https://www.owasp.org/index.php/A1_2004_Unvalidated_Input. 

It remained the number one flaw in 2010. See Top 10 2010-A1-Injection, OWASP (2010), 

https://www.owasp.org/index.php/Top_10_2010-A1-Injection (“Injection flaws occur when an application sends 

untrusted data to an interpreter”). 

199 For example, here is a good, but not exhaustive list: 

ROSS ANDERSON, SECURITY ENGINEERING: A GUIDE TO BUILDING DEPENDABLE DISTRIBUTED SYSTEMS 849 (2nd 

ed. 2008) (“you certainly need to educate all your developers to the point that they understand the basics, such as the 

need to sanitise input to prevent overflows”); www.cl.cam.ac.uk/~rja14/book.html; 

BRIAN CHESS & JACOB WEST, SECURE PROGRAMMING WITH STATIC ANALYSIS (2007); 

MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING: PRINCIPLES & PRACTICES 92–93, 103–106 (2003); 

MICHAEL HOWARD & DAVID LEBLANC, WRITING SECURE CODE 341–361 (2nd ed. 2003) (“Chapter 10: All Input Is 

Evil!”), https://blogs.msdn.microsoft.com/michael_howard/; 

MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 274–284 (2006) (“Fuzz testing is an effective testing technique for input 

validation issues.”), https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-securitydevelopment-lifecycle/; 

GARY MCGRAW, SOFTWARE SECURITY: BUILDING SECURITY IN (1st ed. 2006), http://www.swsec.com/; 

ROBERT C. SEACORD, SECURE CODING IN C AND C++ (1st ed. 2006) (2nd ed. 2013); 

KENNETH R. VAN WYK, MARK G. GRAFF, DAN S. PETERS & DIANA L. BURLEY, ENTERPRISE SOFTWARE SECURITY: A

CONFLUENCE OF DISCIPLINES (2015); 

JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID SECURITY PROBLEMS THE RIGHT 

WAY (1st ed. 2001); 

Robert Seacord, Top 10 Secure Coding Practices, CERT, CMU/SEI (2009) (“1. Validate Input”), 

https://wiki.sei.cmu.edu/confluence/display/seccode/Top+10+Secure+Coding+Practices; 

CWE, CWE-241: Improper Handling of Unexpected Data Type, CWE (“Assume all input is malicious. Use an 

‘accept known good’ input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to 

specifications.”), http://cwe.mitre.org/data/definitions/241.html; 

CWE, CWE CATEGORY: CERT C Secure Coding (2008 Version) Section 09–Input Output (FIO), CWE, 

http://cwe.mitre.org/data/definitions/743.html; 

CWE, CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’), 

CWE, https://cwe.mitre.org/data/definitions/78.html; 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 62 of 165
62 

117. There are two general approaches to filtering input. The first is blacklisting, where the 

software rejects certain inputs.200 At a bare minimum, programmers can blacklist unneeded 

special characters like slashes, percentage signs, and quotation marks that could never represent 

legitimate input, and might be used by an attacker to cause a malfunction. Depending on the 

desired outcome, the programmer might set up the software to either delete the special characters 

from the input and process the remainder, or reject the input entirely. A more secure method is 

to whitelist, which is to define the permitted inputs, and to reject any input that does not match 

that definition.201

118. Since at least 2012, D-Link Systems and D-Link Corporation have been alerted numerous 

times to input validation failures in D-Link Systems devices, both by experts they hired and 

outside security researchers alerting D-Link Systems to vulnerabilities. Indeed, to read the reports 

commissioned by D-Link Systems and D-Link Corporation is to encounter a litany of entreaties 

for improved input filtering. For example, in his 2013 security evaluation of both the DIR-505L 

and the DIR-826L, Mr. Doyle identified directory traversal vulnerabilities in each. In 

Never Use Unvalidated Input as Part of a Directive to any Internal Component, US-CERT (June 26, 2013), 

https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/never-use-unvalidated-input-part-directive-anyinternal; and 

SAFECODE, FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT 15–18 (2nd ed. Feb. 8, 2011) 

(“Validate Input and Output to Mitigate Common Vulnerabilities”), 

https://www.safecode.org/publication/SAFECode_Dev_Practices0211.pdf. 

200 OWASP has long suggested that developers avoid blacklisting. A1 2004 Unvalidated Input, OWASP (Apr. 18. 

2010) (“‘Negative’ approaches that involve filtering out certain bad input or approaches that rely on signatures are 

not likely to be effective and may be difficult to maintain.”), 

https://www.owasp.org/index.php/A1_2004_Unvalidated_Input#How_to_Protect_Yourself. 

201 See M1: Establish and maintain control over all of your inputs, CWE MONSTER MITIGATIONS (2011), 

http://cwe.mitre.org/top25/archive/2011/2011_mitigations.html#Mit-M1; A1.5 2004 Unvalidated Input, 5. How To 

Protect Yourself, OWASP (Apr. 18, 2004) 

https://www.owasp.org/index.php/A1_2004_Unvalidated_Input#How_to_Protect_Yourself. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 63 of 165
63 

each report, he advised: “[v]alidate user input to ensure only known good characters are used. 

Refer to the OWASP reference for detailed approaches.”202

119. In addition, I have reviewed more than ten III/Onward reports that advised this change.203

For example, in a report on IP 

 

120. D-Link Systems’ pervasive input filtering/validation failures led in part to its devices

being vulnerable to the most serious kinds of attacks, including the ability to remotely inject 

commands—taking over devices—and the many harms to device-owners that come with 

complete takeover, as discussed in Section III.A.1 above. Input filtering failures contributed to 

many of the critical vulnerabilities I discuss in detail below, and affected many D-Link Systems’ 

devices just in these few examples. See Sections III.E.1.b (Three Additional Paleari Command 

Injection Vulnerabilities), III.E.1.c (Messner Buffer Overflow Exploit), III.E.1.d (Lovett 

Vulnerabilities—Clear Text Password, XSS, and Remote Code Execution Vulnerabilities), 

III.E.1.e (Huntley/Qihoo/Heffner Command Injection Vulnerability in HNAP), III.E.1.f (Adkins

Command Injection Vulnerability), III.E.1.g (Romero Remote Code Execution Vulnerability), 

and III.E.2.c (Senrio Stack Overflow Vulnerability), below.

202 Jason Doyle, DIR-505L Security Evaluation (Apr. 8, 2013) (DLS0030614–624, DLS0030618); Jason Doyle, 

DIR-826L Security Evaluation (Apr. 16, 2013) (DLS00038165–76, at DLS00038169). 

203 See Appendix C (Materials Considered), Category III (III/Onward Device Security Reports). 

204

 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 64 of 165
64 

2.

121. In addition to failing to filter or validate input, D-Link Systems routers and IP cameras

have exhibited basic failures in other aspects of handling user input strings. String handling is 

the manipulation of character strings. The software can invoke various functions to shorten the 

strings, terminate them, combine them with others (concatenate them), move them from location 

to location, or otherwise manipulate them. It is important to properly handle strings and (on 

linux/Unix systems) terminate them with a null byte205 so that, should input filtering not 

successfully reject malicious code, that code is not processed as a command. If, on the other 

hand, a programmer uses methods that pass on entire strings of unlimited, unvalidated user 

input—or that fail to terminate strings—this can result in a buffer overflow or stack overflow.206 

Overflows are a type of vulnerability wherein the software stores more characters of a string in 

memory than was reserved for that purpose, leaving the excess saved in memory—at locations 

“running off the end” of the buffer or stack, as applicable—where it may be erroneously 

interpreted by the processor as though it were a new instruction or data value by the software 

program.207

205 A null byte is the classic way to signal that a string has ended in Unix/Linux. The software will discard anything 

after the null byte when copying the string, preventing buffer overflows. 

206 A buffer is a designated location in computer memory that the software uses to temporarily store pieces of 

information as it carries out software instructions. It’s like an expanded version of the Memory function on a basic 

calculator. The term “stack,” in this context, is a reference to the call stack, a formatted memory location that 

preserves where in the larger software process the software should return when a particular subroutine is completed. 

The processor will pass control to particular subroutines in the execution of the software, and the call stack will 

record where the software should return after the subroutine is finished. 

207 MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 188–89 (2006), (“Stack-based buffer overruns go back to the 1980s or 

before (Eichlin and Rochlis 1989), and the authors put tremendous effort into removing them during the Microsoft 

Windows Server 2003 security push. But exploitable heap-based buffer overruns and integer overflow attacks on the 

length calculations that attempt to prevent buffer overruns are relatively new developments. For example, the ASN.1 

network protocol– parsing component of Microsoft Windows was extensively scrubbed for buffer overrun 

vulnerabilities during the security push (CERT 2002). A researcher subsequently pointed out that the component 

was vulnerable to integer overflow attacks in the code that was supposed to prevent buffer overruns. Of course, our 

tools, training, and processes now focus on such vulnerabilities, but at the time of that particular security threat, we 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 65 of 165
65 

122. One of the failures that leads to buffer and stack overflow vulnerabilities is the use of

functions that fail to limit the input they accept to only that which is expected and necessary for 

the program when handling user input. 

123. Here’s a simplified example: one step in a software program may be to use a function to

add a country code to a user-entered telephone number. Suppose that the programmer 

anticipates only digits in the input string—no parentheses, no hyphens, no other characters of any 

kind. The function that takes the user input from one location and combines it with the country 

code (concatenates the two in programming terms) might then allocate space for only eleven 

bytes for the user input (ten for the phone number and one null byte, which is how the end of a 

string is signified in C). There are numerous functions in the C library that are set up to 

accomplish this allowing only the set number of characters—eleven in this case—and rejecting 

the excess. That way, if the user enters a ten-digit number but adds to the end of the number 

some exploit code that attempts to issue a command to the software to allow the user to take 

over, the software rejects the characters after the phone number, and the attack is foiled. But 

there are also older functions that take any size of user input and pass it along. Using these 

functions for user input risks the software passing along additional input that, if properly styled 

by an attacker, the software would read as a command—an exploitation of an overflow 

vulnerability.208 

had to invoke our security response process and release Microsoft Security Bulletin MS04-007 to deal with 

vulnerabilities in a component we thought we had gotten right (Microsoft 2004a).”), 

https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/. 

208 This problem is slightly different from input filtering. Input filtering should be performed before the function 

handles the input. Input filtering typically addresses the content of the input, although it can also address length. 

For example, in this example, the software engineer should have also had an input filtering step, which could include 

rejecting too-long entries, blacklisting all characters other than numerical digits and dashes, or whitelisting input that 

conforms to a (###) ###-#### format. Performing input filtering and avoiding insecure functions are both critical 

when handling user input, because attackers will constantly be trying to evade input filtering rules with cleverly 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 66 of 165
66 

124. Common examples of this problem are strcpy() and strcat() (which stand for “string

copy” and “string concatenate,” respectively), which have no built-in method to limit the size of 

the string they handle.209 For example, if a programmer uses strcpy() to move a string of user 

input into the buffer, agnostic of how many characters are expected by the process that is 

instructed to retrieve the data from the buffer, the next process may well take only the characters 

needed and leave the remainder in the buffer. This extra string may cause an error or, if an 

attacker has correctly styled the additional input, may result in the software executing an 

attacker’s command. 

125. People have known about string function manipulation problems for decades. One

function that was included in the original C language—gets()—was deemed so inherently 

styled input. As discussed in Sections III.E.1.e and 2.c below, D-Link Systems devices had buffer overflow 

vulnerabilities due to the lack of input filtering and the use of strcpy() to handle that input. 

209 Daniel Plakosh, strcpy() and strcat(), U.S. CERT (Sept. 27, 2005) (“The strcpy() and strcat() functions are a 

source of buffer overflow vulnerabilities.”), https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strcpyand-strcat; 

SAFECode, FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT 12–14 (2nd ed. Feb. 8, 2011) 

(“Minimize Use of Unsafe String and Buffer Functions”), 

https://www.safecode.org/publication/SAFECode_Dev_Practices0211.pdf; 

SAFECode, FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT 7–10 (1st ed. Oct. 8, 2008) (noting a 

common cause of buffer overrun is using unsafe string- and buffer-copying C runtime functions, and recommending 

that function families such as the “strcpy() amily” be removed from older code), 

http://www.safecode.org/publication/SAFECode_Dev_Practices1108.pdf; 

Top 25 Most Dangerous Software Errors (2011) CWE-676: Use of Potentially Dangerous Function, CWE/SANS 

(“the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and blindly 

copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an 

attacker can influence the contents of the string parameter”), http://cwe.mitre.org/top25/#CWE-676,

https://cwe.mitre.org/data/definitions/676.html; 

Top 25 Most Dangerous Software Errors (2011) CWE-120: Classic Buffer Overflow, CWE/SANS (“Buffer 

overflows are Mother Nature’s little reminder of that law of physics that says: if you try to put more stuff into a 

container than it can hold, you’re going to make a mess. The scourge of C applications for decades, buffer overflows 

have been remarkably resistant to elimination. However, copying an untrusted input without checking the size of 

that input is the simplest error to make in a time when there are much more interesting mistakes to avoid. That’s 

why this type of buffer overflow is often referred to as “classic.” It’s decades old, and it’s typically one of the first 

things you learn about in Secure Programming 101.”), http://cwe.mitre.org/top25/#CWE-120. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 67 of 165
67 

insecure that it was removed from the C standard language in 2011.210 Since at least 1996,211

experts have publicized problems with other, often problematic functions, such as strcpy() and 

strcat(), and advised caution in their use with user input.212 

 

210 See ISO/IEC, PROGRAMMING LANGUAGES—C xiv (2011) (“removed the gets function (<stdio.h>)”) 

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf. See also SAFECODE, FUNDAMENTAL PRACTICES

FOR SECURE SOFTWARE DEVELOPMENT, 7 (1st ed. 2008) (recommending that “gets family” function be removed

from older code), http://www.safecode.org/publication/SAFECode_Dev_Practices1108.pdf. 

211 Aleph One, Smashing the Stack For Fun and Profit, PHRACK 7 (49) (1996), http://phrack.org/issues/49/14.html. 

212 Reviewing Code for Buffer Overruns and Overflows, OWASP (Sept. 9, 2010),

https://www.owasp.org/index.php/Reviewing_Code_for_Buffer_Overruns_and_Overflows; 

MICHAEL HOWARD, DAVID LEBLANC & JOHN VIEGA, 19 DEADLY SINS OF SOFTWARE SECURITY: PROGRAMMING

FLAWS AND HOW TO FIX THEM (1st ed. 2005); 

ROBERT C. SEACORD & JASON RAFAIL, SECURE CODING IN C AND C++: A LOOK AT COMMON VULNERABILITIES

(CERT, SEI-CMU, Nov. 2005), https://resources.sei.cmu.edu/asset_files/presentation/2005_017_101_52657.pdf; 

MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING: PRINCIPLES & PRACTICES 85–93, 101 (2003), 

http://securecoding.org; 

ROBERT C. SEACORD, COBASSA 2005: BEST PRACTICES FOR SECURE CODING (CERT, SEI, Carnegie Mellon, Nov. 

2005), https://resources.sei.cmu.edu/asset_files/presentation/2005_017_001_52663.pdf; 

MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 242–49 (2006), 

https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/; 

SAFECODE, FUNDAMENTAL PRACTICES FOR SECURE SOFTWARE DEVELOPMENT 7–10 (1st ed. 2008) (noting a

common cause of buffer overrun is using unsafe string- and buffer-copying C runtime functions, and recommending

that function families such as the “strcpy() family” be removed from older code), 

http://www.safecode.org/publication/SAFECode_Dev_Practices1108.pdf; Reviewing Code for Buffer Overruns and 

Overflows, OWASP (Sept. 9, 2010), 

https://www.owasp.org/index.php/Reviewing_Code_for_Buffer_Overruns_and_Overflows. 

213 See, e.g., III/Onward, DCS-930L Device Security Testing Report, Appendix D (Aug. 27, 2012) (DKC0003183–

203, at DKC0003185, DKC0003187, DKC0003189); III/Onward, DIR-826L Device Security Testing Report, 

Appendix D (Sept. 28, 2012) (DKC0003966–4003, at DKC0003971, DKC0003980, DKC0003981, DKC0003984, 

DKC0003985); III/Onward, DCS-942L Device Security Testing Report, Appendix D (Nov. 10, 2012), 

(DKC0003351–65, at DKC0003353); DCS-942L Vulnerability Info Spreadsheet (DKC0501497); III/Onward, 

DCS-935L Device Security Testing Report, Appendix D (June 26, 2015) (DKC0003222–56, at DKC0003239); 

III/Onward, DCS-960L Device Security Testing Report, Appendix D (Aug. 6, 2015) (DKC0003387–407, at 

DKC0003400). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 68 of 165
68 

input, but this did not result in sufficient steps to prevent the function from leading to exploitable 

vulnerabilities in D-Link Systems’ routers and IP cameras.214

126. Improper string handling, such as incautious use of strcpy() function, can create an

opportunity for attackers to interfere with the operation of a computer, and in some 

circumstances compromise its security. If, for example, the program copies whatever the user 

inputs into a buffer without removing malicious characters or properly terminating the string, the 

attacker may be able to overflow the buffer intended to contain the string. Sometimes, this 

malicious overflow of a buffer can cause the computer (such as a router) to halt entirely. In other 

instances, a specially designed input string which is improvidently copied into a buffer contained 

in one of the computer’s registers could alter the path of execution of the software, causing 

malicious code to be executed instead of the program that was originally loaded onto the 

computer (or router). This latter technique, first identified in print in 1996, is known as 

“smashing the stack,” and special utilities have existed for more than a dozen years easing the 

task for an attacker to compose the precise set of bytes needed to effect a stack-smashing attack. 

It is also possible to compromise the security of a system by, for example, injecting or appending 

a malicious command into an otherwise benign input string. In this case, the buffer is not 

overfilled, but nevertheless has been subjected to malicious manipulation as a result of the 

improper string manipulation. 

214 D-Link Sys. 30(b)(6) Dep. 222:3–10 (Apr. 25, 2018)

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 69 of 165
69 

127. There are many ways to avoid having problematic string handling in software. For

example, a series of alternative, generally safer, versions of string-handling functions have been 

available in the C language for many years. The simplest are strncpy() and strncat(), functions 

where the letter “n” denotes the fact that the programmer must specify the length of the string to 

be passed along.215 (By specifying the precise number of bytes to be moved, these functions 

avoid many of the problems associated with misuse of the strcpy() and strcat() functions, which 

merely move bytes until they encounter a “0”). Companies can also prevent or find and correct 

these flaws in numerous ways, including developer training and testing source code with basic 

static code checkers. It is easy for these checkers to find unbounded functions like strcpy() and 

strcat() by scanning source code, and any free or commercial static code checker distributed in 

the last decade or more would be set up to catch these and flag them to be double-checked and 

fixed if necessary. 

128.

 including, among the examples I discuss below, a remote code 

execution vulnerability disclosed to D-Link Systems by Daniel Romero in 2016 (Section 

III.E.1.g below), which affected numerous D-Link Systems routers, and a stack overflow

vulnerability disclosed to D-Link Systems by Senrio in 2016 (Section III.E.2.c below), which 

affected many D-Link Systems IP Cameras. 

215 Although they can be somewhat more secure than strcpy() and strcat(), even strncpy() and strncat() can be 

subject to overflow problems in some cases. For that reason, C has released a series of other strcpy()- and strcat()-

related functions, giving programmers an arsenal of solutions to avoid using these insecure functions when handling 

user input. See ROBERT C. SEACORD & JASON RAFAIL, SECURE CODING IN C AND C++: A LOOK AT COMMON 

VULNERABILITIES (CERT, SEI-CMU, Nov. 2005), 

https://resources.sei.cmu.edu/asset_files/presentation/2005_017_101_52657.pdf; ROBERT C. SEACORD, COBASSA

2005: BEST PRACTICES FOR SECURE CODING (CERT, SEI, Carnegie Mellon, Nov. 2005), 

https://resources.sei.cmu.edu/asset_files/presentation/2005_017_001_52663.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 70 of 165
70 

3. Unnecessary System() Library Calls

129.

216 

130. System() calls are an easy way to accomplish tasks in software. On the one hand, they are

easy because the system() call can process any type of command, such as changing date and time 

or shutting down the device. Other library calls can only accomplish a narrower subset of tasks, 

and they require the developer to satisfy the application programming interface (API) 

specifications of the library in order to complete the desired task. 

131. That ease of use is sometimes outweighed by the significant risk of completing tasks

through system() calls. System() can be an insecure way to accomplish tasks because when 

invoked by a privileged process, it operates with full privileges, meaning there is no limit to the 

commands that it can execute. Because of this, secure coding resources advise programmers to 

limit the use of system() calls to situations where it is absolutely necessary, and to avoid using 

system() when handling user input without extensive validation.217 Other library functions that 

can achieve the same result are less powerful because they operate with limited privileges, but as 

a result, the damage is mitigated if an attacker is able to feed the function a command. 

216 This is equivalent to the command line applications available on personal computers. Unlike most software 

applications, which only allow you to accomplish certain tasks and only through the interface of the application, the 

command line will allow you to control any aspect of the computer, with properly formatted commands. 

217 MARK G. GRAFF, SECURE CODING: THE STATE OF THE PRACTICE 4.5.1. (Para–Protect Services, Inc., White Paper, 

2001) (“Use exec() instead of system(), to avoid invoking a shell.”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 71 of 165
71 

132. The perils of using system() have been well-documented for at least a decade.218 

 

133. Use of system() can be avoided by substituting specific functions that can accomplish the

desired task without running at full privilege, and coding the input to make use of that specific 

function. Companies can easily find instances of system() by running a static code checker. 

Because the risk of using system() is so well-known and easy to detect when scanning source 

code, any free or commercial static code checker distributed in the last decade or more could be 

set up to search for system(). 

134. Several of the serious vulnerabilities I discuss below were caused in part by unnecessary

system() calls, or the related problem of accepting commands to functions running with privilege, 

which could have been avoided using standard code review processes. See Sections III.E.1.c 

(Messner Buffer Overflow Exploit—passing commands to privileged ping function), III.E.1.e 

218 Ben Tucker, ENV33-C. Do not call system(), SEI-CMU (“Use of the system() function can result in exploitable 

vulnerabilities, in the worst case allowing execution of arbitrary system commands”), 

https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152177; MARK G. GRAFF & KENNETH R. VAN 

WYK, SECURE CODING: PRINCIPLES & PRACTICES 85–89 (2003), http://securecoding.org; ROBERT C. SEACORD, THE

CERT C SECURE CODING STANDARD 479–487 (2009). 

219 III/Onward, DIR-615 Device Security Testing Report, Appendix D (May 10, 2013) (DKC0003511–3535, at 

DKC0003517) (“The web application apply dangerous functions (e.g., system command execution) without filtering 

the parameter value sent by the client-side user. Attackers can let the target execute arbitrary command through 

sending the special designed string. . . . Solution . . . Disable dangerous command execute function, such as 

exec,system.”). 

220 Email from Daniel Hsu to William Brown (Oct. 9, 2014) (DLS0029140–41) (emphasis added). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 72 of 165
72 

(Huntley/Qihoo/Heffner Command Injection Vulnerability in HNAP), and III.E.1.f (Adkins 

Command Injection Vulnerability), below. 

4. Unnecessary Protocols and Services

135. D-Link Systems also frequently ran unnecessary protocols and services on its devices,

expanding the potential opportunities for compromise. Routers and IP cameras typically receive 

connections from across the Internet, and these connections can relate to numerous protocols and 

be directed to a variety of services.221 Services typically make use of a designated software port 

on the device, for example 8080 for HTTP, which enables the router to direct traffic from over 

the Internet to the correct piece of software handling requests for that service. 

136. Ports are numbered openings (or addresses) for information to be exchanged by

networked devices. If a linux/Unix computer (such as a router) wishes to offer a particular 

service (such as http the web-browsing protocol), it specifies a particular piece of software to 

handle requests for that service. That servicing software, often referred to as a “daemon,” is 

invoked for each incoming connection request of that service. When information is received, the 

daemon will be invoked. Each port and service is potentially vulnerable to attack. For that 

reason, it is a well-known security flaw to run protocols or services that are not needed.222 These 

are needless risks. 

221 Protocols are communication languages, like Hyper-text Transfer Protocol (HTTP). Services are particular 

functions or functionalities, such as a File Transfer service (often named by the protocol it uses: File Transfer 

Protocol, or FTP). They are usually implemented by executables or scripts saved on the device that are called into 

action when they receive appropriate input. Telnet is another example of a protocol and service that share a name. 

222 CWE-477: Use of Obsolete Function, CWE (“The code uses deprecated or obsolete functions, which suggests 

that the code has not been actively reviewed or maintained.”), https://cwe.mitre.org/data/definitions/477.html; A10.1 

2004 Insecure Configuration Management, OWASP (2004), 

https://www.owasp.org/index.php/A10_2004_Insecure_Configuration_Management#Description. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 73 of 165
73 

137. The risk of running unnecessary services or protocols has been understood for decades,

and many security resources advise against it.223

 Today, sources such as OWASP explicitly 

advise against this practice too. The reason why a basic tenet of secure design is to trim 

unnecessary protocols and services is because you cannot predict all the potential ways they 

could be misused. As with other flaws affecting D-Link Systems’ devices, D-Link Corporation’s 

security testing vendor warned of this problem in specific instances and advised against it.224

 

138. Companies can avoid running unnecessary protocols and services through basic security

design review. First, through security design review, developers should identify and document 

everything they are trying to do with the device. Second, they should evaluate everything that is 

running in the code. If there is any service that is not necessary to provide the functionality 

223 Simpson Garfinkle & Gene Spafford, PRACTICAL UNIX AND LINUX SECURITY 17.1.3 (1st ed. 1996), Chapter 17

TCP/IP Services, at The /etc/inetd Program, https://docstore.mik.ua/orelly/networking/puis/ch17_01.htm; 

MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 81 (2006) (requiring developers to ask: “‘Is this feature needed by at 

least 80 percent of our users?’ If the answer is no, the feature should be turned off, not installed, or disabled by 

default.”), https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-developmentlifecycle/; 

MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING: PRINCIPLES & PRACTICES 45 (2003) (“features that do 

not exist cannot be subverted, and programs that do not need to be written have no bugs.”), http://securecoding.org; 

GARY MCGRAW, SOFTWARE SECURITY: BUILDING SECURITY IN 124 (1st ed. 2006), http://www.swsec.com/; 

Insecure Configuration Management, OWASP (listing server configuration problems, such as “unnecessary services 

enabled”), https://www.owasp.org/index.php/Insecure_Configuration_Management; 

Top 10 2013-A5-Security Misconfiguration, OWASP (2013) (“Are any unnecessary features enabled or installed 

(e.g., ports, services, pages, accounts, privileges)?”), https://www.owasp.org/index.php/Top_10_2013-A5-

Security_Misconfiguration; 

Enterprise Application Security Vulnerability Assessment, OWASP (2010) (Top 10 OS issues – 2010 include 

“Unnecessary enabled services”; Top 9 Application Issues – 2014 include “Unnecessary enabled functionality”), 

https://www.owasp.org/index.php/Enterprise_Application_Security_Vulnerability_Assessment; 

OWASP Secure Coding Practices Checklist, OWASP (Jan. 21, 2016) (system configuration includes “remove all 

unnecessary functionality and files”), https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_ 

Checklist. 

224

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 74 of 165
74 

identified in the first step, it should be completely removed from the system. (Leaving a piece of 

software resident on the router, even though it does not need to be there, represents a 

vulnerability in that an intruder or attacker might activate the software and use it for nefarious 

purposes). Companies can also make use of free tools like NMAP to see what ports are in 

service and evaluate whether some services are not needed.225 NMAP is a free security scanner 

that will contact an IP address at each potential port to see if the port is being serviced (which 

will tell a company the services running that are associated with those ports).226 

139. D-Link Systems’ failure to prevent or remove unnecessary protocols and services on its

devices contributed to several of the vulnerabilities I discuss in detail below. See Sections 

III.E.1.c (Messner Buffer Overflow Exploit), III.E.1.e (Huntley/Qihoo/Heffner Command

Injection Vulnerability in HNAP), III.E.1.f (Adkins Command Injection Vulnerability), and 

III.E.2.a (Hidden Guest-Guest Account, maintaining a undisclosed, default account meant for

business users in cameras sold to consumers), below. 

5. Backdoors: Hard-Coded and Undocumented Credentials

140. D-Link Systems has also struggled with multiple reports of backdoors, hard-coded

credentials, and undisclosed accounts on its devices. I will discuss each of these security failures 

in this section. 

141. Credentials are the keys to access privileged resources on a device or system, for

example, the settings by which the device is controlled. Because they can provide privileged 

access, attackers routinely search target systems for these flaws. Credentials must be unique and 

225 See Nmap (“Network Mapper”) (described as “a free and open source (license) utility for network discovery and 

security auditing”), https://nmap.org/. 

226 Unfortunately, attackers also make use of services like NMAP to conduct “port knocking,” scanning the Internet 

for devices with known vulnerabilities. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 75 of 165
75 

restricted to users who should hold the privilege. That restriction is undermined when there are 

preset, alternative credentials that provide access to those resources. The ability of the privileged 

users (the users with the password to access privileged resources) to protect themselves is further 

undermined if they are not aware of the alternative credentials and how, if possible, to make 

them unique and private. This can take the form of alternative accounts on a device, hard-coded 

credentials, and/or backdoors.227 Hard-coded credentials and backdoors often appear when code 

inserted for debugging is not removed before deployment.228

142. Credentials should never be hard-coded—written into source code—for several reasons.

First, they are not unique to the user, meaning the compromise of one device can lead to the 

compromise of all others. Second, the barrier to changing them in the case of compromise is too 

high, because it requires the company to issue new software, rather than have the user change the 

credentials in an appropriately-protected user table. And finally, passwords in the code will not 

be protected—unless special steps have been taken to obfuscate them—from attackers who can 

227 A few definitions: In the security field, we typically refer to credentials as “hard-coded” if they are written into 

the source code of the software, and can only be changed in the software end-users are running by modifying the 

code and pushing it out to end-users as updated software. A backdoor is a means to gain access to a device without 

needing to know the user’s credentials or make use of another vulnerability. In many cases, what we consider 

backdoors are openings that have been intentionally put in the code. This could be either malicious, to allow a bad 

actor inside the organization to exploit the software, or because a developer needed the access during the 

development of the software but failed to remove it before it was shipped. Sometimes a flaw is both: a hard-coded 

credential that gives privileged access to a device could also be described as a backdoor. By undocumented and/or 

hidden credentials, I mean credentials associated with an alternative user account that are not brought to the 

attention of the end-user in any way. By preset or default, I mean that the credentials are set up to work without the 

user taking any action to enable them. 

228 Carol Woody, et al., Predicting Software Assurance Using Quality and Reliability Measures 25 CMU/SEI-2014-

TN-026 (Dec. 2014) (“Backdoors often appear when code inserted for debugging is not removed before deployment 

or when code is added for remote system administration, but not properly secured.”), https://resources.sei.cmu.edu/ 

asset_files/technicalnote/2014_004_001_428597.pdf; CWE-489: Leftover Debug Code, CWE (“A common 

development practice is to add ‘back door’ code specifically designed for debugging or testing purposes that is not 

intended to be shipped or deployed with the application. These back door entry points create security risks because 

they are not considered during design or testing and fall outside of the expected operating conditions of the 

application.”), https://cwe.mitre.org/data/definitions/489.html. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 76 of 165
76 

disassemble or decompile229 code to decipher them. Even if the code is obfuscated,230 a 

motivated attacker has the means to reveal the password without breaking additional barriers. 

143. Backdoors are among the most serious possible vulnerabilities, in part because they may

indicate purposeful malicious acts by the programmers. In my experience, the discovery of a 

potential backdoor on a system would be treated as a security emergency. In some cases, a 

backdoor can provide a means for circumventing all of the security defenses on a system, and 

proceeding directly to act as a privileged user. To illustrate the gravity of this kind of problem: 

in my experience as a security profession in situations like these, I have advocated that my 

company stop shipping the software and alert customers explicitly about the issue.231 However, 

not all backdoors are created with malicious intent; some are created by programmers as a 

debugging aid. In that case, the programmer would know the backdoor was there, and would 

have the responsibility to ensure that it was removed before the software shipped. 

144. Hard-coded credentials, backdoors, and secret credentials have been known to be a flaw

for decades.232 OWASP discussed hardcoded passwords in its earliest iterations.233 Unlike most 

229 To “disassemble” an executable file is to produce, via a byte-by-byte analysis of the binary contents of the file, a 

new output file that inferentially resembles a notional assembly-language version of the program. “Decompilation” 

is a similar process aimed at producing a higher language simulacrum of the program. 

230 “Code obfuscation” refers to the security practice of writing software that is intentionally obscure, offering

obstacles to interpretation via disassembly or decompilation. One way to obfuscate code is to conceal the logical 

sequence of execution by unnecessary jumps and calls. Strings can also be obfuscated by breaking up character 

sequences and assembling them only when needed. For example, to prevent the prompt “Password” from being 

uncovered in an executable file via disassembly, and obfuscating programmer could build the string starting with

“P,” concatenating “as” to it, then concatenating the word “sword” to the string being built. A search of the 

executable file for strings containing “Password” would not find it, but at run time the string would be ready for 

use. 

231 By comparison, see D-Link Systems’ disclosure regarding a hidden user account, advising that users change the 

password on the “guest” account, but not mentioning that the guest account had an easily-guessed “guest” 

password. Guest User Account Security Advisement for Select D-Link IP Cameras (May 7, 2013) (DLS0005316–

17, at DLS0005317). 

232 See RICHARD R. LINDE, OPERATING SYSTEM PENETRATION 368 (AFIPS National Computer Conference, May 

19–22, 1975) (“Clandestine Code—The submission of “patch” code containing trap doors used to repair an 

operating system or utility program error, allowing the repairman to subsequently enter the computer system in an 

unauthorized fashion.”), https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830361.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 77 of 165
77 

vulnerabilities, which require conditions to be met and careful attacks to be crafted, alternative 

credentials/backdoors are like a door being left unlocked. Many sources flag the risk of 

alternative credentials.234 D-Link Corporation’s security testing vendor raised the issue of hardcoded credentials to D-Link Corporation in 2014.235

145. These alternative credentials can be prevented in a number of ways. Companies can

forbid their use by policy, and provide checklists to programmers of last-minute items to confirm 

before software is completed. Good software development practice, in my opinion, requires 

checks before release that all debugging or development shortcuts—including hardcoded 

credentials—are removed.236 In the case of alternative, secret accounts, companies should 

engage in design-level discussion of who their products are for, and what the risks are in the way 

those customers will deploy them. Peer code review is another method by which a hard-coded 

credential might be identified and removed. 

146. Hard-coded or hidden credentials were the cause of two critical backdoors I discuss

below that were discovered in many of D-Link Systems’ IP Cameras. See Sections III.E.2.a 

233 A3 2004 Broken Authentication and Session Management, OWASP (2004),

https://www.owasp.org/index.php/A3_2004_Broken_Authentication_and_Session_Management (“Passwords 

should never be hardcoded in any source code.”).

234 CWE-798: Use of Hard-coded Credentials, CWE (2011), http://cwe.mitre.org/top25/#CWE-798; 

https://cwe.mitre.org/data/definitions/798.html;

CWE-259: Use of Hard-coded Password, CWE (2009), https://cwe.mitre.org/data/definitions/259.html; 

Configuration, OWASP (May 3, 2009) (“Do not hard code any backdoor accounts or special access mechanisms”), 

https://www.owasp.org/index.php/Configuration; 

Top 10 2010-A3-Broken Authentication and Session Management, OWASP (2010),

https://www.owasp.org/index.php/Top_10_2010-A3-Broken_Authentication_and_Session_Management; 

MARK G. GRAFF, SECURE CODING: THE STATE OF THE PRACTICE, 4.3 Design Ideas (“Do not code usernames or 

passwords into an application.”) (Para–Protect Services, Inc., White Paper, 2001). 

235 See, e.g., III/Onward, DCS-2136L Device Security Testing Report, Appendix D (Sept. 22, 2014) (DKC0002878); 

DCS-2136L Vulnerability Info Spreadsheet (DKC0501497); III/Onward, DIR-890L Device Security Testing 

Report, Appendix D (Feb. 24, 2015) (DKC0004364); III/Onward, DIR-868A Device Security Testing Report, 

Appendix D (Apr. 25, 2017) (DKC0004070). 

236 MICHAEL HOWARD & DAVID LEBLANC, WRITING SECURE CODE 561 (2d ed. 2003).

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 78 of 165
78 

(Hidden Guest-Guest Account) and III.E.2.b (Core Security Hard-Coded Backdoor in RTSP), 

below. 

6. Clear Text Passwords

147. Another well-known flaw that is present repeatedly in several D-Link Systems’ devices is

passwords stored in clear text. As a matter of general practice, it is best to not store credentials 

on the device that is being secured. If the secret portion of a credential must be stored 

somewhere on a device or in software, it should not be stored in clear, human-readable text. 

Rather, the developers should store the password in a mathematically transformed state that 

makes it difficult to infer the original clear text from the stored version. It should never be stored 

in the format that it was typed.237

148. Storing passwords with at least some form of obfuscation has been advised since the

1970s.238 

237 Hash has two meanings. One way of using the word hash is to perform a numerical operation on a series of bytes 

to produce a new series of bytes. You have used a mathematical operation to transform it. The result is often used 

as a lookup index into a table. Secondarily, I have seen some people use “hash” to mean such a transformation that 

is symmetrically reversible. Some of these routers, for example, take content and flip all the 1s to 0s, and all the 0s 

to 1s, as a form of obfuscation. It is poor practice to rely on this as a form of masking, because it is trivial to reverse 

it. 

238 RICHARD R. LINDE, OPERATING SYSTEM PENETRATION 361, 363, 366 & 367 (AFIPS National Computer 

Conference, May 19–22, 1975), https://www.computer.org/csdl/proceedings/afips/1975/5083/00/50830361.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 79 of 165
79 

 

149. There are many ways for developers to avoid storing clear text passwords on a router or

IP camera on which the password is being used. Assuming there is not a need to use the original, 

typed version of the password, the password can be stored through one-way hashing. Passwords 

can be hashed using one of several widely available, free algorithms that are available on the 

Internet.241 In unusual circumstances where the original, typed version of the password is 

necessary (e.g., the device itself needs to authenticate to another web-server that requires the 

clear text password), then the password can be stored encrypted, and then can be decrypted when 

it is used to authenticate to the web server. Like hashing, encryption and decryption can be 

accomplished using one of several widely available, free algorithms that are available on the 

Internet.242 These hashing and encryption techniques have been known and commonly used for 

decades. 

150.

 See Sections III.E.1.a (Paleari Command Injection 

240

241 See, e.g., Hash Functions, NIST (Aug. 5, 2015) https://csrc.nist.gov/projects/hash-functions/nist-policy-on-hashfunctions; SHA-3 Project, NIST (Jan. 4, 2017), https://csrc.nist.gov/projects/hash-functions/sha-3-project. 

242 See, e.g., SP 800-111, Guide to Storage Encryption Technologies for End User Devices, NIST (Nov. 2007), 

https://csrc.nist.gov/publications/detail/sp/800-111/final; 

Cryptographic Standards and Guidelines AES Development, NIST (Dec. 29, 2016), 

https://csrc.nist.gov/Projects/Cryptographic-Standards-and-Guidelines/Archived-Crypto-Projects/AESDevelopment; 

Cryptographic Storage Cheat Sheet, OWASP (Dec. 19, 2009) 

https://www.owasp.org/index.php?title=Cryptographic_Storage_Cheat_Sheet&oldid=75271; 

William E. Burr, Data Encryption Standard, NIST, https://nvlpubs.nist.gov/nistpubs/sp958-lide/250-253.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 80 of 165
80 

Vulnerability), III.E.1.d (Lovett Vulnerabilities—Clear Text Password, XSS, and Remote Code 

Execution Vulnerabilities), and III.E.3 (Failing to Encrypt Mobile App Credentials), below. 

7. Code Maintenance Failures

151. In addition to flaws that D-Link Systems’ vendors created (or adopted if they reused or

incorporated others’ code), D-Link Systems devices were also subject to vulnerabilities that 

could have been prevented by using proper code maintenance. Code maintenance is an umbrella 

term for a number of competent practices that developers should engage in when altering code 

that has already been released; for example, to alter the code to introduce a new feature, or to fix 

a vulnerability that has been identified in the original code.243

152. Actually fixing the particular flaw. In addition, companies must make sure their

programmers are working to fix the real issue underlying a vulnerability, not just breaking an 

exploit by black-listing a character used in a researcher’s or tester’s proof-of-concept that a 

vulnerability exists. When developers are given an exploit and told to “fix this,” they often just 

stop the exploit from working, which may not address the underlying flaw that caused the 

vulnerability. As a result, another version of the same exploit is likely to be feasible.244

153. Fixing identical instances of the flaw. Properly fixing a flaw using competent code

maintenance entails finding and resolving other instances of the same flaw.245 It’s common for 

different pieces of software, especially when owned or developed by a single owner or 

243 Where a company lacks access to the source code that underlies its own devices, as with D-Link (see D-Link 

Corp. 30(b)(6) Dep. 157:3–16 (Jan. 30, 2018)), then these code maintenance requirements must be mandated by its 

policies for, or contracts with, the entities responsible for the source code maintenance. 

244 MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 219 (2006) (“Failing to take the time to search for related vulnerabilities 

exposes you to the risk that the researcher who reported the first vulnerability, or one of his peers, will be back the 

week after you release your update with a new report that looks almost like the last one”), free ebook available at 

https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/. 

245 Ibid. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 81 of 165
81 

developer, to share code. 246 Indeed, this is efficient and smart. What that means, however, is 

that when a vulnerability is found in one piece of code, it may very well exist in other software 

that shares that code. Accordingly, a single vulnerability can exist across multiple pieces of 

software. Thus, when a vulnerability is found in a single piece of software, malicious actors 

know that they are likely to be able to run the same exploit in other similar pieces of software 

from the same company. 

154. Fixing analogous instances of the flaw. Another key part of competent code maintenance

is to understand the cause of a flaw, and to fix all flaws emanating from that cause that can be 

reasonably be found, rather than just fixing the known flaw.247 These additional analogous flaws 

can often be found by examining what failure caused the known problem, and then to look for 

other, as-yet-unknown flaws that are likely to have been caused by the same failure. 

155. Improper code maintenance not only ignores additional, latent issues that might exist in

code, it is also inefficient. Much of the cost of revising code are the fixed costs of having a 

developer dig into a code base and test the finished product.248 The cost of making multiple 

246 MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 209 (2006) (“In large software organizations such as Microsoft, sharing 

and reuse of code and software components are common. (We’ve referred to those components as giblets, after the 

plastic bag of assorted innards that comes inside a frozen turkey.) The practice of reusing and sharing components 

has benefits for efficiency and consistency, but it does carry with it the risk that a vulnerability in giblet A will be 

manifest in product B, whose development team didn’t create giblet A and might not have the capability to update 

it.”), https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/. 

247 MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 219 (2006) (“Failing to take the time to search for related vulnerabilities 

exposes you to the risk that the researcher who reported the first vulnerability, or one of his peers, will be back the 

week after you release your update with a new report that looks almost like the last one”), free ebook available at 

https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/. 

248 MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING 

DEMONSTRABLY MORE SECURE SOFTWARE, 11, 13 (2006) (“SDL is not free; it costs time, money, and effort to 

implement. But the upfront benefits far outweigh the costs of revisions, developing and testing security updates, and 

having customers deploy the updates.”) (“Most importantly, if you get it right upfront, the cost of fixing bugs later 

diminishes rapidly. . . . You can pay now and increase the odds that you’ll get it right, or you can pay much more 

later.”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 82 of 165
82 

changes does not linearly increase the cost of the revision. Generally, then, it is most economical 

to make all necessary fixes at one time, where feasible.249

156. The importance, from a security and efficiency standpoint, of not taking a whack-a-mole

approach to addressing vulnerabilities has been expressed in the literature since at least 2006, in 

Howard and Lipner’s book on the Secure Development Lifecycle.250 It was common practice 

before then as well, because it is also just common sense and basic management for a company 

interested in any level of assurance as to the security of its software to require that a problem 

identified in one location is remedied anywhere it might exist. 

157. Companies can engage in proper code maintenance through policy and processes. When

addressing known vulnerabilities, the instruction should be for developers to remedy not only the 

particular flaws and failures underlying that vulnerability, but also to identify the causes of those 

flaws, and to remediate, if feasible, any additional flaws created by the root cause. In order to 

efficiently address vulnerabilities across multiple devices that share code, companies commonly 

use tools to track code trees.251 Accordingly, the evidence of the successful accomplishment of 

the task should not be evidence that the exploit is no longer effective, but rather that the 

249 MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING: PRINCIPLES & PRACTICES 56 (2003) (citing IBM 

Systems Sciences Institute statistics, cited by Kevin Soo Hoo, Andrew W. Sudsbury & Andrew R. Jaquith in 

“Tangible ROI through Secure Software Engineering,” Secure Business Quarterly, Volume 1, Issue 2), 

http://securecoding.org. 

250 MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 212–13 (2006) (“The final but most important response-related task for 

the product team is to use vulnerability reports as a learning experience and to fix as many vulnerabilities as possible 

with as few updates as possible. To do this, the team must develop an in-depth understanding of each reported 

vulnerability and then determine whether the vulnerability represents an instance of some recurring pattern. If it 

does, the team must try to find the other instances and correct them all.”), 

https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/. 

251

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 83 of 165
83 

underlying cause of those flaws has been identified, and all flaws resulting from that same cause 

have been identified and remediated.252

158. D-Link Systems’ repeated failure to exercise basic code maintenance contributed to

several of the vulnerabilities I discuss below. See Sections III.E.1.d (Lovett Vulnerabilities—

Clear Text Password, XSS, and Remote Code Execution Vulnerabilities), III.E.1.e 

(Huntley/Qihoo/Heffner Command Injection Vulnerability in HNAP), and III.E.1.f (Adkins 

Command Injection Vulnerability). 

8. Private Key Exposure

159. Finally, another serious issue arose from D-Link Systems’ failure to properly manage the

private key used to sign its code. 

160. Private code-signing keys are a type of cryptographic key used to validate the source of a

piece of software. Cryptographic keys were originally developed to address the problem of trust 

on the Internet: Specifically, how a recipient of a file on the Internet can know the file truly 

came from wherever it claims to have come from.253 Cryptographic keys solve this problem of 

trust with a private key and a public key: A person can sign the information with a private key, 

and the authenticity of that signature can be validated with a public key. If the public key does 

not validate the private key signature, the information does not come from where it claims to 

come from. 

252 MICHAEL HOWARD & STEVE LIPNER, THE SECURITY DEVELOPMENT LIFECYCLE: A PROCESS FOR DEVELOPING

DEMONSTRABLY MORE SECURE SOFTWARE 219 (2006) (“Failing to take the time to search for related vulnerabilities 

exposes you to the risk that the researcher who reported the first vulnerability, or one of his peers, will be back the 

week after you release your update with a new report that looks almost like the last one”), 

https://blogs.msdn.microsoft.com/microsoft_press/2016/04/19/free-ebook-the-security-development-lifecycle/. 

253 Whitfield Diffie & Martin E. Hellman, New Directions in Cryptography, IEEE Transactions on Information 

Theory, (Vol. IT–22, No. 6, Nov. 1976), https://ee.stanford.edu/~hellman/publications/24.pdf; Steve Fyffe & Tom 

Abate, Stanford Cryptography Pioneers Whitfield Diffie and Martin Hellman Win ACM 2015 A.M. Turing Award, 

STANFORD NEWS (Mar. 11, 2016), https://news.stanford.edu/2016/03/01/turing-hellman-diffie-030116/. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 84 of 165
84 

161. In the context of code signing keys, the private key is held by the author of the software.

The public key can be looked up from the Internet, or found on the operating system itself, when 

that software is intended to run. When the operating system detects that software was signed by 

a known and trusted private key, it permits the software to run. If it was not signed by a known 

and trusted private key, the operating system can either, depending on its security settings, 

(a) give the user the option of running the software anyway or (b) prevent the software from

running without input from the user.254

162. In the context of the Microsoft Windows operating system, companies such as Symantec

have the authority to issue digital certificates, which are public keys combined with certain 

identifying information of the entity that holds the private key.255 Companies such as Symantec 

that hold this delegated authority are tasked to only issue these certificates to companies the 

identity of which they have validated. 

163. Of course, the cryptographic key system only works properly if the holder of the private

key actually keeps that key private. Proper management of the private key is an important 

element of this “distributed trust” code-signing ecosystem. 

164. Microsoft Corporation has implemented a system of code signing to prevent rogue

software from being run on its operating system. This arrangement allows a system to run 

software with assurance that it originates from the credited source. When developing software 

intended to run on the Windows operating system, the software author is the keeper of a private 

key. Anyone with access to the private key can use it to create software that is signed with the 

254 See generally Microsoft Security Advisory 3097966: Inadvertently Disclosed Digital Certificates Could Allow 

Spoofing, MICROSOFT (Oct. 13, 2015) (“Advisory FAQs. . . . What caused the issue? The issue was caused by DLink Corporation inadvertently publishing the certificates.”), https://technet.microsoft.com/enus/library/security/3097966. 

255 See, e.g., Code Signing Certificate Technical Resources, DIGICERT

https://knowledge.digicert.com/solution/SO26496.html. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 85 of 165
85 

identity of the key owner. These digital signatures offer an important protection against 

malicious software being installed that purports to be from a trusted source. Given the 

penetration of the Windows operating system on computers across the world, software—or 

malware—that runs automatically is can carry significant risk and has a huge potential for 

cybercrime.256 This danger is well known and understood.257 Indeed, in discussions of 

encryption of sensitive data, private keys are always among the top examples of sensitive data 

that must be properly encrypted.258

165. Professionals have understood the necessity of keeping private keys private since the

inception of cryptographic keys in the mid-1970s.259 In 2010, Symantec published a white paper 

advising holders of private keys about the importance of securing those private keys.260 The 

256 How Cybercrime Exploits Digital Certificates, INFOSEC INSTITUTE (July 28, 2014) 

https://resources.infosecinstitute.com/cybercrime-exploits-digital-certificates/#gref. 

257 Dan Goodin, Stuxnet-style code signing is more widespread than anyone thought, ARS TECHNICA (Nov. 3, 2017), 

https://arstechnica.com/information-technology/2017/11/evasive-code-signed-malware-flourished-before-stuxnetand-still-does/. 

258 Top 10 2007-A8-Insecure Cryptographic Storage, OWASP (2007) (“Insecure use of strong algorithms” and 

“Hard coding keys, and storing keys in unprotected stores”; also “Generate keys offline and store private keys with 

extreme care. Never transmit private keys over insecure channels. Ensure that infrastructure credentials such as 

database credentials or MQ queue access details are properly secured (via tight file system permissions and 

controls), or securely encrypted and not easily decrypted by local or remote users”), 

https://www.owasp.org/index.php/Top_10_2007-Insecure_Cryptographic_Storage; 

Top 10 2010-A7-Insecure Cryptographic Storage, OWASP (2010) (demonstrating that the A8 vulnerability type 

from 2007 is still significant in 2010), https://www.owasp.org/index.php/Top_10_2010-A7-

Insecure_Cryptographic_Storage; 

Top 10 2013-A6-Sensitive Data Exposure, OWASP (2013) (“Sensitive Data Exposure,” includes “Insecure 

Cryptographic Storage”) (demonstrating that the same vulnerability type from 2007 and 2010 is still significant in 

2010), https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure and 

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#OWASP_Top_10_for_2013; 

Christopher J. May, et al., Defense in Depth: Foundations for Secure and Resilient IT Enterprises, 110–11, 

CMU/SEI-2006-HB-003 (Sept. 2006), 

https://resources.sei.cmu.edu/asset_files/Handbook/2006_002_001_14633.pdf. 

259 Whitfield Diffie & Martin E. Hellman, New Directions in Cryptography, IEEE Transactions on Information 

Theory, (Vol. IT–22, No. 6, Nov. 1976), https://ee.stanford.edu/~hellman/publications/24.pdf. 

260 Larry Seltzer, Securing Your Private Keys As Best Practice for Code Signing Certificates, SYMANTEC (2010), 

https://www.symantec.com/content/en/us/enterprise/white_papers/b-securing-your-private-keys-csc-wp.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 86 of 165
86 

potential concerns with the exposure of a private key have existed as long as the existence of 

private keys themselves, because the exposure of a key creates the very problem that the 

invention of a private key was designed to address (i.e., allowing a computer to trust an 

untrustworthy system). Indeed, the contract that Symantec had with the recipients of certificates 

made clear that the private keys must be kept secret.261

166. In 2007, Microsoft itself published a paper that included a section with advice on how to

maintain the secrecy of private keys, which advised: “The cryptographic keys that are the core 

of the code-signing process must be well protected and treated with the same care as a 

company’s most valuable assets.”262 As detailed in the Symantec’s 2010 white paper on 

securing private keys, “companies that are diligent and willing to invest in the appropriate 

security measures can make the compromise of their private keys highly unlikely.”263 The paper 

identified two “critical factors” in keeping private keys secret: (1) securing the system where 

they’re located, and (2) minimizing access.264 

167. As discussed below in Section III.D.4, an exposed key for D-Link software in 2015

placed at risk, potentially, all users of most of the then-current versions of the Windows 

Operating System for approximately six months.265 Although there is no evidence that any of the 

261 Code Signing Certificate Subscriber Agreement Version 10.0 (May 2015) (DKC1825166–75, at DKC1825166). 

262 Code Signing Best Practices, MICROSOFT 32 (July 25, 2007), 

http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/best_practices.doc. 

263 Larry Seltzer, Securing Your Private Keys As Best Practice for Code Signing Certificates, SYMANTEC 3 (2010), 

https://www.symantec.com/content/en/us/enterprise/white_papers/b-securing-your-private-keys-csc-wp.pdf. 

264 Larry Seltzer, Securing Your Private Keys As Best Practice for Code Signing Certificates, SYMANTEC 3 (2010), 

https://www.symantec.com/content/en/us/enterprise/white_papers/b-securing-your-private-keys-csc-wp.pdf. See 

also Key Management Cheat Sheet, OWASP, 

https://www.owasp.org/index.php/Key_Management_Cheat_Sheet#Authors_and_Primary_Editors (describing how 

private keys should only be shared with trusted parties who are authorized to sign on behalf of the key owner). 

265 See generally Microsoft Security Advisory 3097966; Inadvertently Disclosed Digital Certificates Could Allow 

Spoofing, MICROSOFT (Oct. 13, 2015) (“Advisory FAQs. . . . What caused the issue? The issue was caused by DCase 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 87 of 165
87 

myriad harms associated with private key exposure came to pass, the fact of its exposure 

demonstrates the inadequacy of D-Link Systems’ security processes, policies, and procedures. 

E. Critical Vulnerabilities that Appear in D-Link Routers and IP Cameras

168. In this section, I will evaluate reported vulnerabilities in routers and IP cameras sold by

D-Link Systems. As I conclude below, these vulnerabilities demonstrate that these devices were

not secure from unauthorized access or control. As I also conclude, these vulnerabilities 

demonstrate that many of the basic code development failures discussed above, in Section III.D, 

were present in D-Link routers and IP cameras. The significance of this second conclusion is 

that, in my opinion, these vulnerabilities, caused by basic code development failures, establish 

that the lack of secure software development practices created the conditions where these 

vulnerabilities were highly likely to occur. 

169. As a side note, it is not always possible to identify precisely in which previous releases of

software a given vulnerability exists. However, common sense will tell, and my experience 

shows, that if a bug was fixed in release number nine, for example, that it was present in release 

number eight, and quite possibly in earlier versions as well. Quite often, a vulnerability will 

exist in the originating version, and carry through unnoticed and unfixed through several 

versions of the software. 

170. In my review of these vulnerabilities that I discuss below, I did not endeavor to re-create

the exploit that demonstrated the vulnerability. In many cases, neither D-Link Systems nor the 

security researcher provided sufficient public information to re-create the exploit. Nonetheless, I 

Link Corporation inadvertently publishing the certificates.”), https://technet.microsoft.com/enus/library/security/3097966. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 88 of 165
88 

was able to rely on my expert experience to evaluate the vulnerability as described both in the 

(a) public documents266 and (b) internal D-Link Systems and D-Link Corporation documents.

171. The vulnerabilities I discuss below are only a fraction of those that affected D-Link

Systems’ routers and IP cameras since 2011.267 I have not endeavored to describe every 

vulnerability, and my choice of those discussed below is not meant to be an exhaustive list of 

serious vulnerabilities, or those that resulted from avoidable software development failures.268 

172. As to all the vulnerabilities described below, I was able to reliably conclude that they

were, in fact, exploitable vulnerabilities that permitted unauthorized access or control to a DLink router or IP camera. In the subparts below, I describe each vulnerability, including (a) what 

the vulnerability was; (b) how the vulnerability permitted unauthorized access and control; 

(c) what code development flaws it relied on; and (d) what devices were known to be implicated

by this vulnerability. 

173. For each of the vulnerabilities described below, I have not reviewed any evidence that

these vulnerabilities have been exploited.269 The absence of evidence, however, does not 

indicate that they have not been exploited. 

266 Rapid7 maintains an open source database called Metasploit, which contains lists of exploits that are attributed to 

various vulnerabilities. See RAPID7, METASPLOIT, https://www.metasploit.com. 

267 E.g., MITRE, CVE search results for D-Link, https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=D-Link; 

CVEDetails, CVE results for D-Link, https://www.cvedetails.com/vendor/899/D-link.html (showing vulnerabilities 

given CVE numbers by year). Note, these search results include devices not on Appendix A. See also Appendix C, 

Category Security Advisories (list by Bates ranges of Security Advisories and Support Announcements D-Link 

Systems has made regarding vulnerabilities affecting devices in Appendix A). 

268 In addition, because not all vulnerability disclosures are alike, in many cases the documentation of a vulnerability 

will not have enough information to conclude exactly what failures contributed to it. 

269 One exception is an article on an attack campaign in which a researcher states the attack also exploits a 

vulnerability that affected D-Link Systems’ routers. See Footnote 331 below. I note this report as an example of 

public reports that certain attacks are not hypothetical, but it did not inform my opinion. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 89 of 165
89 

1. Router Vulnerabilities

a. Paleari Command Injection Vulnerability

174. On February 20, 2013, a security researcher named Roberto Paleari identified a

vulnerability that permitted a remote user to access the administrator password of the device, 

which was being stored (and then was transmitted) in clear text.270 The password could then be 

used to access the device with full privileges.271 Because it involves accessing the administrator 

password, this exploit permits a remote user to completely take over the device, and control all 

settings, even if the consumer has remote administration turned off.272 

270 Roberto Paleari, Unauthenticated remote access to D-Link DIR-645 devices (Feb. 27, 2013), 

http://roberto.greyhats.it/advisories/20130227-dlink-dir.txt; see also D-Link DIR 645 Password Extractor, RAPID7

VULNERABILITY & EXPLOIT DATABASE, 

https://www.rapid7.com/db/modules/auxiliary/admin/http/dlink_dir_645_password_extractor. 

271 Roberto Paleari, Unauthenticated remote access to D-Link DIR-645 devices (Feb. 27, 2013), 

http://roberto.greyhats.it/advisories/20130227-dlink-dir.txt; see also D-Link DIR-645 Password Extractor, RAPID7

VULNERABILITY & EXPLOIT DATABASE, 

https://www.rapid7.com/db/modules/auxiliary/admin/http/dlink_dir_645_password_extractor. 

272 This exploit was available locally, as well. Remotely, the exploit could be used only if turned on “remote 

administration,” which is a feature that D-Link included on its routers. Consumers may have turned on remote 

administration themselves, or it could be turned on through the use of an additional exploit, such as cross-site 

scripting or cross-site request forgery. 

 Mr. Brown appears to have been quoting a 

forum post about this attack. See Skello, Multiple D-Link Router Authentication Bypass Vulnerabilities (Jan. 22, 

2011), http://forums.dlink.com/index.php?topic=23161.0. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 90 of 165
90 

175. The exploit works by exploiting a significant vulnerability in the web interface of the

DIR-645.274 By using the getcfg.php script, the attacker can simply ask the router to send the 

configuration of the router, including the clear text password. This exploit implicates two 

security failures: First, the software fails to require authentication to access these directories, 

which is easy to fix (and is how D-Link addressed this issue).275 Second, the command allowed 

the hacker to receive the administrator password in clear text (see Section III.D.6 above), an 

egregious failure. 

176. The flaw affected the DIR-645, on versions of the firmware prior to v1.03.276 This means

the vulnerability was live from the release of the device in September 2011 at least through 

November 2012.277 Moreover, although Mr. Paleari identified the flaw after the firmware update 

was announced, due to delays of updating firmware, the flaw likely affected many active 

devices.278 In addition, we cannot know if any, or how many, malicious hackers may have 

identified this vulnerability prior to Mr. Paleari. I’m not aware of any evidence that it was 

exploited maliciously. 

274 D-Link DIR 645 Password Extractor, RAPID7 METASPLOIT FRAMEWORK (Aug. 30, 2017), 

https://github.com/rapid7/metasploitframework/blob/master/modules/auxiliary/admin/http/dlink_dir_645_password_extractor.rb. 

275 Roberto Paleari, Unauthenticated remote access to D-Link DIR-645 devices (Feb. 27, 2013), 

http://roberto.greyhats.it/advisories/20130227-dlink-dir.txt (“D-Link has released an updated firmware version

(1.03) that addresses this issue.”). 

276 Roberto Paleari, Unauthenticated remote access to D-Link DIR-645 devices (Feb. 27, 2013), 

http://roberto.greyhats.it/advisories/20130227-dlink-dir.txt (“The firmware is already available on D-Link web site, 

and introduces additional restrictions to forbid unauthenticated access to page “getcfg.php”.”). 

277 DIR-645 Revision A Release Notes (June 11, 2013) (DLS0008837). Mr. Brown validated that this vulnerability 

existed in the original release: “To see it simply load a DIR-645 with FW 1.00 (that was my devices [sic] version) 

then follow the vulnerability below.” Email from William Brown to Daniel Hsu (Mar. 4, 2013) (DLS0023965–70, 

at DLS0023965). 

278 See Section III.A.1.c above. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 91 of 165
91 

b. Three Additional Paleari Command Injection Vulnerabilities

177. In June 2013, Mr. Paleari disclosed to D-Link Systems three additional command

injection flaws exploiting buffer overflows.279 These vulnerabilities permitted a remote user to 

completely take over the devices being attacked, without authentication.280 As D-Link Systems 

described in its security advisory: “This router model is affected by multiple security 

vulnerabilities. All of them are exploitable by remote, unauthenticated attackers.”281 When Mr. 

Brown received this report, he reported to Mr. Hsu and others at D-Link Corporation: “Mr. 

Roberto Paleari came back to me with six new vulnerabilities for the DIR-645. This information 

cannot get out to public regarding our 11ac products!!”282

178. The second two exploits are available as exploits on Rapid7’s exploit database.283 Both

of these exploits rely on the fact that the hedwig.cgi and authentication.cgi scripts accept inputs 

of a username (for hedwig.cgi) or password (for authentication.cgi), but both permit any size 

input for these values. As a result, an exploit can be crafted that inserts large numbers of 

characters to overflow the buffer set aside for these inputs, and then inject a script that will open 

a shell, which permits the attacker to run any commands with privilege on the machine, taking it 

279 Roberto Paleari, Multiple vulnerabilities on D-Link DIR-645 devices (Aug. 2, 2013) (FTC-DLS-00054012–13). 

See also D-Link hedwig.cgi Buffer Overflow in Cookie Header, RAPID7, VULNERABILITY& EXPLOIT DATABASE, 

https://www.rapid7.com/db/modules/exploit/linux/http/dlink_hedwig_cgi_bof; D-Link authentication.cgi Buffer 

Overflow, RAPID7, VULNERABILITY& EXPLOIT DATABASE, 

https://www.rapid7.com/db/modules/exploit/linux/http/dlink_authentication_cgi_bof. 

280 D-Link, Security Advisory: DIR-645 – Multiple Security Vulnerabilities: Buffer Overflow and Cross-site (XSS) 

Scripting – Firmware 1.03B08 and lower (Dec. 31, 2013) (DLS0059960–63, at DLS0059960) (stating “Ensuring 

Remote Management is off does not mitigate exposure to these vulnerabilities.”) (emphasis added). 

281 Ibid. at DLS0059961. 

282 Email from William Brown to Daniel Hsu (Mar.7, 2013) (DKC0012298–DKC0012304, at DKC0012301). 

283 Brent Cook, dlink_hedwig_cgi_bof.rb, RAPID7/METASPLOIT-FRAMEWORK (Feb. 8, 2013), 

https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/http/dlink_hedwig_cgi_bof.rb; 

h00die, dlink_authentication_cgi_bof.rb, RAPID7/METASPLOIT-FRAMEWORK (Feb. 8, 2013), 

https://github.com/rapid7/metasploitframework/blob/master/modules/exploits/linux/http/dlink_authentication_cgi_bof.rb. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 92 of 165
92 

over completely. Both of these exploits make manifest a critical failure to engage in input 

filtering (see Section III.D.1 above). 

179. These flaws affected the DIR-645, this time including what was then the latest version of

the firmware, 1.03.284

 It appears that the subsequent version, 1.04, was released on June 11, 

2013.285 According to internal emails, the vulnerability also affected “many of the [third-party 

vendor] Alpha Routers... 850L, 865L confirmed.”286 Remarkably, D-Link Systems only 

acknowledged in its Security Advisory the one device Mr. Paleari had identified, rather than 

identifying all devices that were implicated by the vulnerabilities.287

c. Messner Buffer Overflow Exploit

180. On April 5, 2013, a security researcher named Michael Messner identified yet another

command injection attack on a number of D-Link routers.288 This vulnerability was 

demonstrated to permit an attacker to completely take over a router, remotely, without 

authentication.289

284 DIR-645 Revision A Release Notes (Nov. 21, 2012) (DLS0008837–38). 

285 DIR-645 Revision A Release Notes (June 11, 2013) (DLS0008837–38). It appears there may also have been 

earlier releases that were called “beta” firmware patches that addressed some of these flaws at earlier times. 

286 Email from William Brown to Daniel Hsu (Mar.7, 2013) (DKC0012298–304, at DKC0012301). Of the six 

vulnerabilities that Mr. Paleari reported, it is unclear whether just one or all six affected all Alpha-sourced routers. 

287 D-Link, Security Advisory (Dec. 31, 2013) (DLS0059960). Perhaps uncharitably, the failure to identify the other 

routers suggests to me that D-Link may have only intended to admit to vulnerabilities when it was going to get 

caught. They may, though, have benign reasons to conceal these other vulnerable systems—perhaps the patches for 

the other systems may been delayed. 

288 Michael Messner, Multiple Vulnerabilities in D-Link devices, S3CUR1TY.DE (Apr. 5, 2013), 

http://www.s3cur1ty.de/m1adv2013-017; Michael Messner, D-Link DIR-645 / DIR-815 diagnostic.php Command 

Execution, RAPID7, VULNERABILITY & EXPLOIT DATABASE, 

https://www.rapid7.com/db/modules/exploit/linux/http/dlink_diagnostic_exec_noauth; D-Link, Security Advisory: 

DIR-600/DIR-300 revB/DIR-815/DIR-645/DIR-412/DIR-456/DIR-110–Multiple Vulnerabilities Command 

Injection Information Disclosure (June 30, 2014) (DLS0060250). 

289 Unlike the prior vulnerability, which permitted direct remote command execution, it appears that this exploit first 

required an additional exploit, such as the four-step cross-site request forgery attack discussed above, Section 

III.E.1.a, because it cannot be run without remote administration. See Security Advisory: DIR-600/DIR-300

revB/DIR-815/DIR-412/DIR-456/DIR-110–Multiple Vulnerabilities–Command Injection and Information

Disclosure (June 30, 2014) (DKS00036745-46) (advising consumers to not turn on remote management).

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 93 of 165
93 

181. Based on my review of the exploit code available from Rapid7, an attacker could use this

exploit to download a file to a router and then run that software remotely.290 The exploit 

described allows an attacker to use the code to download a program onto the D-Link device, 

modify that program, and then execute that program remotely.291 Alternatively, for certain DLink devices without a particular feature (wget), an attacker would be able to use the code to 

inject a command to open a telnet daemon (telnetd), which could subsequently be used to take 

over the device.292

182. The basic failure underlying this exploit is, once again, a failure to implement appropriate

input filtering (see Section III.D.1 above). This failure allowed an attacker to use the 

diagnostic.php script to inject a command. The second failure was the passing of user input to a 

command (ping) that runs with privilege on the software. This has a similar effect (but is not the 

same) as when a developer unnecessarily uses a system() call (see Section III.D.3 above)—the 

user input can be used to trigger powerful commands that can take over the device. A third 

failure, is the unnecessary presence of the telnetd executable (see Section III.D.4 above—

Unnecessary Protocols and Services), which would permit the attacker to take over the device in 

circumstances where the wget executable was not available to use the exploit described in the 

Rapid7 exploit code database. I question, in fact, the wisdom of implementing the 

diagnostic.php script in the first place. Its presence on the system significantly reduces the 

security of both the routers and any network to which the router is connected. If business 

290 D-Link DIR-645 / DIR-815 diagnostic.php Command Execution, RAPID7, METASPLOIT FRAMEWORK, 

https://github.com/rapid7/metasploitframework/blob/master/modules/exploits/linux/http/dlink_diagnostic_exec_noauth.rb. 

291 Ibid. 

292 Ibid. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 94 of 165
94 

considerations warranted its development and installation, prudence dictates special care should 

have been taken to forestall its misuse by attackers. 

183. These remote code execution exploits identified by Mr. Messner affected D-Link Routers

DIR-815, DIR-645, and DIR-412 routers, among others.293 Only one security advisory that 

appears to have been published about this vulnerability, contemporaneous with this 

vulnerability.294 That advisory listed the DIR-412 fix as “pending” more than a year after its 

discovery, and perhaps more, and that advisory was never updated to suggest it was fixed. 

d. Lovett Vulnerabilities—Clear Text Password, XSS, and Remote

Code Execution Vulnerabilities

184.

 

 

185. I have reviewed the flaws based on the acknowledgement on the D-Link website297 and

Mr. Lovett’s post on Packet Storm298 to better understand how these vulnerabilities operate. The 

clear text vulnerability appears to be able to exploited by a logged in user. It permits an 

individual who is not the administrator to see the administrator password in clear text.299 The 

293 D-Link, Security Advisory: DIR-600/DIR-300 revB/DIR-815/DIR-645/DIR-412/DIR-456/DIR-110–Multiple 

Vulnerabilities Command Injection Information Disclosure (June 30, 2014) (DLS0060250). 

294 Ibid. 

295 Email from Kyle Lovett to William Brown (Apr. 19, 2014) (DLS0021794–801, at DLS0021799). 

296 D-Link, Security Advisory: DIR-652 / DIR-835 / DIR-855L / DGL-5500 / DHP-1565–Storage of Passwords in 

clear text, Cross-Site Scripting (XSS), Information Disclosure–(FW 1.02b18/1.12b02 or older) (DLS0060220–21). 

297 Ibid. 

298 Kyle Lovett, D-Link Cross Site Scripting / Information Disclosure, PACKET STORM (May 22, 2014), 

https://packetstormsecurity.com/files/126779/D-Link-Cross-Site-Scripting-Information-Disclosure.html. 

299 Ibid. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 95 of 165
95 

purpose of the administrator password is that there should be a trusted user with full privileges to 

make any changes to the device (the administrator) and other users with limited privileges (the 

non-administrator). Although the conceivable misuses of this exploit are fewer than what I have 

identified for other vulnerabilities in this report, the storage of the administrator password in

clear text, accessible by the non-administrator user, entirely negates the security feature of 

having an administrator password. 

186. The other vulnerability I will discuss is the “apply.cgi” cross-site scripting vulnerability.

This vulnerability permits an unauthenticated user to execute a cross-site scripting attack, which 

permits the attacker to call up arbitrary folders, which should not be visible, such as contents of 

the /etc/passwd file on the device.

187. These vulnerabilities demonstrate two failures: First, the failure of storing password in

clear text (see Section III.D.6 above), notwithstanding that it has been standard practice for 

decades to mathematically obfuscate passwords before storage. And, second, a failure to 

implement proper input filtering. If the input at apply.cgi were properly filtered, an attacker 

would not be able to enter characters that could be used as part of a command to conduct a crosssite scripting attack.

188. Far more significant than these two vulnerabilities (password theft and cross site

scripting) and these two code development failures (clear text password storage and input 

filtering) is the fact that D-Link Corporation had already been informed of the existence of both 

of these vulnerabilities one year earlier by III/Onward—its third-party security testing vendor.300

 

That report identified the very same clear text password vulnerability: 

300 III/Onward, DIR-855L Device Security Testing Report, Appendix D–48 (Apr. 19, 2013) (DKC1896734–848). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 96 of 165
96 

:

301 

302

 It is 

304 DIR-855L Vulnerability Info Spreadsheet, Last Modified by Peter Tsai (DKC0501497). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 97 of 165
97 

possible that the fix may have been in progress prior to Mr. Lovett’s report, but the coincidental 

timing suggests that the fix was released only after the vulnerability was discovered by this thirdparty researcher. 

190.

 

 

305 Email from Daniel Hsu to Jade Wang (Apr. 23, 2013) (DKC1321035). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 98 of 165
98 

 

 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 99 of 165
99 

e. Huntley/Qihoo/Heffner Command Injection Vulnerability in

HNAP

193. On January 22, 2015, a security researcher named Sam Huntley emailed William Brown

to identify an exploit of a vulnerability with the implementation of the Home Network 

Administration Protocol (HNAP) of the DIR-645.310 D-Link was informed on March 18, 2015, 

by a different researcher, that a nearly-identical exploit worked on DIR-817, DIR-818L, 

DIR-820L, DIR-850L, DIR-868L, DIR-880L, and DIR-890L (as well as others not listed on 

Appendix A).311 The exploit permits a remote attacker, without authorization, to inject 

commands and take over the router.312 

194. According to the National Vulnerabilities Database, this vulnerability rated as a “10” on

the Common Vulnerability Scoring System—the very worst score, indicating ease of execution 

and high degree of potential harm.313 This is a devastating attack made worse D-Link Systems 

309 Email from Rick Chuang to Charles Teng (May 28, 2013) (DKC1135800–01, at DKC1135801) (“We have 

merged the security code from the DIR-855L and we will lab in pre-test today to check these security on 

DIR-505.”). This suggests that both the DIR-855L and the DIR-505 were Cameo devices and shared the same 

vulnerabilities, but without a code-sharing inventory it is impossible to know with certainty. 

310 Email from Samuel Huntley to security@dlink.com [William Brown] (Jan. 22, 2015) (DKC0489690–695, at 

DKC0489693–695). 

311 Email from xueyufeng@360.cn [Qihoo] to security@dlink.com [William Brown] (Mar. 18, 2015) 

(DLS0052808–809, at DLS0052809). I was able to find no indication in any of the emails I reviewed or searched 

for that D-Link Systems (or its parent or vendors on its behalf), prior to the March 18, 2015 email, had any 

understanding that the same HNAP vulnerability from the DIR-645 was also present on these many additional DLink routers. 

312 See generally Samuel Huntley, Craig Heffner & Michael Messner, D-Link Devices HNAP SOAPAction-Header

Command Execution, RAPID7 VULNERABILITY & EXPLOIT DATABASE (“This module has been tested on a DIR-645

device. The following devices are also reported as affected: . . . DIR-880L, DIR-865L, DIR-860L revA, DIR-860L 

revB DIR-815 revB, DIR-300 revB, DIR-600 revB, DIR-645”),

https://www.rapid7.com/db/modules/exploit/linux/http/dlink_hnap_header_exec_noauth. 

313 CVE-2015-2051 Detail, NIST NATIONAL VULNERABILITY DATABASE (Feb. 23, 2015) (“The D-Link DIR-645 

Wired/Wireless Router Rev. Ax with firmware 1.04b12 and earlier allows remote attackers to execute arbitrary 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 100 of 165
100 

(or its parent) failed to realize until informed by a third party two months later that it affected not 

just one, but a large number of its devices.314

 

. This permits an attacker to inject a 

variety of commands including, as the exploit proposes, a telnetd command to open an

unauthenticated root shell—that is, a command line that completely takes over the router. 317

commands via a GetDeviceSettings action to the HNAP interface.”), https://nvd.nist.gov/vuln/detail/CVE-2015-

2051. 

314 Email from xueyufeng@360.cn [Qihoo] to security@dlink.com [William Brown] (Mar. 18, 2015) 

(DLS0052808–809, at DLS0052809). 

315

316 The omission was likely purposeful—I infer that the programmers felt that it was unnecessary to require 

authentication for getdevicesettings, because they believed this action to be passive and harmless. On its face, it is; 

but because of the implementation failure (failing to conduct input filtering), the absence of authentication on the 

getdevicesettings action created a security hole one could drive a truck through. 

317 See generally D-Link Devices HNAP SOAPAction-Header Command Execution, RAPID7 VULNERABILITY & 

EXPLOIT DATABASE, https://www.rapid7.com/db/modules/exploit/linux/http/dlink_hnap_header_exec_noauth; See 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 101 of 165
101 

196.

 

 

. 

Craig Heffner, Hacking the D-Link DIR-890L, /DEV/TTYS0 (Apr. 10, 2015), 

http://www.devttys0.com/2015/04/hacking-the-d-link-dir-890l/. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 102 of 165
102 

 

 This 

vulnerability amply displays why so many of D-Link’s routers and IP cameras are not secure 

from unauthorized access—D-Link Systems routinely failed to take reasonable steps to secure 

their routers and IP cameras from easily predicable unauthorized access. 

199. A discussed above, this vulnerability affected the DIR-645,322 as well as the DIR-817,

DIR-818L, DIR-820L, DIR-850L, DIR-868L, DIR-880L, and DIR-890L.323

f. Adkins Command Injection Vulnerability

200. In January 2015, a security researcher named Peter Adkins reported a command injection

vulnerability to D-Link Systems.324 The vulnerability could be exploited from the local area 

320 Vulnerability Info (noting May 15, 2014 fixed date) (DKC0136325). 

321 Email from Daniel Hsu to Joseph Chao and Zhi-Feng Lin (May 22, 2014) (DKC1354860–71, at DKC1354862–

63). 

322 D-Link, Security Advisory, DIR-645: Rev. Ax–Command Injection–Buffer Overflow: FW 1.04b12 (Version 

9) (Apr. 24, 2015) (DLS0060307–09).

323 D-Link, Security Advisory, D-Link Router: HNAP Privilege Escalation–Command Injection (Version 14) 

(Apr. 25, 2015) (DLS0060368–71).

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 103 of 165
103 

network or over the Internet, under certain conditions.325 This vulnerability allows an attacker to 

take over the router, including the ability to install software, change settings or passwords, and 

attack other devices on the local network, including potentially installing malicious software on 

those devices. For example, Mr. Adkins demonstrated changing the DNS settings, which could 

allow an attacker to redirect users to a malicious, spoofed version of a banking website.326 

201. Mr. Adkins explains in his disclosure how he disassembled the firmware and used

methodical, but not original, techniques to identify a problem in the “ncc/ncc2” service of several 

D-Link Systems routers.327 The ncc/ncc2 service included a “ping” diagnostics function. The

ping function “ping” a specified IP address, by sending tiny packets of information to test 

whether the destination IP address is communicating with the device sending the ping. 

202. However, the ncc/ncc2 service ping function on the affected routers was accepting

unauthenticated requests from within the local area network.328 As a matter of general principle, 

the ping function—or any network utility running on the router—should only be invoked by 

324 Peter Adkins, D-Link and TRENDnet ‘ncc2’ service - multiple vulnerabilities, DARKARNIUM/SECPUB (Jan. 11, 

2015) (“Issues reported to D-Link via email (security contact).”), 

https://github.com/darkarnium/secpub/tree/master/Multivendor/ncc2; 

CVE-2015-1187: D-Link DIR-636L Remote Command Injection - Incorrect Authentication, CVE Mitre (Jan. 17, 

2015), https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1187. 

325 D-Link, Security Advisory, DIR-626L/DIR-636L/DIR-808L/DIR-810L/DIR-820L/DIR-826L/DIR-830L/DIR836L–Remote code execution–Information disclosure–DNS hijacking (Mar. 16, 2015) (DLS0060338–41); 

III/Onward, DIR-820L Device Security Testing Report, Appendix D (June 5, 2014) (DKC0003804–66); DIR-820L 

Vulnerability Info Spreadsheet (DKC0501497). 

326 Peter Adkins, D-Link and TRENDnet ‘ncc2’ service - multiple vulnerabilities, DARKARNIUM/SECPUB (Jan. 11, 

2015), https://github.com/darkarnium/secpub/tree/master/Multivendor/ncc2; 

D-Link/TRENDnet NCC Service Command Injection, RAPID7/METASPLOIT FRAMEWORK (first posted Mar 12, 2015),

https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/http/multi_ncc_ping_exec.rb.

327 Peter Adkins, D-Link and TRENDnet ‘ncc2’ service - multiple vulnerabilities, DARKARNIUM/SECPUB (Mar. 3,

2015), https://github.com/darkarnium/secpub/tree/master/Multivendor/ncc2. 

328 D-Link, Security Advisory, DIR-626L/DIR-636L/DIR-808L/DIR-810L/DIR-820L/DIR-826L/DIR-830L/DIR836L–Remote code execution–Information disclosure–DNS hijacking (Mar. 16, 2015) (DLS0060338–41); 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 104 of 165
104 

users who have authenticated to the router. Mr. Adkins states that the vulnerability could be 

exploited over the Internet if the router had WAN management enabled or via a cross-site 

request forgery (CSRF) attack.329 Classically, a CSRF is a way to remotely exploit a 

vulnerability that can otherwise only be exploited locally, by forcing an end user to “execute 

unwanted actions on a web application in which they’re currently authenticated.”330 In this case, 

the vulnerability can be leveraged even without authentication because the vulnerable service did 

not require authentication. But regardless of whether we call it CSRF or not, it could be 

exploited if an attacker could trick someone on the router’s network to visit a website containing 

properly-styled attack code.331

203. Mr. Adkins revealed that the software did not filter the input provided to the ping request

for an IPv6 address.332 Rather than building in a step to verify that the input received matches 

329 Peter Adkins, D-Link and TRENDnet ‘ncc2’ service - multiple vulnerabilities, DARKARNIUM/SECPUB (Mar. 3, 

2015), https://github.com/darkarnium/secpub/tree/master/Multivendor/ncc2. 

330 E.g., Cross-Site Request Forgery (CSRF), OWASP, https://www.owasp.org/index.php/CrossSite_Request_Forgery_(CSRF) (emphasis added). 

331 Peter Adkins, D-Link and TRENDnet ‘ncc2’ service - multiple vulnerabilities, DARKARNIUM/SECPUB (Mar. 3, 

2015), https://github.com/darkarnium/secpub/tree/master/Multivendor/ncc2. Attackers know how to attract people 

to such sites. A common way is what is often called a water-cooler attack. In my experience, attackers identify a 

subject that will be of interest to many people, based on the news or other current events, and then build websites 

that will draw people interested in trending topic. For example, I saw examples of this kind of attack leveraging 

interest in the Fukushima nuclear power plant disaster, when that disaster was still occurring. In this way, attackers 

can get many people to visit and some will be using software that is vulnerable to their crafted exploit. See also 

Email from William Brown to Daniel Hsu (Mar. 4, 2013) (DLS0023965–70, at DLS0023966) (quoting 

http://forums.dlink.com/index.php?topic=23161.0, describing steps to use a D-Link forum post that would attract 

people having problems with a vulnerable router to visit and click). The risk that such vulnerabilities would be 

exploited is not theoretical. See Michael Mimoso, Exploit Kit Using CSRF to Redirect SOHO Router DNS Settings, 

THREATPOST (May 26, 2015), https://threatpost.com/exploit-kit-using-csrf-to-redirect-soho-router-dnssettings/112993/. This attack campaign could change routers’ DNS settings, which allows the attackers to redirect 

the users to websites of their choosing. According to a researcher who observed the attack campaign, one of the 

vulnerabilities this attack leveraged was the one disclosed by Mr. Adkins. See CVE-2015-1187: D-Link DIR-636L 

Remote Command Injection - Incorrect Authentication, CVE Mitre (Jan. 17, 2015), https://cve.mitre.org/cgibin/cvename.cgi?name=CVE-2015-1187. 

332 IPv6 is the abbreviation for a newer format for IP addresses: Internet protocol version 6. It is a replacement for 

the more-familiar IPv4 addresses—which take the form ###.#.#.###—and will accommodate many more addresses 

than IPv4 (which is running out of unique addresses). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 105 of 165
105 

the parameters of the expected input—an IPv6 address—the software was written to pass along 

whatever the user provided to other functions. 

204.

. If 

the software engineer had implemented a similar step when adding in the IPv6-handling code, 

Mr. Adkin’s exploit code would have been rejected, and a substitute exploit would have been 

much harder to construct, if possible at all. 

205. The software then processed the foregoing IPv6 ping request using a system() call, 

instead of using a more appropriate, limited library call that could accomplish the ping task 

without processing the input at the highest privilege level.333 As described in Section III.D.3 

above, this is a lazy and dangerous way to handle user input, which significantly raises the stakes 

for input filtering. 

206. Because D-Link Systems’ vendor failed to filter input and passed the input to a system()

call, the result was a command injection vulnerability, allowing complete takeover of the routers. 

Attackers know to look for vulnerabilities like this. For example, Mr. Adkins identified that the 

333 In Mr. Adkins’ disclosure, he uses the term __system(), because he is interpreting the symbol represented in the 

binary. This corresponds to system() which would appear in the programming language. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 106 of 165
106 

jjhttpd portion of the code would handle input, and he focused on that using a tool called 

readELF to examine the code looking for problems that could be exploited.334

207. In addition to not requiring a user to be logged in to access ping, which itself is a serious

code development failure, this vulnerability is made possible by three code development failures 

discussed above. This vulnerability existed because of the software did not filter the input 

provided to the ping function (see Section III.D.1 above), and passed that user input to a system()

call, (see Section III.D.3 above). In addition, this vulnerability was due to a code maintenance 

failure (see Section III.D.7 above), because the software engineer failed to mirror the example of 

more secure solution in the very same part of the software. Lastly, this is arguably an 

unnecessary service, to the extent it is unnecessary to permit a user to be able to trigger the ping 

command from the browser (see Section III.D.4 above). 

208. This vulnerability affected the following routers models listed on Appendix A: DIR626L, DIR-636L, DIR-808L, DIR-810L, DIR-820L, DIR-826L, DIR-830L, DIR-836L.335

g. Romero Remote Code Execution Vulnerability

209. In June 2016, a security researcher named Daniel Romero, working for a security

company called NCC Group, disclosed a stack overflow vulnerability to D-Link Systems that 

affected several of D-Link Systems’ routers and could be remotely exploited to enable remote 

code execution.336 The vulnerability could allow attackers to send commands to a vulnerable 

334 Peter Adkins, D-Link and TRENDnet ‘ncc2’ service - multiple vulnerabilities, DARKARNIUM/SECPUB (Mar. 3, 

2015), https://github.com/darkarnium/secpub/tree/master/Multivendor/ncc2. 

335 D-Link, Security Advisory: DIR-626L/DIR-636L/DIR-808L/DIR-810L/DIR-820L/DIR-826L/DIR-830L/DIR836L–Remote code execution–Information disclosure–DNS hijacking (Mar. 16, 2015) (DLS0060338–41). 

336 Email Daniel Hsu to William Brown (Aug. 10, 2016) (DLS0015101–10, at DLS0015104, at –10) (email 

forwarding Romero’s report); Vulnerability Note VU#332115: D-Link routers contain buffer overflow vulnerability, 

CERT, SEI-CMU (Aug. 11, 2016), http://www.kb.cert.org/vuls/id/332115; D-Link, Support Announcement: CVE2016-5681 VU#332115–Some D-link routers are vulnerable to buffer overflow exploit (June 2, 2016) 

(DLS0053132). See also CVE-2016-5681 Detail, NIST NATIONAL VULNERABILITY DATABASE (Nov. 28, 2016), 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 107 of 165
107 

 

 

 

211. This vulnerability was the result of two code development failures discussed above,

among other things. First, this portion of the software did not handle strings properly, using 

strcpy() improperly instead of a more secure method (see Section III.D.2 above). A second 

cause was the failure to adequately filter input, which also would have prevented Mr. Romero’s 

https://nvd.nist.gov/vuln/detail/CVE-2016-5681?cpeVersion=2.2#vulnConfigurationsArea; Martin Beltov, D-Link is 

Patching CVE-2016-5681, Critical Flaws in their Routers, BEST SECURITY SEARCH, 

http://bestsecuritysearch.com/d-link-patching-cve-2016-5681-critical-flaws-routers/. 

 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 108 of 165
108 

exploit from succeeding (see Section III.D.1 above). As discussed further in Section III.D.2 

above, the strcpy() function is an element of the C language library, found on many operating 

systems, including linux/Unix. Strcpy() passes on a string regardless of its length, creating in 

some cases a potential overflow vulnerability. 

212. This vulnerability affected the following router models listed on Appendix A: DIR-817L, 

DIR-818L, DIR-822, DIR-823, DIR-850L, DIR-868L, DIR-880L, DIR-890L, and DIR-895L.341 

2. Camera Vulnerabilities

213. D-Link Systems IP Cameras also experienced many serious vulnerabilities.342 Below are 

a few examples illustrating the kinds of serious vulnerabilities that affected D-Link Systems’ 

devices as a result of failures described in Section III.D above. 

a. Hidden Guest-Guest Account

214.

341 D-Link, Support Announcement: CVE-2016-5681 VU#332115 - Some D-link routers are vulnerable to buffer 

overflow exploit (Nov. 11, 2017) (DLS0053132); Email from William Brown to Daniel Hsu (Aug. 10, 2016) 

(DLS0015101-10, at DLS0015101-02) (listing affected models). 

342 E.g., Spreadsheet of IP Cameras Vulnerabilities and Affected Devices (last modified June 6, 2013) 

(DKS00002081). 

343 Email from AJ Wang to William Brown (Feb. 28, 2013) (forwarding email from Ersin Akar to Irfan Munir et al.) 

(staff of another D-Link Corporation subsidiary outside the U.S. realized the problem in February and looped in AJ 

Wang of DLS) (DLS0017467–81, at DLS00017480). 

344

. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 109 of 165
109 

215. The hidden user account had the easily-guessable username “guest” and password

“guest”.345 The hidden guest account seems to have been built into the cameras from the start.346 

216. Camera owners could change the password for the Guest Account in the administrative

settings for the cameras, but they could not delete the account or change the username.347 The 

only way to change the default password for the account was to go through the steps to “add” a 

guest user account with a unique password, which overwrote the “guest” password.348 

Remarkably—and, in my opinion, terrifyingly—there was no mention of the default Guest 

account in the setup for the cameras, in user manuals, or any warnings in the settings of the 

existence of the account.349 

217. Building an undisclosed, default credential into devices exemplifies two security failures

I have discussed before. D-Link Systems not only failed to prevent or remove undocumented 

credentials and backdoors (see Section III.D.5 above), but also D-Link Systems failed to prevent 

E.g., DCS-2310 User Manual v.1.0 (Jul. 10, 2012) (DLS0005107–95, at DLS0005149–51) (setup IP camera to have

its own IP address for access over the Internet).

345 Email from AJ Wang to William Brown (Feb. 28, 2013) (DLS0017467–81, at DLS00017480) (email from Ersin 

Akar to Irfan Munir et al.); Guest User Account Security Advisement for Select D-Link IP Cameras (May 9, 2013) 

(DLS0005316–17). 

346 E.g., DCS-2132L Firmware Release Notes (July 29, 2013) (DKS00036648–50, at DKS00036649) (removing the 

default account “guest” in version V1.01.10, which was the first firmware version after the initial version, 

V1.00.06); DCS-2132L Vulnerability Info Spreadsheet (DKC0501497). In my experience, firmware release notes 

are a reliable source of information on what is changed between software versions, and whether features were added. 

347 This was the case at the time of the disclosure. Guest User Account Security Advisement for Select D-Link IP 

Cameras (May 9, 2013) (DLS0005316–17, at DLS0005317). The default guest account was subsequently disabled 

in updated firmware. E.g., DCS-2132L Firmware Release Notes (July 29, 2013) (DKS00036648–50, at 

DKS00036649); DCS-2132L Vulnerability Info Spreadsheet (DKC0501497). In order to learn of the Security 

Advisement or get the updated firmware, I believe camera owners would have to either be checking D-Link 

Systems’ websites or have downloaded its mydlink app. 

348 Guest User Account Security Advisement for Select D-Link IP Cameras (May 9, 2013) (DLS0005316–17, at 

DLS0005317). 

349 See, e.g., DCS-2310 User Manual v.1.0 (Jul. 10, 2012) (DLS0005107–95, at DLS00005179) (showing device 

management interface). Instead, it says “but you may want to reserve at least one as a guest account,” implying that 

there is no such account without action by the user. Likewise, these User Manual sections instructing users how to 

configure cameras to be reachable over the Internet do not provide any warning about increased risks, tell users 

about the hidden guest account, or recommend users verify the access accounts they have set up. DCS-2310L User 

Manual v.1.0 (July 10, 2012) (DLS0005107–95, at DLS0005149–51). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 110 of 165
110 

or remove unnecessary services, in that they maintained a default account designed for 

commercial purposes in IP cameras sold to consumers (see Section III.D.4 above). 

218. The devices with this hidden guest account were nominally “security” cameras, and DLink Systems recommended many for use in the home.350 D-Link Systems could have avoided 

undermining the security of these cameras in a number of ways. D-Link Systems could have 

asked users during setup whether they wished to enable a guest account, and prompted them to 

set a password (the process that the user manual seems to suggest, see Note 349 above). D-Link 

Systems could have shipped the cameras with the guest account active, but required the user to 

create a unique password before the camera could be activated. D-Link Systems could also have 

shipped the cameras with the guest account password set to a unique, not-guessable351 default 

value that a user could easily find (but that an unauthorized user could not), such as the device’s 

serial number. Lastly, the risk of strangers watching D-Link Systems’ customers in their 

homes—unknown to them—would have been reduced if the camera’s user manual simply had 

explained the risk and remediation options to the camera’s owners. In addition, D-Link Systems 

could have prevented this problem by conducting a review of the user accounts on its devices, or 

requiring its vendors to do so. 

219. Around the time D-Link Systems and D-Link Corporation decided to address the hidden

guest account, an article about the Internet-connected-device search engine Shodan352 appears to 

350 See, e.g., DCS-2310L User Manual v.1.0 (July 10, 2012) (“unique solution for your small office or home . . . . 

that transmits high quality video images for security and outdoor surveillance.”) (DLS0005107–95, at 

DLS0005112). 

351 For example, making the guest account password the model number of the camera would be guessable by 

persons trying to get unauthorized access to camera feeds. 

352 Shodan is a search engine that looks for Internet-connected devices. Any Internet user can use Shodan to search 

for specific kinds of computers on the Internet, such as cameras, routers, and hardware devices, using a variety of 

filters. SHODAN, https://www.shodan.io/. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 111 of 165
111 

have caused alarm at D-Link Systems and D-Link Corporation 

 

4

The same day, D-Link Systems 

published a statement advising customers to change the password for the guest account, and 

notifying them that firmware that would remove it was underway.355

 

220. In testimony, D-Link Systems employees have claimed that most of the affected cameras 

were models intended for businesses, and that the hidden guest account was incorporated to 

enable the cameras to be integrated into Video Management Systems (VMS).356 Even if this is 

the reason the guest account was devised, there is no excuse for carrying this feature into at least 

several cameras D-Link Systems describes as “consumer product[s].”357 What may have been a 

feature for commercial purchasers became a backdoor putting consumers at risk of having their 

security monitoring turned into surveillance against them. 

221.

353 Email from William Brown to Kevin Wen (May 7, 2013) (DKS00035676–79, at DKS00035679) (email from 

Dan Dowdy sending link to Businessweek article). 

354 Email from William Brown to Kevin Wen (May 7, 2013) (DKS00035676–79, at DKS00035678) (email from 

William Brown to Robert Lin et al.). 

. 

355 Guest User Account Security Advisement for Select D-Link IP Cameras (May 9, 2013) (DLS0005316–17). 

356 Brown Investigational Hr’g. Tr. 781:18–784:8 (July 31, 2014); Brown Dep. 101:24–103:9 (Mar. 14, 2018). See 

also Wang Dep. 229:7–230:11, 233:13–234:8 (Dec. 6, 2017) (stating cameras were business, and guest account was 

necessary for devices to connect to Camera Management Systems (CMSs)). 

357 D-Link Sys. Answers and Objections to FTC 5th Set of Interrogs. No. 23–24 (May 4, 2018), Resp. to Interrog. 

No. 22 (listing the “Product Category” of the DCS-2132L, DCS-2310L, DCS-2332L as “Consumer Product”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 112 of 165
112 

 AJ 

Wang, of D-Link Systems, on this point stated that, although he believed the Guest account was 

a feature, not a bug, it should not have been enabled by default.359

222. The undisclosed guest account was built into the following devices listed in Appendix A:

DCS-2132L, DCS-2210, DCS-2230, DCS-2310L, DCS-2332L, DCS-3112, DCS-3710, DCS3716, DCS-6010L, DCS-6210, DCS-6510, DCS-6511, DCS-6513, DCS-6616, DCS-6818, DCS7010L, DCS-7413, and DCS-7513.360

b. Core Security Hard-Coded Backdoor in RTSP

223. Around the same time in early 2013, researchers from the firm Core Security disclosed

the existence of a hard-coded password in numerous D-Link Systems’ IP Cameras that acted as a 

backdoor to the device.361 The backdoor allowed anyone who could connect to the camera’s IP 

address to view the camera’s RTSP (Real Time Streaming Protocol) video stream—what the 

camera was capturing at any given moment—without needing to crack or steal the user’s login 

358 Email from AJ Wang to William Brown (Feb. 28, 2013) (DLS0017467–81, at DLS00017476–77) (email from 

Mike Lange to Kevin Wen). 

359 Email from AJ Wang to Roger Kao, William Brown (Feb. 28, 2013) (DLS0017452–66 at DLS0017452) (“The 

only problem is that guest is enabled by default. It should have been disable be [sic] default.”). Mr. Wang seems to 

have qualified his answer in his deposition, arguing that the hidden account was a feature. Wang Dep. 239:4–19 

(Dec. 6, 2017). However, Mr. Wang did not seem to be aware of the user manuals for the affected devices, which 

do not disclose the hidden account. Wang Dep. 239:4–19 (Dec. 6, 2017); DCS-2310 User Manual v.1.0 (Jul. 10, 

2012) (DLS0005107–95, at DLS00005179). 

360 Guest User Account Security Advisement for Select D-Link IP Cameras (May 7, 2013) (DLS0005316–17); 

Spreadsheet of IP Cameras Vulnerabilities and Affected Devices (last modified June 6, 2013) (DKS00002081) 

(hidden column K notes cameras for which D-Link “Remove[d] Guest account”). 

361 D-Link IP Cameras Multiple Vulnerabilities, CORE SECURITY (Apr. 29, 2013) (CVE-2013-1603, bypass RTSP 

authentication using hard-coded credentials), https://www.coresecurity.com/advisories/d-link-ip-cameras-multiplevulnerabilities. 

Core Security also disclosed several more critical vulnerabilities, including two ways to bypass the authentication of 

the cameras and a vulnerability that allowed an attacker to remotely execute commands on the affected cameras. 

Ibid. (CVE-2013-1599, Command Injection; CVE-2013-1600, to access the video stream via HTTP; CVE-2013-

1602, Authentication Bypass vulnerabilities); Email from William Brown to Oscar Navarro and attachments (Apr. 

24, 2013) (DLS0030634–44, at DLS0030635) (attaching spreadsheet of devices affected by each CORE-disclosed 

vulnerability). See also D-Link IP Cameras RTSP Authentication Weak, VULDB (May 6, 2013),

https://vuldb.com/?id.8574. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 113 of 165
113 

credentials. If a camera owner had set up his or her camera to connect directly to the Internet, as 

D-Link Systems provided instructions how to do,362 unauthorized users could watch the video

stream over the Internet. 

224. By disassembling the firmware, the researchers found that the code was written to accept

“?*” as a password, regardless of what username was entered, or if username was left blank.363 

The backdoor was not obfuscated in the source code to make it harder for the researchers, or an 

attacker, to find out.364 

225. As discussed in Section III.D.5 above, incorporating and not removing hard-coded

credentials is a serious code development failure. It is inherently insecure to write credentials 

directly into source code—the resulting credentials cannot be unique to each device, and they 

require a firmware update to change if compromised. 

226. Hard-coded credentials are preventable because they are the result of a purposeful act,

rather than an oversight. In addition to relying on the software engineer not to incorporate them 

in the first place, organizations can take a number of steps that D-Link Systems and D-Link 

Corporation did not to avoid them. For example, organizations should have policies prohibiting 

the use of hard-coded credentials, even during development, and could incorporate a step to 

require programmers to affirm they have not used them or removed them before passing along 

code. 

362 See, e.g., DCS-2310L User Manual v.1.0 (July 10, 2012) (DLS0005107–95, at DLS0005149–51). 

363 D-Link IP Cameras Multiple Vulnerabilities, CORE SECURITY (Apr. 29, 2013), 

https://www.coresecurity.com/advisories/d-link-ip-cameras-multiple-vulnerabilities. 

364 Although hard-coded credentials are never acceptable for secure functions, like access to a camera’s video, there 

are also numerous methods by which companies can obfuscate sensitive areas of code, such as authentication, to 

make it harder for attackers to reverse engineer and search for vulnerabilities. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 114 of 165
227. T

credible. 

they repr

with the 

The effec

company

incorpora

Corporat

228. T

DCS-110

5635.365 

this hardwere firs

365 E.g., Sp

(DKS0000

29, 2013) (

https://ww

366 E.g., DC

DCS-1130

Notes v.1.0

cameras su

The analysis 

 The researc

resented: “A

string :?* (th

ct of these lin

y validated th

ated checkin

tion’s D-Lab

This backdoo

00/1100L, D

Based on fi

-coded back

t sold.366

preadsheet of IP

02081) (see col

(CVE-2013-16

w.coresecurity

CS-5605/DCS0 Firmware Rel

04B7712 (Apr

uggesting the R

of the resear

chers’ disclo

s we can see

he character 

nes is to auth

he existence 

ng for this pa

b (see Section

or affected th

DCS-1130/11

rmware rele

kdoor was lik

P Cameras Vul

lumn CVE-201

603, bypass RT

y.com/advisorie

-5635 Firmwar

lease Notes v.1

. 30, 2013) (DL

RTSP code was

rchers is stra

osure showed

e in the follo

: is used for

henticate any

of this back

assword strin

n III.F.1 belo

he following 

130L, DCS-3

ease notes, no

kely in at lea

lnerabilities an

13-1603) D-Lin

TSP authenticat

es/d-link-ip-cam

re Release Not

1.04B7712 (Ap

LS0004470). I

s added to the c

114 

aightforward

d at lines 10–

owing dump,

r concatenati

y person wh

kdoor in their

ng in the reg

ow). 

D-Link Sys

3410, DCS-3

oting fixes f

ast some of th

nd Affected De

nk IP Cameras

tion using hard

meras-multiple

tes v.1.01_patc

pr. 30, 2013) (D

I don’t see any

cameras source

d, logical, an

–12 of the d

, the submitt

ion of userna

ho submits “?

r internal do

gression tests

stems IP cam

3411, DCS-3

for other Cor

he affected c

evices (last mod

s Multiple Vuln

d-coded creden

e-vulnerabilitie

ch02, 7812 (Ap

DLS0004558);

ything in the rel

e code in an int

d in my opin

disassembly e

ted password

ame:passwo

?*” as the pa

ocuments, an

s conducted b

meras listed o

3430, DCS-5

re Security v

cameras’ sof

dified June 6, 2

nerabilities, CO

ntials), 

es. 

pr. 12, 2013) (D

 DCS-1100 Fir

lease notes for

termediate firm

nion highly 

exactly what

d is compare

rd).” 

assword. Th

nd they later 

by D-Link 

on Appendix

5605, and D

vulnerabilitie

ftware since 

2013) 

ORE SECURITY

DLS0006908–1

rmware Releas

r the affected IP

mware release. 

t

ed 

he 

x A: 

CSes, 

they 

(Apr. 

10); 

se 

P

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 115 of 165
115 

c. Senrio Stack Overflow Vulnerability

229. In 2016, a security company named Senrio reported a remotely exploitable stack

overflow vulnerability to D-Link Systems affecting its IP cameras.367

230. Senrio found the vulnerability by disassembling the firmware and reverse engineering the

source code using a well-known and reliable program called Interactive Disassembler,368 or IDA, 

which in my opinion is currently the gold standard for analyzing packaged code. Here’s how it 

works: First, a researcher or attacker could take D-Link Systems’ firmware update packages and 

decode them into a set of executables and data files. Then, IDA can be used to generate 

assembly language source code from those executable files. This gives the researcher or attacker 

something approximating the source code of the device as the software engineer who created it 

would see it. 

231. Examining the code in this way, Senrio identified multiple, insecure uses of the function

strcpy().

369 As discussed in Section III.D.2 above, using strcpy() to handle user input insecurely 

is an easily preventable flaw that can lead to buffer and stack overflows. This is another example 

of D-Link Systems’ improper string handling in devices. D-Link Systems had been warned of 

367 Senrio, D-Link Vulnerability Details (Jun. 13, 2016) (PX07000-001–10, at PX07000-006-10); D-Link, Support 

Announcement: Regarding Senr.io Vulnerability Information Updates (Nov. 10, 2017) (DLS0053130–31); Email 

Richard Chen to Yin Khvat (July 7, 2016) (DLS0042766-76, at DLS0042766) 

Ibid. 

368 Ibid. at PX07000-006.

369 Ibid. at PX07000-007

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 116 of 165
116 

problems in this area by III/Onward, and the insecure use of strcpy() in particular, for at least 

three years.370 

232. Senrio was able to find an instance where strcpy() was used to write to the stack that

accepted input but did not check for a signature (based in part on the user password).371 The 

flaw was in a part of the code that listens for DCP (Discovery and Basic Configuration Protocol) 

packets on a loop.372 The vulnerability resulted from the combination of three well-known 

failures: (1) not authenticating the user sending input on DCP service;373 not filtering the user 

input properly to reject input that featured arbitrary characters (see Section III.D.1 above); and 

another instance where a D-Link Systems device used strcpy() to handle user input (see Section 

III.D.2 above—Improper String Handling). Senrio leveraged the stack overflow vulnerability to

send code to the device to change its password to one of Senrio’s choosing.374

233. Senrio’s exploit of changing the device’s password was just an example. The stack

overflow could also have allowed Senrio, or an attacker, to feed commands to the device. In the 

case of Senrio’s proof of concept, the command was used to change the device’s password. But 

this vulnerability would also have allowed an attacker to access a command shell,375 to remotely 

control the camera, to install software, or more. 

370 See, e.g., III/Onward, DCS-930L Device Security Testing Report, Appendix D-3, D-5, D-7 (Aug. 27, 2012) 

(DKC0003183–203, at DKC0003185, DKC0003187, DKC0003189); III/Onward, DIR-826L Device Security 

Testing Report, Appendix D-6, D-15, D-16 (Sept. 28, 2012) (DKC0003966–4003, at DKC0003971, DKC0003980, 

DKC0003981, DKC0003984, DKC0003985); III/Onward, DCS-942L Device Security Testing Report, Appendix 

D-3 (Nov. 10, 2012), (DKC0003351–65, at DKC0003353). 

371 Senrio, D-Link Vulnerability Details (Jun. 13, 2016) (PX07000-001–10, at PX07000-006–08). 

372 Ibid. 

373 Only a user logged in to the IP camera should be permitted to use this service. A user without the login 

credentials would not have a legitimate need for it. 

374 Senrio, D-Link Vulnerability Details (Jun. 13, 2016) (PX07000-001–10, at PX07000-008-09).

375 A command shell is a piece of software on a linux/Unix system which uses a command-line interface to give the 

user access to the operating systems’ services. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 117 of 165
117 

234. This vulnerability could have been exploited over the Internet if the camera owner set up 

the device to connect to the Internet, which D-Link Systems instructs its users how to do in its 

manuals.376 Senrio stated that it found vulnerable cameras online using Shodan.377

235. Many of D-Link Systems’ IP Cameras at the time included this vulnerability, including 

the following models listed on Appendix A: DCS-930L, DCS-931L, DCS-932L, DCS-933L 

DCS-934L, DCS-960L, DCS-2132L, DCS-2136L, DCS-2210, DCS-2230, DCS-2310L, DCS2330L, DCS-2332L, DCS-5009L, DCS-5010L, DCS-5020L, DCS-5222L, DCS-6010L, DCS7010L, and potentially the DCS-1100 and DCS-1130.378

3. Failing to Encrypt Mobile App Credentials

236. In February 2014, a researcher named James Fitts contacted D-Link Systems with a

disclosure that their mydlink Lite application for Android failed to encrypt user credentials stored 

on the devices.379 Mr. Fitts showed the specifics of what he found in his disclosure, and it was 

confirmed by representatives of D-Link Corporation.380

237. Google has advised developers as early as 2008 to encrypt mobile application credentials, 

providing tools and tips for that purpose.381 Platform providers—such as Google and Apple—

commonly create these basic tools to help developers do the right thing in the software 

distributed for their platform, i.e., code it securely. Accordingly, companies that fail to use these 

376 See, e.g., DCS-2310L User Manual v.1.0 (July 10, 2012) (DLS0005107–95, at DLS0005149–51). 

377 Senrio, D-Link Vulnerability Details (Jun. 13, 2016) (PX07000-001–10, at PX07000-010). 

378 D-Link, Support Announcement: Regarding Senr.io Vulnerability Information Updates (Nov. 10, 2017) 

(DLS0053130–31). 

379 Security Advisory: mydlink Lite mobile application for Android–Mis-handling user-credentials with-in the local 

file system (Feb. 27, 2014) (DLS0059990–91). 

380 Email from William Brown to Kevin Chen, Mac Mac, and attachments (Feb. 12, 2014) (DLS0049688–91) 

(containing Mr. Fitts’ report); Email from Mac Mac to William Brown (Feb. 14, 2014) (DLS0049714–15) 

(confirming vulnerability). 

381 See, e.g., PETER TEUFL, THOMAS ZEFFERER, CHRISTOF STROMBERGER, MOBILE DEVICE ENCRYPTION SYSTEMS

(Feb. 9, 2017), https://hal.inria.fr/hal-01463828/document. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 118 of 165
118 

free tools available for platform developers—or provide equivalent protections—are in my 

opinion unnecessarily endangering their users’ data privacy. 

238. This issue represents another instance of the code development failure I described as

“Clear Text Passwords” in Section III.D.6 above. As Mr. Fitts described, the username and 

password were stored in clear text in a file on the local file system.382 D-Link Systems, in my 

opinion unadvisedly, not only shows in its security advisory the precise location of the file 

containing the username and password in clear text, but also the precise sequence of commands 

needed to view them.383 It appears to me in studying the D-Link advisory that the credentials in 

question are not just those for the mobile app, but actually those needed to log into the user’s 

account at mydlink.com, the D-Link cloud services site. My understanding is this site allows 

users to view the video feed of some D-Link Systems IP Cameras and manage other functions 

related to cameras and some D-Link Systems routers, if the account is set up and configured to 

connect to them.384 Although the most likely exploitation scenario I can see involves a third 

party getting physical possession of the phone and unlocking it, this poor practice nevertheless 

creates significant unnecessary risks for D-Link Systems’ customers. 

239. Not only should D-Link Systems have abated this vulnerability by adopting the

recommended Google software, or equivalent methods, I referred to earlier, but it was told to do 

so by D-Link Corporation’s security testing vendor III/Onward as early as September 2012.

385 

382 D-Link Security Advisory: mydlink Lite mobile application for Android–Mis-handling user-credentials with-in 

the local file system (Feb. 27, 2014) (DLS0059990–91). 

383 Ibid. 

384 See, e.g., DCS-2310L User Manual v.1.0 (July 10, 2012) (DLS0005107–5195, at DLS0005136 (“You will be

able to remotely access your camera from www.mydlink.com.”), DLS0005140 (“The Settings tab [in mydlink]

contains several options for you to control how your DCS-2310L operates.”)). 

385 E.g., III/Onward, DIR-826L Device Security Testing Report, Appendix D-10 (Sept. 28, 2012) (DKC0003948–

4024, at DKC0003975). Two subsequent III/Onward reports in 2012 reported the same problem. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 119 of 165
119 

they did not address this issue until it was 

brought to their attention through the security report provided by Mr. Fitts.386 

240. This vulnerability appears to me to affect owners of all D-Link Systems devices ending in 

an “L,” if they made use of the mobile application in question (the D-Link Systems devices 

ending in “L” related to the mydlink.com cloud service site), including those in Appendix A.387 

4. Code Signing Key Exposure

241. In September 2015, D-Link Systems (via its parent) permitted its private key, which was 

used to sign software that D-Link distributed to U.S. consumers, to be published on a public 

website.388 D-Link Corporation, which acquired and managed the private key for software that 

D-Link Systems distributed along with D-Link Systems devices,389 shared the private key with 

D-Link Systems’ vendors so they could use it to sign software for Windows PCs.390 A vendor 

had apparently copied the private key into a folder containing open source software it was using 

in a device, and then failed to remove the private key from the folder before packaging the 

386 D-Link, Security Advisory: mydlink Lite mobile application for Android–Mis-handling user-credentials with-in 

the local file system (Version 4) (Feb. 27, 2014) (DLS0059990–91). 

387 D-Link Sys. 30(b)(6) Dep. 206:23–207:2 (Apr. 25, 2018) (“L” routers and IP cameras connect to mydlink.com); 

https://www.mydlink.com/apps. 

388 E.g., Email William Brown to AJ Wang (Sept. 22, 2015) (DLS0025082–87, at DLS0025083–87). 

389 If D-Link Corporation acquired a key that D-Link Systems was using in distributing software in the United 

States, D-Link Systems is just as responsible for ensuring the security of the key as its parent, including by making 

sure D-Link Corporation as its agent was not sharing it. 

390 D-Link Corp. 30(b)(6) Dep. 243:11–254:11 (Jan. 30, 2018). The key was used to sign support software for DLink Systems devices that is installed on PCs, not the firmware that runs on the devices themselves. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 120 of 165
120 

modified open source code.391 This failure provided access to the private key to anyone who 

opened the package. 

242. The private key at issue, also known as code-signing key, was used to provide validation 

that software signed with that key in fact came from a legitimate publisher who is trusted by 

Symantec.392 When running any software signed with this key, an end user would not receive a 

warning regarding the program (or, in more controlled environments, the program would not be 

blocked from running) because it would appear to be legitimate D-Link software.393

243. The unintentional exposure of a private key is a catastrophic event, permitting anyone to 

sign any software so that it would appear to be a legitimate D-Link program and run without 

warning on Windows devices. The consequence of leaking the key was thus not limited to DLink Systems or even D-Link Systems’ customers. Because the key was trusted by all Microsoft 

operating systems, it could be used to attack consumers who did not own a D-Link device of any 

391 Michael Mimoso, D-Link Accidentally Leaks Private Code-Signing Keys, THREATPOST (Sept. 18, 2015), 

https://threatpost.com/d-link-accidentally-leaks-private-code-signing-keys/114727/. The open source software the 

vendor was using was subject to a license called GPL, for Gnu General Public License. GPL is a prevalent license 

agreement for open-source software that allows free use and modification, but requires, among other things, that 

modifications be publicly re-shared for the benefit of the community. 

392 See generally Inadvertently Disclosed Digital Certificates Could Allow Spoofing, Microsoft Security Advisory 

3097966, MICROSOFT (Oct. 13, 2015) (“Advisory FAQs. . . . What caused the issue? The issue was caused by DLink Corporation inadvertently publishing the certificates.”), https://technet.microsoft.com/enus/library/security/3097966. 

393 Michael Mimoso, D-Link Accidentally Leaks Private Code-Signing Keys, THREATPOST (Sept. 18, 2015), 

https://threatpost.com/d-link-accidentally-leaks-private-code-signing-keys/114727/; 

Dan Goodin, In blunder threatening Windows users, D-Link publishes code-signing key, ARSTECHNICA (SEPT. 18,

2015), https://arstechnica.com/information-technology/2015/09/in-blunder-threatening-windows-users-d-linkpublishes-code-signing-key/; 

Chris Williams, D-Link spilled its private key onto the web—letting malware dress up as Windows apps, THE 

REGISTER (Sept. 18, 2015), https://www.theregister.co.uk/2015/09/18/d_link_code_signing_key_leak/; 

Sean Buckley, Leaked D-Link code-signing key could make malware look legit, ENGADGET (Sept. 18, 2015), 

https://www.engadget.com/2015/09/18/leaked-d-link-code-signing-key-could-make-malware-look-legit/.

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 121 of 165
121 

kind.394 Although Microsoft acted quickly to disable the key once it was discovered, it appears 

that the key may have been publicly posted for six months before, and we have no way of 

knowing whether it was found and used by bad actors in that time.395 The significance of the 

event is demonstrated by how Microsoft swiftly and publicly reacted, including revoking trust in 

the disclosed key.396 Similarly, William Brown expressed the gravity of this incident in 

correspondence.397 

244. The exposure also indicates a failure of process. As discussed in Section III.D.8 above,

D-Link Systems should have prohibited sharing the key with any third party. If sharing the key

was necessary, D-Link Systems should have exercised significant control over the use and 

storage of the key. Finally, even if they failed to do both of these things, D-Link Systems should 

have examined everything they made public that involved the use of the key to ensure that did 

not expose the key. Who was doing quality control on the open source software before it was 

posted?398 The failure suggests that there were not protocols in place or a standardized process. 

A company could avoid a failure like this by developing automated scripts to package up the 

software and sign it, rather than relying on manual steps. Ad hoc processes lead to failures. 

394 Email William Brown to AJ Wang (Sept. 22, 2015) (DLS0025082–87, at DLS0025086–87) (Sept. 18, 2015 

email in thread from Jason Syu to Ping Chen, writing that leaking the code signing key “means anyone can use the 

private certificate to sign their virus/worm program and pretend its D-Link approved program. For end user, they 

will trust D-Link and just run the program, the results will be very very bad.”) 

395 Michael Mimoso, D-Link Accidentally Leaks Private Code-Signing Keys, THREATPOST (Sept. 18, 2015), 

https://threatpost.com/d-link-accidentally-leaks-private-code-signing-keys/114727/ (researcher who found the 

private key identified that it had been posted in February 27, 2015). 

396 See Inadvertently Disclosed Digital Certificates Could Allow Spoofing, Microsoft Security Advisory 3097966, 

MICROSOFT (Oct. 13, 2015), https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/3097966. 

397 Email from William Brown to Roger Kao et al. (Sept. 26, 2015) (DLS0017981). 

398 There is evidence that, only after this disclosure, Patrick Cline of D-Link Systems took it upon himself to do 

some quality control on previously-posted D-Link Systems modifications of open-source software to look for any 

other private keys. Cline Dep. 74:11–77:4 (Apr. 24, 2018). Given how D-Link Corporation was sharing its key, DLink Systems and D-Link Corporation should have had a process to scan the open source before it was posted for 

this or any other problematic disclosures. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 122 of 165
122 

There are well-known processes to permit code signing by a developer who outsources the 

development of source-code, and it is telling that D-Link Systems was able to undertake one of 

these processes,399 but only following the disastrous exposure of their key. 

F. D-Link Systems’ Limited Affirmative Processes and Procedures Were

Inadequate

245. As discussed above, my opinion that D-Link Systems’ routers and IP cameras were not

secure from unauthorized access or control is based on the serious, preventable vulnerabilities 

affecting those routers and IP cameras. These vulnerabilities result predictably from 

fundamental failures in software development processes and practices. Reviewing the 

vulnerabilities and poor practices would lead any expert in my field to conclude that D-Link 

Systems’ approach was reactive and inadequate. Neither D-Link Systems, D-Link Corporation, 

nor D-Link Systems’ vendors took meaningful steps to identify and address failures that were 

likely to, and often did, result in serious vulnerabilities. In that way, the failures and 

vulnerabilities identified in their devices speak for themselves: What they were doing wasn’t 

working. 

246. I have also reviewed the practices D-Link Systems says it has taken to protect its devices

and its software from malicious use or well-known security flaws.400 In addition to the generally 

399 D-Link Corp. 30(b)(6) Dep. 253:16–254:11 (Jan. 30, 2018); D-Link Sys. 30(b)(6) Dep. 195:11–22 (Apr. 25, 

2018) (“Also how that key is handled today has been completely overhauled so the incident that we saw could not 

happen again.”); D-Link Sys. Answers to FTC’s 5th Set of Interrogs. 6 (May 4, 2018), (Resp. to Interrog. No. 15, “A 

robust Digital Signature Auto-Sign is also used to ensure secure product development.”). 

400 D-Link Systems describes the following practices : (1) “black box” security testing by III/Onward Security since 

2014; (2) work with “independent third-party security expert such as SEARCH-LAB and Jason Doyle”; (3) prerelease testing by D-Link Systems’ vendors; (4) “quality assurance functional and security testing by D-Lab”; (4) 

Digital Signature Auto-Sign System (Private Key); (5) “source code scans (‘white box’ tests by Checkmarx 

software)” on the “vendors’ source code for new products and firmware”; (6) “Software Security Risk 

Questionnaire... and [] Security Requirement Traceability Matrix”; (7) Security Issue Management (SIM) process.

D-Link Sys. Answers to FTC 5th Set of Interrogs. 3–7 (May 4, 2018) (Resp. to Interrog. No. 15). In addition to the 

foregoing topics, D-Link Systems refers to its work with Kapil Khot and Rapid7’s reports. See D-Link Sys. 

Answers to FTC 1st Set of Interrogs. 5–6 (Resp. to Interrog. No. 2), 11 (Resp. to Interrog. No. 4) (Aug. 17, 2017).

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 123 of 165
123 

sound practices D-Link Systems describes,401 I have also considered other relevant development 

and oversight practices, addressed below, described in deposition testimony and documents 

produced by D-Link Systems and D-Link Corporation.402 D-Link Systems’ security practices, 

which it sometimes engaged in on its own, but more often relied on its parent to handle, were ad 

hoc and generally ineffective prior to 2017.403 As discussed in this section, these practices 

reinforce my conclusion that, at least until approximately 2017, D-Link Systems’ routers and IP 

cameras were not secure from unauthorized access or control. 

247. Much more recently, beginning in 2016 and more seriously in Spring 2017, there appear

to be some efforts, primarily at D-Link Corporation, to work meaningfully on their software 

security program. According to the testimony of Mr. Brown individually and on behalf of DLink Systems, D-Link Systems still has little visibility into these recent efforts.404 And D-Link 

Systems still appears to have no means to require the continuation of these recent practices 

besides the same intermittent inquiry of D-Link Corporation that it has relied on in the past. 

Moreover, D-Link Systems seems not to receive the documentation that might enable it to 

evaluate the effectiveness of new practices or the security analyses of its products that are the 

401 Although sound in and of themselves, these practices do not add up to a secure development program. 

402 Although D-Link Systems does not mention it, I will also address D-Link Systems’ short-lived bug bounty 

program. 

403 In addition to some ongoing testing conducted by D-Link Corporation and III/Onward, D-Link Systems and DLink Corporation received evaluations from several other individuals and firms, but in almost every case, this work 

appears to have been a one-off, and general recommendations by these firms to put in place secure development 

processes seem not to have been acted upon. Further, my count of reports of the device security testing that D-Link 

Systems requested and paid for itself is five: two from Jason Doyle, two from SEARCH-LAB, and one from Kapil 

Khot (compensated with free hardware only), for all the routers and cameras they sold. See Sections III.F.3 and 

III.F.5.a below.

404 In addition, I understand that the documents evidencing these changed practices come entirely from the files of

D-Link Corporation, based on their Bates numbers.

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 124 of 165
124 

product of these new practices.405 It is too early in the implementation of these improvements to 

evaluate the adequacy of their implementation, their impact on the security quality of D-Link 

Systems’ devices, and whether these practices and tools properly and professionally 

implemented can in fact deliver assurance of security quality in the future. 

1. D-Lab and Vendor Testing

248. D-Link Systems points in its Responses to Interrogatories to testing conducted by D-Link 

Corporation’s D-Lab unit as part of its security program.406 D-Lab is a division or department of 

D-Link Corporation. I have reviewed the reports and testing plans evidencing this testing.407 It 

is clear from this documentation that D-Lab did very little testing for the purpose of uncovering 

new, undiscovered security issues. 

249. Rather, D-Lab was conducting functionality and quality assurance (QA) testing408—that 

is, running specified tests to ensure that devices function correctly and don’t suffer from specific, 

known problems. Quality assurance is important in its own right, but it can’t replace processes 

for preventing or fixing not-yet-discovered failures that could lead to vulnerabilities. 

250. D-Lab’s testing plans and reports describe the precise testing done.409

405 D-Link Sys. 30(b)(6) Dep. 89:1–91:24 (Apr. 25, 2018) 

). The two exceptions may be D-Link Systems’ engagement of SEARCHLAB Ltd. and Kapil Khot of Qualys. Each of these is addressed below. 

406 D-Link Sys. Answers and Objs. to FTC 5th Set of Interrogs. No. 15. 

407 See Appendix C (Materials Considered), D-Lab Testing. D-Link Systems identified a number of reports by 

Bates number as “(testing).” D-Link Sys. Answers and Objs. to FTC 1st Set of Interrogs. No. 2. I have determined 

that these “testing” documents (and others like them that were provided recently) are likely D-Lab testing reports 

and plans, based on other documents that mention D-Lab (e.g., DKC1827671 (using “DKP” numbers as “ID”s, 

which are used in testing plans and reports), and a handful of these “testing” documents that mention “Dlab system,” 

e.g., DKC1826417–30, at DKC1826429).

408 Brown Dep. 137:2-16 (Mar. 14, 2018);

409

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 125 of 165
125 

 

 

 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 126 of 165
126 

252.

 

253. D-Link Systems also refers to “rigorous pre-release testing” by its vendors.416 Although

D-Link Systems did not identify any documents reflecting this testing, I have reviewed a number

of spreadsheets and test reports that appear to originate from D-Link Systems’ vendors and 

identify testing processes.417 I understand the testing being described.418 Like D-Lab’s testing 

documents, these documents also reflect functionality and Quality Assurance testing.419 In the 

few instances where the documents do relate to security vulnerabilities, they simply confirm that 

a past problem has been solved, just like D-Lab’s testing.420

414 Regression testing is a feature of sound quality assurance practices intended to ensure that flaws previously 

remediated do not recur in subsequent versions of the software. 

415 See Section III.E.1.b above, which describes an egregious example of D-Link Systems’ vendors breaking a 

specific exploit—most likely by black-listing a character used in it—without addressing the underlying 

programming failure. 

416 D-Link Sys. Answers and Objs. to FTC 5th Set of Interrogs. No. 15. 

417 I

See Appendix C, Materials Considered, Section VI – Vendor 

Test Reports. I selected several for review, including samples from each of the vendors, and read them closely. 

418 E.g., Alpha Networks, D-Link DIR-850LA1 FW V1.06 Test Report (June 13, 2013) (DLS0042893). In some 

cases, the reports I selected for review referred to attachments containing related findings and test reports that did 

not seem to have been supplied. For example, see the Alpha Networks, DCS-934L Firmware Test Report (Nov. 11, 

2014) (DKC1828478–84, at DKC1828481). 

419 These reports/processes are distinct from the 2017 implementation of Checkmarx source code scanning, which I 

discuss in Section III.F.5.d below. 

420 Alpha Networks, D-Link DIR-850LA1 FW V1.06 Test Report (June 13, 2013) (DLS0042893) (see tab “1. Test 

Case,” rows 716-39 (“6. Web security”)). In some cases, the vendors did try to test for vulnerabilities, such as when 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 127 of 165
127 

254. The testing conducted by D-Link Corporation’s D-Lab unit and D-Link Systems’ vendors

are additional examples of D-Link Systems’ reactive approach to security. D-Lab and D-Link 

Systems’ vendors tested to make sure known security problems were not present in subsequent 

software. D-Lab and the vendors made little documented effort to identify coding failures or 

implementation flaws that could result in undiscovered vulnerabilities. 

2. III/Onward Security

255. D-Link Systems repeatedly mentioned III/Onward as part of its security program.421

III/Onward is a security testing company that evaluated IP cameras and routers for a discrete set 

of security issues.422 

256. I have reviewed the reports of device security testing conducted by III/Onward that were

provided by D-Link Corporation.423 As described below, D-Link Systems was not reasonable in 

relying on III/Onward’s services to provide documented assurance that D-Link Systems devices 

were secure from unauthorized access or control.

257. By and large III/Onward’s reports reflect competent tests, employing in many cases

commonly-accepted testing tools. But the scope of what III/Onward was asked to do was 

Cameo tried to test for a potential path traversal vulnerability. Cameo, D-Link DIR-505, Hardware Rev. A1, 

 

421 E.g., D-Link Sys. Answers and Objs. to FTC 5th Set of Interrogs. No. 15; D-Link Sys. Answers and Objs. to 

FTC’s 4th Set of Interrogs. Nos. 8, 11, 12 (Mar. 29, 2018). 

422 Decl. of Chung-Chieh Lin ¶ 28 (ECF 50-3) (Apr. 3, 2017). E.g., Contract of Info. Sec. Testing Servs. V1.0 (Dec. 

13, 2016) (DKC0004490-T–501-T, at DKC0004494-T) (see Article 3.1, “Work Scope”). D-Link Corporation 

appears to have had some devices tested by III/Onward since at least 2012, and, according to D-Link Systems, its 

devices have been subject to pre-release testing by III/Onward since 2014. D-Link Sys. Answers and Objs. to FTC 

5th Set of Interrogs. No. 15 (May 4, 2018) 

423 See Section II.A of Appendix B (Materials Considered). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 128 of 165
128 

limited,424 and the way they pursued the answer to the questions posed was also limited.425 

However, the work they did within these narrow confines was competent. Even with their 

limitations, III/Onward’s findings could have tipped off D-Link Systems—if it had reviewed 

them—and D-Link Corporation to the need for significant improvements in their software 

development process, and some of the specific ways in which the vendors were falling short. 

258.

 

 

424 E.g., Proposal for Product and System Security-enhancing Services (D-Link Corporation) (Jan. 1, 2014) 

(DKC0004402-T–15-T, at DKC0004403-T) (“Work Scope” includes “Opaque System [‘Black Box’] Testing 

(including vulnerability scanning, penetration testing, fuzz testing [‘fuzzing’]) testing and inspection) (brackets in 

original). 

425 III/Onward, DIR-855L Device Security Testing Report 1 (Apr. 19, 2013) (DKC1896734–848, at DKC1896740) 

(“Project Scope Description...1.1 Project Briefing...III emulates hacker skill, including vulnerability scan, 

penetration test and fuzzing test[], to evaluate the security level of the target device.”). 

426 E.g., III/Onward, DIR-855L Device Security Testing Report A-1, (Testing Tool List), C-1-14 (Test Results, 

stating vulnerabilities which were tested for and the Test tool used) (Apr. 19, 2013) (DKC1896734–848, at 

DKC1896761, DKC1896765–78); III/Onward, DCS-5020L Device Security Testing Report, Appendix A, A-1 (Oct. 

3, 2014) (DKC0002979) (Testing Tool List). 

427 Ibid. 

428 E.g., III/Onward, DCS-935L Device Security Testing Report 16 (June 26, 2015) (DKC0003222–56, at 

DKC0003237) (“Testers used CSRFTester testing tool.”). CSRFTester is the name of a free OWASP tool, which 

is likely what III/Onward testers were using. OWASP, OWASP CSRFTester Project, 

https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 129 of 165
129 

 

 

259. Because of its tools and techniques, III/Onward has, with limited exception, only been

able to test D-Link Systems’ routers and IP cameras for known vulnerabilities or security issues 

already recognized in the community. Without access to source code and disassembly analyses, 

it would be difficult for III/Onward to identify logic errors, backdoors written into source code, 

or the insecure use of functions or library calls, each of which might lead to serious, but 

preventable future vulnerabilities.430

260. III/Onward appears to have been professional in completing what it was asked to do and

reporting and cataloging results.431 III/Onward’s recommendations have also been reasonably 

competent, but seem often to have been disregarded or downplayed.432 III/Onward’s reports 

includes a summary section with high-level recommendations based on the most critical issues 

revealed.433 In these brief, summary recommendations, the report provides headline advice, such 

as “Filter use input data,” “Encrypt sensitive data,” or “Check System Configuration,” paired 

429 E.g., D-Link Corp. 30(b)(6) Dep. 124:8–126:13. 

430 III/Onward states in its “Test Items Checklist” that it tests for certain CWEs (Common Weakness Enumerations) 

for which it cannot truly test in any meaningful way without examining source code or binaries. E.g., III/Onward, 

DIR-855L Device Security Testing Report B-2–3 (Apr. 19, 2013) (DKC1896734–848, at DKC1896763–64) (“Table 

2: CWE/SANS Top 25 Most Dangerous Software Errors Checklist”). For example, the DIR-855L report states that 

III/Onward tested for “Use of Hard-coded Credentials.” Ibid. at B-2 (DKC1896763). This is misleading. In fact, 

III/Onward would only be able to test the use of specific, known hard-coded credentials. It could not, for example, 

detect the hard-coded backdoor identified by CORE Security in the RTSP protocol, see Section III.E.2.b above, 

without disassembling the software or getting extraordinarily lucky. 

431 E.g., III/Onward, DIR-855L Device Security Testing Report 1-3 (Apr. 19, 2013) (DKC1896734–848, at 

DKC1896740–43). 

432 See generally Section III.D above, in which I have noted several examples where III/Onward had warned of 

categories of problems that contributed to serious vulnerabilities later uncovered by researchers. 

433 E.g., III/Onward, DIR-855L Device Security Testing Report 17–19 (Apr. 19, 2013) (DKC1896734–848, at 

DKC1896756–58) (“Conclusions and Suggestions”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 130 of 165
130 

with concise explanations and recommendations.434 In my opinion, as discussed above in 

Section III.D, III/Onward’s recommendations were seldom if ever heeded. 

261. To the extent III/Onward’s recommendations as to specific vulnerabilities were followed,

I have reviewed examples suggesting they were followed in only the narrowest sense, addressing 

the particular exploits to which III/Onward found a device to be vulnerable. For example, as 

discussed previously, had D-Link Systems required its vendor Cameo Communications to follow 

III/Onward’s full input-filtering recommendations to address vulnerabilities in the DIR-855L, a 

cross site scripting vulnerability researcher Kyle Lovett found and disclosed a year later would 

likely have been mitigated long before (see Section III.D.1.e above). 

262. There are several other problems with D-Link Systems’ reliance on III/Onward. First, DLink Systems cannot reasonably rely on III/Onward’s testing because it does not have a direct 

business relationship with III/Onward to require and direct testing. III/Onward’s contract is with 

D-Link Corporation.435 In addition, it has not received the reports of III/Onward’s testing done

on D-Link Corporation’s behalf.436 Without receiving the documentation itself, D-Link Systems 

434 Ibid. 

435

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 131 of 165
131 

has been hamstrung from overseeing how comprehensive the testing was, its results, and whether 

it was adequate to provide assurance to D-Link Systems. 

263. In addition, III/Onward’s testing, though useful, could not replace the many basic steps

D-Link Systems was not taking, or requiring its vendors to take, to ensure its devices were not

subject to serious, undiscovered vulnerabilities. The kind of testing III/Onward was asked to do 

is not a panacea, and D-Link Systems was unreasonable in expecting that the most serious risks 

to its devices would come from the kind of vulnerabilities III/Onward was equipped to find, as 

opposed to new flaws discovered in its devices. In that way, III/Onward is another example of

D-Link Systems relying on a wait-and-see approach, assuming any serious problems would be

brought to its attention by the security community (as opposed to first exploited by attackers 

against its customers). 

264. D-Link Systems and D-Link Corporation could have made better use of III/Onward’s

recommendations and findings by considering the broader trends those findings revealed about 

the poor state of D-Link Systems’ vendors’ software development. For example, even relying on 

the limited tools it used to test D-Link Systems devices, I can see that, across the testing reports 

to which I have access, III/Onward flagged more than three dozen instances of unfiltered input 

problems between August 2012 and November 2015 in reports on at least fourteen devices.437

 

But D-Link Systems, and D-Link Corporation, did not take such trends as a warning sign that its 

vendors were not creating secure code. Despite the high number of such flaws identified, DLink Systems did not change its security oversight practices, or require its vendors to do so. 

Perhaps D-Link Systems and D-Link Corporation were not capable of recognizing the 

437 See Appendix C (Materials Considered), Category III (III/Onward Device Security Reports). Input filtering 

recommendations or vulnerabilities were flagged in reports for IP Cameras DCS-930L, 935L, 942L, 960L, 2132L, 

and 2136L, and routers DIR-615, 645, 820L, 826L, 830L, 880L, 890L, and 895L. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 132 of 165
132 

consequence of these pervasive problems in its vendors’ software development; perhaps they 

were capable, but chose not to spend the time and money to abate these risks.438 

265. For the reasons stated above, the work III/Onward performed for D-Link Corporation 

was insufficient to provide the documented assurance D-Link Systems needed that its devices 

were secure from unauthorized access or control. 

3. Short-Lived Bug Bounty Program

266. From sometime in 2011–2012 until mid-2013, D-Link Systems maintained an 

unpublished bug bounty program.439

 

267. Bug bounty programs can be a good addition to a security program, and it was a 

commendable instinct to create one. The emergence and evolution of formal bug bounty 

programs is evidence of the professionalization of white hat hacking—security researchers can 

now make a living looking for vulnerabilities. 

268. However, a bug bounty program is not the first software security process companies 

should implement—not even close. There are many more things a company should focus on 

prior to creating a bug bounty program. William Brown’s instinct to create a bug bounty 

program was commendable. However, D-Link Systems was unlikely to have incentivized 

researchers to find the most pressing security problems in its devices—to the extent security 

438 See Email from Tarik Erdemir to Daniel Hsu et al. and attached D-Link Router Security Test report (Mar. 28, 

2013) (DKC0010751–815, at 10780–81) (Richard Edlin speaking on behalf of D-Link Corporation to staff of 

foreign business unit implies that D-Link Corporation’s agreement to have four models tested, presumably by 

III/Onward, represents “considerable cost” and “demonstrates our commitment to resolving these problems.”). 

439 Brown Investigational Hr’g 268:23–270:6 (July 30, 2014). The exact dates are unclear; Will tified 

that the program ran from October 2011 until March 2013, but he also said it kicked off with a 

, the first evidence of which I’ve seen taking place in June 2012. Email Jason Doyle to William Brown 

and attached signed agreement (June 19, 2012) (DLS0053419–23) Letter from William 

Brown to Jason Doyle (Jan. 25, 2013) (DKS00009097) . The end date he states doesn’t align 

with documents, suggesting it was still going at least in April 2013. Email William Brown to Rick Chiang (Apr. 9, 

2013) (DLS0030587–89, at DLS0030587) (noting unpublished bug bounty program); Email from William Brown to 

Jason Doyle (Aug. 20, 2013) (DLS0021772) (confirming bounty program ended). Regardless, the various sources 

all agree that the bounty program was in place in the 2012–2013 time frame. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 133 of 165
133 

researchers are able to do this, which is not a given—with such a short-lived program that was 

unpublished. If D-Link Systems had published its bug bounty program, it may have attracted 

reports from a wider set of sources, rather than just those seeking to establish a reputation as 

security researchers.440 

269. During its short-lived bug bounty program, D-Link Systems paid bounties to researcher 

Jason Doyle.441 Mr. Doyle sent disclosure reports on IP camera models DCS-932L and 

DCS-5222L, describing vulnerabilities in each that could enable an attacker to retrieve the 

camera’s admin password.442 Apparently, William Brown was sufficiently impressed with Mr. 

Doyle’s work that he commissioned him to perform an evaluation of two routers.443 Mr. Doyle’s 

findings as to those two devices included several findings he deemed high risk, and, as mentioned 

before, led him to note as to the DIR-826L that “the results of this assessment are indicated of a 

system that has not undergone a thorough security evaluation.”444 Although Mr. Doyle was 

limited in his techniques, he nonetheless found some vulnerabilities of note, and saw enough 

problems to conclude D-Link Systems needed to make process improvements; it seems to me that 

this was well-warranted advice at the time. 

270. It is not entirely clear to me why D-Link Systems stopped its bug bounty program, 

although Mr. Brown stated to a security researcher that D-Link Systems “discontinued [the 

440 See Email from William Brown to Angelica Zack (Sept. 3, 2014) (DLS0033352) (stating that D-Link Systems 

ended bounty program because researchers were declining the bounty because it “may reflect badly on their 

integrity”). 

441 Email from Jason Doyle to William Brown and attached signed agreement (June 19, 2012) (DLS0053419–23); 

Letter from William Brown to Jason Doyle (Jan. 25, 2013) (DKS00009097) . 

442 Vulnerability Disclosure—D-Link DCS-932L Network Camera (June 20, 2012) (DKS00001802–06); 

Vulnerability Disclosure – D-Link DCS-5222L Network Camera (Jan. 1, 2013) (DKS00009301–06). 

443 Jason Doyle Evaluation Request (July 25, 2013) (DKS00011858–59). See Jason Doyle, DIR-505L Security 

Evaluation (Apr. 8, 2013) (DLS0030614–24, DLS0030618); Jason Doyle, DIR-826L Security Evaluation (Apr. 16, 

2013) (DLS00038165–76, at DLS00038168–69). 

444 Ibid. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 134 of 165
134 

bounty program] based on feedback from a number of security experts declining because it would 

may [sic] reflect poorly on their integrity.”445 Given D-Link Systems’ repeated statements about 

its commitment to security, maintaining a bug bounty program was among the few affirmative 

steps to which it could point.446 D-Link Systems decision to drop the bug bounty program seems 

to have reverted its posture back to a primarily reactive one. 

4. Other Security Practices

271. In addition to the above, I considered other pre-2017 security practices in forming my

opinion. I have reviewed information about various software security trainings held by D-Link 

Corporation in Taiwan, often apparently conducted by III/Onward, and sign-in sheets for these 

training.447 It is clear that at least some representatives of D-Link Systems’ main vendors 

attended the trainings, which is important given that the vendors are performing the software 

development.448 D-Link Systems employees did not attend the trainings.449 

272. Application security training is an important part of a software security program.

Although much of the content of the training slides I reviewed is in Chinese, I can tell from the 

substantial English content and topics that the content of these training sessions was likely of 

substantial quality, and improving over the presentations dated in subsequent years.450 In 

conjunction with other parts of a software security program, training can help programmers and 

445 Email from William Brown to Angelica Zack (Sept. 3, 2014) (DLS0033352). 

446 See Email William Brown to Rick Chiang (Apr. 9, 2013) (DLS0030587–89, at DLS0030587). 

447 Compilation of Sign-In Sheets for Secure Development Trainings (Sept. 18, 2015–Mar. 29, 2017) 

(DKC1827536–48). E.g., D-Link 資安檢測服務 (Sept. 25, 2015) (DKC1827751–86); 安全軟體開發教育訓練

(Sept. 8, 2016) (DKC0005191–287) (Sept. 8, 2016) (DKC0005191–287); 20170526 Mobile Security (May 25, 

2017) (DKC1827913–79); D-Link-Training-1026 (Oct. 26, 2017) (DKC1827699–750). 

448 Compilation of Sign-In Sheets for Secure Development Trainings (Sept. 18, 2015–Mar. 29, 2017) 

(DKC1827536–48, at DKC1827536). 

449 Ibid. 

450 E.g., 安全軟體開發教育訓練 (Sept. 8, 2016) (DKC0005191–287). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 135 of 165
135 

others understand how to meet the expectations the organization has set. But training needs to be 

conducted in conjunction with other security practices if an organization. In addition, the 

importance of training as part of a software security program has been well-known long before 

the September 2015 date the provided sign-in sheets begin.451 If it is the case that D-Link

Corporation did not conduct or require security training prior to that, it is further evidence of

their minimal security efforts. 

273. I also reviewed documentation, referenced above, of evaluations conducted by Rapid7. DLink Corporation engaged Rapid7 in 2010 to evaluate the mydlink service and the D-Link

Systems IP camera DCS-1130L, but it also seems to have conducted testing on D-Link Systems 

IP camera DCS-930.452 D-Link Systems cited to these reports in its interrogatory responses.453 

As noted previously, in addition to describing specific vulnerabilities, Rapid7 told D-Link 

Corporation and D-Link Systems in January of 2011 that “[d]ue to the degree of these 

vulnerabilities Rapid7 additionally recommends D-Link develop and implement a comprehensive 

Security Development Life cycle program that will integrate secure design principals [sic] into 

the development process.” 454

5. Recent Efforts to Address Security

274. Starting in late 2016, and to a greater extent in 2017, D-Link Systems and D-Link

Corporation appear to have begun efforts on a number of different fronts to improve its secure 

software development practices. 

451 Compilation of Sign-In Sheets for Secure Development Trainings (Sept. 18, 2015–Mar. 29, 2017) 

(DKC1827536–48). 

452 Statement of Work for D-Link (July 13, 2010) (DLS0056583–606) (contract between D-Link Corp. and Rapid7); 

Rapid7, mydlink DCS-1130 Assessment (Jan. 25, 2011) (DLS0056608–659). 

453 D-Link Sys. Answers and Objs. to FTC 1st Set of Interrogs. No. 4. 

454 Rapid7, mydlink DCS-1130L Assessment (Jan. 25, 2011) (DLS0056608–59, at DLS0056611). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 136 of 165
136 

a. SEARCH-LAB Ltd. and Kapil Khot

275. D-Link Systems points to its work with SEARCH-LAB, Ltd. and Kapil Khot as an

affirmative security step it has taken.455 In both cases, these were third-party security researchers 

that approached D-Link Systems with vulnerability disclosures before publicly disclosing them. 

D-Link Systems chose to engage both SEARCH-LAB and Mr. Khot for additional evaluations.

The follow-up work each researcher performed pursuant to their engagement by D-Link Systems 

was recent: SEARCH-LAB provided its evaluation reports in the summer of 2016, and Mr. Khot 

in mid-2017. 

276. SEARCH-LAB contacted D-Link Systems in September 2015 regarding serious

vulnerabilities in the myDlink service.456 Under the norms of responsible disclosure, SEARCHLAB gave D-Link Systems a chance to address problems before it publicly disclosed its report. 

Ibid. It appears that D-Link Systems engaged SEARCH-LAB to investigate its myDlink findings 

further and help address them.457

277. From correspondence, it appears that the publicity surrounding the vulnerabilities

reported by Senrio (see Section III.E.2.c above) spurred D-Link Corporation to ask SEARCHLAB to evaluate two of its IP cameras.458 It appears from reviewing the SEARCH-LAB 

455 D-Link Sys. Answers and Objs. to FTC 5th Set of Interrogs. No. 15 (SEARCH-LAB); D-Link Sys. Answers and

Objs. to FTC 1st Set of Interrogs. No. 2 (SEARCH-LAB and Kapil Khot). 

456 Email William Brown to AJ Wang et al. and attachments (Sept. 21, 2015) (DLS0025073–81) (email attaching 

SEARCH-LAB notice of “Numerous critical security vulnerabilities found in D-Link’s mydlink services”). D-Link 

Systems and/or D-Link Corporation seem to have previously worked with SEARCH-LAB on a disclosure relating to 

categories of devices not listed in Appendix A. SEARCH-LAB, Security Advisory V3.0–Multiple Vulnerabilities in 

D-Link DNS-320, 320L, 327L, and DNR-326 Devices (May 27, 2015), https://www.search-lab.hu/media/DLink_Security_advisory_3_0_public.pdf.

457 Email William Brown to Zoltán Hornák (Nov. 20, 2015) (DLS0036531–41) (negotiating proposal for D-Link 

Systems to pay SEARCH-LAB to address vulnerabilities found in mydlink); Email William Brown to Mellani 

Stainbrook attaching SEARCH-LAB Project Proposals (Jan. 20, 2016) (DLS0036354–68); Email Zoltán Hornák to 

William Brown (Apr. 21, 2016) (DLS0035325–32) (transmitting links to mydlink report). 

458 Email William Brown to Anny Wei (June 10, 2016) (DLS0042005–18, at DLS0042006–07). In this email, Ted 

Kuo of D-Link Systems writes: “[l]ast time we specifically commissioned the Search-Lab to audit the cloud servers 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 137 of 165
137 

documents that were provided to the FTC that such device testing has only been performed as to 

two devices in Appendix A as of the present: the DCS-932L and DCS-5222L.459 William Brown 

testified that there was an ongoing relationship with SEARCH-LAB.460 If that relationship 

involves testing of devices included in Appendix A, I am surprised that there are no further 

evaluation reports for me to review, two years later. 

278. I reviewed the final SEARCH-LAB evaluation reports, which date from July 2016.461

These reports are comprehensive and of high quality. The reports are also devastating in their 

evaluation of these two IP cameras.462 For example, in the DCS-5222L report, the problems 

identified include multiple buffer overflow vulnerabilities, including at least one that could be 

remotely exploitable to crash the device;463 that the firewall was turned on but configured to 

accept all input;464 that the Linux distribution on which the firmware was based contains many 

but not devices. Nevertheless, they managed to find some security issues about our devices from a couple 

accompanied devices.” Ibid. Richard Chen replies that: “PP already asked the vendors to provide the sample for 

Search Lab already.” Ibid. See also Email from Zoltán Hornák to Mac Mac et al. attaching proposed contract, 

quarterly testing proposal (June 24, 2016) (DLS0037403–57). Although no executed contract was provided, 

proposed contracts were, and the testing reports described next seem to imply that D-Link Systems at least began to 

use SEARCH-LAB’s services pursuant to the contract. 

459 SEARCH-LAB, Security evaluation of the D-Link Systems Inc. DCS-5222LB1 Camera (July 8, 2016) 

(DKC0207601–734); SEARCH-LAB, Security evaluation of the D-Link Systems Inc. DCS-932LB1 Camera (July 8, 

2016) (DKC0207735–826); Email from Mac Mac to Albert Chang et al. (July 13, 2016) (DKC0207600) 

(transmitting final reports to D-Link Corp.); SEARCH-LAB, Security evaluation of the D-Link Systems Inc. 

DCS-5222LB1 Camera (Preliminary Report) (July 1, 2016) (DLS0037665–783); SEARCH-LAB, Security 

evaluation of the D-Link Systems Inc. DCS-932LB1 Camera (Preliminary Report) (July 1, 2016) (DLS0037784–

839); Email from Balázs Berkes to Mac Mac (July 1, 2016) (DLS0037657–664) (transmitting preliminary reports). 

460 D-Link Sys. 30(b)(6) Dep. 114:10-116:19 (Apr. 25, 2018). 

461 SEARCH-LAB, Security evaluation of the D-Link Systems Inc. DCS-5222LB1 Camera (July 8, 2016) 

(DKC0207601–734); SEARCH-LAB, Security evaluation of the D-Link Systems Inc. DCS-932LB1 Camera (July 8, 

2016) (DKC0207735–826), 

462 SEARCH-LAB, Security evaluation of the D-Link Systems Inc. DCS-5222LB1 Camera (July 8, 2016) 

(DKC0207601–734, at DKC0207605). 

463 Ibid. at DKC0207667. In an internal response to outstanding issues from SEARCH-LAB’s evaluations, a 

representative of D-Link Systems’ vendor APPRO Tech acknowledge that two of the buffer overflows SEARCHLAB found were caused by failing to limit the string size. Email from Louie Hsu to Albert Chang et al. (July 20, 

2016) (DKC0208484–486, at DKC0208484). 

464 Ibid. at DKC0207671. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 138 of 165
138 

outdated and vulnerable third-party services and applications;465 that the web interface was not 

protected by any CSRF mitigation techniques;466 and that all the Linux processes were running as 

root.467

279. In my experience, a security professional would been have justified in immediately

sounding the alarm upon receipt of these reports; suggesting or demanding the products be 

suspended from production and withdrawn from the stores; and immediately suggesting or 

demanding changes to whatever process had yielded such security-defective devices. Best 

security practice would have been to subject devices to this kind of assessment before any were 

shipped. 

280. SEARCH-LAB’s findings regarding two D-Link Systems IP cameras reinforce my

opinion that many serious, undiscovered vulnerabilities are present in D-Link Systems’ routers 

and IP cameras, due to D-Link Systems’ lacking software development process, and that D-Link 

Systems’ routers and IP cameras have not been secure from unauthorized access or control. 

SEARCH-LAB’s work, like D-Link Corporation’s recent improvements discussed below, is too 

recent to evaluate whether it has resulted in meaningful improvement in the underlying security 

quality of D-Link Systems’ software. It remains to be seen whether D-Link Systems uses 

SEARCH-LAB’s findings to drive improvements on an ongoing basis, rather than just providing 

them to its vendors to minimally patch the specific exploits. In addition, it remains to be seen 

whether D-Link Systems will use SEARCH-LABs in a more systematic fashion, by, for example, 

having them test more key routers or IP cameras. 

465 Ibid. at DKC0207668. 

466 Ibid. at DKC0207669–70. 

. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 139 of 165
139 

281. D-Link Systems also mentions that it contracted with a security researcher named Kapil

Khot of Qualys.468 Based on my review of the correspondence, Mr. Khot seems to have 

contacted D-Link Systems in February 2017 with a security report regarding IP camera 

DCS-933L and related hardware.469 Mr. Brown then asked Mr. Khot to do some follow-up 

retesting to see if mitigations incorporated by the vendors addressed his findings.470 Mr. Khot 

provided a follow-up report pointing out how cross site request forgery protections incorporated 

into D-Link Systems IP cameras in 2016, according to Mr. Brown, could still be circumvented.471 

Mr. Khot was not paid for his work; he received free devices.472 

282. As with D-Link Systems’ work with SEARCH-LAB, I cannot conclude whether these

recent steps have improved the security of D-Link Systems’ devices from unauthorized access or 

control, without evidence that D-Link Systems will do more with Mr. Khot’s findings than feed 

them to its vendors for minimal patching, and trust D-Link Corporation to decide if anything 

more is needed. 

b. Security Incident Management (SIM)

283. As discussed above in Section III.C.4, D-Link Systems lacked an effective mechanism

for tracking the post-release vulnerabilities that were identified in products. At some point in 

2015 or 2016, D-Link Corporation implemented its new system, which D-Link Corporation calls 

468 D-Link Sys. Answers and Objs. to FTC 1st Set of Interrogs. No. 2. 

469

472 D-Link Sys. 30(b)(6) Dep. 121:15–122:24 (Apr. 25, 2018). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 140 of 165
140 

the Security Incident Management or “SIM”.473 The SIM is much closer to an appropriate 

mechanism for tracking vulnerabilities than the incomplete table maintained by Mr. Cline or the 

use of emails.474 

284. D-Link Corporation has stated that it implemented the SIM in March 2015.475 However,

even in mid-2016, some D-Link Systems personnel working on D-Link Systems’ response to a 

security issue affecting its mydlink service had not heard of the SIM.476 Assuming that access to 

the SIM was rolled out to D-Link Systems by no later than 2016, it represents a significant step 

forward in security quality; however, it is still not a sufficient means for D-Link Systems to track 

and ensure security flaws were fixed. Here is why: D-Link Systems relies on D-Link 

Corporation to enter information into the SIM. It does not have the ability to enter information 

into the SIM or open new tickets. Correspondence produced by D-Link Systems shows that in 

some cases, other regions have had to argue with D-Link Corporation about whether tickets 

should be opened in SIM, with D-Link Corporation either delaying in doing so or not doing so at 

all.477 D-Link Systems cannot manage open security issues and be assured of their adequate 

resolution by using a tool for which it is a bystander. 

285. Given the premise, discussed above at Section III.B.2, that D-Link Systems is responsible

for security of the devices sold in the United States, it is, under these circumstances, 

473 D-Link Corp. Answers to FTC 2nd Set of Reqs. for Admis. No. 45 (“SIM was utilized starting from early March 

in 2015.”). 

474 D-Link Product Security Issue Analysis (attached to Oct. 10, 2017 email) (DKC0648113–54, at 115–116) 

(presentation with introduction of SIM). 

475 D-Link Corp. Answers to FTC 2nd Set of Reqs. for Admis. No. 45 (May 18, 2018) (“SIM was utilized starting 

from early March in 2015.”). 

476 Email from Ted Kuo to Richard Chen (June 9, 2016) (DLS0042005–18, at DLS0042007) (“Indeed I’m not aware 

of the existence of the SIM system.”). See also email from William Brown to Ted Kuo (June 10, 2016) 

(DLS0045583–87, at DLS0045583) (“Today SIM is very young.”). 

477 Email from Mary Harrison to Quenton Miao (Mar. 18, 2016) (DLS0038010–92, at DLS0038010–12) (email 

between D-Link Europe staff and D-Link Corporation about why a security issue was not entered into SIM). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 141 of 165
141 

unacceptable for D-Link Systems to not have privileges to enter information into the SIM 

directly. Again, this reflects the fact that D-Link Systems is at the mercy of its parent to track 

and resolve vulnerabilities. That said, this is a positive step, but it is too early to know whether it 

will be effective to manage the resolution of vulnerabilities consistently and reliably.

c. BSIMM

286. D-Link Systems also refers to the implementation of BSIMM by D-Link Corporation.478

The Building Security in Maturity Model (BSIMM, pronounced “Bee Sim”), developed in 2008 

by Gary McGraw, is a tool for measuring the presence and probable efficacy of software 

development measures contributing to security quality.479 Additionally, BSIMM allows a 

company to compare the maturity of its software development processes to other companies in 

the same industry. I have used BSIMM in my capacity as a Chief Information Security Officer, 

and found it useful. In my understanding, it is most effective when repeated year after year to 

measure the impact of incremental improvements. 

287. BSIMM is not a “standard”; BSIMM is not a guide. It does not provide checklists. It

does not supply rules of what to do or not to do. It does not fix problems. Rather, it is a 

measurement tool. Properly used, it can help identify issues with development processes; 

security quality improvement could result thereafter from efforts to improve the processes.

288. Not having seen any reports or measurements provided by D-Link Corporation or D-Link

Systems that would result from a BSIMM evaluation, I cannot offer an opinion as to what 

improvements might have been made in their software development process, and what if any 

478 E.g., D-Link Sys. Answers and Objs. to 4th Set of Interrogs. No. 14. See also D-Link Corp. Answers and Obj. to 

FTC 1st Set of Interrogs. No. 2. 

479 BSIMM, https://www.bsimm.com/; Cigital, Building Security in Maturity Model (BSIMM) Version 7

(DKC1895789–859). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 142 of 165
142 

improvements in the security quality of their products might result. In addition, I cannot 

comment on the accuracy of any comparison BSIMM might offer to other companies, because 

D-Link Systems and D-Link Corporation did not provide the results of any such comparison.

289. Much like with the SIM, D-Link Systems didn’t seem to have anything to do with

BSIMM. Even though D-Link Systems discusses in its Interrogatory responses the 

“implementation of BSIMM,”480 it’s obvious that neither Mr. Brown nor D-Link Systems itself 

have any idea what BSIMM actually is: 

Q What are the requirements of [BSIMM]? 

[Attorney Objection] 

THE WITNESS: [D-Link Systems ] doesn’t—doesn’t—[D-Link Systems] 

—[D-Link Systems ] doesn’t use [BSIMM]. It’s [D-Link Corporation]. And I 

require them to have that—have—again, for me, I feel like I’m testifying to the 

same thing over and over, and I apologize. 

[BSIMM] is—is a [D-Link Corporation] work. And, again, the goal is—

to me is to get quality firmware. So as far as their audits and how they deal with 

[BSIMM], I think it’s a very qualified process, but it’s outside the scope of [DLink Systems] or my job scope. 

BY MR. MORIARTY: 

Q Can you identify one requirement of [BSIMM]? 

[Attorney objection] 

THE WITNESS: So based on my personal knowledge through my normal 

scope of work, when that term came up in conversation, [BSIMM] is a 

guideline—a public guideline. 

So you can go to a place called B-SIM.org [sic] —or I don’t remember the 

URL exactly—and it explains what their—their framework is. That’s from my 

personal knowledge. 

At one point I’ve—I’ve looked at that, but beyond that, I don’t know if I 

can testify for [D-Link Systems ] anything further.481

480 D-Link Sys. Answers and Objs. to FTC’s 4th Set of Interrogs. No. 14. 

481 D-Link Sys. 30(b)(6) Dep. 90:15–91:24 (Apr. 25, 2018). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 143 of 165
143 

290. While BSIMM is a good step, it cannot be reduced to an inchoate shared desire for

“quality firmware,” as Mr. Brown describes it. If D-Link Systems is going to understand the 

quality of security of the products they sell in the United States, it needs to be able to understand 

what measures are being used by BSIMM to evaluate security processes. 

d. 2017 D-Link Corporation Policy Documents

291. D-Link Systems also refers to a series of policy documents produced by D-Link

Corporation.482 I have reviewed these documents (see Appendix C, Category D-Link 

Corporation 2017 Security Policies).483 All the documents state an implementation date around 

March 2017.484 These policies seem very promising. Writing good policies is important, but 

implementing them is more important. D-Link Systems does not possess the documents 

evidencing practices D-Link Corporation is ostensibly imposing on D-Link Systems’ vendors, 

has apparently not reviewed them, and has not described any means to ensure that the practices 

are not dropped tomorrow.485 Given their recent date, the fact that Mr. Brown was unable to 

substantively describe these or any requirements being imposed on D-Link Systems’ vendors, 

and that D-Link Systems is not the party reviewing, creating, and requiring compliance with 

these policies, these recent policies do not affect my opinion as stated above. It is too soon to 

know whether D-Link Corporation will meaningfully enforce these policies, and whether the 

new system articulated in the policies, which D-Link Systems continues to be unable to control, 

482 D-Link Sys. Answers and Objs. to FTC 4th Set of Interrogs. No. 14; D-Link Sys. Answers and Objs. to FTC 5th 

Set of Interrogs. No. 15; D-Link Corp. Answers and Obj. to FTC 1st Set of Interrogs. No. 2 (stating Bates range of 

policy documents). 

483 See Summary List of PSC Management Documents (Nov. 24, 2016) (DKC0005968) (listing policy documents). 

I believe that this set of policies may be what D-Link Systems and D-Link Corporation mean when they speak of 

implementing BSIMM in testimony and written responses. E.g., D-Link Sys. Answers and Objs. to FTC 4th Set of 

Interrogs. No. 14. As discussed above, this understanding is incorrect. 

484 E.g., Vendor’s Source Code Security Testing Process (Mar. 1, 2017) (DKC0006053–57) (stating 

“Announcement” occurred on March 1, 2017). 

485 D-Link Sys. 30(b)(6) Dep. 87:19–88:17; 90:16–91:3 (Apr. 25, 2018). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 144 of 165
144 

will provide sufficient assurance as to the security quality of D-Link Systems devices. In my 

experience as a CISO, I would never rely on another party to decide on the rules and evaluate the 

security testing in the way D-Link Systems does. But in any case, there is not enough evidence 

regarding these late improvements to assess their impact. 

e. Checkmarx Code Scanning

292. D-Link Systems also refers to the use of Checkmarx to scan its software during product

development.486 Checkmarx provides a static code checker.487 Unlike the types of security tests 

that III/Onward did, involving the operation of the devices, static code checkers subject the 

actual source code to analysis. Static code checkers have been in common use since at least 

1995; and many of these tools are free, or distributed as shareware at minimal cost. 

293. It appears that D-Link Corporation that it began requiring vendors to have their source

code scanned by Checkmarx in March 2017.488 That is great, but long overdue. Even simple 

static code checking—available from free, public-domain utilities—could in earlier years have 

flagged for remediation many of the problems that have instead plagued D-Link Systems’ 

devices. 

294. I have reviewed the testing reports D-Link Corporation produced evidencing the results

of Checkmarx testing.489 Many—the “Code review brief reports”—appear to be summaries of 

486 E.g., D-Link Sys. Answers and Objs. to 5th Set of Interrogs. No. 15 (“During the product verification stage,

source code scans (‘white box’ tests by Checkmarx software) are used on the vendors’ source code for new products 

and firmware.”). 

487 See https://www.checkmarx.com/products/static-application-security-testing/. 

488 E.g., D-Link Product Security Issue Analysis (attached to Oct. 10, 2017 email) (DKC0648113–54, at 

DKC0648128) (“All product [firmware] must have source code scan report before release[;] D-Link provide scan 

tool: http://checkmarx.com [;]...Start from 2017/3/31.”); Appro, Code review brief report DCS-7010L_V1.09.00

(Apr. 5, 2017) (DKC1828112); D-Link Sys. 30(b)(6) Dep. 96:1–23 (Apr. 25, 2018) (Checkmarx, BSIMM required 

in February or March of 2017). 

489 See Appendix C, Category Checkmarx Scan Reports. I have reviewed sample reports, that I selected, out of 

approximately 150+ reports identified in Appendix C. There appear to be two kinds: (a) lengthy reports produced 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 145 of 165
145 

the results of Checkmarx scanning meant to demonstrate that a particular firmware passes 

muster, pursuant to D-Link Corporation’s new standards.490 As summary reports, they are 

adequate and comprehensive. 

 

295. I also note that the documents make clear that these are not the initial static code checker

reports on the vendor’s source code—these are the final reports, ostensibly demonstrating that 

the software is of sufficient quality to be shipped. The

 

by Checkmarx listing particular vulnerabilities (e.g., Checkmarx Camera_Series_Web 掃描報告 (Mar. 15 ,2017) 

(DKC1842647–98)), and (b) summary spreadsheets (“Code review brief report[s]”) (e.g., Appro, Code review brief 

report DCS-7010L_V1.09.00 (Apr. 5, 2017) (DKC1828112)). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 146 of 165
146 

296. In addition, D-Link Systems continues to be ignorant of these processes, and does not

demand to review these reports, at least as of the time of Mr. Brown’s deposition on behalf of DLink Systems. 493

G. Many D-Link Routers and IP Cameras Were Not Secure From Unauthorized

Access or Control

1. From December 2013 to September 2015, D-Link Systems Failed to

Take Reasonable Steps to Secure D-Link Routers and IP Cameras

From Unauthorized Access

297. As discussed in Sections III.C, D, E, and F, from December 2013 to September 2015, DLink Systems failed to take reasonable steps to secure its routers and IP cameras from 

unauthorized access, such as through back doors or other means of unauthorized access. These 

failures included lack of input filtering or validation, improper string handling, unnecessary 

system() calls, unnecessary protocols and services, hard-coded and undocumented credentials, 

clear text passwords, code maintenance failures, and private key exposure. These failures 

resulted in the types of flaws identified above in Section III.D. The types of flaws identified 

above in Section III.D caused the types of vulnerabilities identified above in Section III.E. These 

failures would have affected any of the devices being developed, maintained, or sold by D-Link 

Systems during the period of December 2013 to September 2015. 

2. The DIR-615 Was Not Secured From Unauthorized Access or Control

298. The DIR-615 was not secured from unauthorized access or control. Although none of

the documents or testimony I have reviewed have confirmed that the DIR-615 versions sold by 

493 E.g., D-Link Sys. 30(b)(6) Dep. 100:15–23 (William Brown can request Checkmarx reports, he does not appear 

to receive them as a matter of course). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 147 of 165
147 

D-Link Systems494 could have been remotely compromised, the DIR-615 was subject to

vulnerabilities that significantly reduced the security of the device, 495 resulting from code 

development failures including the failure to adequately filter or validate input (see Section 

III.D.1 above) and failure to conduct adequate code maintenance (see Section III.D.7).496 DLink Systems acknowledged that these vulnerabilities included a cross-site scripting 

vulnerability and an open redirect in the ping_response.cgi, and a lack of protection to cross-site 

request forgery attacks in apply.cgi.497 In addition, as discussed in Sections III.C, III.D, and III.F 

above, D-Link Systems failed to develop and maintain its routers, including the DIR-615, to 

secure them from unauthorized access or control. 

3. The DIR-412 Was Not Secured From Unauthorized Access or Control

299. The DIR-412 was not secure from unauthorized access or control. Specifically, the DIR412 suffered from a command injection vulnerability resulting from numerous code development 

failures, as discussed in Sections III.D and III.E.1.c above. Moreover, as discussed in Sections 

III.C, III.D, and III.F above, D-Link Systems failed to develop and maintain its routers, including

the DIR-412, to secure them from unauthorized access or control. 

494 D-Link Sys. 30(b)(6) Dep. 157:1–158:15 (Apr. 25, 2018) (stating hardware revisions sold by D-Link Systems). 

495 DIR-615 Firmware Release Notes (Apr. 14, 2014) (DLS0023364); Osande Malith, D-Link DIR-615 Open 

Redirection and XSS, BLOG OF OSANDA, https://osandamalith.com/2017/01/04/d-link-dir-615-open-redirection-andxss/; Osande Malith, D-Link DIR-615 Open Redirection/Cross Site Scripting, PACKET STORM (Jan. 13, 2017), 

https://packetstormsecurity.com/files/140489/D-Link-DIR-615-Open-Redirection-Cross-Site-Scripting.html; Email 

from Osanda Malith Jayathissa to William Brown attaching proposed public disclosure (Jan. 10, 2017) 

(DLS0023351-54); Email from from Osanda Malith Jayathissa to William Brown attaching proof of concept (Dec. 

19, 2016) (DLS0023365–66). 

496 As discussed in Section III.C.4 above, the effect of these vulnerability was needlessly exacerbated for United 

States customers by D-Link Corporation’s failure to recognize that United States routers were also vulnerable to this 

problem that it patched in 2014. See Email from William Brown to Osanda Malith Jayathissa (Dec. 21, 2016) 

(DLS0023367–68) (noting a fix had been posted on worldwide support site in 2014, but not to the United States 

support site). 

497 DIR-615 Firmware Release Notes (Apr. 14, 2014) (DLS0023364) (“Fixed the exploit... that can be used for 

CSRF attack from LAN side. ... Corrects XSS and Open Redirect on ping_response.cgi.”). 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 148 of 165
148 

4. The DIR-815 Was Not Secured From Unauthorized Access or Control

300. The DIR-815 was not secure from unauthorized access or control. Specifically, the DIR815 suffered from a command injection vulnerability resulting from numerous code development 

failures, as discussed in Sections III.D and III.E.1.c above.498 Moreover, as discussed in Sections 

III.C, III.D, and III.F above, D-Link Systems failed to develop and maintain its routers, including

the DIR-815, to secure them from unauthorized access or control. 

5. The DIR-645 Was Not Secured From Unauthorized Access or Control

301. The DIR-645 was not secure from unauthorized access or control. Specifically, the DIR645 suffered from several command injection vulnerabilities resulting from numerous code 

development failures, as discussed above at Sections III.D.1 and III.E.1.a – e.499 Moreover, as 

discussed in Sections III.C, III.D, and III.F above, D-Link Systems failed to develop and 

maintain its routers, including the DIR-645, to secure them from unauthorized access or control. 

6. Many D-Link IP Cameras Were Not Secure From Unauthorized

Access or Control

302. The Specified IP Cameras—the DCS-2132L, DCS-2210, DCS-2230, DCS-2310L, DCS2332L, DCS-3112, DCS-3710, DCS-3716, DCS-6010L, DCS-6210, DCS-6510, DCS-6511, 

DCS-6513, DCS-6616, DCS-6818, DCS-7010L, DCS-7413, and DCS-7513, and the DCS1100/1100L, DCS-1130/1130L, DCS-3410, DCS-3411, DCS-3430, DCS-5605, and DCS5635—were not secure from unauthorized access or control. Specifically, the Specified IP 

Cameras contained the hard-coded credentials and hidden default credentials vulnerabilities, as 

discussed above in Sections III.D.5, III.E.2.a, and III.E.2.b. Moreover, as discussed above in 

498 Ibid. 

499 Ibid. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 149 of 165
149 

Sections III.C, III.D, III.E.2-3, and III.F, the Specified IP Cameras were developed in a way that 

rendered them not reasonably secure from unauthorized access or control. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 150 of 165
A-1

Appendix A 

List of Routers and IP Cameras 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 151 of 165
A-2

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 152 of 165
A-3

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 153 of 165
B-1

Appendix B 

Experience, Qualifications, Testimony, and Publications 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 154 of 165
B-2

M ARK G . G RAFF , CISSP

New York, NY • (650) 714–3550 • mark@tellagraff.com 

CHIEF INFORMATION SECURITY OFFICER 

& CONSULTANT

Highly accomplished senior executive with more than 40 years of success within IT, cyber security, 

national security, and broadcasting. Programmer and technologist, with 40+ years of ongoing 

development experience. Broad range of specialty fields including information security, risk assessment 

and management, election security, communications, team building and development, security awareness 

and training, software development, and human cognition. Author of several books and host of weekly 

radio show/podcast, “CyberMatters with Mark Graff.” 

CRITICAL LEADERSHIP I NITIATIVES

 Shared cyber security responsibility for protecting America’s nuclear secrets over a nine-year

period, successfully upholding all security measures and combating attempted breaches.

 Protected largest stock market company in the world from cyber attack.

 Founded cyber security collaboration group for World Federation of Exchanges.

 Developed and hosted the first-ever gathering of world stock market security experts, the Defense

of International Markets & Exchanges Symposium, in April 2014.

 Established first-ever radio show focusing on bringing cyber security to the general public.

 Expert witness for State of California on electronic voting system software (2008-2009) and U.S.

Congress (2000, 2012).

 Co-founder of Para-Protect Services, a startup company that was the first to make a profit from

managed security services.

P ROFESSIONAL E XPERIENCE

CEO & Founder, TELLAGRAFF LLC 2015 to Present 

 Established cyber security consulting firm to deliver critical threat and risk evaluation and

remediation, C-level and Board-level training and decision support, expert witness services,

keynote addresses and presentations to technical and non-technical audiences, and technical

product development guidance.

 Established strategic professional relationships/board positions with leading/emerging cyber

security firms.

 Cyber expert for national news outlets and publications including CNN International, CBS News,

Wall Street Journal.

Chief Information Security Officer, NASDAQ QMX 2012 to 2015 

 Managed a $17-20 million budget and led a team of 30 staff to secure worldwide operations and

data against cyber-attacks by foreign countries, criminal organizations, and other hostile entities.

 Directed global security policy, awareness and training, quality in software development, risk

assessments, and application security.

 Created and hosted the first-ever gathering of Information Security Experts from global exchanges

and stock markets, the Defense of International Markets & Exchanges Symposium (April 2014).

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 155 of 165
B-3

Chief Cyber Security Strategist, LAWRENCE LIVERMORE NATIONAL LAB 2008 to 2012 

 Designed and wrote complex software utility for DOE sites to detect Personally Identifiable

Information and other sensitive data on workstations and servers.

 Conducted numerous cyber security research projects and risk analyses, including classified

systems.

 Key advisor to senior executive team on cyber policy, strategy, R&D topics, and potential

investments.

Chief Cyber Security Officer, LAWRENCE LIVERMORE NATIONAL LAB 2003 to 2008 

 Led comprehensive Cyber Security Program across unclassified and classified operations,

overseeing a $23 million budget and 60 employees, including teams for incident response, security

training and awareness, and internal audits.

 Oversaw regulatory compliance with DOE and NNSA standards, while managing the policy and

procedure formulation for internal projects.

 Negotiated compliance schedules and contractual agreements with federal regulatory officials and

agencies.

 Spearheaded laboratory-wide FISMA-mandated certification and accreditation program,

implementing a Safe Harbor approach to move lab forward while meeting rigid compliance

requirements.

Vice President & Chief Scientist, PARA-PROTECT 2000 to 2002 

 Managed technology forecasting, security trend and threat analysis, and led promotional activities

to raise awareness of necessity of secure future for global information infrastructure.

 Assisted in the development and execution of managed security service portfolio, including

incident prevention and response.

Manager, Information Security Deployment, SUN MICROSYSTEMS 1992 to 2000 

 Held a range of increasingly responsible positions from Security Coordinator (1993-1997) to

Network Security Architect (1997-1999) to Manager, Information Security Deployment (1999-

2000)

 Responsible for corporate global programs to measure security risks and deploy countermeasures,

including program and resource development, security awareness training, and lecturing.

 Testified before U.S. Congress, delivered invited lectures to nuclear research laboratories and the

American Academy for the Advancement of Science on information security measurement and risk

assessment techniques.

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 156 of 165
B-4 

P UBLICATIONS

THE OFFICIAL (ISC)2 GUIDE CISSPCBK REFERENCE (5th ed. forthcoming 2018) (ISBN 

9781119423348) (authored chapter on Identification and Access Control) 

KENNETH R. VAN WYK, MARK G. GRAFF, DAN S. PETERS & DIANA L. BURLEY, ENTERPRISE SOFTWARE 

SECURITY: A CONFLUENCE OF DISCIPLINES (Addison-Wesley 2015) 

MATT BISHOP, SEAN PEISERT, CANDICE HOKE, MARK G. GRAFF & DAVID JEFFERSON, E-VOTING AND 

FORENSICS: PRYING OPEN THE BLACK BOX (2009), 

https://www.usenix.org/legacy/event/evtwote09/tech/full_papers/bishop.pdf

CANDICE HOKE, MATT BISHOP, MARK G. GRAFF & DAVID JEFFERSON, RESOLVING THE UNEXPECTED IN 

ELECTIONS: ELECTION OFFICIALS’OPTIONS, CLEVELAND STATE UNIVERSITY, Book 38 (2008), 

https://engagedscholarship.csuohio.edu/cgi/viewcontent.cgi?referer=https://www.google.com/&httpsre

dir=1&article=1000&context=lawfac_reports

MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING: PRINCIPLES & PRACTICES (2003), 

http://securecoding.org 

MARK G. GRAFF, TWENTY YEARS OF INTERNET SECURITY, NEXT TWENTY YEARS NEWSLETTER (2001) 

MARK G. GRAFF, SECURE CODING: THE STATE OF THE PRACTICE (Para-Protect Services, Inc., White 

Paper, 2001) 

MARK G. GRAFF, PEXLIB: AREFERENCE MANUAL, PRENTICE-HALL (1994) 

PEXLIB: ATUTORIAL, PRENTICE-HALL (1994) (Mark G. Graff, Editor) 

MARK G. GRAFF, THE ACCESS CONTROL EXECUTIVE: PSYCHOLOGICAL ELEMENTS OF COMPUTER 

SECURITY, (Monograph 1987) 

C ONGRESSIONAL TESTIMONY

Cyber Threats to Capital Markets and Corporate Accounts: Hearing Before the H. Financial Services 

Committee Subcommittee on Capital Markets 112th Cong. (June 1, 2012) (Testimony of Mark G. 

Graff, Vice President, NASDAQ OMX Group), https://financialservices.house.gov/uploadedfiles/hhrg112-ba16-wstate-mgraff-20120601.pdf. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 157 of 165
B-5 

Next Steps Towards Internet Security: Hearing Before the Joint Economic Committee, 106th Congress 

(Feb. 23, 2000) (statement of Mark G. Graff, Sun Microsystems), 

https://www.jec.senate.gov/archive/Documents/Hearings/graff22300.htm

E XPERT WITNESS TESTIMONY

Bowen v. Election Systems & Software, Inc. (ES&S) (2007-2009) (electronic voting system software) 

(San Francisco Superior Court), http://admin.cdn.sos.ca.gov/press-releases/prior/2007/DB07_086.pdf, 

and http://admin.cdn.sos.ca.gov/press-releases/2009/db09-014.pdf

E DUCATION

UNIVERSITY OF SOUTHERN MISSISSIPPI

Bachelor of Science (BS), Computer Science, 1978 

CERTIFICATION & T RAINING

CISSPCERTIFICATION (2017, 2009) 

FCC Amateur Extra Broadcast License (2009) 

1000+ hours of commercial training 

3000+ hours of technical training 

MILITARY E XPERIENCE

U.S. AIR FORCE 

Computer Technician, 1975-1979 

B OARDS & ADVISORY R OLES

DIGITAL AUTHENTICATION TECHNOLOGIES

Board Member 

 

NETWORK TIME FOUNDATION

Board Member 

BLACKRIDGE TECHNOLOGY

Technical Advisory Board Member 

FORUM OF INCIDENT RESPONSE & SECURITY TEAMS (FIRST)

Former Chair 

LA HONDA-PESCADERO UNIFIED SCHOOL DISTRICT 

Former President & Board Member 

S ELECTED S PEAKING E NGAGEMENTS

“CYBER MATTERS WITH MARK GRAFF” 

Radio Show Host 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 158 of 165
B-6 

NYIT CYBER SECURITY CONFERENCE (2016) 

Keynote Speaker 

ACM CPR SIG (2015) 

Keynote Speaker 

SPLUNK CYBER SECURITY CONFERENCE (2014) 

Keynote Speaker 

YOUTUBE / TELEGRAFF WEBSITE

Sixty-Second Video Essays 

S ELECTED F EATURES AND OPINION PIECES

INC., FORBES, USATODAY, SF CHRONICLE, CSO MAGAZINE, PC MAGAZINE, CNN INTERNATIONAL,

CBS RADIO, THE INTERCEPT

S ELECTED HONORS & AWARDS

INFORMATION SECURITY EXECUTIVE OF THE YEAR FOR NORTHEAST US, 2014 

“KEEP IT SAFE” EDUCATIONAL VIDEO -TELLY AWARD, 2000 

TESTIFIED BEFORE CONGRESS 2000, 2012 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 159 of 165
C-1 

Appendix C 

Materials Considered 

 In addition to the documents cited in my opinion, and my process described in Section 

I.C, above, I considered the following sets of documents provided by D-Link Systems and DLink Corporation, identified by Bates number or range. 

I. D-Lab Testing Reports, Testing Requests, and Test Plans 

DKC1826527 – DKC1827520 

DKC1827606 – DKC1827696 

DKC1861455 – DKC1861464 

DKC1861479 – DKC1861526 

DKC1861542 – DKC1861554 

DKC1895636 – DKC1895637 

DKC1895889 

DKC1896849 – DKC1896933 

DKS00021147 – DKS00027373 

II. Institute for Information Industry/Onward Security Device Security Testing Reports 

DKC0002523 

DKC0002538 – DKC0002584 

DKC0002667 – DKC0002757 

DKC0002792 – DKC0002795 

DKC0002840 – DKC0002919 

DKC0002979 – DKC0003039 

DKC0003040 – DKC0003063 

DKC0003155 – DKC0003221 

DKC0003222 – DKC0003256 

DKC0003323 – DKC0003326 

DKC0003342 – DKC0003386 

DKC0003387 – DKC0003407 

DKC0003491 – DKC0003535 

DKC0003568 – DKC0003593 

DKC0003652 – DKC0003744 

DKC0003804 – DKC0003866 

DKC0003948 – DKC0004024 

DKC0004025 – DKC0004053 

DKC0004054 – DKC0004100 

DKC0004254 – DKC0004331 

DKC0004354 – DKC0004375 

DKC0004376 – DKC0004389 

DKC1896734 – DKC1896848 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 160 of 165
C-2 

III. Checkmarx Scan Reports 

DKC0257716 – DKC0257721 

DKC1635409 – DKC1636176 

DKC1756967 – DKC1756978 

DKC1828078 – DKC1829766 

DKC1842647 – DKC1848963 

DKC1849020 – DKC1861440 

DKC1862088 

DKC1862094 

DKC1862102 

DKC1862104 

DKC1862126 

DKC1862130 

DKC1862284 

DKC1876959 – DKC1876992 

DKC1886119 – DKC1886239 

DKC1886580 – DKC1886803 

DKC1895861 – DKC1895864 

IV. D-Link Systems Security Advisories/Support Announcements 

DLS0059930 – DLS0059933 

DLS0059937 – DLS0059943 

DLS0059960 – DLS0059965 

DLS0059969 – DLS0059971 

DLS0059981 – DLS0059983 

DLS0059990 – DLS0059991 

DLS0059994 

DLS0060008 – DLS0060009 

DLS0060012 – DLS0060015 

DLS0060055 – DLS0060056 

DLS0060161 – DLS0060167 

DLS0060220 – DLS0060221 

DLS0060226 – DLS0060227 

DLS0060248 – DLS0060258 

DLS0060265 – DLS0060267 

DLS0060270 – DLS0060273 

DLS0060280 – DLS0060282 

DLS0060307 – DLS0060309 

DLS0060338 – DLS0060344 

DLS0060368 – DLS0060371 

DLS0060408 – DLS0060412 

DLS0060446 – DLS0060447 

DLS0060456 – DLS0060457 

DLS0060519 – DLS0060522 

DLS0060551 – DLS0060552 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 161 of 165
C-3 

DLS0060559 – DLS0060560 

DLS0060580 – DLS0060581 

DLS0060598 – DLS0060601 

DLS0060776 – DLS0060779 

DLS0060802 – DLS0060803 

DLS0060812 – DLS0060814 

DLS0060844 – DLS0060848 

DLS0060852 – DLS0060854 

DLS0060869 – DLS0060870 

DLS0060873 – DLS0060874 

DLS0060883 – DLS0060884 

V. Third-Party Vendor Test Reports 

DKC0042892 – DKC0042893 

DKC1828204 – DKC1842646 

DKC1862442 

DKC1868608 

DKC1871054 – DKC1872284 

DLS0042893 – DLS0042893 

VI. D-Link Corporation 2017 Security Policies 

DKC0005921 – DKC0005925 

DKC0005968 – DKC0005969 

DKC0005975 – DKC0006071 

DKC0006073 – DKC0006078 

DKC0006080 

DKC0006082 

DKC0006084 – DKC0006090 

DKC0006097 – DKC0006101 

VII. SEARCH-LAB, Ltd. Reports and Correspondence 

DKC0207600 

DKC0207601 – DKC0207734 

DKC0207735 – DKC0207826 

DLS0024446 – DLS0024452 

DLS0036354 – DLS0036368 

DLS0037657 – DLS0037664 

DLS0037665 – DLS0037783 

DLS0037784 – DLS0037839 

DLS0042019 – DLS0042025 

 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 162 of 165
C-4 

VIII. Translated Contracts/Scope of Work 

DKC0004402-T – DKC0004415-T 

DKC0004416-T – DKC0004425-T 

DKC0004426-T – DKC0004430-T 

DKC0004431-T – DKC0004435-T 

DKC0004436-T – DKC0004462-T 

DKC0004463-T – DKC0004468-T 

DKC0004469-T – DKC0004489-T 

DKC0004490-T – DKC0004501-T 

DKC0006140-T – DKC0006154-T 

DKC0006155-T – DKC0006173-T 

DKC0006183-T – DKC0006198-T 

IX. Depositions and Investigational Hearings 

July 29-31, 2014 Investigational Hearing of William Brown 

December 6, 2017 Deposition of AJ Wang 

January 30, 2018 Deposition of Peter Tsai as 30(b)(6) Witness for D-Link Corporation 

January 31, 2018 Deposition of Daniel Hsu 

February 1, 2018 Deposition of Robert Lin 

March 14, 2018 Deposition of William Brown 

April 24, 2018 Deposition of Patrick Cline 

April 25, 2018 Deposition of William Brown as 30(b)(6) Witness for D-Link Systems 

X. Discovery Responses 

Defendant D-Link Systems, Inc.’s Answers and Objections to Plaintiff Federal Trade 

Commission’s First Set of Interrogatories 

Defendant D-Link Systems, Inc.’s Answers and Objections to Plaintiff Federal Trade 

Commission’s Second Set of Interrogatories 

Defendant D-Link Systems, Inc.’s First Amended Answers and Objections to Plaintiff Federal 

Trade Commission’s Third Set of Interrogatories 

Defendant D-Link Systems, Inc.’s Answers and Objections to Plaintiff Federal Trade 

Commission’s Fourth Set of Interrogatories 

Defendant D-Link Systems, Inc.’s Answers and Objections to Plaintiff Federal Trade 

Commission’s Fifth Set of Interrogatories 

Non-party D-Link Corporation’s First Amended Answers and Objections to Plaintiff Federal 

Trade Commission’s First Set of Interrogatories to Non-party D-Link Corporation 

Non-party D-Link Corporation’s Answers and Objections to Plaintiff Federal Trade 

Commission’s Second Set of Interrogatories to Non-party D-Link Corporation 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 163 of 165
C-5 

XI. Other 

DLS0053134 

DLS0008839 

DLS0017452 – DLS0017466 

DLS0022930 – DLS0022932 

DKC0008477–89 

DKC0009490–9503 

Declaration of Jerome Radcliffe, In the Matter of D-Link Systems, Inc., Before the Federal Trade 

Commission (Mar. 16, 2015) 

CVE-2017-14429 Vulnerability Details (Sept. 13, 2017), https://www.cvedetails.com/cve/CVE2017-14429/. 

Kyle Lovett, D-Link DAP-1320 Directory Traversal / Cross Site Scripting, PACKET STORM (Apr. 

17, 2014), https://packetstormsecurity.com/files/126219/dlinkdap1320-traversalxss.txt. 

Michael Messner, D-Link DIR-600, DIR-300 Command Execution / Bypass / Disclosure, 

PACKET STORM (Feb. 5, 2013), https://packetstormsecurity.com/files/120052/D-Link-DIR-600-

DIR-300-Command-Execution-Bypass-Disclosure.html. 

Michael Messner, D-Link DIR-600, DIR-300 Remote Command Execution, PACKET STORM (Apr. 

9, 2013), https://packetstormsecurity.com/files/121152/D-Link-Remote- CommandExecution.html. 

Michael Messner, D-Link DIR-615, CSRF / Disclosure / Command Injection, PACKET STORM

(Feb. 11, 2013), https://packetstormsecurity.com/files/120208/D-Link-DIR-615-Rev-H-CSRFDisclosure-Command-Injection.html. 

Michael Messner, D-Link DIR-645, Authentication Bypass, PACKET STORM (Feb. 28, 2013), 

https://packetstormsecurity.com/files/120591/D-Link-DIR-645-Authentication-Bypass.html. 

Mumbai and Zdenda, DIR-850L (Un)authenticated OS Command Exec, RAPID7 (Mar. 23, 2018), 

https://www.rapid7.com/db/modules/exploit/linux/http/dlink_dir850l_unauth_exec. 

Pierre Kim, Pwning the DLink 850L routers and abusing the MyDlink Cloud protocol, GITHUB 

(Sept. 8, 2017), https://pierrekim.github.io/blog/2017-09-08-dlink-850l-mydlink-cloud-0daysvulnerabilities.html. 

Pierre Kim, et al., D-Link DIR-850L Credential Disclosure, PACKET STORM (Nov. 23, 2017), 

https://packetstormsecurity.com/files/145097/dlink-850-admin-creds-retriever.sh.txt. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 164 of 165
D-1

Appendix D 

Bibliography of Selected Secure Coding Books 

ROSS ANDERSON, SECURITY ENGINEERING: A GUIDE TO BUILDING DEPENDABLE DISTRIBUTED

SYSTEMS (John Wiley & Sons, 2nd ed., 2008), www.cl.cam.ac.uk/~rja14/book.html. 

BRIAN CHESS & JACOB WEST, SECURE PROGRAMMING WITH STATIC ANALYSIS (AddisonWesley, 2007), http://buildingsecurityin.com. 

MARK G. GRAFF & KENNETH R. VAN WYK, SECURE CODING (O’Reilly, 2003), 

http://securecoding.org. 

MICHAEL HOWARD & DAVID LEBLANC, WRITING SECURE CODE (Microsoft Press, 2nd ed., 

2003), http://blogs.msdn.com/michael_howard. 

MICHAEL HOWARD & STEVE LIPNER, THE SECURE DEVELOPMENT LIFECYCLE, (Microsoft Press, 

2006). 

GARY MCGRAW, SOFTWARE SECURITY: BUILDING SECURITY IN (AddisonWesley, 2006), www.swsec.com. 

ROBERT C. SEACORD, SECURE CODING IN C AND C++ (Addison-Wesley, 2nd ed., 2013). 

FRANK SWIDERSKI & WINDOW SNYDER, THREAT MODELING (Microsoft Press, 1st ed., 2004). 

KENNETH R. VAN WYK, MARK G. GRAFF, DAN S. PETERS, & DIANA L. BURLEY, ENTERPRISE

SOFTWARE SECURITY: A CONFLUENCE OF DISCIPLINES (Addison-Wesley, 2015). 

JOHN VIEGA & GARY MCGRAW, BUILDING SECURE SOFTWARE: HOW TO AVOID SECURITY

PROBLEMS THE RIGHT WAY (Addison-Wesley, 2001), www.buildingsecuresoftware.com. 

Case 3:17-cv-00039-JD Document 256-3 Filed 01/04/19 Page 165 of 165