The raspberry pi was a great little device a few years ago. Great price point, allowed you to run linux on a very small device that if lost/stolen wouldn't be the end of the world, but it also had very little horse power to do much of anything. Trying to run a GUI on it was painfully slow due to the limited ram and single core proc running at 700 or so.
There have been a few different clones, found 2 I liked last night in searching around for things.
The ODROID-C1- http://ameridroid.com/products/odroid-c1
At $37 bucks hard to beat a quad cpu, 1 GB ram device. It should provide a bit more omf when needed! It is on my wish list to order now since I found it, perhaps today I'll do it.
The BPi-R1 - http://www.bananapi.com/index.php/component/content/article?layout=edit&id=59
Newegg is carrying these at $75 (http://www.newegg.com/Product/Product.aspx?Item=9SIA6DB29F2479). While not as powerful as the ODROID-C1, this one is the kitchen sink, designed specifically for a home router type setup, it has what I've wanted which is a built in switch. I've wanted to build a box to route game traffic through and do some manipulation of the traffic. Not sure if it will be powerful enough, but doing some tcpdumps off this may be an option.
For now I'll stick with the ODROID-C1 I think and just put a USB to ethernet jack on it so I have a 2nd wired port to route stuff through.
Anyway, raspberry pi has made some great things possible. I hope we continue to see higher powered systems (more ram actually) at the sub $50 mark.
Maybe I'll just build a few of these with ARPWatch on them and drop them on some of my closed networks!
Subscribe To
Posts
All Comments
Friday, December 26, 2014
Monday, June 23, 2014
Filters and updates
This was one of those learning moments. You've used a tool for years and it has always worked for you and then all of a sudden you're getting results you aren't expecting. After 30 mins of looking at the code, verifying it works in your primary location but not in the one you've provided to the rest of the world, it finally dawns on you that you've added filters into the program to limit the garbage that you have to process.
This could have been wireshark or a plethora of programs out there, but this was in Satori.
Historically I didn't use the filters much, it was something added at the request of someone else, but more are more at home I've found myself using them. Problem is, I sometimes forget they are turned on. I wanted all of my local 192.168.x.x traffic and any of my local IPv6 traffic (FE80::), but when doing DHCP work, it makes a big difference if you've added that last one in there. Without 0.0.0.0 I wasn't seeing any discover or request packets and for the life of me I couldn't figure out why!
It is always wise to go back to the basics when something all of a sudden stops working. Get things back to a set starting point with no tweaks in place and make sure it is working there, before spending 30 mins digging through code and realizing there is nothing wrong with it and it works fine on that system!
Anyway, all that to lead up to the fact that I've updated web, tcp, webagents, sip and the main satori.exe file (that was one change to make sure Windows 8.1 was in the hard coded part of the program I've never got out to config files yet).
This could have been wireshark or a plethora of programs out there, but this was in Satori.
Historically I didn't use the filters much, it was something added at the request of someone else, but more are more at home I've found myself using them. Problem is, I sometimes forget they are turned on. I wanted all of my local 192.168.x.x traffic and any of my local IPv6 traffic (FE80::), but when doing DHCP work, it makes a big difference if you've added that last one in there. Without 0.0.0.0 I wasn't seeing any discover or request packets and for the life of me I couldn't figure out why!
It is always wise to go back to the basics when something all of a sudden stops working. Get things back to a set starting point with no tweaks in place and make sure it is working there, before spending 30 mins digging through code and realizing there is nothing wrong with it and it works fine on that system!
Anyway, all that to lead up to the fact that I've updated web, tcp, webagents, sip and the main satori.exe file (that was one change to make sure Windows 8.1 was in the hard coded part of the program I've never got out to config files yet).
Thursday, May 29, 2014
DHCP Inform vuln?
I have not verified this, but since most of my work was around DHCP related fingerprinting I found it interesting. I wonder how many other DHCP clients are vuln to this on my test systems.
Anyway, this is a direct repost off of FD from earlier today with only slight modifications for formatting issues:
Anyway, this is a direct repost off of FD from earlier today with only slight modifications for formatting issues:
Title: Microsoft DHCP INFORM Configuration Overwrite
Version: 1.0
Issue type: Protocol Security Flaw
Affected vendor: Microsoft
Release date: 28/05/2014
Discovered by: Laurent Gaffié
Advisory by: Laurent Gaffié
Issue status: Patch not available
==============================
Summary
-------
A vulnerability in Windows DHCP (http://www.ietf.org/rfc/
found on Windows OS versions ranging from Windows 2000 through to Windows server 2003. This
vulnerability allows an attacker to remotely overwrite DNS, Gateway, IP Addresses, routing, WINS server, WPAD, and server configuration with no user interaction. Successful exploitation of this issue will result in a remote network configuration overwrite. Microsoft acknowledged the issue but has indicated no plans to
publish a patch to resolve it.
Technical details
-----------------
Windows 2003/XP machines are sending periodic DHCP INFORM requests and are not checking if the DHCP INFORM answer (DHCP ACK) is from the registered DHCP server/relay-server. Any local system may respond to these requests and overwrite a Windows 2003/XP network configuration by sending a properly formatted unicast reply.
Impact
------
Successful attempts will overwrite DNS, WPAD, WINS, gateway, and/or routing settings on the target system.
Affected products
-----------------
Windows:
- 2000
- XP
- 2003
Proof of concept
----------------
The DHCP.py utility found within the Responder toolkit can be used to exploit this vulnerability.
git clone https://github.com/Spiderlabs/
Solution
--------
Set a DWORD registry key "UseInform" to "0" in each subfolder found in HKLM\SYSTEM\CCS\Services\TCP\
Response timeline
-----------------
* 18/04/2014 - Vendor notified.
* 18/04/2014 - Vendor acknowledges the advisory ( [MSRC]0050886 )
* 18/04/2014 - Suggested to vendor to run Responder on a A-D environment while looking at the DHCP issue for education purposes. Since multiple attempts were made to have them be aware that any A-D environment by default is vulnerable if Responder is running on the subnet. Also, MSRC was
asked what code change made this DHCP INFORM issue different on Windows
Vista than Windows Server 2003.
* 21/04/2014 - MSRC answers with an automated response.
* 08/05/2014 - Request for a reply.
* 14/05/2014 - MSRC reply and refuses to share their view on the code change, however they mention that 'The product team is investigating whether the RFC for a DHCPINFORM message is properly implemented'.
* 14/05/2014 - An email was sent to notify MSRC that no code change was requested, but the logic behind it. Also, MSRC was asked if they were successful with Responder.
* 16/05/2014 - MSRC closes [MSRC]0050886 and doesn't provide any info on if they were successful with Responder in their environment.
References
----------
* Responder: https://github.com/Spiderlabs/
* http://g-laurent.blogspot.ca/
* https://twitter.com/
* http://blog.spiderlabs.com/
Issue type: Protocol Security Flaw
Affected vendor: Microsoft
Release date: 28/05/2014
Discovered by: Laurent Gaffié
Advisory by: Laurent Gaffié
Issue status: Patch not available
==============================
Summary
-------
A vulnerability in Windows DHCP (http://www.ietf.org/rfc/
found on Windows OS versions ranging from Windows 2000 through to Windows server 2003. This
vulnerability allows an attacker to remotely overwrite DNS, Gateway, IP Addresses, routing, WINS server, WPAD, and server configuration with no user interaction. Successful exploitation of this issue will result in a remote network configuration overwrite. Microsoft acknowledged the issue but has indicated no plans to
publish a patch to resolve it.
Technical details
-----------------
Windows 2003/XP machines are sending periodic DHCP INFORM requests and are not checking if the DHCP INFORM answer (DHCP ACK) is from the registered DHCP server/relay-server. Any local system may respond to these requests and overwrite a Windows 2003/XP network configuration by sending a properly formatted unicast reply.
Impact
------
Successful attempts will overwrite DNS, WPAD, WINS, gateway, and/or routing settings on the target system.
Affected products
-----------------
Windows:
- 2000
- XP
- 2003
Proof of concept
----------------
The DHCP.py utility found within the Responder toolkit can be used to exploit this vulnerability.
git clone https://github.com/Spiderlabs/
Solution
--------
Set a DWORD registry key "UseInform" to "0" in each subfolder found in HKLM\SYSTEM\CCS\Services\TCP\
Response timeline
-----------------
* 18/04/2014 - Vendor notified.
* 18/04/2014 - Vendor acknowledges the advisory ( [MSRC]0050886 )
* 18/04/2014 - Suggested to vendor to run Responder on a A-D environment while looking at the DHCP issue for education purposes. Since multiple attempts were made to have them be aware that any A-D environment by default is vulnerable if Responder is running on the subnet. Also, MSRC was
asked what code change made this DHCP INFORM issue different on Windows
Vista than Windows Server 2003.
* 21/04/2014 - MSRC answers with an automated response.
* 08/05/2014 - Request for a reply.
* 14/05/2014 - MSRC reply and refuses to share their view on the code change, however they mention that 'The product team is investigating whether the RFC for a DHCPINFORM message is properly implemented'.
* 14/05/2014 - An email was sent to notify MSRC that no code change was requested, but the logic behind it. Also, MSRC was asked if they were successful with Responder.
* 16/05/2014 - MSRC closes [MSRC]0050886 and doesn't provide any info on if they were successful with Responder in their environment.
References
----------
* Responder: https://github.com/Spiderlabs/
* http://g-laurent.blogspot.ca/
* https://twitter.com/
* http://blog.spiderlabs.com/
Thursday, May 8, 2014
Accelerometer fingerprinting in mobile devices
Interesting research here.
http://www.scmagazineuk.com/phone-tilt-sensors-can-be-used-to-track-you/article/345712/
They say: “An accelerometer fingerprint can serve as an electronic cookie, empowering an adversary to consolidate data per user, and track them over space and time. Alarmingly, such a cookie is hard to erase, unless the accelerometer wears out to the degree that its fingerprint becomes inconsistent. We have not noticed any evidence of this in the nine months of experimentation with 107 accelerometers.”
Original writeup:
http://synrg.csl.illinois.edu/papers/AccelPrint_NDSS14.pdf
---
It would be interesting to know how accurate this really is once you start getting into 1000's and 100,000's of devices. While I can see where you could determine general info about what device and accelerometer is it in, using it to track and individual user may be a bit more problematic. With that said, I haven't read the 16 page right up yet, just the quick news article and with that I'll admit I scanned it.
Interesting approach and cool way to do it!
http://www.scmagazineuk.com/phone-tilt-sensors-can-be-used-to-track-you/article/345712/
They say: “An accelerometer fingerprint can serve as an electronic cookie, empowering an adversary to consolidate data per user, and track them over space and time. Alarmingly, such a cookie is hard to erase, unless the accelerometer wears out to the degree that its fingerprint becomes inconsistent. We have not noticed any evidence of this in the nine months of experimentation with 107 accelerometers.”
Original writeup:
http://synrg.csl.illinois.edu/papers/AccelPrint_NDSS14.pdf
---
It would be interesting to know how accurate this really is once you start getting into 1000's and 100,000's of devices. While I can see where you could determine general info about what device and accelerometer is it in, using it to track and individual user may be a bit more problematic. With that said, I haven't read the 16 page right up yet, just the quick news article and with that I'll admit I scanned it.
Interesting approach and cool way to do it!
Subscribe to:
Posts (Atom)