BF3 Server & Procon Console Showing rcon Pwd

[dapriest]

TehKing, portscanning does nothing other than state whether a tcp/udp port is open or closed. To actually get any information through the events streaming, you would have to still be logged in to receive them. Unless you were sitting in-between the procon server, and the BF3 Server. Which never usually happens, and sitting in-between isn't the same as being on the same segment. Modern day switches don't allow you to see other peoples traffic, as you only see whats destined for your MAC Addr. So you would either have to do a man in the middle attack or else its pretty much impossible to get that information.

What I don't get is how you're seeing it in procon, because if the bf3 server isn't echoing and the nfo admin scripts are using rcon. Then how is procon knowing that the bf3 admin scripts are connecting with a password. Sounds like this might be a bf3 issue on top of Procon.

I don't know much about the events protocol and what is shown when someone is logged in, by default does it echo any passwords?

[Zaeed]

TehKing, we just login normally, with "login.plaintext".

Here lies the problem.. You are connecting to the BF3 server with an unencrypted password, which is a serious security flaw.

Procon is repeating the command because it is being sent down the line by the BF3 server as an event, which is probably a BF3 related issue.

This is not a procon issue directly, we are just repeating the event to layers so they get the information, it is no different to an onKill event. We could filter it out, but that doesn't stop the issue, as any other RCON tool can see it.

The issue is that your server console connects to the server using an unencrypted connection. You should use a hashed login instead.

Please refrain from blaming Procon for issues in the future, unless you have definitive proof that it is in fact Procon at fault.

Regards,
Zaeed
Procon Administrator

[globel]

I don't think anyone is blaming procon. It's just unfortunate that this occures. Seeing in how all rcon tools need a server password to read server events I don't see an issue. The only real issue is the reason we use tools like procon...., to limit server admins, so it makes cents to filter the rcon. U should also stop it from letting admins that are only allowed to kick players the ability to type any rcon command

[.=QUACK=.Major.Pain]

The easiest way to fix it is to allow server owners the ability in Procon to restrict access to the console area. Add a check box to the accounts settings.

[Edge100x]

TehKing, we just login normally, with "login.plaintext".

Here lies the problem.. You are connecting to the BF3 server with an unencrypted password, which is a serious security flaw.

It could be considered a security flaw to not use a hashed password, but it is not a serious one, because it requires a man in the middle to take advantage of -- a random attacker cannot exploit this. FTP works the same way, as do password-protected webpages that are not https. If Procon is parroting BF3 event responses to unauthenticated clients, that would be an example of serious security flaw. It's still not clear to me, based on what's been said, whether it is actually doing this.

Procon is repeating the command because it is being sent down the line by the BF3 server as an event, which is probably a BF3 related issue.

As I indicated previously, if Procon is only showing the rcon password authenticated clients (ones which by definition already know the password), then that's potentially not actually a flaw. If it's showing it to unauthenticated clients (such as anyone who discovers some sort of open Procon port), then that's a major problem. I am going off of what has been said on how Procon works and have not tested it.

This is not a procon issue directly, we are just repeating the event to layers so they get the information, it is no different to an onKill event. We could filter it out, but that doesn't stop the issue, as any other RCON tool can see it.

If Procon is just repeating it internally to authenticated clients, then this is not a major issue. Depending on how your software works, you may still want to filter it out. For instance, if you have multiple access levels, with some clients who have restricted privileges.

This event is indeed different than an onKill event. An onKill event does not broadcast a password.

Please refrain from blaming Procon for issues in the future, unless you have definitive proof that it is in fact Procon at fault.

I was careful to make reasoned statements and to explain what I said as being based on what others were posting. If you are confused, reread my replies.

[Sorry]

I logged into a procon layer connection to where we have procon hosted. I turned on the console log and did a search for our rcon password and it does not show up in the console log.

[MyOdessa]

I had a chance to re-start server and checked ProCon logs, rcon password is hashed there. It is in plain text in NFO Control Panel, Server Control window when server restarts and all var. scroll by.

[TehKing]

First off let me say I have a bachelors in CS so I know what I am talking about(At least I have this piece of paper that says so).

I have successfully port scanned a procon server box, finding an open port, and then listening and waiting for it to announce their password. There is no mim, simply me connecting to a procon server and waiting for the nfo daemon todo something stupid and relay the password.

I still cannot figure out how NFO's server software is the only software that causes the event to appear in the procon logs, I've got my own software that logs into the server to query data and even kick players(Paying members+ Clan members can make room on our servers without needing to ask an admin), yet it does not cause the login.plaintext event to be fired.

[Edge100x]

TehKing, some of us have a CS degree and have also been handling security topics like this in practice for 10 years .

What the NFO daemon did -- using the game's facility for logging in without hashing -- was not particularly "stupid". As I mentioned before, this method would be theoretically vulnerable to snooping from a man in the middle between our daemon and the BF3 server, but in practice, only trusted networks are between the two. BF3's repeating the password to clients over the event channel is much riskier, as client networks are not necessarily trusted or secure, such as in a wireless environment. Further, if Procon BF3 is parroting information to unsecure or unauthenticated clients (those with no knowledge of the rcon password), this is even less secure. Ultimately, in order, we have:

Procon's behavior: Potentially, highly insecure
BF3's behavior: Fairly insecure
NFO daemon behavior: Relatively safe

login.plaintext is not used by all tools, and the command is only needed once if a persistent connection is used. So, the other tools you are testing with may be using login.hashed, and/or only connect when the tool is started. The daemon and control panel here use multiple concurrent login processes for speed, so login operations are common, and speed is also why I chose to use login.plaintext; it was a calculated tradeoff.

In any case, in order to work around the less-secure behavior of BF3 and Procon, I switched everything over to using login.hashed on Friday morning. As a result, this is now a non-issue when it comes to concerns about the admin daemon. However, it would still be advisable for BF3 and Procon to still fix their more serious problems.

[globel]

http://www.phogue.net/forumvb/showthrea ... sues/page2

It looks like this issue is now resolved. Actualy double resolved. NFO no longer uses plain text And procon is going to scrub plaintext. Booo yah



Thanks to both NFO and procon for being so ontop of things and fixing it so fast. Kudos to everyone.

[yingxuy]

This is definitely a mistake, a major security issue, and PROCON, broadcast and other events who cares to listen to such people.

[wyseguy79]

This is now a mute point and has been resolved.



Im kinda excited that I started a topic and it got resolved!