Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

twitter.com

Post reply on HN
Print view View original

31–40 of 322 posts

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#31

Post by ezoe »

faitswulff wrote: post #12
StavrosK wrote: post #9

Earlier quoted context omitted.

How? Do you think developers would be so crazy as to add some sort of "--user-agent" option to software like curl that would cause arbitrary strings to be presented as the user agent? Why would somebody write software to do this, just go on the internet and tell lies?

I thought all this security nonsense ended in the 90s when they introduced the IS-MALICIOUS-REQUEST header. It must be, because I haven't seen any web traffic declaring itself malicious since then.

I believe most devices implemented now 11 years old RFC 3514. So evil packets and non-evil packets can be easily distinguished.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#32

Post by StavrosK »

stevefan1999 wrote: post #17
stavros wrote: post #3

I don't see what the fuss is about. This is an effective mitigation, given that software can't just arbitrarily lie about its user agent.

This is quite funny

I am not laughing one bit let me tell you. Honesty in user agents is one of the last few defenses we have against hackers running rampant on the internet and turning it into some lawless wasteland where people don't even answer truthfully about their A/S/L.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#33

Post by stavros »

mehrdadn wrote: post #30
MiddleEndian wrote: post #20

User agents shouldn't exist any more. They serve only to help unsuspecting users be fingerprinted.

They help you figure out if a user agent wants a mobile view of a page without Javascript... which is pretty useful.

We don't need user agents for that. There's an easy way to tell whether a visitor wants a cleaner view of a page, without Javascript: Yes.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#34

Post by Jach »

Dylan16807 wrote: post #18
ikeboy wrote: post #7

Source says they also did some input sanitizing along with blocking curl, and they had to make a new PoC to get around that. If I'm reading that right then this isn't really an issue, nothing wrong with defense in depth. Edit: >The update adds several filters to handle single quotes in user input. However, these filters can be evaded by specially crafted inputs. By providing the following string for the certificate's…

The equivalent of a "pls dont hack" sign is not defense in depth. Good to know they at least half fixed the problem, I guess. But that's not enough, and they should be capable of testing this.

The real defense is the attacker needs to access and authenticate with the router's web interface. A more honest patch would be to legitimize the bug as a new feature since it must be too amateur-hour over there to actually address any webshit security issues. "Dear Admin, here's a textarea to run arbitrary commands as root, don't hurt yourself!"

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#36

Post by baggy_trough »

justinjlynn wrote: post #29
baggy_trough wrote: post #25

Earlier quoted context omitted.

Rubbish. They are incredibly useful for debugging.

There are better solutions available than hanging functionality on unreliable vestigial bits and pieces that shouldn't be there anyway which, because others abuse the functionality, you can't trust to be correct for debugging purposes.

That might be true, although you don't list the solutions, but it doesn't refute my point in any case.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#37

Post by Arnavion »

ikeboy wrote: post #7

Source says they also did some input sanitizing along with blocking curl, and they had to make a new PoC to get around that. If I'm reading that right then this isn't really an issue, nothing wrong with defense in depth. Edit: >The update adds several filters to handle single quotes in user input. However, these filters can be evaded by specially crafted inputs. By providing the following string for the certificate's…

Speaking of filtering, the diff between the two exploits is:

    -"common_name=a'\$(ping -c 4 192.168.1.2)'b"
    +"common_name='a\$(ping -c 4 192.168.1.2)'b"
and POST instead of GET (and kurl as the UA, of course).

Does their fix specifically check for injection starting with `a'` ? And only works for GET requests? Mind-boggling...

Edit: The new exploit also targets https instead of http. I would've said that surely that would not make a difference, but given what's already happened I'm not sure.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#38

Post by Macross8299 »

stavros wrote: post #3

I don't see what the fuss is about. This is an effective mitigation, given that software can't just arbitrarily lie about its user agent.

Exactly, once they roll out the patch with a boolean OR in the conditional as '$http_user_agent ~* "wget"', it'll pretty much be hack proof!

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#39

Post by mehrdadn »

stavros wrote: post #33
mehrdadn wrote: post #30

Earlier quoted context omitted.

They help you figure out if a user agent wants a mobile view of a page without Javascript... which is pretty useful.

We don't need user agents for that. There's an easy way to tell whether a visitor wants a cleaner view of a page, without Javascript: Yes.

I said "mobile", not "cleaner". Sizes and aspect ratios are different on phones than PCs.

Re: Cisco Fixes RV320/RV325 Vulnerability by Banning “curl” in User-Agent

#40

Post by gruez »

danso wrote: post #8

Of all the security post-mortems I’ve ever wanted to read, it’s sad I’ll probably never get to read this one and its tale of how a team of well-paid comfortable engineers got together and decided this patch was a good idea.

>how a team of well-paid comfortable engineers got together and decided this patch was a good idea

Test-driven development

Post reply on HN