View Single Post
  #305   Spotlight this post!  
Unread 19-07-2012, 15:54
simpsonboy77 simpsonboy77 is offline
Registered User
AKA: Garrett Dicken
FRC #0041 (RoboWarriors)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 2005
Location: New Jersey
Posts: 87
simpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond reputesimpsonboy77 has a reputation beyond repute
Re: [FRC Blog] Einstein Report Released

KelliV,

I'll try to simplify it as much as possible.

The first tests (1-6) were to test FMS. There could be many issues with the hardware used to run FMS, so this was to test the software FMS uses, hardware, and peripherals. I don't know exactly what they were looking for, but I'm guessing just stability issues. A faulty router could cause drop outs etc. Basically you are looking for something, you don't know exactly what it is, but when you find it you will know. This is the approach for intermittent issues, poke the system until something gives.

The client authentication issue works due to issues in the D-Link DAP-1522 Revision A hardware. This is the wireless bridge that you stick on your robot. This can only manifest itself when paired with the newest firmware of the access point used during competition. No team would have control over this as it is FMS controlled. It is a Cisco 1252. The firmware was changed in week 4 because of an issue where the 1252 would reboot while setting up a new match. I am going to guess that this was done to decrease setup time between matches. However Cisco did not verify the setup in entirety. Had they done this, the issue would have been caught, and likely fixed in firmware.

As for which device connects, it honestly does not matter. What matters is how often the device connects to the network. It is relatively easy to write a program that will run on a laptop to imitate this. What is worse is such a program can be written and run without user intervention, so the person next to you in the stands would not know if you are attacking the field. I will skip what happened at Einstein as that is not as technical, and I am somewhat pressed for time making this post.

De-auth attacks are very effective at causing denial of service. Basically an attacker can spoof the access point, and tell the robot's bridge to reauthenticate and associate. This takes time, and it is trivial to send this packet upwards of 400 times a second at one robot. I may have misinterpreted this, but an attacker can send 400 packets a second at a single robot for 89 seconds and not be detected. Additionally an attacker can trickle deauth packets for the entire match and not be detected. A trickle of 3-7 packets per second will cause some network congestion for that one robot. This is not so much a vulnerability in any hardware or FMS, but more so a vulnerability in 802.11. There are other vulnerabilities such as TKIP session hijacking in TKIP (we use AES), and hole 196 in WPA2 AES. It becomes very difficult to fix these bugs as they are beyond the scope of FMS and FIRST.

The robot specific issues are to show that while it may have been an attack the entire time, these other issues likely contributed to failures.

A high CPU usage could hinder the cRio's ability to send packets to communicate with the driver station. If the cRio is trying to process images, that is time it is not using to communicate with the driver station. If enough data gets buffered and not handled, this will cause drop outs. Think of it as someone reading off several phone numbers and you are writing them down. If the person reads them too fast, you cannot remember all of them. The ones you forget are analogous to dropped packets.

Further down in the report they mention QoS, or quality of service. This will let FMS limit how much bandwidth a robot can use on its own. There is ideally only 300 mbps of bandwidth available amongst 6 robots. Two uncompressed video feeds can eat up much of this. This will prevent robots from starving other robots of bandwidth. It can also be configured to prioritize driver station packets over custom and video packets. This will likely be done off of ports, however I do not know for certain.

As for additionally monitoring, computers can be setup with programs such as wireshark to listen to ALL communication. This will be useful to spot attacks that aren't listed and provides comprehensive logging. Wireless cards can sometimes be put into a mode call promiscuous mode which allows them to listen to data even not directed at them.


I hope that helps, I tried to clarify as much as possible. The report was extremely thorough. I read it first and thought it was missing some important data points, however on a second and third read through, I realized I just missed them >.<

-Garrett
__________________
2013 - Present MAR Control System Adviser and FTAA
2009 - Present Programming an Electrical Mentor Team 41
2005 - 2008 Team 41 Programmer
2008 NYC Regional Winner
Reply With Quote