![]() |
Re: Team 548 Einstein Statement
Quote:
D400- My old laptop, has a Broadcom BCM4306 chip that can do WPA2 and B/G/A. D800- My dad's laptop, has an older version of ^ that has the same capabilities. D630- My current laptop. Used to have an Intel 3945 B/G/A, I later upgraded it to an Intel 4965 B/G/N/A. I've seen those models in pits before... I've seen a couple D400s used as driver stations as well. Not every D400 has a dualband chip but the BCM 4306 was very common in the D_00 units (Dell offered it as a free upgrade from the base Intel B chip). IIRC they make USB/PCMCIA/ExpressCard adapters that are dual band that one could hide and later plug in when nobody was looking. |
Re: Team 548 Einstein Statement
Quote:
I ask you to consider why you feel that FRCHQ is unresponsive, and why others do not feel that way. Is it HQ? Is it the others? Or is it you? |
Re: Team 548 Einstein Statement
Larry,
Not all devices that claim full 802.11 wifi can actually do 5 GHz. Most devices, phones especially, are very difficult to determine as to what frequencies they can operate at. |
Re: Team 548 Einstein Statement
As far as I understand the extent of the problems, and as far as I understand the OSI model, the attacks that people are talking about are mostly happening on the network layer, which means that they would have to be resolved on the network layer or above. Since I doubt we will be moving away from 802.11 as the physical layer, and since I doubt we will be messing with MAC addressing and whatnot on the data link layer, this means that issues would have to be resolved at the network layer*.
So, possible solution time: what if FIRST developed custom firmware for the routers that would require a handshake using PKI in addition to the normal procedures for connecting to the field AP? Give every team a SD card or flash drive that contains a signed public-private keypair belonging to the team, as well as the certificate for the field APs. As long as every team's private key remains private, this would ensure that any request to connect to the field by a team would be irrevocably linked to that specific team (so no posing as team XXX trying to disrupt field communications), and any request to connect to the field that is not signed could safely be ignored. MITM should be mitigated in this scenario as well. Denial-of-service or other types of jamming would be possible, but I am assuming they would be more easily detected (because blocking out a user's communication entirely should require more bandwidth than simply impersonating them (I think? Even the FCA attack described did not stop communications on the physical layer, it only made the router ignore a valid connection attempt))*. * I am by no means an expert, I am just spouting off from my understanding of a couple of networking courses in school. |
Re: Team 548 Einstein Statement
Quote:
Yeap there's the response I already predicted in this very topic (look back page or 2 or ask me to quote it). You are simultaneously saying you want help and information then simultaneously being highly selective of who offers that help without a second thought to the point they make or any proof they may offer. I asked weeks ago for merely a description of the process for these additional concerns. None has been provided. I asked again in this topic and none has been provided. I asked why people that send e-mails to the designated address aren't even granted the courtesy of an auto-responder and got no response. I asked people at FIRST and the mere response I got was they were 'looking into it' which is often the response I get when you're not getting a call back. The argument you think counters my point isn't as strong as you'd like to believe. Now what am I supposed to do to refute your commentary Eric? Show you this works publicly? Then what? What's going to be the process then, demand I resign as a mentor, or go after the team I helped start? Here's what I'm going to do for this forum. I'm not posting again in here today. Come what may I don't play this contest to score the most points, so in the end the threat to my priorities is trivial. I do this to help kids and to honor what I do for a living...whether or not we can score the most points has little to do with that. Even the years with the worst robots the kids still come out the winners and that's fine in my score book. |
Re: Team 548 Einstein Statement
Quote:
Please take a step back from your own commentary as well. I am not sure how you came to some of these conclusions from Eric's post. If you two want to argue, carry it to a PM. Sometimes "we're looking into it" has to be taken as good enough. Please avoid drawing random conclusions from what others say on here. But yes, please do take a few days off from this thread. Thank you, Akash |
Re: Team 548 Einstein Statement
David,
The specific phone attack only occurred when a 5 GHz enabled device attempted to connect to a robot. No data transfers took place, no handshaking, no virus like attacks, no special apps or software, no involvement with the FMS. Just the simple operation of attempting to connect to the robot access point. |
Re: Team 548 Einstein Statement
Quote:
This is what I was getting at with my question about institutional knowledge. Either someone at FIRST knew about this hole, and there was an error in communications, or no one found out about this, because there was no reason for someone outside the small FRC team to go an official route. I think there needs to be an official way to report bugs and to encourage people to report this type of exploit. An official FRC award for work in security, where as part of the submission process there would be a demonstration of the exploit discovered, would help these problems come out officially rather than being used maliciously. Instead of trying to fight "hackers" by ignorance and fear of persecution, give them a reason to strengthen the system, not destroy it. |
Re: Team 548 Einstein Statement
Quote:
EricH, While it seems that going to the head ref could have yielded the same result, I think its just as likely that the ref (along with the FTA) may have chosen to hear the student out and see a demonstration. That's completely my opinion, there's no way of knowing what would have happened. |
Re: Team 548 Einstein Statement
Quote:
By the time the student has told the ref, who has told the FTA, you have the following chain: 1) Mentor thinks there may have been a DoS attack. (or other issue) 2) Mentor tells student to tell the ref that there may have been a DoS attack. 3) Student tells ref that there may have been a DoS attack, and the FTA may want to know about it. 4) Ref tells FTA (if the FTA isn't already there listening). That's a minimum of twice removed, on a suspicion. The FTA is going crazy trying to figure out what's going on--and remember, all eyes are on the FTA and his crew (normally they blend into the background, or are supposed to). And, remember, there's an alert that is supposed to catch DoS attacks and it hasn't gone off. If I'm the FTA, I'm likely to go, "Tell your mentor that there wasn't one detected and we're trying to get to the bottom of this" and get back to trying to get to the bottom of the problem. It won't be until the second match at least that I look at it and go "Hey, there might be something to what that kid was saying his mentor thought. Now what team was he on again?" Now, if the student was there and said, "We think someone tampered with a robot during a match by this process, which you might not be able to detect", the FTA would be a whole lot more likely to take action, because a) they now have an idea that their detectors aren't working and b) they have something concrete that they can look for if the logs haven't disappeared yet. But that whole thing involves a mentor explaining the process to a student, which takes time. |
Re: Team 548 Einstein Statement
Quote:
How do I know? My router is a dualband N (two APs) and all 3 laptops can see and connect to my 5ghz Network (set to 5ghz only) just fine. |
Re: Team 548 Einstein Statement
Quote:
Correct me if I misunderstand though, but for 802.11 there is a standard protocol for the router (or other device) to attempt to make the connection. What I was suggesting was modifying this protocol through the router/AP firmware so that the routers/APs that are part of the field network could ignore unauthorized connection attempts. I see so much discussion of problems with the field without much discussion of solutions. That is not to say that people do not have solutions; I think it is easier to focus on what went wrong than on plans for the future (especially when I get the impression that people feel like they do not have a means of influencing change in the organization as a whole). As much as this discussion is veering from the original intent of the thread (the apology), I would rather see it derailed in a constructive fashion focusing on possible solutions, even if those solutions won't necessarily work. |
Re: Team 548 Einstein Statement
Quote:
I do argue with others on this thread that we need a more consistent/accepted/responsive/official/useful/publicized/whathaveyou reporting channel for these sorts of things. So I ask as nicely and respectfully as physically possible towards both parties: how do we do this? |
Re: Team 548 Einstein Statement
Quote:
An 802.11 protocol change that encrypts "management packets" could probably prevent deauthorization flood attacks from succeeding. It would also break a lot of things in the process. Quote:
|
Re: Team 548 Einstein Statement
Quote:
The important thing to remember is that the hardest part of engineering is communication. The value of your ideas are limited to the people you can influence with them. As a volunteer I've been cursed out several times by people trying to influence me with their ideas, and it is turns out that screaming in someone's face it isn't very effective persuasion. By the time they've finished commenting on my heritage and IQ, they could have instead told me their idea and provided supporting information. So, when you "attempt to notify FIRST personnel of [your] belief", please be clear, concise, and civil. |
| All times are GMT -5. The time now is 23:13. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi