FYI for anyone running a D-Link router, I've found some rather glaring issues that affect multiple models from 2006 to present:


Full description and POC code available here: http://www.sourcesec.com/2010/01/09/d-link-routers-one-hack-to-own-them-all/

braxivamov:

I can't say for sure what the problem might be with OpenOffice; I assume that you are building your redirector DLL against the same original DLLs on the target system? Have you tried running it in a debugger and seeing where it is crashing? Knowing what function in the DLL is causing problems can help a lot. In the case of user32.dll, it is probably crashing near the entry point, so you could single-step through the code and find the culprit in short order. For gdi32.dll, you'll probably want to go into your debugger (OllyDbg for instance) and set a breakpoint on all calls to gdi32 to see where the problem is.

I didn't know about the loadFrom attribute in the manifest files, and I couldn't dig up much on it. According to Microsoft's Schema (http://msdn.microsoft.com/en-us/library/aa375635(VS.85).aspx), it looks like it would just be another attribute to the file tag in the manifest though, so it would look something like:

<file
    name="user32.dll"
    loadFrom="c:\"
/>

I'll try it out when I get a chance - if you try it first, let us know if/how it works!

Thanks Otter, we had a lot of fun presenting it too.

We'd definitely appreciate some capture files of the 802.11b router, and even the ones that you might have that don't have the factory firmware - we want to try to generate signatures for third party stuff too, like DD-WRT and the like.

Well, we just got back from ChicagoCon yesterday, and we had a blast! The talks were great, the people were great, and we had a really good time.

For those of you who saw our talk, we released a new tool called WiFinger which performs passive access point fingerprinting. We think that this tool can be extremely useful in wireless security, however, a fingerprinting tool is only as good as the signature database that it has, and while we have a handful of signatures right now, we really need more.

So here's where we'd like to ask the community for some help. Obviously, we can't go out and buy every router / access point out there in order to generate signatures for them (as much as we wish we could!), so we're looking for you guys to help us really improve our tool.

If you have an access point that we don't have a signature for, all you have to do in order to contribute to this project is to send us a packet capture file of the AP's beacon packets. That's it; we'll generate signatures for you from there, and we'll definitely give you credit for the submission.

More detailed submission instructions can be found here: http://www.sourcesec.com/2009/05/10/wifinger-signatures-request/ .

Hey, that's what security and discovering exploits is all about: questioning your surroundings. You learned something, and that's what it's all about.

@ethicalhack3r:

"Ive talked to a few people who have just dismissed it as normal behaviour."

I suspect that's because this is normal behavior; what you've described is exactly how HTTP and HTML are supposed to work. Obviously, you can obtain the IP address, referrer, etc from any request that is sent to a Web server that you control; if you tell the Web browser that there's an image that it should display that is located at www.mysite.com, the browser will make a request for that image.

Now, this certainly can be used to gather people's IP addresses, and if an administrator has to approve the post, then the first request for that image will likely be from the administrator's IP address. However, unless there is some identifying information in the referrer, you are unlikely to be able to associate any other IP addresses to specific forum accounts. Using this information, you can target the administrator's IP address directly, at least until his IP changes. Most people have dynamic IP addresses, so their IPs are subject to change at anytime (although in practice, you may keep the same IP for quite some time).

"phpBB3 recongises it as a valid image, which it shouldnt."

Why not? If your PHP script is returning a valid JPEG header, then for all intents and purposes, it is a valid image. Many sites use PHP/ASP/whatever to reference and return images, so software designers can't assume that image links will necessarily have a jpg, gif, or png file extension.

Now, if you give most forum sites a link to an external image, they often will not check to see if it is a valid image. This is reasonable, because when referenced as a HTML image tag, the browser will treat it as an image; if the content returned from the request is not a valid image, then no image will be displayed. However, this is commonly used to attack CSRF vulnerabilities: for example, you tell the Web app that your avatar is located at http://www.mysite.com/admin/delete_forum.php?forum_id=1234, so when an admin views your profile or posts, his browser makes the request to delete the forum. However, that requires an actual vulnerability to be present in the forum that you are targeting.

In all, I would say that this can be a useful technique in some situations, but it is just that, a technique. I would not classify this as a vulnerability by itself. Regardless of what you want to call it, it is well-known and commonly used for other purposes such as the CSRF attack described above.

Looks like a nice tool Erik; UPnP can defiantly be used to help identify hosts and devices on the network, but passive collection tools are very limited when it comes to a full analysis of UPnP. Really all you can glean from the multicast packets are the devices and services that a device supports, and in my experience even this usually isn't a complete list. Active queries and XML parsing is key if you want to really examine a UPnP implementation.

I understand what you're saying, but I'm afraid your logic is flawed; you want to be able to send some un-encrypted token (i.e., the cookie) across an un-secured network, and have that token tied to only your IP address, even though the Web server has no way of knowing for sure what your IP address is. I think the better solution is to simply encrypt the traffic to prevent cookie theft in the first place. However, if you really want to tie it to some dynamic IP address, you could set up a dynamic DNS solution where your computer, no matter where it is or what IP address it has, updates a specific DNS entry whenever its IP address changes. When your web application sees a request come in, it can lookup the DNS entry and see if the IP that the entry resolves to is the same IP that made the request. Of course, you have to ensure that whatever dynamic DNS solution you choose is secure, because otherwise someone could sniff your credentials for that and update your DNS host name with their own IP address (starting to get into the chicken-and-egg problem here). Remember also that this will not protect you against XSS and CSRF attacks.

I think that the best solution to your problem is to follow the guidelines that apollo and myself have already laid out: protect your application against XSS and CSRF, prevent JavaScript from accessing your cookies, and encrypt your traffic. This will help keep third parties from getting your cookie in the first place. Of course, you could also set up an SSH tunnel to your Web server that then connects back to itself on port 80 of the loop back interface - it would probably be slow, but really secure!

Ha! I'll second that...

From your post I am assuming that you are creating a Web application. I will also assume that when you talk about "RAM cookies" you are referring to session cookies. While session cookies will be destroyed when the browser closes, they are sent to a Web server in the exact same manner that any other cookie is sent, so there is no way for you to determine if a cookie has been saved to disk or not.

If you are concerned about the security of your session cookies, keep these points in mind:

• Session cookies are usually captured by an attacker via packet sniffing or XSS attacks. Using SSL and sanitizing user input to prevent XSS will go a long way in ensuring the security of your cookies.
• Cookies can also be marked as http-only, which prevents JavaScript code from accessing them.
• I don't know what language you are writing your application in, but most languages have built in support for session cookies, and will automatically time out the session cookies after a pre-defined period. This way, even if a session cookie is compromised, it will only be useful for a finite period of time.
• If you are concerned about preventing client impersonation, also ensure that you protect your application against CSRF attacks.

Hope this helps.

Full disclosure: I wrote this tool, so I might be a bit biased. 

If you've been following along with GNUCitizen over the past year, you've no doubt heard about their foray into UPNP attacks. I wanted to test some of my own devices against UPNP, but was discouraged by the lack of good UPNP utilities, especially for Linux.

Miranda is a Python-based Universal Plug-N-Play client application designed to discover, query and interact with UPNP devices, particularly Internet Gateway Devices (aka, routers). It can be used to audit UPNP-enabled devices on a network for possible vulnerabilities. Some of its features include:

    * Interactive shell with tab completion and command history
    * Passive and active discovery of UPNP devices
    * Customizable MSEARCH queries (query for specific devices/services)
    * Full control over application settings such as IP addresses, ports and headers
    * Simple enumeration of UPNP devices, services, actions and variables
    * Correlation of input/output state variables with service actions
    * Ability to send actions to UPNP services/devices
    * Ability to save data to file for later analysis and collaboration
    * Command logging

So far I've tested it in Linux (though, being Python, most functionality should be available in other platforms as well) against Linksys, D-Link, Belkin and ActionTec routers with some very interesting results.

More on UPNP hacking can be found at http://www.gnucitizen.org/blog/hacking-with-upnp-universal-plug-and-play and http://www.upnp-hacks.org

You can check out Miranda here: http://www.sourcesec.com/2008/11/07/miranda-upnp-administration-tool/

I can't tell you for sure what is happening, but I would suspect that since your tab character is being corrupted before the strcpy() then it is probably an issue with how the command line argument is being processed. I would try reading the shellcode out of a file or through a socket and see if that fixes the issue. If you can narrow the issue down to a problem with passing the shell code via the command line, then that at least will help narrow down your Google search...

What application/service were the hashes related to? Are these Windows logons, or something else? Some services will use a nonce value combined with the password to produce a unique hash value each time. Or, it could be something completely different; you really need to take a look at how the service in question works, what kind of hashing it uses, and how that hashing is implemented.

http://www.binrev.com/forums/index.php?showtopic=38128
http://www.rohitab.com/discuss/index.php?s=6663bc8bee6ee3e5202f4ed081e74a52&showtopic=31086&pid=10044820&st=0&#entry10044820
http://antionline.com/showthread.php?t=277201

Not much more to add other than what those guys said. Although AltaVista used to have a case-sensitive search, I think they're partnered with Yahoo now and no longer support that feature.

Is there something specific that you are trying to find? Perhaps there is another way of narrowing down your search.

Yahoo mail used to use the exact same method to hash their passwords. Google for a program called Ycrack (dictionary attack tool), it should work for your situation - just substitute your $user_salt string for the challenge string that Yahoo used.

P.S. - If you want to speed up Ycrack, delete the line before compiling it.