Threat Level: green Handler on Duty: Manuel Humberto Santander Pelaez

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Call for packets udp/137 broadcast

Published: 2014-04-01
Last Updated: 2014-04-01 19:01:22 UTC
by Basil Alawi S.Taher (Version: 1)
2 comment(s)

One of our readers have reported that he has seen a broadcast traffic to udp/137 . He suspected that the traffic cause a denial of service to some of his systems.

If you have seen such traffic and you would like to share some packets we would appreciate that.

 

Keywords:
2 comment(s)

Upgrading Your Android, Elevating My Malware

Published: 2014-04-01
Last Updated: 2014-04-01 15:39:46 UTC
by Basil Alawi S.Taher (Version: 1)
0 comment(s)

A new study[1][2] by Indiana University Bloomington show that updating any Android device can allow an attacker to escalate apps privileges.

The researchers have discovered a new type of vulnerability called Pileup flaws, the vulnerability exist in the Package Management Service.

When a new app installed on old version of Android request a permission for features that don’t exist on that version of Android, however when the user upgrade to the new version, Android keeps all the permissions which mean that they will work in the new version of Android.

 

The researchers have developed a detection service, called SecUp, which deploys a scanner on the user’s device to capture the malicious apps designed to exploit Pileup vulnerability.

Like many other threats, the best mitigation is installing trusted software only.

 

 

 



[1] http://www.informatics.indiana.edu/xw7/papers/privilegescalationthroughandroidupdating.pdf

 

[2] http://www.scmagazine.com/pileup-flaws-enable-privilege-escalation-during-android-updates-researchers-find/article/339854/

Keywords: android mobile pilupe
0 comment(s)

cmd.so Synology Scanner Also Found on Routers

Published: 2014-04-01
Last Updated: 2014-04-01 12:38:31 UTC
by Johannes Ullrich (Version: 1)
1 comment(s)

Yesterday, we talked about a scanner looking for Synology devices that was running on a ARM CPU equipped DVR. Looking at a few other sources of these scans, we did see a couple that didn't originate from similar DVRs. The first guess was that the scan originated from a device that was sitting behind a NAT gateway and wasn't exposed. At this point, it could have been "anything", even a good old infected Windows PC. 

To our surprise, at least in one case it turned out that a binary by the same name, "cmd.so", was running on the NAT router itself. In addition, a second process was running that looked just like the bitcoin miner we saw running in the infected DVRs. Sadly, we were not able to retrieve the binaries, but the processlist looks similar enough to make us believe that this is the same basic binary just compiled for MIPS in this case (the router in question uses a MIPS CPU).

The first image shows the processlist with "cmd.so". In this case, the binary was dropped in /var/run, not /dev, likely due to the different architecture of the router allowing write access to /var/run. The screen show shows a partial output of the "ps" command executed using the routers web based admin interface.

cmd.so in processlist.

Figure 1: Partial Process List with "cmd.so". Click on image for larger version.

 

Figure 2: Partial "ps" output showing the suspected bitcoin miner. In this case, it is called TgW66Q.

The process we think is a copy on minerd uses the same command line parameters as the process we identified as minerd on the DVR.

If you got a router like this, take a look what you find. We do still need a copy of the respective executables to confirm our suspicion. 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

1 comment(s)
Diary Archives