Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    dion
    @User-debbie
    Fuzzing only the json body seems a poor way to fuzz :(
    Joshua Pereyda
    @jtpereyda
    @User-debbie overall, I'd say it depends on what you're targetting. Fuzzing the body will target the JSON parser and the application. Fuzzing the HTTP request will tend to target the HTTP server.
    And sometimes it will pay just to do both. I haven't done a ton of web app fuzzing, but I know one limitation is that boofuzz currently has no primitives targeting JSON. One open area of work would be to create a JSON primitive that accepts a default JSON blob, and then executes mutations on it in a way that makes sense for JSON.
    E.g., trying different data types like null/int/string.
    Another option would be to take a specification (e.g. Swagger) and use that to generate mutations.
    But that all requires a fair chunk of engineering work...
    Maximilian Lindner
    @SR4ven
    That's what I did. Took the spec and defined the protocol in boofuzz. Fuzzing only values, no delimiters or keys. Found a few issues that way, so it can be worth it. However it will always depend on your specific case, how complex your JSON structure is and of course always luck :D
    dion
    @User-debbie
    Thanks ! It helps a lot ! I 'll keep trying to fuzz json body and see if I am lucky enough to find some bugs~
    @jtpereyda making a JSON primitive sounds very good! But It would require a huge amount of work I guess. LOL :D
    Now that I know fuzzing body can actually work, I can keep on working on it.
    Joshua Pereyda
    @jtpereyda
    yes that would be a bunch of work! Probably not worth it for a specific use case; that would really be closer to building a new fuzzing tool
    dion
    @User-debbie
    33803605.png
    When I run my boofuzz scrpit on linux, it reports an error:[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1091)
    . But the same code runs perfectly on Windows. Any ideas?
    Can I set SSL connection not to verify my certificate ?
    Maximilian Lindner
    @SR4ven
    Sounds like the CA is not trusted on your Linux machine. You could try to import the CAs cert. Or disable verification by using sslcontext arg of SSLSocketConnection. Just pass your own SSLContext and set verify_mode accordingly https://docs.python.org/3/library/ssl.html#ssl.SSLContext.verify_mode
    dion
    @User-debbie
    Thanks! I'll try it right away
    dion
    @User-debbie
    I created an unverified context and it worked! Thank you~
    Joshua Pereyda
    @jtpereyda
    Great!
    LakshayKaushik
    @lakshaykaushik
    Hey folks, i am looking for fuzzing my NGAP (N1, N2) interfaces in 5G network. I went through the documentation but i couldnt find support for NGAP protocol. How should i extend boofuzz to include NGAP protocol
    Maximilian Lindner
    @SR4ven
    I guess NGAP is not based on ethernet so you'd have to implement your own boofuzz connection class. Take a look at https://github.com/jtpereyda/boofuzz/blob/master/boofuzz/connections/tcp_socket_connection.py
    We currently don't have a protocol definition for NGAP, but feel free to define one yourself and contribute. There is a sample definition for http here https://github.com/jtpereyda/boofuzz/blob/master/examples/http_simple.py
    Joshua Pereyda
    @jtpereyda
    NGAP would be super cool!
    Katharina Bogad
    @mistressofjellyfish
    hey everyone :) is this still relevant? https://github.com/jtpereyda/boofuzz/tree/master/boofuzz/doc
    At least the SocketConnection file is completely outdated, and the rest of the files don't seem to add anything that isn't available in the "normal" docs already
    Maximilian Lindner
    @SR4ven
    I'd be fine with removing that folder. If there still is any valuable information we should move it to docstrings or the root docs folder
    Katharina Bogad
    @mistressofjellyfish
    is there any reason why Session._callback_current_node() calls the node callback, passing session itself as an argument?
    Katharina Bogad
    @mistressofjellyfish
    AFAICT the intention is to modify the current node data so we can fuzz stuff that needs to pass, say, an authorization check
    but I don't get what part of session is needed there. I'm hesitant to just push session along everywhere because this makes reasoning about what happens where basically impossible
    Katharina Bogad
    @mistressofjellyfish
    Also, I see that there is A LOT of duplicate code between the paths of the Session class that are there for fuzzing vs. message/feature checking
    Katharina Bogad
    @mistressofjellyfish
    ah, there is functools.partial
    so we can have session there without polluting the API. nice.
    Katharina Bogad
    @mistressofjellyfish
    @jtpereyda do you recall what's up with Session.on_failure? looks like it's only ever actually invoked if the target is restarted, which at least makes the name hugely misleading and erroneous at worst. e.g. if the first connection fails, it will eventually fire before any actual fuzz data has been sent
    Katharina Bogad
    @mistressofjellyfish
    I guess its a legacy artifact of somewhere, but now it's functionally equivalent to just using a monitor. Since the name is misleading I'll treat it as a candidate for removal w/o deprecation
    Katharina Bogad
    @mistressofjellyfish
    If I ever get permission to opensource this patch, I am so sorry.
    Katharina Bogad
    @mistressofjellyfish
    so - not counting any compatiblity / shim code, my Session class is now sub 1000 lines long :D
    Joshua Pereyda
    @jtpereyda
    @mistressofjellyfish I wouldn't be surprised if on_failure is off a bit. And yes, I think you would use a monitor now. I agree it could be slated for removal
    Katharina Bogad
    @mistressofjellyfish
    the main motivation would be that Session._restart_target() then can be moved to Target.restart() (which it conceptually belongs anyways)
    I've implemented that now alongside a boatload of other changes because I needed to adapt the fuzzing execution steps in a certain way I can't yet speak about
    if all goes well, I've got a PR ready for you sometime this year
    on that occasion I deprecated a whole load of Session properties that assume that there is only a single target
    not that I am touching that, but I thought that while I'm at it I might prepare boofuzz further to support multiple targets.
    Joshua Pereyda
    @jtpereyda
    Cool! Looking forward to it (hopefully)!
    sarvesh kumar pandey
    @sarvesh_kpandey_twitter

    Hi, I am trying to send a login request only once and then followed by a request that i want to fuzz using same TCP connection (resuse_Target_Connection=True).
    To achieve that i provided "pre_send_callback=login" in Session parameters.

    When i run the code, i see 'function' object is not iterable

    I have the "login" function that will send login request only once even if we call "login" function many times
    sarvesh kumar pandey
    @sarvesh_kpandey_twitter
    The erro is "typeError: 'function' object is not iterable"
    Katharina Bogad
    @mistressofjellyfish
    @sarvesh_kpandey_twitter I presume you mean pre_send_callbacks (notice the s). Also, look at the documentation: https://boofuzz.readthedocs.io/en/stable/source/Session.html#boofuzz.Session
    it takes a list of functions, so in your case Session(...., pre_send_callbacks=[login], ...)
    however it is almost always better to just make a subclass of BaseMonitor and implement the pre_send method in your subclass, then provide this monitor to the Target in question
    Katharina Bogad
    @mistressofjellyfish
    The callbacks do A LOT of non-obvious error processing, have an order and might not get called if a callback further up in the list produces an exception. This can't be changed because legacy code might depend on that, and it has led to confusion in the past. Just so that you are aware.
    AFAICT this behavior also isn't documented (hint, hint @SR4ven, I think we should add a warning to the callback arguments in the session docs and remove their usage from the examples).
    Maximilian Lindner
    @SR4ven
    Sorry I completely missed that message @mistressofjellyfish.
    I like the idea, let's not point users to this legacy feature and mark it as deprecated. Thinking about it, I might have already done the deprecation part somewhere locally a long time ago :D