heise Security did some research on this issue and actually captured the packets with the requests for stock prices. And while they did contain a number, it was certainly not the IMEI of the iphone. For what it is worth: the weather application even transmitted a different imei parameter.
see:
Controversial checks of stock prices with iPhone
bye, ju
I run all tests from a linux machine. Look at the packet dumps. It shows two machines communicating over a network. Look at the IP address given as an argument to ntpdate -- it is a public IP of an ISP that I queried from our company network. Look at the quoted logfile entries. All of them show that the tests have been run from external machines.
In fact I could have gone into lengths discussing this (*).
But it's as simple as this: If I choose "Block all incoming connctions", I expect that it blocks all incomming requests. What is wrong with this approach?
(*) Ok some of the caveats of this new design: The firewall automatically trusts all applications digitally signed by Apple. The problem is, that Apple delivers a digitally signed version of netcat, which provides you with a transparent communication endpoint (signed by Apple, therefor passing the firewall in limited access mode). So all the programmer of an (unsigned!) trojan needs to do is replace his calls to listen() (that would present a dialog asking for permssion) with a suitable combination of fork/exec -- in fact he could even write a wrapper library implementing this. So at the end of the day, your firewall is worthless again.
Note, that I didn't even start to talk about possible vulnerabilities in digitally signed applications yet.
The only assumption in this article is: If your OS vendor supplies you with a firewall and you choose "Block all incoming connections" it should do simply that. If it does not and others can still connect to your system over the internet, there is something wrong with the firewall.
You might want to read the original article WGA notification just doesn't stop by heise Security instead of the gibberish google translation of the german version;-).
Of course some of the stuff is far fetched -- that's where the fun is...
But while I agree that the number of zombies may decline, I don't think the number of attacks will do so. This only means, that an infected PC is "worth" more and the bad guys will put more effort into staying unnoticed and keeping control. We already see that trend in the latest botnet clients like Spamthru: decentralized control infrastructure is beeing built, rootkits are used, rivals are removed and so on...
BTW: I *did* follow the symlinks - as the pppd daemon did, when it was complaining about the permissive access rights. Perhaps this is fixed by now - I sure hope so.
And there are multiple users on the system -- even if they cannot log in: Squid for example runs with uid "nobody" and has/had access rights to files with passwords and secret keys -- w.o. any need. This is unnecessarily increasing risks.
Obviously there is a lack of understanding of basic security concepts.
bye, ju
Just a couple of comments to the Smoothwall answer to my review:
My major concern is not, that somebody other than the administrator
might log into the machine. The major issue of a firewall system is, to
tighten security, not to remove existing security mechanisms like tight
access rigts to sensitive files, shaddow passwords, etc. But that is
exactly what Smoothwall does in direct comparism to any standard linux
distribution.
I'm sorry, if the text doesn't make it clear, that I'm not complaining
about the format of files but about sensitive files with passwords or
secret keys, that are world readable (ie mode 0644). Something like
-rw-r--r--/etc/ipsec.secrets
is a bad thing - period.
I made every effort, to get "printable" response from the developers. I
wrote several E-Mails about the issues to Richard Morrel - who was named as contact person- and I went to the IRC channel of the developers. The only printable
comment to the subject I got there is "This doesn't matter".
Slashdot Mirror
is available on thier UK site: 25C3: Serious security vulnerabilities in DECT wireless telephony
heise Security did some research on this issue and actually captured the packets with the requests for stock prices. And while they did contain a number, it was certainly not the IMEI of the iphone. For what it is worth: the weather application even transmitted a different imei parameter. see: Controversial checks of stock prices with iPhone bye, ju
Yes you are missing something.
I run all tests from a linux machine. Look at the packet dumps. It shows two machines communicating over a network.
Look at the IP address given as an argument to ntpdate -- it is a public IP of an ISP that I queried from our company network.
Look at the quoted logfile entries. All of them show that the tests have been run from external machines.
bye, ju
This guy missed to run with "sudo" -- so lsof has not sufficient rights to query.
Do a
sudo lsof -iUDP
and you will see all the services listening on UDP ports.
bye, ju
In fact I could have gone into lengths discussing this (*).
But it's as simple as this: If I choose "Block all incoming connctions", I expect that it blocks all incomming requests.
What is wrong with this approach?
(*) Ok some of the caveats of this new design: The firewall automatically trusts all applications digitally signed by Apple. The problem is, that Apple delivers a digitally signed version of netcat, which provides you with a transparent communication endpoint (signed by Apple, therefor passing the firewall in limited access mode). So all the programmer of an (unsigned!) trojan needs to do is replace his calls to listen() (that would present a dialog asking for permssion) with a suitable combination of fork/exec -- in fact he could even write a wrapper library implementing this. So at the end of the day, your firewall is worthless again.
Note, that I didn't even start to talk about possible vulnerabilities in digitally signed applications yet.
bye, ju
You used "lsof -iUDP" which indeed reveals nothing. ...
Try with "sudo lsof -iUDP"
bye, ju
The only assumption in this article is: If your OS vendor supplies you with a firewall and you choose "Block all incoming connections" it should do simply that. If it does not and others can still connect to your system over the internet, there is something wrong with the firewall.
bye, ju
There must be something wrong. Not even Bonjour is running... You propably have the deactivated services. bye, ju
You might want to read the original article WGA notification just doesn't stop by heise Security instead of the gibberish google translation of the german version ;-).
Of course some of the stuff is far fetched -- that's where the fun is ...
...
;-)
But while I agree that the number of zombies may decline, I don't think the number of attacks will do so. This only means, that an infected PC is "worth" more and the bad guys will put more effort into staying unnoticed and keeping control. We already see that trend in the latest botnet clients like Spamthru: decentralized control infrastructure is beeing built, rootkits are used, rivals are removed and so on
bye, ju
And yes -- I am an editor of heise Security
BTW: I *did* follow the symlinks - as the pppd daemon did, when it was complaining about the permissive access rights. Perhaps this is fixed by now - I sure hope so.
And there are multiple users on the system -- even if they cannot log in: Squid for example runs with uid "nobody" and has/had access rights to files with passwords and secret keys -- w.o. any need. This is unnecessarily increasing risks. Obviously there is a lack of understanding of basic security concepts.
bye, ju
My major concern is not, that somebody other than the administrator might log into the machine. The major issue of a firewall system is, to tighten security, not to remove existing security mechanisms like tight access rigts to sensitive files, shaddow passwords, etc. But that is exactly what Smoothwall does in direct comparism to any standard linux distribution.
I'm sorry, if the text doesn't make it clear, that I'm not complaining about the format of files but about sensitive files with passwords or secret keys, that are world readable (ie mode 0644). Something like
is a bad thing - period.
I made every effort, to get "printable" response from the developers. I wrote several E-Mails about the issues to Richard Morrel - who was named as contact person- and I went to the IRC channel of the developers. The only printable comment to the subject I got there is "This doesn't matter".