![](bga.png)
kets (≈ 7.4 · 10
370
). Using the heuristics, this amount
of test cases can be reduced to 106,000, which can be
conducted in a reasonable amount of time.
5.2.4 Vulnerability Discoveries
During the execution of the fuzzing tests, we disco-
vered multiple vulnerabilities in each of the DuTs.
On the one hand, there were expected vulnerabilities
which are present in the DuTs because they originate
from weaknesses in the design of PNIO. A prominent
example for this, which is also mentioned in (Pfrang
and Meier, 2017), is a DCP Set request which chan-
ges the name of the PNIO device (nameOfStation).
Since there is limited use in testing if the communica-
tion breaks if the device is renamed to a or b or c, we
limited those test cases.
On the other hand, we discovered vulnerabilities
which are located in the implementation. As an exam-
ple, we will describe a vulnerability in the PNIO-CM
protocol which two DuTs have in common. When
setting up an application relationship, both communi-
cation partners configure the frequency in which they
exchange real time data messages. The respective pa-
rameter is called SendClockFactor and defined in a 2
byte field.
When setting this parameter to the values of 8, 9,
10, 11 or 65524, two DuTs crash and reboot with all
status LEDs flashing shortly. Usually, devices loosing
a connection have to send alarm frames. This does not
work either. The monitoring also confirms that neither
are the devices pingable nor can their web server be
reached. Their digital outputs stop working and the a
CM connect is not possible for half a minute.
In real factories, it is common to fix failures of au-
tomation equipment by power cycling the respective
device. But this vulnerability cannot be fixed by this
means, because the device has lost its device name
which is indispensable in a PNIO communication.
Probably those values cause a memory corruption. In
order to cure this behaviour, one has to reset the de-
vice name using the PNIO-DCP protocol.
6 CONCLUSION
Security testing for IACS is crucial. By detecting vul-
nerabilities and fixing them before they can be abused
by attackers, manufacturers can improve the overall
security of automation systems. The ISuTest frame-
work enables developers to perform security tests on
their IACS automatically. Fuzzing is another, inte-
resting technique to discover vulnerabilities. By ad-
ding this functionality to the ISuTest framework, its
effectiveness in finding vulnerabilities could be im-
proved extraordinarily.
Within this work, first, available fuzzers and fuz-
zing frameworks have been characterized and com-
pared. Then, requirements for effective fuzzing of
IACS, based on existing security testing require-
ments, were developed. By comparing the studied
fuzzers to these requirements, it was shown that none
of the fuzzers fulfilled them completely. As a result, a
new fuzzer was developed and described in this paper,
which can be integrated into the ISuTest framework as
well as meet the requirements for an ideal IACS fuz-
zer.
During the evaluation, it was shown that the new
fuzzer is able to fulfill these requirements. The fuz-
zer was evaluated further by setting up a test bed and
conducting fuzzing test against multiple Profinet de-
vices. During this evaluation, several vulnerabilities
could be discovered. The fact that two devices suf-
fered from the same vulnerability stresses the impor-
tance of security tests not only for developers but also
for integrators of IACS. As shown, the fuzzing frame-
work proved its usefulness successfully.
6.1 Future Work
During this work, it became clear that future work
should focus on the precise description and classifica-
tion of the vulnerabilities. This is important to be able
to clearly classify detected vulnerabilities and report
them to the manufacturer of the device. This includes
formal methods taking into account the special requi-
rements for IACS.
Further work needs also to be put into the defini-
tion of new protocols following the presented fuzzer
definition. As the IACS domain consists of highly
heterogeneous technology, it is important to cover as
many technologies and protocols as possible.
REFERENCES
Amini, P. and Portnoy, A. (2007). Sulley: Fuz-
zing framework. http://www.fuzzing.org/wp-content/
SulleyManual.pdf. [Online; accessed 2016-10-23].
Banks, G., Cova, M., Felmetsger, V., Almeroth, K., Kem-
merer, R., and Vigna, G. (2006). SNOOZE: toward
a stateful NetwOrk prOtocol fuzZEr. In International
Conference on Information Security, pages 343–358.
Springer.
Biondi, P. (2010). Scapy documentation. http://
www.secdev.org/projects/scapy/doc/. [Online; acces-
sed 2017-11-07].
BlackHat (2017). Fuzzing for vulnerabilities.
https://www.blackhat.com/us-17/training/fuzzing-for-
vulnerabilities.html. [Online; accessed 2017-11-07].