8 ms·

That wifi dongle in particular supports packet injection, and supports aircrack-ng for penetration testing.

by matchai 7y ago

thelittleone 7y ago
Indeed and cheap enough to throw away after each project for improved opsec.
- Godel_unicode 7y ago
  Given that you can change the MAC address, how does throwing it away improve opsec...?
  - diminoten 7y ago
    Makes you feel more like an operator, I guess?
  - jascii 7y ago
    It seems good practice not to assume there are no other ways to id/fingerprint a device then by mac address..
    - Godel_unicode 7y ago
      That's actually the opposite of good practice; good practice in security is to base your planning off of facts and research. Throwing away your whole setup after every gig works for Mission: Impossible, and I guess it makes people feel extra-super-ninja, in practice it just perpetuates the endless (and pointless) culture of I-know-something-you-don't. Opsec should be based on reality and threat modeling, not endless rounds of whatabout. Edit: if you (the rhetorical you, not parent specifically) actually know something here, chime in!
      - jascii 7y ago
        That really is the difference between "proven secure" vs "not proven insecure", which would you consider best practice? As far as fingerprinting WiFi devices goes: It is an rf device and all rf devices vary in behaviour due to component tolerances. This shows in such things as spurious emissions, power variations across its transmission spectrum, oscillator drift, etc, etc. These are fairly easy to detect remotely. One example is shown in this paper: https://www.cs.ucr.edu/~zhiyunq/pub/infocom18_wireless_fingerprinting.pdf https://www.cs.ucr.edu/~zhiyunq/pub/infocom18_wireless_finge...
        Godel_unicode 7y ago
        That paper states that the accuracy could be as high as 95%. Apple has sold over a billion iOS devices with WiFi radios in them. I'll let you Google the base-rate fallacy for yourself, and decide if that risk is worth it. Edit: make that over 2 billion Edit: also, "proven secure" is impossible.
        jascii 7y ago
        The paper is only one such method, there are countless and these methods have been in documented use in signal intelligence since at least WW2, combined your accuracy increases. And this is on top of all the other known methods of fingerprinting network devices.. Besides, most of the time you only care whether the same device was used, 95% gives you a lot of certainty. Within propper constraints "proven secure" certainly is possible.
      - scarejunba 7y ago
        I actually recycle my entire person after each pen test attempt to prevent people from cottoning on to each body’s unique tics.
      - nickpsecurity 7y ago
        "That's actually the opposite of good practice" Good security practice is considering all devices as insecure until proven otherwise. Also, mitigating known unknowns where a general problem happens a lot. Devices snooping on you, misleading you, interdiction, hacks on firmwate, etc. Then, you mitigate it in situations where you're unsure of what's going on just in case. So, long as mitigation isn't too costly. I used to buy and get rid of WiFi devices and throwaway computers for that reason. Also, buy them in person at random places with cash. You can even turn it into charity by using FDE, wiping them afterwards, and reselling cheap or donating to others that cant afford full price. Put Ubuntu and Firefox on them to spread some other good things.
        Godel_unicode 7y ago
        > until proven otherwise Well that's impossible (see also the halting problem) so that's pretty clearly not good security practice. Nothing in that says anything about what your threat model is. What risk are you mitigating by doing this? This sounds like the type of "ignore the words and listen to the sound of my voice" security espoused by management and vendor sales people. It sounds like you have a diverting past time, and I wish you the best with that, but this isn't what security is about. Security is about identifying and mitigating specific risks. This goes doubly for operational security. All else is security theater.
        nickpsecurity 7y ago
        "Well that's impossible (see also the halting problem) so that's pretty clearly not good security practice." No it's not. It's been done many times. The halting problem applies to a more general issue than the constrained proofs you need for specific, computer programs. If you were right, tools like RV-Match and Astree Analyzer wouldn't be finding piles of vulnerabilities with mathematical analyses. SPARK Ada code would be as buggy as similar C. Clearly, the analyses are working as intended despite not being perfect. "Security is about identifying and mitigating specific risks. " Computer security, when it was invented in the 1970's, was about proving that a system followed a specific, security policy (the security goals) in all circumstances or failed safe. The policy was usually isolation. There's others, such as guaranteed ordering or forms of type safety. High-assurance security's basic approach was turned into certification criteria applied to production systems as early as 1985 with SCOMP being first certified. NSA spent five years analyzing and trying to hack that thing. Most get about two years with minimal problems. I describe some of the prescribed activities here in my own framework from way back when: https://pastebin.com/y3PufJ0V https://pastebin.com/y3PufJ0V I eventually made a summary of all the assurance techniques I learned from studying these commercial/government products and academic projects: https://pastebin.com/uyNfvqcp https://pastebin.com/uyNfvqcp Note that projects in the 1960's were hitting lower defect rates than projects achieve today. For higher cost-benefit, I identified the combination of Design-by-Contract, Cleanroom (optional), multiple rounds of static analysis by tools with lower false positives, test generators (esp considering the contracts), and fuzzing w/ contracts in as runtime checks (think asserts). That with a memory-safe language should knock out most major problems with minimal effort on developers' part (some annotations). Most of it would run in background or on build servers. https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-by-contract/index.html https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-b... https://web.archive.org/web/20190428052851/http://infohost.nmt.edu/~al/cseet-paper.html https://web.archive.org/web/20190428052851/http://infohost.n... Meanwhile, the state of development for a major OS leads to about 10,000 bugs that even a fuzzer can find: https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf https://events.linuxfoundation.org/wp-content/uploads/2017/1... Modern OS's, routers, basic apps, etc aren't as secure as software designed in 1960's-1980's. People are defining secure as mitigates some specific things hackers are doing (they'll do something else) instead of properties the systems must maintain in all executions on all inputs. We have tools and development methods to do this but they're just not applied in general. Some still do, like INTEGRITY-178B and Muen Separation Kernel. Heck, even IRONSIDES DNS and TrustDNS done in SPARK Ada and Rust respectively. Many tools to achieve higher quality/security are free. Don't pretend like it's just genius mathematicians or Fortune 25 companies that can, say, run a fuzzer after developing in a disciplined way with Ada or Rust.
      - JasonFruit 7y ago
        It's less a culture of I-know-something-you-don't than a culture of someone-may-know-something-I-don't. I don't understand your implication of intellectual delusions of grandeur here; I see it as the opposite.
        Godel_unicode 7y ago
        If you read the other reply to my comment, you'll see that it was in fact a case of I-know-something-you-don't, although in this instance they are in fact wrong about the implications of the thing that they know. The gate keeping that goes on in security (saying that there's a threat but not saying what it is) is extremely frustrating to me.
- dTal 7y ago
  Why would you care about opsec for consensual "penetration testing"?
  - jascii 7y ago
    Your security profile needs to exceed that set for the highest level of clearance you could possibly gain. In practice that means exceeding the highest level of security used in an organisation. You wouldn't want to inadvertently exfiltrate a clients data would you? Aside from that, it is not uncommon for say a department to not be aware they are being pen-tested with consent of their management, and you don't want to trigger counter measures.
    - dTal 7y ago
      I upvoted you because your first sentence is a useful observation, but I'm having a hard time using any of that to justify throwing away a wifi adapter. Even if it were possible to fingerprint the adapter beyond its MAC address, there's no global database of whitehat pentester wifi adapter fingerprints, and such a thing would be worthless anyway. You're not going trigger countermeasures by reusing a wifi adapter. The only threat model that remotely makes sense for that kind of precaution is fear of nation-state level resources trying to identify and catch you. And that's well outside of the realm of "pentesting". (And the idea of accidentally exfiltrating data through a reused wifi adapter is ludicrous)

That wifi dongle in particular supports packet injection, and supports aircrack-ng for penetration testing.

thelittleone 7y ago

Indeed and cheap enough to throw away after each project for improved opsec.

Godel_unicode 7y ago
Given that you can change the MAC address, how does throwing it away improve opsec...?
- diminoten 7y ago
  Makes you feel more like an operator, I guess?
- jascii 7y ago
  It seems good practice not to assume there are no other ways to id/fingerprint a device then by mac address..
  - Godel_unicode 7y ago
    That's actually the opposite of good practice; good practice in security is to base your planning off of facts and research. Throwing away your whole setup after every gig works for Mission: Impossible, and I guess it makes people feel extra-super-ninja, in practice it just perpetuates the endless (and pointless) culture of I-know-something-you-don't. Opsec should be based on reality and threat modeling, not endless rounds of whatabout. Edit: if you (the rhetorical you, not parent specifically) actually know something here, chime in!
    - jascii 7y ago
      That really is the difference between "proven secure" vs "not proven insecure", which would you consider best practice? As far as fingerprinting WiFi devices goes: It is an rf device and all rf devices vary in behaviour due to component tolerances. This shows in such things as spurious emissions, power variations across its transmission spectrum, oscillator drift, etc, etc. These are fairly easy to detect remotely. One example is shown in this paper: https://www.cs.ucr.edu/~zhiyunq/pub/infocom18_wireless_fingerprinting.pdf https://www.cs.ucr.edu/~zhiyunq/pub/infocom18_wireless_finge...
      - Godel_unicode 7y ago
        That paper states that the accuracy could be as high as 95%. Apple has sold over a billion iOS devices with WiFi radios in them. I'll let you Google the base-rate fallacy for yourself, and decide if that risk is worth it. Edit: make that over 2 billion Edit: also, "proven secure" is impossible.
        jascii 7y ago
        The paper is only one such method, there are countless and these methods have been in documented use in signal intelligence since at least WW2, combined your accuracy increases. And this is on top of all the other known methods of fingerprinting network devices.. Besides, most of the time you only care whether the same device was used, 95% gives you a lot of certainty. Within propper constraints "proven secure" certainly is possible.
    - scarejunba 7y ago
      I actually recycle my entire person after each pen test attempt to prevent people from cottoning on to each body’s unique tics.
    - nickpsecurity 7y ago
      "That's actually the opposite of good practice" Good security practice is considering all devices as insecure until proven otherwise. Also, mitigating known unknowns where a general problem happens a lot. Devices snooping on you, misleading you, interdiction, hacks on firmwate, etc. Then, you mitigate it in situations where you're unsure of what's going on just in case. So, long as mitigation isn't too costly. I used to buy and get rid of WiFi devices and throwaway computers for that reason. Also, buy them in person at random places with cash. You can even turn it into charity by using FDE, wiping them afterwards, and reselling cheap or donating to others that cant afford full price. Put Ubuntu and Firefox on them to spread some other good things.
      - Godel_unicode 7y ago
        > until proven otherwise Well that's impossible (see also the halting problem) so that's pretty clearly not good security practice. Nothing in that says anything about what your threat model is. What risk are you mitigating by doing this? This sounds like the type of "ignore the words and listen to the sound of my voice" security espoused by management and vendor sales people. It sounds like you have a diverting past time, and I wish you the best with that, but this isn't what security is about. Security is about identifying and mitigating specific risks. This goes doubly for operational security. All else is security theater.
        nickpsecurity 7y ago
        "Well that's impossible (see also the halting problem) so that's pretty clearly not good security practice." No it's not. It's been done many times. The halting problem applies to a more general issue than the constrained proofs you need for specific, computer programs. If you were right, tools like RV-Match and Astree Analyzer wouldn't be finding piles of vulnerabilities with mathematical analyses. SPARK Ada code would be as buggy as similar C. Clearly, the analyses are working as intended despite not being perfect. "Security is about identifying and mitigating specific risks. " Computer security, when it was invented in the 1970's, was about proving that a system followed a specific, security policy (the security goals) in all circumstances or failed safe. The policy was usually isolation. There's others, such as guaranteed ordering or forms of type safety. High-assurance security's basic approach was turned into certification criteria applied to production systems as early as 1985 with SCOMP being first certified. NSA spent five years analyzing and trying to hack that thing. Most get about two years with minimal problems. I describe some of the prescribed activities here in my own framework from way back when: https://pastebin.com/y3PufJ0V https://pastebin.com/y3PufJ0V I eventually made a summary of all the assurance techniques I learned from studying these commercial/government products and academic projects: https://pastebin.com/uyNfvqcp https://pastebin.com/uyNfvqcp Note that projects in the 1960's were hitting lower defect rates than projects achieve today. For higher cost-benefit, I identified the combination of Design-by-Contract, Cleanroom (optional), multiple rounds of static analysis by tools with lower false positives, test generators (esp considering the contracts), and fuzzing w/ contracts in as runtime checks (think asserts). That with a memory-safe language should knock out most major problems with minimal effort on developers' part (some annotations). Most of it would run in background or on build servers. https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-by-contract/index.html https://www.win.tue.nl/~wstomv/edu/2ip30/references/design-b... https://web.archive.org/web/20190428052851/http://infohost.nmt.edu/~al/cseet-paper.html https://web.archive.org/web/20190428052851/http://infohost.n... Meanwhile, the state of development for a major OS leads to about 10,000 bugs that even a fuzzer can find: https://events.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf https://events.linuxfoundation.org/wp-content/uploads/2017/1... Modern OS's, routers, basic apps, etc aren't as secure as software designed in 1960's-1980's. People are defining secure as mitigates some specific things hackers are doing (they'll do something else) instead of properties the systems must maintain in all executions on all inputs. We have tools and development methods to do this but they're just not applied in general. Some still do, like INTEGRITY-178B and Muen Separation Kernel. Heck, even IRONSIDES DNS and TrustDNS done in SPARK Ada and Rust respectively. Many tools to achieve higher quality/security are free. Don't pretend like it's just genius mathematicians or Fortune 25 companies that can, say, run a fuzzer after developing in a disciplined way with Ada or Rust.
    - JasonFruit 7y ago
      It's less a culture of I-know-something-you-don't than a culture of someone-may-know-something-I-don't. I don't understand your implication of intellectual delusions of grandeur here; I see it as the opposite.
      - Godel_unicode 7y ago
        If you read the other reply to my comment, you'll see that it was in fact a case of I-know-something-you-don't, although in this instance they are in fact wrong about the implications of the thing that they know. The gate keeping that goes on in security (saying that there's a threat but not saying what it is) is extremely frustrating to me.
dTal 7y ago
Why would you care about opsec for consensual "penetration testing"?
- jascii 7y ago
  Your security profile needs to exceed that set for the highest level of clearance you could possibly gain. In practice that means exceeding the highest level of security used in an organisation. You wouldn't want to inadvertently exfiltrate a clients data would you? Aside from that, it is not uncommon for say a department to not be aware they are being pen-tested with consent of their management, and you don't want to trigger counter measures.
  - dTal 7y ago
    I upvoted you because your first sentence is a useful observation, but I'm having a hard time using any of that to justify throwing away a wifi adapter. Even if it were possible to fingerprint the adapter beyond its MAC address, there's no global database of whitehat pentester wifi adapter fingerprints, and such a thing would be worthless anyway. You're not going trigger countermeasures by reusing a wifi adapter. The only threat model that remotely makes sense for that kind of precaution is fear of nation-state level resources trying to identify and catch you. And that's well outside of the realm of "pentesting". (And the idea of accidentally exfiltrating data through a reused wifi adapter is ludicrous)